RE: Does VW claim is it an ANSI compliant Smalltalk?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

RE: Does VW claim is it an ANSI compliant Smalltalk?

Terry Raymond
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

Reply | Threaded
Open this post in threaded view
|

Re: Does VW claim is it an ANSI compliant Smalltalk?

Reinout Heeck
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
-

Reply | Threaded
Open this post in threaded view
|

[vw-tech]Making it easier to manage these threads

Conor Shankey
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

Reply | Threaded
Open this post in threaded view
|

Re: [vw-tech]Making it easier to manage these threads

Holger Kleinsorgen-4
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

Reply | Threaded
Open this post in threaded view
|

RE: [vw-tech]Making it easier to manage these threads

Steven Kelly
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