Arc Forumnew | comments | leaders | submit | drcode's commentslogin
7 points by drcode 6303 days ago | link | parent | on: Alists vs table

I was confused by this as well, until I figured it out...

He's not talking about about CONTENT sharing a tail- He's talking about two association lists sharing their ENTIRE STRUCTURE...

Let's say you have a database made of key-value pairs and then need to fork it. The fork only contains one difference- One of the keys has to have a different value.

If the database is in a hash table, you're gonna have to clone the entire existing hash table. (They could share content, but the table, itself, needs to be a clone)

If the database is in an assoc list, the fork with the changed key can just have an extra pair for the new key, but then it can "borrow" the entire rest of the data from the other database. So virtually the entire database is shared between the two forks.

-----

3 points by almkglor 6303 days ago | link

Or use this instead: http://arclanguage.com/item?id=7365

-----

1 point by rincewind 6303 days ago | link

the lookup time in alists is O(n). What about proto-tables? Is the key hashed again for lookup in every prototype?

-----

1 point by almkglor 6302 days ago | link

O(M) where M is the depth of the find, or the nested prototype depth if it's not found.

Yes, the key is rehashed.

But really, the point is that proto-tables are quite a bit easier to use: you still retain the table lookup syntax tb.key

-----

2 points by drcode 6304 days ago | link | parent | on: Improve this function?

I don't know if I'd actually write something like that in a real program... not because of performance (which isn't good, but merely by a constant factor, so it's not an issue IMHO) but because the errsafe could hide other errors...

that said, the performance, in theory, might actually be better in some cases: lists (but not atoms) will be processed with one less condition.

-----


First of all, this is a nice piece of work, rincewind- I'm going to have to think a while to decide on the merits of this approach for my personal use. I like the fiendish use of 'zap :-)

FYI- If any of you are confused by the extra 2 in rincewinds code, it is NOT one of the numbers to be added. The currying code just requires it because of the impedance mismatch between variable arguments and currying. The Haskell core doesn't have variable argument support, so this is not an issue in Haskell.

Keep in mind that "On Lisp" covers currying, whereas arc currently does not. I assume this is because pg is still trying to decide on a currying approach, whether it will be implicit currying, syntax-based currying, or function-based currying.

Here's an awesome variant based on your approach I'm probably going to try and implement soon, now that I've thought of it- Have a number in the function position (currently an error) initiate currying!

For example:

  > (2 +)
  #<procedure>
The two here, as in rincewind's code, means that the curried version of '+ should resolve to the result after two parameters are passed in.

  > ((2 +) 7)
  #<procedure>

  > (((2 +) 7) 5)
  12

  > (map ((2 +) 7) '(1 2 3))
  (8 9 10)

  > (map (2.+ 7) '(1 2 3))
  (8 9 10)

  (these next ones assume my mods to the intrasymbol syntax are in place http://arclanguage.org/item?id=7644)

  > (map 2.+.7 '(1 2 3))
  (8 9 10)

  (for those of you wondering why the "2" is necessary)

  > (map 3.+.7 '(1 2 3))
  (#<procedure> #<procedure> #<procedure>)

  > (map [_ 100] (map 3.+.7 '(1 2 3)))
  (108 109 110)
Note that the "integers in function position" concept could also work with implicit currying- In that case, "2.+" would simply convert '+ into the dual arity version of '+. The examples would stay the same- However, in that case the integer could of course be ommited for fixed arity functions.

-----

7 points by drcode 6305 days ago | link | parent | on: Improve this function?

  (def ravg (x)
    (or (errsafe:avg:map ravg x) x))

-----


In Lisp, function parameters are always evaluated. However, many commands in Lisp are not true "functions", but instead special forms or macros.

You probably mean to ask one of two other questions:

Q: How do I pass a literal list into a function?

A: By quoting it (This is probably not what you're trying to achieve though)

   (myfun '(functionthatreturnsalist xint))
Q: How do I write a command that can perform manipulations on parameters before evaluating them?

A: You write a macro, not a function. (See the pg arc tutorial for examples)

-----


thanks for posting that

-----

3 points by drcode 6309 days ago | link | parent | on: Just a thought

It's an interesting idea, but I'm not sure your use of ":" fits in well with the current concept of colon-based composition.

I would like to see this issue approached a little differently. I think we should:

  1. Make "." and "!" work in a nested fashion (as I implemented in http://arclanguage.org/item?id=7644)
  2. Allow the reader to treat a parenthesized item as an item that supports intrasymbol syntax.
Then, you could write the following to resolve the same way as your example:

  '(a (b c)).1.0
I'll probably try implementing something that can do this sooner or later...

-----

1 point by almkglor 6308 days ago | link

Alternatively, we could define compose as being:

  (= compose
     (reducer
       (fn () (err "compose requires at least one argument"))
       (fn (e) e)
       (fn (a b) (<base>compose a b))))

  (def reducer (f0 f1 f2)
    (fn rest
      (if
        (no rest)
          (f0)
        (no:cdr rest)
          (f1:car rest)
          ((afn (acc l)
             (if l
                 (self (f2 acc (car l)) (cdr l))
                 acc))
           (f2 (car rest) (cadr rest)) (cddr rest)))))
(as I proposed here: http://snapvm.blogspot.com/2008/08/base-functions.html)

Then we can redefine <base>compose as:

  (defm <base>compose ((t a int) (t b int))
    (annotate 'composed-int
      (cons a b)))
  (defm <base>compose ((t a composed-int) (t b int))
    (annotate 'composed-int
      (cons a b)))
Then we can redefine the call* table as an overloading of the <base>call function:

  (defm <base>call ((t l cons) (t v composed-int))
    (let (first second) (rep v)
      ((l first) second)))
> 2. Allow the reader to treat a parenthesized item as an item that supports intrasymbol syntax.

This is probably going to conflict with (a . d) format

-----


Could be you don't have unix permissions on port 80. I think it's common on Unices for non root users to have limited access to low numbered ports. Maybe try running mzscheme with sudo?

-----

1 point by rincewind 6309 days ago | link

I think this is the problem.

But running your webserver as root is a huge security risk. If your app is ever exploited, your whole system will be compromised.

try this instead and run your server on port 8080 http://en.wikipedia.org/wiki/Iptables#Redirection_example

-----

1 point by drcode 6309 days ago | link

I agree it's a security risk- Trying "sudo" would be a way to diagnose the problem but not a permanent solution.

-----


I like that idea. If I ever get around to writing something like this I may do it that way.

-----

2 points by drcode 6316 days ago | link | parent | on: Proposed new axiom: symeval

not a bad idea, but it is a limited solution to the problem, since it won't prevent you from creating a new global 'cplx-fun. Plus, it places code dealing with a crosscutting concern right inside the macro. That feels grungy to me.

If I think about the problem my preferred solution would be a function called 'lock-name. Right after defining 'cplx-fun you would call:

  (lock-name 'cplx-fun)
Then, whenever this name is redefined, whether locally or globally, it would give a warning when the code is run. There would also be an 'unlock-name function for supressing the warning. This way, you could write macros without worrying about this issue but still had a way to guard against it.

Of course, I might be missing part of the problem or my solution may have its own problems that I don't see right now.

Good luck on your multiprocess library BTW- I think it could be a useful tool. I may look into it sometime soon, if it can be adapted to work with the base arc2.tar.

-----

2 points by almkglor 6316 days ago | link

err, it's not a library, it's a full implementation of Arc.

I'll probably also include some method of locking the global (and only the global) but only with a lot of big warning signs around the locking function, saying that this should be used only if efficiency is a real concern. Also, my intended lock is a true lock: no redefinition of the <edit>global</edit> at all.

Also, ssyntax could potentially help with the apparently long symeval!foo form; say: <>foo maybe?

-----

More