Pragma syntax

Andrew Tween amtween at hotmail.com
Fri Aug 18 14:29:56 UTC 2006


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


> > 1. Doesn't help avoid typing errors
> >     I had in mind that only anything that didn't begin <primitive: or
<pragma:
> > would be rejected by the compiler, unless there was a compiler extension
(e.g.
> > FFI that added others - <cdecl: etc).
>
> My point was that there are not only primitives that can be
> misspelled, but any other pragma as well and that kind of misspelling
> is a possible cause for bugs.
>
> > 2. More verbose.
> >     Yes, but is that necessarily a bad thing? I mean <primitive: 1> could be
> > written <1>, but I don't think it's better.
>
> "A pragma is a message-send composed of a selector and a literal array
> of arguments."
>
> <1> and the FFI syntax don't comply to this definition.


If that is the definition, then aren't  <+ 2>  , << 'a'>  and  <> 4> also
pragmas?
It would be nicely consistent if they were.



>
> > 3. Incompatible with other implementations.
> >      Compatibility is a good thing to strive for. Maybe it is part of the
ANSI
> > standard? (I don't know, I'd have to check)
>
> Pragmas are not part of ANSI, neither are primitives or FFI. It is
> just that the most important commercial competitor of Squeak
> (VisualWorks) is using this syntax. There are other Smalltalk using it
> as well, so it is a quasi standard, I would say.
>
> > the case of FFI, maintained). Here I am thinking of my sql example. <sql:
select
> > * from table>.
>
> Put the SQL inside a string <sql: 'select * from table'>. If we allow
> anybody to build its own pragma syntax, everybody has to extend/patch
> the compilers, the parsers, the syntax highlighters, the code
> completors, the decompilers, etc. For me it doesn't makes sense to
> allow this kind of customization, it complicates things. A pragma is a
> message-send composed of a selector and a literal array of arguments:
> this is simple, powerful and nicely integrates with the existing
> Smalltalk syntax and tools.
>
> > rather than a special <sql: type thing. My idea was to give equal status to
> > primitives, pragmas, FFI, and anything else that comes along later. The
current
> > pragma syntax tries to force everything to be a pragma, which seems to me to
be
> > a bad thing, and I was trying to come up with a way of avoiding that.
>
> Yes, what makes things simpler, because you only need one parser, one
> compiler, one syntax highlighter, one code competition, one decompiler
> and all those tool work well together with the system without having
> to extend and patch them.
>
> Btw, did you know that you get a list of all primitive functions if
> you look for the senders of #primitive:module: in a 3.9 image? That
> wouldn't work so nicely and for free if a primitive wouldn't be
> modelled using a pragma.

Yes. Free is good.

>
> > On the other hand, I would make a distinction between primitives and
pragmas.
> > Primitives are not pragmas. So they aren't like any other pragma, simply
because
> > they aren't pragmas.
>
> I do model primitives as pragmas. I do love it. It completely makes
> sense. It is done like this in 3.9 (except for FFI). It makes the
> compiler much simpler. It nicely integrates with the tools.

ok. You've convinced me,  I suspected that you would :)
Cheers,
Andy

>
> > > - Introduce a similar correction mechanism for pragmas as we do for
> > > message selectors that are unknown to the system. This would pop-up a
> > > message in case the pragma is not already known to the system and
> > > allow the user to proceed or correct it. I think this would be a nice
> > > solution, though it has the drawback that once you misspelled your
> > > pragma you don't get a warning anymore.
> >
> > That seems like a better solution.
>
> I can come up with a fix for that.
>
> Cheers,
> Lukas
>
> -- 
> Lukas Renggli
> http://www.lukas-renggli.ch
>
>




More information about the Squeak-dev mailing list