Well, it has to do with the ssyntaxes.arc precedence rules and how they work: basically, split according to the current ssyntax, then go to next ssyntax. Since #\. is listed before #\!, symbols are first split by #\. into (foo! x), so it works properly.
It won't work with a type that ends in ! and if you use the ? ssyntax:
(def my-type! (x)
(annotate 'my-type! x))
(my-type!? my-type!.1) ; will transform to (my-type '?)
> 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
On Anarki there's the 're function which matches regular expressions. It uses the underlying mzscheme's regular expressions.
Also, we do have a decent parser library, treeparse: it's just not a very concise one. And I should really, really finish the treeparse tutorial I started.
This would mean to have a huge hash table containing all destructive operations, and that a lookup in that table would be necessary just to call a function. A namespace system (such that of CL) would be the right thing, because names in such a system are resolved before runtime.
(d::join ...)
The character #\: has been already taken, though.
Maybe a good name would be (d/join ...). What do you think?
Depends. If we accept the modification in http://arclanguage.com/item?id=7451 , it would be possible to make modules into a macro, and D!join would be resolved during macro-expansion into a 'uniq that can be 'symeval -ed to the destructive join operation.
That's what I would have thought, but it appeared to work. Though it may only have worked because of your second observation. And given that, I will repeat my desire for the destructive! custom. I like it because it doesn't interfere with any name (e.g. how alist could be association list or the "is the object a list?" predicate [though that's a bad example, you get the idea]), it has seen use in multiple languages, and it pretty clearly says what it means (assuming you want to encourage functional programming, as I think we do).
I suggest running a poll on this - of course, pg probably won't care either way, but we can integrate his code into Anarki next time he bothers to release an update, ne?
I think this convention is good; I'm just somewhat concerned with the fact that foo!bar is plenty overloaded.
edit: IIRC this has been suggested a few times before already, so I think there'll be good support for this - but it means we will then have to formally standardize the ssyntaxes too.
None yet. tokipin's idea here is approximately what I had in mind for SNAP, where I might possibly define a module system accessible using module!export syntax, but really the problem is the interaction between modules and types as well as modules and macros.
They still have some problems when you use the compiler to compile itself, because macros have to run in the host compiler environment and not in the target environment (that doen't still exist). I'll write more about this problem in a NOTES file I have to add to the repository.
The key point in implementing macros in a compiled system is first to get the system able to compile itself: once that point is reached, they are quite straightforward to implement, except for the problem mentioned before. The last two functions in transformations.arc plus the function eval in lib.arc implement macros.
The "Create your own collection" series should help a bit - these collections all use lib/settable-fn.arc, and with minimal modification should be useable with lib/settable-fn2.arc
