I agree, the vertical-bar symbol-syntax is a very smelly onion. And as far as I could tell the last time I checked, the only place arc really depends on it is in webserver code, to define a handler for the application root uri ( "/" ) - this path is defined by the empty symbol, which is represented as ||
You could get away with totally ignoring vertical-bar symbol-syntax, and add this somewhere before you define your webapp:
(assign || (sym ""))
Hindsight is great. I wish I had thought of this before writing all those vertical-bar tests :)
"Do people consider srv.arc to be 'part of arc' for compatibility purposes?"
I would consider any Arc program to be "part of Arc" for compatibility purposes because any Arc program is supposed to use only the core and things defined in arc.arc (along with its own libraries, of course).
Obviously all bets are off if it uses the $ macro to drop into Racket, but then you're not really writing Arc code anymore, so I'm ignoring that case.
---
"(assign || (sym ""))"
That's a pretty good way of solving that one particular use-case, but it won't help in general because there might be some Arc program that actually does use the |...| notation more extensively.
However, I suspect such programs are quite rare, and with good reason. So I don't think it's a major deal if an Arc implementation chooses to not implement the |...| notation. However, such incompatibilities should be documented, so people using your implementation know what works and what doesn't (and why it doesn't work).
And in that case, it would probably also be a good idea to have your implementation throw an error if a program ever uses the |...| notation. That makes it easy to figure out which programs are broken, and makes it easy to pinpoint where the problem is so it can be easily fixed, rather than failing silently or at a later step in execution.
"I don't understand. If I write a hello world arc program, are you saying that's part of arc?"
For the sake of compatibility with Arc, yes. An implementation claiming compatibility with Arc should be capable of running programs designed for Arc 3.1.
---
"what do you consider to be the core of arc?"
We were discussing what constitutes "part of Arc" for compatibility purposes. "srv.arc" is not a part of the core of Arc, nor are any libraries written in Arc. But it is still "part of Arc" for the sake of compatibility, in the sense that a compatible implementation of Arc must be capable of running them, warts and all.
Unfortunately, that means that certain programs may end up relying on things inherited from Racket, such as the |...| syntax. I think it must be decided on a case-by-case basis whether compatibility with Arc 3.1 is worth it or not. In the particular case of |...| I don't think it's worth it. But I'm not the one implementing Arcueid: that's up to dido to decide.
Looks like akkartik ran across one of my rants. :) Well, I'd then like to ask what does the community think of this. One of Arc's distinctive features that no other Lisp dialect has is ssyntax. Since it works by breaking apart symbols that contain special characters, I think there should be some way to escape these special characters so they are not interpreted as ssyntax. A backslash looks like a good a character as any, so I could do foo\.bar.baz to get (foo.bar baz) or perhaps (foo\.bar baz). What other mechanisms might be helpful in handling ssyntax?
You could also just disallow ssyntax chars in symbols. That's what I do. Arc doesn't abuse them like that even though the underlying racket permits, so you'd arguably still be 'compatible'.
"You could also just disallow ssyntax chars in symbols."
How would ssyntax work, then?
Whatever gets passed to 'ssyntax or 'ssexpand oughta be able to contain symbols with ssyntax characters in them, or else they'll be trivial to implement. :-p
If I were designing a language with a.b and (a:b c) stuff, I'd implement that in the parser, like Semi-Arc does. However, I don't consider that Arc-compatible.
Arcueid used to do it that way, by parsing and expanding ssyntax at read time, rather than at compile time the way reference Arc does. It turns out that the reason why ssyntax expansion is thus deferred has to do with the way the ssyntax compose (:) and complement (~) operators work. They cannot be expanded properly by simple lexical substitution the way all other ssyntax operators can be, as they alter the structure of a sexpr that uses them, so it is impossible for the reader to do it. It has to be done once we already have the full sexprs, and that means that it becomes a step at compile time.
