Travis, Steve
Well, as long as you brought it up, recently Eliot posted a message to c.l.s about parsing some St expressions and made the point that without interveing white space some smalltalk expressions are difficult to parse. I would like to see this "anomaly" cleaned up. Basically, I think it would be a good idea to set the goal of requiring all binary operators and keywords to be separated by whitespace. My thought would be to begin by updating Smalllint tests so developers would be alerted and change their habits. Additionally, we could have rewrite rules that would fix existing code. I would think that by having optional compiler settings and using code tools we could improve the syntax in this area and migrate existing code with minimal pain. Terry =========================================================== Terry Raymond Smalltalk Professional Debug Package Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On > Behalf Of Steve Dahl > Sent: Wednesday, May 10, 2006 10:06 PM > To: Travis Griggs > Cc: VW DEV > Subject: Re: Does VW claim is it an ANSI compliant Smalltalk? > > > VW claims that it is somewhat ANSI-compliant, and that it wants to > become more-so over time, but not at the expense of: > - motherhood and apple pie > - some other project that looked like it would benefit customers more > than a little more ANSI compliance > - breaking customers' code in ways that cost us more good will than we > earn from adding the ANSI feature. > > In the case of binary selectors, it's been the third one that's caused > us to at least hesitate. > > ANSI, as I recall it, specifies arbitrary length binary selectors, no > restrictions. VisualWorks indeed says that binary selectors can't be > longer than two characters, but more importantly, it says that if a > binary selector ends with a -, it can only be one character long. > > This is important because - is also a unary prefix for constant numbers. > If we don't make this restriction, then "3@-4" would be interpreted as > "3 @- 4" rather than "3 @ -4". I think there are three places where > customers could get bit by this (but there might be more): > > - source code of methods > - storeStrings of objects, perhaps stored in a database > - code generators, including but not limited to SomeClass>>storeOn:, > UIDefiner, and BrowserNavigator's code for creating default methods in > classes > > Addressing all three of these to customers' satisfaction sounds hard to > me, although I could be wrong. What would be much easier would be if we > adopted only partial ANSI compliance: we allow arbitrary length of > binary selectors, but only if the last character is not -. The only > binary selector that would be allowed to end in - is #-. > > So #<--->, #--->, and #&!@?/ would be valid binary selectors, but #<--- > would not, because its last character is -. This is essentially > completely backward compatible with all existing VW code, but it's not > 100% ANSI-compatible. Older versions of VW would not be able to file in > new VW code that used long binary selectors, but that's about the only > place existing code would break. > > The question, for Travis and for anyone else interested, is whether this > is ANSI enough. Has anyone here seen, in some other Smalltalk, a use of > a long binary selector ending in -, that was not merely testing the > limits of binary selectors, but ended in - for a good reason? If we > disallowed long binary selectors ending in -, would you ever expect code > written in some other Smalltalk to contain a banned selector? > > > Travis Griggs wrote: > > > > I was just reading the spec and noting that binary selectors should be > > one or more infix characters, no length limit. But it still seems to be > > the case that we're limited to 2. > > > > I might want a shortcut for error: aString ya know: > > > > self ?!?!?!? aString > > > > :) > > > > -- > > Travis Griggs > > Objologist > > "You A students, you'll be back soon teaching here with me. You B > > students, you'll actually go on to be real engineers. You C students, > > you'll go into management and tell the A and B students what to do." - > > My Fluid Dynamics Professor whom I have yet to disprove > > > > > > > > ----------------------------------------- > > DISCLAIMER: This email is bound by the terms and conditions > > described at > > http://www.key.net/disclaimer.htm |
Terry Raymond wrote:
> Travis, Steve > > Well, as long as you brought it up, recently Eliot posted > a message to c.l.s about parsing some St expressions and > made the point that without interveing white space some > smalltalk expressions are difficult to parse. I would like > to see this "anomaly" cleaned up. Basically, I think it > would be a good idea to set the goal of requiring all > binary operators and keywords to be separated by whitespace. IMO this is like having the wagon drag the horse. In essence you are saying that because tokenization is too hard everybody needs to rewrite their code to make tokenizing easier. The 'right' solution is to eliminate the problem altogether for example by removing tokenization altogether, simply hand single characters to the parser. This technique has been tried in the SGLR/SDF project with great success. Read up at http://www.program-transformation.org/Transform/ScannerlessGeneralizedLRParsing and http://www.program-transformation.org/Sdf/WebHome Note at the latter link that they succeeded to make grammars modularized as well: you can add to a grammar without respecifying (copy-paste) the existing grammar you want to extend, and conversely mix a single extension into multiple existing grammars - a big win compared to classical parser generator architectures like SmaCC. Another interesting fall-out of having such a generalized parser and a modularized syntax definition is the Meta Borg approach to embedding DSLs: http://www.program-transformation.org/Stratego/MetaBorg R - |
I was wondering if we could adopt a naming convention for e-mail on this
e-mail thread. James, I am assuming that you are the "moderator". Could you suggest a subject standard such as beginning with "[vw-tech]" so that the end-user can either use an e-mail filter or even just sort these e-mails to group them together. I get enough each day that it is time consuming to sort them out of my other e-mail. I don't think the "tag" really manners too much as long as it makes sense to everyone and isn't used for another discussion thread. Conor |
Conor Shankey wrote:
> I was wondering if we could adopt a naming convention for e-mail on this > e-mail thread. James, I am assuming that you are the "moderator". Could you > suggest a subject standard such as beginning with "[vw-tech]" so that the > end-user can either use an e-mail filter or even just sort these e-mails to > group them together. I get enough each day that it is time consuming to sort > them out of my other e-mail. I don't think the "tag" really manners too much > as long as it makes sense to everyone and isn't used for another discussion > thread. I simply use a filter that moves all mails with "to cc [hidden email]" to a seperate folder. Works like a charm. Holger |
In reply to this post by Conor Shankey
Conor,
This isn't a moderated list per se. People do use tags sometimes, mostly to indicate which VW version their message refers to. If you mean you'd like every single message to carry an extra tag to say it's from the vwnc list, there are other less intrusive ways to accomplish the same thing. For instance, all emails you receive from the list come with extra headers like this: Resent-From: [hidden email] X-Mailing-List: <[hidden email]> archive/latest/18493 X-Loop: [hidden email] Precedence: list Resent-Sender: [hidden email] Return-Path: [hidden email] I - like you - use Outlook. I made a rule (Tools | Rules Wizard) to search for [hidden email] in the headers. "Move new messages from someone", "with specific words in the message header". Cheers, Steve > -----Original Message----- > From: Conor Shankey [mailto:[hidden email]] > Sent: 15 May 2006 23:07 > To: [hidden email] > Subject: [vw-tech]Making it easier to manage these threads > > I was wondering if we could adopt a naming convention for e-mail on this > e-mail thread. James, I am assuming that you are the "moderator". Could > you > suggest a subject standard such as beginning with "[vw-tech]" so that the > end-user can either use an e-mail filter or even just sort these e-mails > to > group them together. I get enough each day that it is time consuming to > sort > them out of my other e-mail. I don't think the "tag" really manners too > much > as long as it makes sense to everyone and isn't used for another > discussion > thread. > > Conor |
Free forum by Nabble | Edit this page |