<body><div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
                                        Sure, there is always the option to provide a custom parser. I was just thinking about how just overriding "self" is simpler than figuring out how to provide a custom parser for such things.<div><br></div><div>So, even with a Warning, the default should be to throw that Warning. I am just not in favor of hard-coding that rule into Parser. :-)<br><div><br></div><div>Best,</div><div>Marcel</div></div><div class="mb_sig"></div><blockquote class="history_container" type="cite" style="border-left-style:solid;border-width:1px; margin-top:20px; margin-left:0px;padding-left:10px;">
                        <p style="color: #AAAAAA; margin-top: 10px;">Am 19.07.2019 10:01:45 schrieb Chris Muller <ma.chris.m@gmail.com>:</p><div style="font-family:Arial,Helvetica,sans-serif">Could we possibly let standard Smalltalk-80 be the default choice, and <br>"crazy" be the optional choice that "experimenters" would explicitly invoke? <br> <br>That way, we don't even need a Warning... <br> <br> <br> <br> - Chris <br> <br> <br> <br> <br>On Fri, Jul 19, 2019 at 12:40 AM Marcel Taeumel <marcel.taeumel@hpi.de> wrote: <br>> <br>> Shadowing those reserved variables seems to be a nice property that supports (crazy) language experiments. We shouldn't make use of it in Trunk, though. <br>> <br>> +1 for adding a preference to raise a Warning (or Error) if somebody tries that <br>> -1 for prohibiting that in Squeak's default parser all the time <br>> <br>> Best, <br>> Marcel <br>> <br>> Am 19.07.2019 04:15:28 schrieb Frank Shearar <frank.shearar@gmail.com>: <br>> <br>> The snippet from the standard says that it is illegal to use these identifiers as method arguments. The example uses block arguments. <br>> <br>> Now maybe a reasonable person would assume that argument names, regardless of whether method or block (especially if one views blocks as anonymous methods), come from the same set, and maybe it seems like a terrible idea to allow this kind of shadowing,  but I don't see the current behaviour as incompatible with the standard snippet. <br>> <br>> So sure, forbid such shadowing because it's terrible, but I don't see it being ILLEGAL. <br>> <br>> frank <br>> <br>> On Thu., Jul. 18, 2019, 18:26 JOHN SARKELA via Squeak-dev, <squeak-dev@lists.squeakfoundation.org> wrote: <br>>> <br>>> It is by definition erroneous. It is counter to the definition of the standard language. That is a problem that should be fixed. <br>>> <br>>> On Jul 18, 2019, at 7:53 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote: <br>>> <br>>> Is it really a problem? <br>>> Did the system horribly break? <br>>> IMO this should just be not recommended. <br>>> <br>>> Le ven. 19 juil. 2019 à 00:39, Chris Muller <asqueaker@gmail.com> a écrit : <br>>>> <br>>>> Wow.  We should disallow that.  Those words are reserved. <br>>>> <br>>>> On Wed, Jul 17, 2019 at 5:52 AM Levente Uzonyi <leves@caesar.elte.hu> wrote: <br>>>>> <br>>>>> Hi All, <br>>>>> <br>>>>> You can currently evaluate the following: <br>>>>> <br>>>>> [ :self :thisContext | <br>>>>>         | nil super true false | <br>>>>>         nil := 1. <br>>>>>         super := 2. <br>>>>>         true := 3. <br>>>>>         false := 4. <br>>>>>         self + thisContext = (nil + super + true + false) ] value: 4 value: 6 <br>>>>> <br>>>>> Is this the expected behavior or should we disallow such oddities? <br>>>>> <br>>>>> Levente <br>>>>> <br>>>> <br>>> <br>>> <br>>> <br></leves@caesar.elte.hu></asqueaker@gmail.com></nicolas.cellier.aka.nice@gmail.com></squeak-dev@lists.squeakfoundation.org></frank.shearar@gmail.com></marcel.taeumel@hpi.de></div></blockquote>
                                        </div></body>