Hi Lukas,
----- Original Message ----- 
From: "Lukas Renggli" <renggli at gmail.com>
To: "The general-purpose Squeak developers list"
<squeak-dev at lists.squeakfoundation.org>
Sent: Sunday, August 20, 2006 1:17 PM
Subject: Re: Re: Re: Re: Re: Re: Pragma syntax


> > Yes. But, there are some potential drawbacks...
> >     1. I cannot write an extension which uses a name that is already in use
by
> > the Parser.
> >         e.g. #notify: , #parse:class: etc.
>
> Yes, but these methods need to be tagged, so the parser/compiler knows
> that these should be called after compilation. All others pragma
> selectors would remain unused and left for interpretation by your
> application.
>
> >     2. It might be a dangerous thing to use one of the method names defined
in
> > Parser's superclasses. e.g. #error:
>
> I think it might make sense to call these methods on the parser, but
> it could be any other class. It just needs to be a fixed place.

Outside the Parser seems, to me, to be better. I am trying to implement some of
my suggestions at the moment. I think that if there is real code that can be
examined, then the discussion will become easier. I'll let you know when I have
something.

>
> >     3. No keyword methods can safely be added to the Parser in the future.
The
> > new method's name might already be in use by an extension. A change to the
> > parser's interface (i.e. the selectors it implements/understands) could
result
> > in an extension, and/or, the parser breaking.
> >
> > Please see my post in the 'Re: An alternative FFI/Parser proposal' thread
for a
> > possible alternative arrangement. What do you think?
>
> I don't see a point in widening the allowed syntax within the angle
> construct. Right now a pragma is using existing Smalltalk construct
> that every newcomer can understand and use.

Yes. But, right now FFI is using something else. And Andreas has said that he
won't change that.
So, currently, the allowed syntax is wider than you want it to be. And it is you
who is arguing for a change towards a narrower syntax.
Now if this discussion had occurred before FFI was created, then your viewpoint
would probably have been accepted. But, the fact remains that FFI exists, isn't
going to change, and so the question isn't what should have happened 5 years
ago, but what should happen now.


>Allowing different
> syntaxes complicates things in different areas. The Smalltalk syntax
> should remain minimal, and not get bloated with new things that nobody
> will understand. There are already many examples where languages got
> destroyed by adding XML, SQL, HTML, ... to the language itself.
> Smalltalk provides different and better ways to change/extend its
> language.

A cynic might suggest that Pragmas are a new thing that extends the syntax. And
given the discussion on "is a primitive a pragma?", there are already different
understandings of what they are.
My argument would be that if something new is going to be added to the language,
then make it as flexible, and powerful, and open as possible. If it is misused,
and people do stupid things with it, and create weird syntax, then so what? I
don't have to use their code if I don't want to. After all, we are talking about
optional extensions here.

>
> To summarize, these are basically two different views:
>
> (1) Pragmas as a syntax extension, where on can put almost anything
> between the angle brackets after an initial keyword selector defining
> the syntax.

Yes. But they aren't, necessarily, Pragmas. By definition. If the thing between
the brackets doesn't conform to the Pragma syntax, then it can't be a Pragma.

>
> (2) Pragmas as a message send with literal arguments.

Those things ARE Pragmas.

>
> I am for the simple and powerful. And this is (2) in my opinion.

I am arguing for the less restrictive, and the more powerful. Which is (1).
Actually, I am arguing for both (1) and (2). Or, rather, that (1) imples (2).
Give me (1) and I can still write Pragmas.
Give me (2) and I can no longer write FFI calls.

Cheers,
Andy

>
> Cheers,
> Lukas
>
> -- 
> Lukas Renggli
> http://www.lukas-renggli.ch
>
>