Bijan Parsia <bparsia(a)email.unc.edu> wrote:
> At 10:55 PM -0400 8/11/99, Lex Spoon wrote:
>
> >Well, it's certainly open to discussion :) I'd think it best to count the
> >first indent as just part of method definition. So to get a block inside a
> >method, you'd have to add *another* indentation, like this:
> >
> > myMethod
> > | x y z |
> > x := 1
> > y := 2
> > z := 3
>
> Blargh! That's gross! Imagine the errors! You can't *tell*, without a
> comment, whether this is a misindentation or a block. *Silent*, *SEMANTIC*
> errors due to copy and paste are evil. Python doesn't have *that* problem.
>
Well, I'm sure people would get real careful with how far they indent. And we'd get real good at reading it, too, so long as we don't read source code from *other* smalltalks. When indentation has a lot of significance, it should be as easy to mis-indent as it would to accidentally place a BEGIN keyword in the middle of somewhere: possible but not common.
In fact, it's surely easier for an author to notice an extra tab floating around, than it is for them to notice an extra [ tossed in somewhere.
> >
> >This syntax also works out fine for storing a block into a variable:
> >
> > myMethod
> > | b x y |
> > b :=
> > x := 1
> > y := 2
> > ^b
> >
> >It doesn't *look* real nice, but the fact that it's different is surely a
> >big contributor.
>
> However big a contributer it may be, it's contribution is *totally* swamped
> by the contribution of the intrinsic butt-ugliness of it :) Ugh. Espeically
> with the caret making the "b"s visually misalign!
>
Heheh, well, okay. Can't really argue with you there. :)
Lex