Arc Forumnew | comments | leaders | submitlogin
1 point by Pauan 4965 days ago | link | parent | on: New version of Arc/Nu

A quick note if you're migrating old code to the new version: the "parameter" macro is gone. Use an ordinary variable and "w/" instead. In other words, rather than doing this:

  (parameter foo ...)
  (w/foo ...)
Do this:

  (= foo ...)
  (w/ foo ...)
Also, "=" still works like it does in Arc, but I recommend using "var" rather than "=", because it's hyper-static:

  (var foo ...)
  (w/ foo ...)
---

Another difference is that keyword arguments are no longer supported at all. This is because it's quite difficult to implement them properly, only a single function in Arc/Nu actually used them, and they're not backwards compatible with Arc 3.1, so I decided it wasn't worth it.

If you run into any other difficulties, feel free to post here and we can work it out.

3 points by idoh 4965 days ago | link | parent | on: New version of Arc/Nu

Thanks Pauan, I'm an Arc/Nu user for my personal projects and I'll be checking it out.
1 point by rocketnia 4968 days ago | link | parent | on: Modifying hash table keys

I agree. ^_^
3 points by dido 4968 days ago | link | parent | on: Modifying hash table keys

Been using Racket 5.1.1. That's a bit reassuring then. I guess that means I shouldn't be worrying too much about the behaviour of mutating keys in the implementation of Arcueid. If Racket says that the insertion and lookup operations of its hash tables become unpredictable then the same is true for reference Arc as well, and it doesn't matter if Arcueid does something completely different as well.
3 points by rocketnia 4968 days ago | link | parent | on: Modifying hash table keys

Arc just uses Racket's hash tables, which come with this disclaimer:

"Caveat concerning mutable keys: If a key in an equal?-based hash table is mutated (e.g., a key string is modified with string-set!), then the hash table’s behavior for insertion and lookup operations becomes unpredictable." - http://docs.racket-lang.org/reference/hashtables.html

If you're just interested in what's happening in the current implementation, I have a guess for your table-in-table example: When you initially put h2 in the table, its hash is calculated, and it's filed in a bin of entries that have that hash. Then when you look up h2 again, it calculates a different hash, so it searches the wrong bin and doesn't find the entry. When you look up (table), it finds the right bin, but the only key in that bin is h2. Since h2 is not currently equal? to (table), the search fails again.

I can't reproduce your second example, but what I get is consistent with this explanation:

  arc> h
  #hash(((3 2 . nil) . 3))
  arc> (h '(3 2))
  nil
  arc> (h '(1 2))
  nil
That was Arc 3.1. Anarki is different, but not by much:

  arc> h
  #hash(((3 2) . 3))
  arc> (h '(3 2))
  nil
  arc> (h '(1 2))
  nil
I used Racket 5.2 for these, and then I upgraded to Racket 5.3.3 and got the same results. What version are you using?
2 points by Pauan 4970 days ago | link | parent | on: New version of Arc/Nu

Rewrote to use boxes. Faster. Cleaner. Has optional hyper-static scope and hygienic macros. Has a great namespace system based around w/include, w/exclude, w/rename, and w/prefix. Still completely compatible with Arc 3.1

Thanks a lot!
2 points by lark 4971 days ago | link | parent | on: How can I store a cookie without a login?

These two lines are not needed:

             (save-table cookie->user* cookfile*)
             (user->cookie* user)
And replace

  makeid
with

  rand-string

Thanks. It seems this should work with Anarki.

If its just a one off thing then you could just emit/print raw JavaScript outputting the document onload function to trigger the storing or updating of your cookie (you could also build arc wrapper functions too).

I.e Document.Onload -> Document.Cookie

5 points by rocketnia 4976 days ago | link | parent | on: Arc in JavaScript Lisp possible?

I've already made an implementation of (threadless) Arc in JavaScript, based on Conan Dalton's Java code for Rainbow:

https://github.com/rocketnia/rainbow-js

It's not something I'm eager to build off of, for a few reasons:

- Rainbow strives to be consistent with official Arc, in the sense that they can be used to run the same programs. It goes out of its way to implement Arc's warts, making it a more complicated language than it has to be.

- Rainbow.js strives to be consistent with Rainbow, this time in the sense that their code can be maintained side-by-side. I've gone out of my way to make the JavaScript code similar to the original Java code, even if it would have been easier to use more first-class functions or dynamic JavaScript compilation. And if I see a bug, I take note of it but I don't fix it.

- By necessity, I implemented some of the primitive I/O operations in terms of asynchronous JavaScript I/O. This opens up a window for other JavaScript code to run while the side effect is executing. I find it unclear how to make this consistent with either Rainbow or official Arc; both of them support preemptive threading, and yet neither of them spells out exactly which moments in the program are possible preemption points.

- I was only able to develop Rainbow.js because Rainbow was mostly stagnant. But the converse worries me: Since I developed Rainbow.js, it will take more work to update Rainbow (or Arc) because multiple implementations must follow along with the update. Seems standards processes are slow and frustratingly arbitrary for a reason. :)


Yeah that seems plausible. I guess I don't understand what you're asking.

Perhaps it'll help to tell us more about what you're building and what you're trying to do and why.

1 point by lark 4979 days ago | link | parent | on: How can I store a cookie without a login?

It seems I need something like this:

  (defop-raw some-fancy-url (str req)
    (w/stdout str
              (anon-login req)
              (prn)
              (some-fancy-url-handler req)))

  (def anon-login (req)
       (if (no (get-user req))
           (withs (user (makeid 14)
                        cookie (cook-user user))
                  (= (logins* user) req!ip)
                  (prcookie cookie)
                  (prn)
                  (save-table cookie->user* cookfile*)
                  (user->cookie* user)
                  )))

  (def some-fancy-url-handler (req)
    (pr "Hello World"))

  ;; And visit /some-fancy-url

To plumb the X-Forwarded-For IP to req!ip, try the patch at http://www.arclanguage.org/item?id=11199. (See gotcha #3 at https://sites.google.com/site/arclanguagewiki/arc-3_1/known-...)

It doesn't work for me.

(pr req!ip) keeps showing the IP address of the server rather than the IP address of the client.

I need a way of telling clients apart. Perhaps I should be looking at cookies instead.

1 point by akkartik 4979 days ago | link | parent | on: Generalizing iflet

After playing with it some more, I'm finding that this actually works better in arc than in wart. In wart perhaps I should require parenthesizing it differently:

  (iflet x ((...) :satisfies f)
             'branch1)
Otherwise it interacts poorly with paren-insertion. Things like this with multiple branches:

  iflet x 2+3 :satisfies even?
            x+1
          3+4 :satisfies even?
            x+2
=> (iflet x 2+3 :satisfies even? x+1 (3+4 :satisfies even?) x+2)

Need wrapping in parens lest the inner test get wrapped in parens:

  (iflet x 2+3 :satisfies even?
             x+1
           3+4 :satisfies even?
             x+2)
Hmm, unhappy with my choices here.

Wifi is spotty here, but here's all the stuff I have in my config for a past project:

    proxy_set_header X-Real-IP  $remote_addr;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Referer $http_referer;
Does that work? If so, can you post the minimal headers needed? Thanks.

BTW, I've been interested in how we implement closure-based webservers for some time now (http://arclanguage.org/item?id=17265), so it was interesting to read citations [43,66,80] just above Question 1. In particular, Christian Queinnec also assumes such state can't be persisted (and so eliminates the option of multiple servers): http://www.cs.grinnell.edu/~rebelsky/courses/CS302/2007S/Rea...

FWIW, I'd submitted it a long time ago: http://www.arclanguage.org/item?id=16698 :) Totally worth looking into.

Can't believe I didn't see this anywhere in the 'newest' queue, because it (a) is incredibly relevant to Arc and (b) has been on the LtU front page since last month---although, it was apparently a repost. See http://lambda-the-ultimate.org/node/4691 and the previous thread linked therein.

Surprisingly insightful paper, for being such an easy read. Starts out a little humdrum, but really picks up in section 3. Definitely food for thought.


And for the successor of Icon: http://unicon.sourceforge.net/

Here is a link from the originating site for Icon: http://www.cs.arizona.edu/icon/
3 points by akkartik 4985 days ago | link | parent | on: Generalizing iflet

1. I like your final solution! But no reason why either of ours couldn't be done in vanilla arc.

2. (whenlet var expr ...) could also be written:

  (let var expr
    (when var ...))
So I don't think letwhen is strictly necessary.

3. Another alternative formulation is:

  (let var expr :when (f var)
    ...)
All that's really saving us is a couple of parens compared to the original pattern. Maybe we don't need a macro, just a different indentation convention:

  (let var expr (when (f var)
    ...))
But both these make the conditional nature of the block harder to see. My original solution and yours don't have that drawback.
3 points by fallintothis 4985 days ago | link | parent | on: Generalizing iflet

Looking for a vanilla Arc solution, if

  (whenlet var expr ...)
is the same (modulo multiple evaluation) as

  (when expr
    (let var expr ...))
then it kind of makes sense to call

  (let var expr
    (when (f var) ...))
the same name in the opposite direction, like

  (letwhen (f var) var expr ...)
I.e.,

  (mac letwhen (test var expr . body)
    `(let ,var ,expr
       (when ,test ,@body)))

  (letwhen (even x) x 50
    (prn "I print"))

  (letwhen (even (+ x 1)) x 50
    (prn "I don't print"))
Alas, it's very clunky to read. I think Haskell makes this sort of code look nice, because you can have a postfix variable declaration, like

  blah = if (f var) then ... else ...
    where var = expr
So, maybe something like

  (when (f var) :where var = expr
    ...)
would do away with the extra level of indentation.

Are you on linux on the server? There's a program called GNU screen which lets you run interactive processes and reconnect to them later: https://www.gnu.org/software/screen

You can probably install it with apt-get or yum or something.


Care to do a mini-review? :)

I've used this language off and on for decades. And Unicon is the successor (http://unicon.sourceforge.net/).
1 point by akkartik 4992 days ago | link | parent | on: Syntax and nesting: Lispy or Algol'ish?

We should discuss the reference to Honu in particular: https://www.cs.utah.edu/plt/publications/gpce12-rf.pdf
1 point by rocketnia 4992 days ago | link | parent | on: A module system for Arc

Okay, we're on the same page now then. ^_^

Having both kinds of scope as options would be great.

3 points by Pauan 4992 days ago | link | parent | on: A module system for Arc

Ah, sorry, huge miscommunication and misunderstanding on my part. I've actually been agreeing with you all along.

A large part of the problem is that I've been thinking about my proposal as two separate parts: one part deals with backwards compat with Arc, and the other part describes a hyper-static system for Arc.

When I was talking about "defs", I was talking about the hyper-static part. But you were talking about the backwards compat part. Hilarity (?) ensues.

More