Eliminating assignments and variable syntax (accessors)
Jarvis, Robert P.
Jarvisb at timken.com
Wed Aug 11 20:39:37 UTC 1999
Given your "indentation as block" rules, would
myMethod
| x y z |
x := 1.
y := 2.
z := 3.
^z
written in your new syntax be equivalent to
myMethod
| x y z |
[ x := 1.
y := 2.
z := 3 ].
^z
(which answers nil) or
myMethod
| x y z |
[ x := 1.
y := 2.
z := 3 ] value.
^z
(which answers 3) written in the current syntax?
Bob Jarvis
The Timken Company
> -----Original Message-----
> From: Lex Spoon [SMTP:lex at cc.gatech.edu]
> Sent: Wednesday, August 11, 1999 1:08 AM
> To: squeak at cs.uiuc.edu
> Subject: Re: Eliminating assignments and variable syntax (accessors)
>
> Stefan Matthias Aust <sma at netsurf.de> wrote:
> > [Indentation as statement continuation]
> >
> > >There is the remaining problem of blocks. Maybe allow blocks with
> > >one statement to be inlined, and force blocks with multiple statements
> > >to have a line per statement?
> >
> > I don't see problems for a parser here. When it detects a [, it knows
> that
> > it has to look for a ]. You can both write the block in one line or in
> the
> > next line - even not indented as the parser knows that there's still
> > something missing. Now if the block contains more than one statement,
> you
> > have to insert new lines.
> >
> > A statement like
> >
> > true ifTrue: [false]
> >
> > would be possible as for example
> >
> > true
> > ifTrue: [false]
> >
> > or even
> >
> > true
> > ifTrue:
> > [false]
> >
>
>
> Okay, but it doesn't seem fully in the spirit of syntax-via-indentation.
> After all, one of the main places python uses indentation is to note the
> start and end of a block, right?
>
> So it might be cool to be able to do something like this:
>
> x<3
> ifTrue:
> y := y + 1
> ifFalse:
> z := z + 1
>
>
> But this doesn't look perfect, either--it takes 5 lines when 3 or even 1
> would do. So, maybe allow the [ ] syntax for blocks that are only one
> statement long?
>
> x < 3
> ifTrue: [ y := y + 1 ]
> ifFalse:
> z := z + 1.
> m := m * m.
>
>
> Lex
More information about the Squeak-dev
mailing list
|