On Sat, 16 Feb 2002, Maarten Maartensz wrote:

> Hello Scott, Ned and Bian,
> 
> Thanks for your clear replies that are reproduced below: It was my mistake
> and Scott diagnosed it first (probably he remembered I am on the
> digest-only). 
> 
> My reason to appeal for help, though, is what also puzzled Ned: 
> 
> Intuitively one - if one thinks like me - would expect that the setting of
> an alternative syntax DISPLAY should have NO effect on how the code it
> displays is or is not RUN.

Well, I suspect you're confused :) But with, perhaps, good reason.

The alternative syntax setting uses the same mechanism as the pretty
printer, but it *isn't* merely pretty printing. When you set alternative
syntax, the idea is that you are displaying *and writing* alternative
sytnax. It's like the tiles syntax.
 
> Yet what happens is that otherwise perfectly good code does NOT run when
> the printAlternateSyntax is in effect,

Not quite. *All* the accepted code in the system runs fine. What happens
is perfectly good code doesn't *compile*, in the standard tools affected
by the preference. It *will* compile programmatically if you do it right.

> and that code does run again if it
> is rewritten as printAlternateSyntax prints it. 

Again, it compiles. There's no Smalltalk interpreter in Squeak, but even
if there were, the problem is a parsing level on. Obviously, if you can
parse something, you can't run it, but let's get the locus of the behavior
and the problems it entails correct.

> LIkewise, as Ned found,
> when printAlternateSyntax is NOT in effect, code written according to the
> Alternate style does NOT run.

Yes, a well known affect. You need *some way* of telling the compiler
which syntax you're using. We could have pragms, like SSP. We could have a
little language button, like Hypercard et al (we sorta do) we could have a
special escape syntax, etc.

In point of fact, as I pointed out, you *can* read write both syntaxes at
the same time, albeit in different browsers.

> There probably is a more or less good reason, and as the answers I received
> indicate the cure is quite simple, but it should  be somewhat interesting
> to know that "printAlternateSyntax" if set true appears to enforce "AND
> your code in order to be run by Squeak must be WRITTEN in Alternate Syntax"
> (at least when addressed to the Transcript).

Well, it looks to me to be an artifact 1) of the names of the other prefs
using the same system, and 2) the expectation that if what you print in an
editor screen is syntactically distinct, you need to use that syntax in
that editor.

> So this seems at least "an unintended side effect" of using
> "printAlternateSyntax" that flummoxed me.

"useAlternativeSyntax" would be clearer.

> O, and as to Bijan's reply to my:
> 
> >> Is there a reason for this change, e.g. of a semantical kind, 
> 
> >But it's not at all semantic, it's purely, and trivially, syntactic.
> 
> Yes indeed, I agree - but see above and below: That one's programs suddenly
> stop running altogether if a supposedly purely syntactical feature is
> turned on would seem to my mind "semantical"- but then, having a logician's
> or linguist's understanding of the term "semantical" I am nearly always
> puzzled when Smalltalkers use it (and probably should have used ironical
> quote-marks).

Oh please! I'm a logician too, y'know. It's not correct to call it a
semantic change no matter what, and it's not clear how one is especially
mislead  by having a "logician's understanding".

It seems to me that the failure of understanding that is causing the
(chain) of problems is failing to understand that the problem was the
language processor didn't see a well formed formula. And the processor
even *signals* that it's a syntax error!

I'm not aware of any divergence in use of "syntax" and "semantics" among
squeakers.

You even make clear that you *know* it's syntactic:

"Indeed, I find everywhere that the arguments of methods are now all in
brackets in the code, which is more in line with other languages I know,
but not according what I learned about Smalltalk."

Where is the semantic change? Methods are still methods, arguments are
still arguments. The *only* difference (in that fragment) is that the
arguments are *syntactically distinguished* by brackets (and the method
signatures keywords loose their syntactic mark, the colon).

Right after, you write: 

"Is there a reason for this change, e.g. of a semantical kind,"

Again, it just isn't. Indeed, as syntactic transformations go, it's very
minor, a mere notational varient. On the order of swapping the tilde for
the minus sign to represent "not", rather than switching to reverse polish
notation (though there is a bit of token rearrangement, especially with
the control structures).

The meaning of the programs remains the same (though the pragmatics differ
a bit, as control structures no long wear their message nature on their
syntactic face -- some would argue that do their special compilation, they
*aren't* messages and the altsyntax better reflects their semantics; but
in context semantics is the same in either case...they compile to
precisely the same bytecode).

"useAlternativeSyntax" would, however, be a less confusing name for the
preference. The Balloon help text could be fixed up a tad too.

Cheers,
Bijan Parsia.