Mats Nygren wrote:

> quite difficult to achieve. There is no parse tree as such, it is

I don't really see what you mean. I use the parse tree for all kinds of
things, or more specifically program transformations, in my partial
evaluator.

> intimately connected with code generation,

The only problem I have is that the message macro transformations are
applied onto the tree, but I've thought a simple switch might be added that
prevents these from being applied unless you want them. But you are right
that a few corners have been cut when the code generation was built into the
parse tree.

> and then when a change to
> another syntax is done (CCodeGeneration) another tree is built.

This isn't strictly necessary IIRC. I once looked rather closely at the T*
parse node classes, and couldn't see any significant reason why the ordinary
parse trees couldn't be used. And the small differences that are there are
IIRC related to the different semantics of C, not the syntax.

>> Maybe this is the wrong place to bring this up, but I think that the
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> emphasis that is often put on syntax is generally misplaced
...
> I didnt put an emphasis on syntax, the emphasis is on separating syntax
> from sematics as was clearly expressed in the posting.

Which is why I hedged myself as above. I was not saying that you did this;
it was merely leading to the point that changing the syntax is not as big a
help for novices as may be thought.

>> If I were to make eg. Squeak more accessible to beginners, say, changing the
>> syntax would probably not list among the ten to twenty first items. Other
>> things would easily have much greater effect.
> 
> Would you say then that for someone who knows another syntax it is no
> advantage to be able to use that other syntax? For instance writing "2*x
> + 2*y" instead of "(2*x)+(2*y)"

No. I would say as I said, namely that this would not be among the ten to
twenty greatest (or in other cases, easiest-to-achieve) improvements for
novices.

You give a terrific example of what I meant by "first impressions".
Precedence may lower the barriers of resistance in the very beginning, but
very soon you have to deal with the general precedence rules for messages,
so then the advantage is lost, perhaps this even makes things worse since
special operator precedence breaks these rules. It almost tricks the novice
to believe that the messages are instead ordinary programming language
statements.

As you know, Smalltalk lets you easily define new operators in a way that
eg. Java doesn't, so the general rules are much more important here. And I
still haven't learned the C precedence rules after 15 years. With Smalltalk
this is _so_ simple: 1 operand is before 2 is before all other higher
operand counts. So I'd speculate that giving people the _reason_ will make
them understand the "awkward precedence" that is actually an extremely
consistent and simple scheme.

In essence, short-term gains are quickly lost, perhaps even
counter-productive. Learning-wise, and speaking of cognition in general,
syntax is just the surface, the important part is the underlying conceptual
model of object orientation, and its concepts such as message passing.
Disguising message passing under Algol-style syntax obscures this model. It
is probably no coincident that lots of people, including Bjarne himself (not
Bjarne Parsia, the other one), complain that C++ and Java are still used by
the majority merely as spiced-up C, instead of in the real OO way, where the
true benefits lie.

>> Very often the syntax is seen as the greatest obstacle in adopting a new
>> language. 
> 
> If that is so and it is a solved problem I say: start using this
> solution and remove that particular obstacle to adopting a new language.

I'm afraid you misunderstood me. I wrote that it is often _seen_ as the
greatest obstacle by people who try to make learning easier, because
intuition seems to tell us so. But in fact it is not, as has been
demonstrated several times. There is an entire subfield of science known as
"the psychology of programming". A very boring one, believe me, much because
all they have been able to prove is that nothing that they've tried has
really made a difference, beyond what is obvious anyway (such as OO being a
great idea). Of course, one of the greatest conceptual advances in
programming was OO, because it changed the conceptual level.

I can see that you read this as the _novices_ seeing it as an obstacle, and
therefore to remove it, but my point here is that this will become a problem
in the longer run.

>> The syntax difference is surely the first one you
>> notice, but this is just a first-impressions issue in my opinion. As Yogi
>> Berra might have said, the surface is only skin-deep. The more important
>> issues are, indeed, deeper.
> 
> I agree, to some extent, about the superficialness of syntax, however we
> all know that extremely little code can be moved without effort from one
> environment to another, not even between dialects of Smalltalk.

Exactly, and this isn't because of the syntax but the differences in class
structure and protocols. This is why I doubt that enforcing := or adding
underscores will be of much help for cross-dialect portability (oops, now I
gave away my opinion on that topic).

> So much
> less is it possible to solve the deeper issues if not even this can be
> done. If syntax is only skin deep then many programmers are racists. My
> point is, it shouldnt be the skin, it should be the clothes.

Hmm, a drastic analogy if there ever was one, but this begs the question,
shouldn't we adress the real issue of 'racism', and help them to see that it
is really the inside that matters, just like their mothers told them,
instead of covering up the problem, literally, by dressing the foreign
elements in new clothes.

> As for your insinuations they do nothing to improve the discussion.
> 

Whoa. I'm sorry, what did you regard as insinuations? I put in smileys, even
double ones, so that it would be clear that I was joking. I try not to take
myself too seriously.

Henrik

PS. Looking forward to your postings on functional programming.