I like aw's localt0 hack [http://awwx.ws/localt0] but can't (yet) see any reason other than compromise not to allow reassignment of 't and the other symbols even at the global level.
He brings up an interesting point about 'nil though, reminding that it's equivalent to the empty list. I could be mistaken, but it seems as though Arc makes 'nil the more fundamental of the two. My evidence for this is that '() evaluate to nil at the REPL, rather than the reverse:
arc> 'nil
nil
arc> '()
nil
I say it should go the other way around, with 'nil evaluating to (). After all, if any symbol in Lisp is sacred it's parens, not the word nil. But more relevant to the point, this frees 'nil up to be a settable symbol that's only initially bound to the empty list.
> I remember reading in one of pg's articles about arc that it supported first class macros
Maybe this quote from "Some Work on Arc" [1] is what you were thinking of:
> For example, Arc currently has first class macros. It just seems to be the simplest way to define the language. First-class macros are potentially very inefficient; you could be expanding macro calls at runtime. But I think most users won't want to take advantage of this possibility. They'll ordinarily make some kind of global declaration that macro calls can all be expanded at compile time, and macros won't cost any more than they do in current Lisps.
Ah, I just found fallintothis' comment about patching "srv.arc" so it can serve static JavaScript. [http://arclanguage.org/item?id=10621] Maybe all that's needed is to append those lists with mp3 entries.
You'll get this error if the browser has closed the connection and isn't reading the data.
One thing to check is what headers are being sent. For example, with the wget utility, you can use the -S option to see the server headers. First look at the response you're getting from the working server, and then compare it with the response you're getting from the Arc server which isn't working.
I thought the point of 'baz was to call the first parameter with the second parameter. That is, the result of (baz "abc" 0) would be the character #\a if not for that meddling macro. Your 'baz1 is totally different.
BTW, here's my version of 'baz: (def baz (m index) do.m.index)
Your 'whatever function rebinds 'test only for the lexical scope of the function definition. After defining the macro and then the function as you have, 'test is still bound to the macro:
arc> (mac test (name actual compare-fn expected)
"test macro")
#(tagged mac #<procedure: test>)
arc> (def whatever (test xs)
test)
#<procedure: whatever>
arc> test
#(tagged mac #<procedure: test>)
arc> (test nil nil nil nil)
"test macro"
The binding of function parameters behaves like 'let in this regard, affecting a variable's value within the lexical scope of the block but producing no side effects on it outside.
We can even pass 'test as a parameter to 'whatever and it will retain its original value as a macro, because the rebinding of 'test as a parameter was only for the function's definition, not for a call to that function:
arc> (whatever test nil)
#(tagged mac #<procedure: test>)
I am trying out your "arc.lisp" now. Seems great so far.
There is much exploring to do, but my initial confusion with =. Seems it's not working and maybe not even defined. I read your discussion above of the problems with =, but I thought that was about your Arc in PLT, not CL. I haven't looked closely at the guts of "arc.lisp" yet, so maybe that will answer my question.
Oh, I forgot to include that in the list of idiosyncrasies. Basically, use setf wherever you would use = in Arc. The reason, in short, is that = is already the numerical-equality function, and CL doesn't like people to redefine things.
In PLT Scheme, you just have to uncheck a box that says "Disallow redefinition of initial bindings" and then you can redefine almost everything, but in CL, it will complain about breaking a package lock and go into the debugger whenever you try to redefine a built-in function, of which = is one. It's possible to tell it "Yes, ignore package lock", but I don't want to do that for every single function every time I start up SBCL. I think it is possible to tell it to automatically ignore the lock... But this is the way it is right now. Also, when you try to redefine 'if, you just run into a brick wall:
The special operator IF can't be redefined as a macro.
I stumbled on one other workaround, too... you can create a new package and choose not to import (all of) the stuff from CL-USER. So far, though, this doesn't even import the symbol nil, and when I do import it, it gets printed with a "COMMON-LISP:" prefix.
I guess one might be able to get used to that. Might try it out if I feel adventurous. For now, put up with using setf, mapcar, iff, and my version of with.
; Though graphically the right choice, can't use _ for currying
; because then _!foo becomes a function. Maybe use <>. For now
; leave this off and see how often it would have been useful.
And this other one:
; Non-fn constants in functional position are valuable real estate, so
; should figure out the best way to exploit it. What could (1 foo) or
; ('a foo) mean? Maybe it should mean currying.
I think it's supposed to be like structure access from C-style languages, like linkedList.tail.tail.head or whatever. For instance, if you're working with a list of mailing addresses at the REPL, assuming it's structured a certain way, you can get the third digit of the fifth address's zip code by typing "addresses.4!zip.2". Using the same mechanism, you can access a list of lists as "matrix.i.j".
There are plenty of times I get frustrated that a.b.c doesn't expand to (a (b c)), but I don't think they outnumber the other case. And anyway, having a.b.c.d.e mean (a (b (c (d e))) isn't as useful when you can already say (a:b:c:d e).
reminds me of ssyntax's strict evaluation rules. I might have been tempted at some point to treat this as meaning the third zip code of the fifth address, thinking in error that . had higher precedence than !. Force of habit from arithmetic expressions with a similar shape, e.g.
a + b / c + d
In ssyntax, everything is evaluated from left to right regardless of the operator.
In ssyntax, everything is evaluated from left to right regardless of the operator.
Actually, no. . and ! are evaluated left-to-right in relation to each other, but there are currently three priority levels; from highest to lowest they are: (1) : and ~, (2) . and !, (3) &. Characters within the same level needn't be evaluated left-to-right, though . and ! are. For example,
arc> (ssexpand 'a.b:c.d) ; : takes precedence over .
(compose a.b c.d)
arc> (ssexpand 'a.b&c.d) ; . takes precedence over &
((a b&c) d)
arc> (ssexpand 'a:b&c:d) ; : takes precedence over &
(compose a b&c d)
Then, since & has lower precedence than ~, you can't do
arc> even&~odd
which causes Arc to hang (which is actually a bug).
Further, though ~ and : are in the same level, : takes priority over ~ regardless of order.
arc> (ssexpand '~a:~b)
(compose (complement a) (complement b))
If you're interested in rewriting code to use ssyntax, you can check out my sscontract library (and let me know if it's broken!): http://arclanguage.org/item?id=11179
> I think it's supposed to be like structure access from C-style languages
http://files.arcfn.com/doc/evaluation.html agrees with you. I may begin using it only in such contexts to help preserve the metaphor, meaning I'd stop taking shortcuts like car.xs for (car xs) because it's not an example of structure access (though xs.1 is).
