I think I disagree. o is certainly a wart, but ? seems unlikely to be a variable name anyway. Have you actually used ? as a variable name before?
There's nothing special about ssyntax. If we would consider using ? as ssyntax, it's fair game to use for other syntactic purposes as well.
Update: A second rationale. As waterhouse found out (http://arclanguage.org/item?id=12612) arc is extremely permissive about letting us override things, so there's no point focusing on what is legal in this arbitrary implementation.
A third rationale. Right now you want to disallow ? because it's not ssyntax. When it becomes ssyntax won't it still be unusable in arglists for the same reason & is unusable now? :) At that rate we'd never get syntax inside arglists. Which may be a plausible position, but then we should be arguing about whether arglists can benefit from syntax.
Have you actually used ? as a variable name before?
I agree with you that it's unlikely. I'm mainly just a consistency nut. :) I'd like for every symbol to be seen as either special everywhere, maximizing its potential power, or else special nowhere, maximizing the number of macros that'll know what to do with it.
At least, I like this kind of consistency as long as the language/utility is going for ease of customization ('cause of fewer cases to cover) and minimalism. When it comes to making code readable and writable, consistency can be less important.
---
A second rationale. As waterhouse found out (http://arclanguage.org/item?id=12612) arc is extremely permissive about letting us override things, so there's no point focusing on what is legal in this arbitrary implementation.
For a language people are eager to make breaking changes to for their own purposes, that's true. But several programmers trying to make interoperable code won't each make breaking changes independently, right? Arc may promote a philosophy of fluidity, but any particular version of Arc is still made immovable by the community that uses it.
---
A third rationale. Right now you want to disallow ? because it's not ssyntax. When it becomes ssyntax won't it still be unusable in arglists for the same reason & is unusable now? :) At that rate we'd never get syntax inside arglists. Which may be a plausible position, but then we should be arguing about whether arglists can benefit from syntax.
Hmm? You've got what I'm saying completely backwards. I think we should commit to having ? be completely special (a kind of ssyntax, for instance) as long as we want it to be special in parameter lists. Meanwhile, & is totally usable for special behavior in parameter lists, since it's already useless for normal behavior (variable names).
I think I'm ok with us as a community saying "this version of arc treats ? as ssyntax" without necessarily having any code to do so :) expand-ssyntax for ? is the identity until we come up with a use for it. "Use ? as a variable at your own risk."
(Probably a strawman.) What I don't want is to start reserving tokens or characters 'for later use' and enforcing that they can't be variables and so on. Common Lisp does this and it's stupid. Did you know you can't declare a function called type even though it doesn't do anything, hasn't done anything for the past 15 years? What a colossal waste of a great token!
https://github.com/akkartik/wart/blob/master/009core.lisp#L1
---
You've got what I'm saying completely backwards.
Ah yes, I did. You said &o is ok.
It does raise the question of the right way to setup ssyntax. Either we're making changes to expand-ssyntax everytime we want a special case to turn off ssyntax expansion or we're saying "leave & as is when it begins or ends a symbol."
But then you could argue that &o is still impinging on a potential variable name. It's starting to feel like arguing about angels and pinheads; why is it ok to pun + and & and : so they do different things in different contexts, but not use ? because of some speculative fear of potentially punning variable names?
Those are all questions I worry about. ^_^ I'm really itching to post about Penknife's syntax, since I think it does a good job of dissolving these issues.
