What about what cchooper proposed in http://arclanguage.org/item?id=4712 : ($car ...) == (map car ...)? That's straightforward to add, if we add a new macro: def-ss-, to add new ssyntax with lower precedence (def-ss+ can be defined by analogy):
Actually, that's precisely why it has to be lower precedence: we want $.sin to turn into ($ sin), so as to get at trig from mzscheme; if it were to become (map .sin ...), things would die because of the malformed ssyntax in .sin. (I tried it both ways, which is how I figured this out.)
Ah, I think we have a misunderstanding here: from my point of view, objects earlier in the list have lower precedence to objects later in the list. ^^ So your "lower precedence" is my "higher precedence". Basically, it has to do with stuff like:
foo!bar:qux!quux
which is compiled as:
{{foo ! bar} : {qux ! quux}}
So !, which is listed later, has higher precedence (it gets grouped more tightly)
You make some really good points, but I have to disagree. Because of Unicode, characters aren't numbers. They have different semantic properties. However, I think arc.arc has a good idea sitting on line 2521 (of the Anarki version): "; could a string be (#\a #\b . "") ?" That is a novel idea, and probably (if more things work with improper lists) a good one. The downside would be that (isa "abc" 'string) wouldn't be true, unless we make strings (annotate "abc" 'string), but then we lose the ability to treat them as lists. Maybe we should have a retype operator, so that (retype "abc" 'string) would return an object str for which (isa str 'string) would be true, but for which all list operations (car, cdr, map, etc.) would still work (so it would probably have to return true for (isa str 'cons), too).
Well, Arc lists are (e e . nil). Why do we have a different terminator for strings?
This is where things get hairy. In Scheme lists are (e e . ()), so I would say that having strings be (#\a #\b . "") would make sense there, but Arc specifically tries to pretend that () is nil. Why should "" be different from nil, when () is nil?
As for [isa _ 'string], I propose instead the following function:
(def astring (e)
((afn (e e2)
(if
(no e)
t
; check for circularity
(is e e2)
nil
(and (acons e) (isa (car e) 'character))
(self (cdr e) (cddr e2))
; else
nil))
e (cdr e)))
Edit:
Hmm. I suppose someone will complain that you might want to differentiate between the empty string and nil. To which I respond: How is nil different from the empty list? Arc attempts to unify them; why do we want to not unify the empty string with nil? If someone says http://example.com/foobar?x= , how different is that from http://example.com/foobar ? x is still empty/nil in both cases.
As another example: table values are deleted by simply assigning nil to the value field. And yet in practice it hasn't hurt any of my use of tables; has anyone here found a real use where having a present-but-value-is-nil key in a table?
They're very very different things, but they have two commonalities. The first is a uniformity: in Lisp, you have data-code correspondence and everything returning a value; in Smalltalk you have everything being an object. The second is syntactic simplicity: Lisp (pretty much) only has its function/macros application with parentheses, (so (all your) 'code (looks like (this))). Smalltalk (pretty much) only has objects and message sending, so all:(your code) looksLike:this.
In fact, given Smalltalk's syntactic uniformity (if, while, etc. are implemented as methods on booleans, etc.), I've occasionally wondered if one could write a Smalltalk with macros. Does anyone know if this exists or why it wouldn't work?
There's a longstanding debate between the two communities about whether or not macros provide any meaningful benefits that Smalltalk blocks don't. (The archives of the LL1 mailing list contain a gold mine of posts on this.) In general, I doubt that most Smalltalk hackers would be very interested in macros in Smalltalk; they'd probably see it as out of sync with the spirit of the language. (Compare this to how Lisp hackers react to the inevitable newbie attempts to "fix" Lisp by removing parentheses or making it infix.)
I think macros in smalltalk are plausible. I have nothing to back that up. I am definitely not a smalltalk hacker. I think that smalltalk can solve the same problems that macros solve just through a different approach.
I'm not sure about the problem (at a guess, it's the forward slashes instead of backslashes in the Windows pathname), but I do have a formatting tip. To format code as code, surround it by blank lines, and then indent each line by two spaces. This will result in code being rendered in a monospaced font with whitespace (including returns) preserved.
open-output-file: cannot open output file: "C:/tmp/shashd39M2tCqX6"
It looks like the official arc2 distribution is being used here, which isn't smart about pathnames, so something in arc.arc, ac.scm, or something like that is just blindly using /s. If the Anarki is being used, then this bug should have been fixed. But as I said, I have a Mac, so I'm really just guessing here.
This has come up before, but I don't like it--symbols and strings feel distinct for me. http://tinyurl.com/6e9fv5 makes some interesting points about (Ruby) symbols, some of which apply here; I think that Ruby 1.9 will make Symbol a subclass of String, and Symbols will effectively be frozen strings (thought that might have gone away). It might be nice if there were some relationship like that with strings and symbols, but I do thing keeping them separate is useful.
I've talked to many fewer people than you, but my impression has been slightly different. Broadly speaking, the engineer-type programmers tend to dislike Lisp, and the computer-science-type programmers tend to like it. (Those two classes cover, in my [albeit limited] experience, two of the principle ways of thinking about programming.)
Eh. It's attitude, not job description :) And anyway, you should probably take that with a relatively enormous grain of salt, as small sample sizes aren't conducive to accurate data.
I've had plenty of luck using the Anarki (the git wiki); it has support for specifying a root "static files" directory, and maps files in there to MIME types by extension. In other words, to set the root directory to "/home/croach/site/", run
(= rootdir* "/home/croach/site/")
Now, if you have the file "/home/croach/site/js/script.js", then going to "http://localhost:8080/js/script.js" will serve the Javascript. Mimetypes are stored in the table ext-mimetypes* , and can be accessed and added to as expected. For instance,
