Authorize upArrow in binary symbols
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?
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
Pharo uses (right now) RBParser as the main Parser⦠in Pharo4 we will remove the old Parser (subclass of Scanner ;-),
Other first plans (we need to start a real discussion after Pharo3 is released) for Pharo4 are in the in the Fosdem talk: Slides: http://www.slideshare.net/MarcusDenker/2013-fosdempharo4 Video: https://www.youtube.com/watch?v=mUV9E03u52g I think even this change should wait for Pharo4⦠but of course it can be prepared and ready for inclusion. (we need to be a bit careful what to change now, the side-effects of changes are always amazing ;-) Marcus
On 24/02/14 19:06, Marcus Denker wrote:
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â¦)
This is interesting for me. I would not go for petitparser personally. My experience, speaking of performance and error reporting, not so great. I have one question: If you replace RBParser with green-field implementation, how would you deal with the rest of RB stuff? Refactorings, lint etc, which are all based of RBParser API? Best, Jan
On 27 Feb 2014, at 13:56, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
On 24/02/14 19:06, Marcus Denker wrote:
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â¦)
This is interesting for me. I would not go for petitparser personally. My experience, speaking of performance and error reporting, not so great.
Yes⦠sadly. Especially good error reporting is very crucial. Yet it would be so nice if Pharo would contain a hight level reflective meta model of itâs own grammar!
I have one question: If you replace RBParser with green-field implementation, how would you deal with the rest of RB stuff? Refactorings, lint etc, which are all based of RBParser API?
The RBParser itself has a very small API⦠âgive me an AST for a stringâ (#parseMethod: and #parseExpression:, in addition #parseMethodPattern: and some special ones for rewrite rules (which is kind of a DSL on top of Smalltalk, these methods already forward to RBPatternParser, a subclass of RBParser) In Pharo3 we already replaced all the references to Parser, Scanner and Compiler with a call to get the Opal compiler facade. Wen we remove the old compiler in Pharo4, the next step is to do the same with *all* direct references to RBParser. (we could not yet do that as, when you enable the old compiler, you get the old AST back⦠for code generation it has the same API, for refactoring not as the old AST does not support that. So for now we kept the code in a state that you can disable Opal, yet refactoring still uses RBParser explicitly. When there is just one compiler, we can simplify that even further). So after doing that, the actual implementation of the Parser can then be easily exchanged, the only thing it needs to do is to create a RB AST. The Opal compilationContext has already a #parserClass accessor that right now returns RBParser, but that any user can override. (this is not yet used so it might not work, but the machinery is there). Marcus
On 27/02/14 14:58, Marcus Denker wrote:
On 27 Feb 2014, at 13:56, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
On 24/02/14 19:06, Marcus Denker wrote:
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â¦)
This is interesting for me. I would not go for petitparser personally. My experience, speaking of performance and error reporting, not so great.
Yes⦠sadly. Especially good error reporting is very crucial. Yet it would be so nice if Pharo would contain a hight level reflective meta model of itâs own grammar!
I have one question: If you replace RBParser with green-field implementation, how would you deal with the rest of RB stuff? Refactorings, lint etc, which are all based of RBParser API?
The RBParser itself has a very small API⦠âgive me an AST for a stringâ (#parseMethod: and #parseExpression:, in addition #parseMethodPattern: and some special ones for rewrite rules (which is kind of a DSL on top of Smalltalk, these methods already forward to RBPatternParser, a subclass of RBParser)
Well, I meant RBParser and RB AST API, actually :-)
In Pharo3 we already replaced all the references to Parser, Scanner and Compiler with a call to get the Opal compiler facade. Wen we remove the old compiler in Pharo4, the next step is to do the same with *all* direct references to RBParser. (we could not yet do that as, when you enable the old compiler, you get the old AST back⦠for code generation it has the same API, for refactoring not as the old AST does not support that. So for now we kept the code in a state that you can disable Opal, yet refactoring still uses RBParser explicitly. When there is just one compiler, we can simplify that even further).
So after doing that, the actual implementation of the Parser can then be easily exchanged, the only thing it needs to do is to create a RB AST.
OK, so the idea is remove RBParser but keep all RBProgramNode classes? Jan
On 27 Feb 2014, at 16:23, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
So after doing that, the actual implementation of the Parser can then be easily exchanged, the only thing it needs to do is to create a RB AST.
OK, so the idea is remove RBParser but keep all RBProgramNode classes?
If the Parser would be changed, then yes, that would be the idea. RBProgramNode + subclasses is an AST. This AST can be created by any kind of Parser, it is independent. Marcus
On 27 Feb 2014, at 13:56, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
On 24/02/14 19:06, Marcus Denker wrote:
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â¦)
This is interesting for me. I would not go for petitparser personally. My experience, speaking of performance and error reporting, not so great.
+1 I would not mind to have two. One for experimental interactive...and the other for production and heavy dutie. Now to me we have so many more important aspects to improve that I would not really build a case for that.
I have one question: If you replace RBParser with green-field implementation, how would you deal with the rest of RB stuff? Refactorings, lint etc, which are all based of RBParser API?
Best, Jan
participants (4)
-
Jan Vrany -
Marcus Denker -
Nicolas Cellier -
Pharo4Stef