[Pharo-project] Parsing problem
Hi, I've discussed with Stephane and may be we can fix all the methods that have : _ instead of := or some methods have [ : myArg ... ] instead of [ :myArg .... ] So we can use a parser that strictly check that we respect grammar. There is in this mail an attach file that contains the list of the classes and methods that are not corrects. Cheers, Gwenael Casaccio
Thanks gwenael I will intergrate your fix. Now pharoers what do we do with _ and external code using [ : x instead of [:x for _ Gwenael proposed to have the parser been able to parse and fix the _ into := but also to be able to have a strict parser. For :x we should have a parser that reject : x code. But what do you think On Dec 18, 2008, at 5:05 PM, Gwenael Casaccio wrote:
Hi,
I've discussed with Stephane and may be we can fix all the methods that have : _ instead of := or some methods have [ : myArg ... ] instead of [ :myArg .... ]
So we can use a parser that strictly check that we respect grammar. There is in this mail an attach file that contains the list of the classes and methods that are not corrects.
Cheers, Gwenael Casaccio
<parsingerrors.txt.zip>_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I've discussed with Stephane and may be we can fix all the methods that have : _ instead of := or some methods have [ : myArg ... ] instead of [ :myArg .... ]
I agree that the use of := should be enforced. I would also like to be able to use _ in names. However: The parser should allow spaces after the $: in block arguments. This is essentially the same syntax as for keyword method declarations without a keyword and there you also allow arbitrary spaces after the colon (normally you even put them there). So I understand when people write block arguments the same way as they do for keyword method declarations: to: stop by: step ... [ : stop : step | ... ]
So we can use a parser that strictly check that we respect grammar. There is in this mail an attach file that contains the list of the classes and methods that are not corrects.
All Smalltalk allow spaces after the $: in blocks. Disallowing this makes porting unnecessary hard. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Dec 18, 2008, at 6:34 PM, Lukas Renggli wrote:
I've discussed with Stephane and may be we can fix all the methods that have : _ instead of := or some methods have [ : myArg ... ] instead of [ :myArg .... ]
I agree that the use of := should be enforced. I would also like to be able to use _ in names.
However: The parser should allow spaces after the $: in block arguments. This is essentially the same syntax as for keyword method declarations without a keyword and there you also allow arbitrary spaces after the colon (normally you even put them there). So I understand when people write block arguments the same way as they do for keyword method declarations:
to: stop by: step ...
[ : stop : step | ... ]
It looks a weak argument to me :) I would hate to teach that. I neither thought you could even do that.
So we can use a parser that strictly check that we respect grammar. There is in this mail an attach file that contains the list of the classes and methods that are not corrects.
All Smalltalk allow spaces after the $: in blocks. Disallowing this makes porting unnecessary hard.
I was not aware of that. So this would be a reason to allow that but in pharo core code I would really like not to have that. To me this is a weakness of the parser and not a feature.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi gwenael Today I want to integrate your changes since I thought that you gave us the code of the methods but fixed and not just the selectors. Now this list is long and I do not want to do it by hand. Could publish a slice in the pharoInbox with all the code changed? If you cannot do it right now tell us how we can proceed. You can do two slices one for [:e and one for _ -> := Stef On Dec 18, 2008, at 5:05 PM, Gwenael Casaccio wrote:
Hi,
I've discussed with Stephane and may be we can fix all the methods that have : _ instead of := or some methods have [ : myArg ... ] instead of [ :myArg .... ]
So we can use a parser that strictly check that we respect grammar. There is in this mail an attach file that contains the list of the classes and methods that are not corrects.
Cheers, Gwenael Casaccio
<parsingerrors.txt.zip>_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
At Thu, 18 Dec 2008 19:55:31 +0100, Stéphane Ducasse wrote:
On Dec 18, 2008, at 6:34 PM, Lukas Renggli wrote:
I've discussed with Stephane and may be we can fix all the methods that have : _ instead of := or some methods have [ : myArg ... ] instead of [ :myArg .... ]
I agree that the use of := should be enforced. I would also like to be able to use _ in names.
However: The parser should allow spaces after the $: in block arguments. This is essentially the same syntax as for keyword method declarations without a keyword and there you also allow arbitrary spaces after the colon (normally you even put them there). So I understand when people write block arguments the same way as they do for keyword method declarations:
to: stop by: step ...
[ : stop : step | ... ]
It looks a weak argument to me :) I would hate to teach that. I neither thought you could even do that.
Just for the record, what Lukas described (the part where the args to block should look like keyword-less keyword message sending) is indeed the original intention of Dan. (As you probably already knew.) -- Yoshiki
to: stop by: step ...
[ : stop : step | ... ]
It looks a weak argument to me :) I would hate to teach that. I neither thought you could even do that.
Just for the record, what Lukas described (the part where the args to block should look like keyword-less keyword message sending) is indeed the original intention of Dan. (As you probably already knew.)
Thanks I was not aware of that and funnily enough I'm a rather visual person and it never occurred to me that this was the case, even today I see what you mean but I have problem to match them in fast eye mode may be because of the absence of characters before.
participants (4)
-
Gwenael Casaccio -
Lukas Renggli -
Stéphane Ducasse -
Yoshiki Ohshima