On 24 Feb 2014, at 19:52, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Though being reserved for return statements, the upArrow ^ could perfectly be accepted as a character composing a binary selector, like the verticalBar | already is. Indeed there is no ambiguity, since the return ^ is always prefixed, while a binary message never is... (well, except in the method source, but method source must begin with selector, it cannot begin with a return statement, so no ambinguity there neither...).
I don't plan to use or add such selector in core Squeak/Pharo, but I think that it is important to allow a variety of selectors : it allows the most simple DSL : one using Smalltalk syntax (no need to define a new syntax, a new parser, etc...). If we did it for |, I don't see why we shouldn't for ^. Note that we recently also extended usage of - at any place in binary selectors (it was restricted to first position previously), though no core message is concerned so far.
The main objection could be that a missing period before a return statement won't be reported, but interpreted as a message send... like in: x := a+b ^x
But I don't think it's really a feature stopper.
It's very easy to modify the old Compiler and shouldn't be that hard in Opal too. I'll try and push a prototype in Squeak inbox this evening.
What do you think?
+1
flexibility is always good :-) You never know what people want to build later. The base level should be extremely flexible (to the point that to you can break *any* Smalltalk convention). Any kind of checks for “best practices” should be done on level up on the tool level, and even there only if really needed. (in the past we had the idea to provide feedback e.g. to not have instance variables with capital letters, but this should *never* be enforced on the low level, as for DSLs, research hacks and real cool stuff (TM) people need all flexibility)
Pharo uses (right now) RBParser as the main Parser… in Pharo4 we will remove the old Parser (subclass of Scanner ;-), on the TODO is to check if PetitParser can be used instead (but there are many open questions related to e.g. error handling, speed…)
Marcus