With proper ordering of the ssyntaxes in 'def-all-ss, yes.
> Do these ssyntaxes currently get optimized away at compile time (i.e. like 'compose does)? Or do they incur a run-time penalty of some sort?
Not yet. The run time penalty should be as small as a function-composition overhead. The optimization away of 'compose is done by the Scheme-side 'ac, so if optimizations for 'orf and 'andf and similar are desired, munging them in the scheme-side is necessary.
Edit: As an aside, the above ssyntaxes are not yet implemented in the ssyntaxes.arc file. For the most popular ones - postfix ?, as well as 'andf && and 'orf //, you can modify:
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)
I've been playing with this, and the other downside is that it's slow. Things are noticeably slower to load (not to run), as the ssyntax check is (a) more complex, and (b) written in Arc, not mzscheme. Other than those two things, though, it's absolutely great.
Hmm. After looking at that, as far as I can tell it can only match a word which ends in one of the strings in its dictionary. Using it to parse out middle bits would be tricky--you could try saving the string at each accept state, or something like that.
Okay, this is now partly implemented on the git. There's a new file, ssyntax.arc, which contains an 'a-ssyntax and 'a-ssexpand function. Those functions will eventually replace the builtin Anarki 'ssyntax and 'ssexpand functions.
What I intend is that the underlying ac.scm will call the arc-world 'ssyntax and 'ssexpand functions. This means that the user can redefine 'ssyntax and 'ssexpand, and all future symbols,when compiled by ac.scm, will be compiled using that schema.
The modifier: idiom is simply a macro, modifier, which accepts a single form. This modifier essentially accepts the argument as an expression and modifies how it operates; in the case of the breakable: modifier, it creates a 'break function which exits the expression.
Another modifier in Anarki is the p-m: modifier (which needs you to (require "lib/defpat.arc")); it transforms any function-defining form into a pattern matching form:
(p-m:mac foo
() ''(the foo)
(x) `'(the foo is ,x))
A while back I also posted a w/collect and w/mcollect macro form, which also works as a modifier: http://arclanguage.com/item?id=4390 . Macros which accept only a body will generally also work as modifiers, without, umm, modification.
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?
