Pragma syntax

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


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: Friday, August 18, 2006 12:37 PM
Subject: Re: Pragma syntax


> > Why isn't the syntax for pragmas something like this...
> >
> > <pragma: A value: 10>
> > <pragma: a:b: value: {1. 2}>
> > or maybe, <pragma: a: 1 b: 2>
>
> I don't see how this could help to avid typing errors? Moreover it
> makes pragmas much more verbose, incompatible with other
> implementations, and harder to read.

you make 4 points, I'll take them in turn

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).

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.

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)

4. Harder to read.
    For standard pragmas, yes, I would agree with that. But, is readability for
<> constructs that do not fit into the standard pragma syntax improved (or, in
the case of FFI, maintained). Here I am thinking of my sql example. <sql: select
* from table>. It would be less verbose, and easier to read to just write
<select * from table>, but it now looks like a pragma with invalid syntax,
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.

>
> > But if I've made a typo...
> >     <primitive: 'a' moduel: 'b'>
> > I get a pragma. Which is almost certainly not what I wanted.
> > Of course, the compiler could check that if the first part is primitive:
then
> > the second part is module: , but what about...
> >     <primitiv: 1>  [sic]
> > Once again I get a pragma.
>
> I wouldn't do a distinction between pragmas and primitives. In my
> opinion primitive pragmas (in your language code-generating angle
> bracket constructs) are the same as any other pragma, the only
> difference is that they are interpreted by the compiler. This can be
> done in a very clean way as I proposed in the FFI thread.

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.
Note, in my syntax  you could have a pragma named primitive: - <pragma:
primitive: $b> , but this wouldn't have any connection to real primitive calls
(which are code).

>
> Now, assuming that primitive-pragmas are the same as any other pragma,

ok. For the sake of the discussion, I'll make that assumption

> how can we avoid typing mistakes in pragma declarations? Actually this
> problem is not new, it also happened to me several times. Let me
> propose two different solutions:
>
> - In VisualWorks you have to declare pragmas (using pragmas) if you
> want to use them. This would solve the problem, though I don't
> particularly like it because Smalltalk is not about declaring things.
> It also creates new dependencies between code that is not easy to cope
> with. So I don't think this would be a good solution.

agreed.

>
> - 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.

Cheers,
Andy

>
> What do you think?
>
> Cheers,
> Lukas
>
> -- 
> Lukas Renggli
> http://www.lukas-renggli.ch
>
>




More information about the Squeak-dev mailing list