Arc Forumnew | comments | leaders | submit | rain1's commentslogin
2 points by rain1 2134 days ago | link | parent | on: Variables & scoping complaint

point [2] sounds like a problem of non-hygienic macros. perhaps it can be reconsidered now that there's syntax objects.

-----

2 points by rain1 2138 days ago | link | parent | on: Variables & scoping complaint

I have been thinking about a modified version of LET that takes a sequence of expressions (like begin) that are either assignments or not assignments. Then it would collect all consecutive assignments together into a letrec. For example:

    (let
      (foo)
      (= a 1)
      (= b 2)
      (= c 3)
      (bar)
      (= x 4)
      (= y 5)
      (baz))
would get collected into

    (begin
      (foo)
      (letrec ((a 1)
               (b 2)
               (c 3))
        (bar)
        (letrec ((x 4)
                 (y 5))
          (baz))))
and this "LET" form would take place of the implicit begin we have in most contexts. What do you think? Could it be useful.

-----

2 points by rain1 2139 days ago | link | parent | on: Show Arc: Serializable Closures

I should add: This works because the host lisp is pure: there is no SET! or mutable cells.

If you have mutable cells, write out and read it back in you'd get a clone of the cell - independent of the original. This seems like the wrong behavior.

To make it work with mutable cells seems kind of impossible. I'm not sure. One system I found replaces mutable cells with distributed uniquely identified mailboxes. (termite scheme).

-----

3 points by waterhouse 2121 days ago | link

It's possible to record the fact that some cons cells (or other structures) are identical. The Lisp reader's #n= notation can be used for this, although usually it's only used to print circular lists. Common Lisp's print-circle can be used to demonstrate this:

  * (let ((x (cons 1 2))) (princ (list x x)) nil)
  ((1 . 2) (1 . 2))
  NIL
  * (let ((*print-circle* t)) (let ((x (cons 1 2))) (princ (list x x))) nil)
  (#1=(1 . 2) #1#)
  NIL
Now, if you have a running process, and you want it to seralize a closure (or, generally, an object) that points to a cell that happens to be identical to something else in the process, and you want to read the closure back in and have its pointed-to cell continue to be identical to that other thing... you'll need something more sophisticated. If each object is given some unique id, that would be one approach; that sounds like the mailboxes thing. Another approach would be... say, if the other cell is the 5th element of a list identified with the global name 'blah, then conceivably that could be a good syntax. This might be useful for modules, separate compilation, and/or saving arbitrary process state.

-----

2 points by whitten 2123 days ago | link

Could you elaborate on this or give me pointer what we re it is discussed?

-----

3 points by rain1 2121 days ago | link

what needs explained?

-----


I think you should have to quote them. Like how you have to quote lists:

    '(foo bar)
is just a list, but

    (foo bar)
will either call the function foo or error if it doesn't exist.

So in a similar way

    {foo "bar"}
should give a syntax error, but maybe it can have some kind of semantic meaning later. I've been considering that square brackets could be used for assignment/local binding, to cut down on the need for LET (not necessarily in arc just in lisp in general).

-----

2 points by i4cu 2157 days ago | link

> should give a syntax error...

I don't agree. quoting a list is a way to protect the expression from evaluation, in this case because round brackets normally indicate an expression that needs to be called. A table literal {...} doesn't need protection from evaluation as a callable expression as it's just data and like any other data it should evaluate to itself. And, frankly, it would really suck having to protect that data everywhere in my code because someone wants a really nuanced use case to work.

Really what should happen is that [] should be implemented such that we don't need to protect lists of data.

-----

2 points by i4cu 2157 days ago | link

> Really what should happen is that [] should be implemented such that we don't need to protect lists of data.

I should point out that I don't think this can happen since square brackets are reserved for other uses in Arc.

-----

2 points by rain1 2157 days ago | link

I see what you mean, making it self evaluate seems like the best option.

-----


It would be nice if it the way it prints out is the same as the way it is written

  arc> (= user '{name "John Doe" age 23 id 73881})
  {(age . 23) (id . 73881) (name . "John Doe")}
or

  arc> (= user '#{name "John Doe" age 23 id 73881})
  #{(age . 23) (id . 73881) (name . "John Doe")}
where

  arc> #{foo "bar"}
gives a syntax error. extra brackets like [] and {} may be used in macros as special syntax.

-----

2 points by rain1 2157 days ago | link

update: having it self evaluate (or evaluate to a hashtable with quoted keys and non-quoted values maybe) instead of a syntax error seems like a better choice

-----