There's already one existing syntax for !, and I think it's unlikely that pg will add another. We're taking advantage of something which is, essentially, defined to be meaningless in arc2.tar but which we can make work on Anarki and using it. And of course, pg can do anything he wants, but that could involve both new ssyntax and new functions. We have been warned that what we're doing is "unsafe," after all. If we do avoid alphanumerics and choose, say, djoin, what happens if pg choose njoin for arc3.tar? Or uses the d prefix for something else? Using existing ssyntax characters is probably pretty safe.
As you might have guessed, by the way, I support the join! standard :)
> If we do avoid alphanumerics and choose, say, djoin, what happens if pg choose njoin for arc3.tar? Or uses the d prefix for something else?
We say "I suggest running a poll on this, pg" ^^
But I still like module syntax T.T However the appended ! convention is winning by a really large margin (waaa hopeless!). So we need to modify the builtin ssyntax/ssexpand to ignore trailing "!" and/or standardize on my ssyntaxes.arc
OK, another point. There is a virtue in having a standard that is backwards compatible with the base Arc release.
For example, I recently borrowed classifier.arc from anarki and ran it with the base release of arc with no troubles. If people start using the ! standard, then to use anarki libs one would have to run all of anarki. Which may be OK, it just has to be accepted that this is the case.
(As a matter of style I like ! too)
(somewhat related tangent:
[One of the best of these is a Gosperism. Once, when we were at a Chinese restaurant, Bill Gosper wanted to know whether someone would like to share with him a two-person-sized bowl of soup. His inquiry was: "Split-p soup?" -- GLS]
We're already not backwards compatible. Things like ssyntax.arc, for an extreme example, but also our additions of functions to places like arc.arc, e.g.butlast. That doesn't exist in arc2.tar, but we have it anyway. Anything that uses such functions requires Anarki. This is more extreme (you wouldn't be able to copy just those functions over), but not unique.
