The history of VW pragmas?

[Andrei N.Sobchuck]

When pragmas where introduced?
What was the purpose?
Do pragmas exist in other Smalltalk dialects?

[Vassili Bykov]

Post by Andrei N.Sobchuck
When pragmas where introduced?

VisualWorks 3.0

Post by Andrei N.Sobchuck
What was the purpose?

Tag methods with properties one could search for and track their
addition and removal. The first use in VW 3.0 was menu extension methods.

Post by Andrei N.Sobchuck
Do pragmas exist in other Smalltalk dialects?

IBM Smalltalk/Visual Age has something they call pragmas, which appears
as special syntax inside method comments. The purpose seems to be
similar, but nothing else is.

I implemented VisualWorks-like pragmas in Squeak when working with Dan
on the Squeak port of Hobbes he shown at ESUG this year. (Available from
me, free for the asking).

[Avi Bryant]

Post by Vassili Bykov
I implemented VisualWorks-like pragmas in Squeak when working with Dan
on the Squeak port of Hobbes he shown at ESUG this year. (Available from
me, free for the asking).

Why not make this available on SqueakMap? Or if you like, send the
.cs to me and I'll be happy to post it for you.

Avi

[Andrei N.Sobchuck]

Post by Andrei N.Sobchuck
When pragmas where introduced?

VB> VisualWorks 3.0

Is it 1998?

Post by Andrei N.Sobchuck
What was the purpose?

VB> Tag methods with properties one could search for and track their
VB> addition and removal. The first use in VW 3.0 was menu extension methods.

What about DLLCC? I think it uses the pragmas.
There was no such package before VW 3.0 or
it didn't use the pragmas?

[Vassili Bykov]

Post by Andrei N.Sobchuck

Post by Andrei N.Sobchuck
When pragmas where introduced?

VB> VisualWorks 3.0
Is it 1998?

Yes, it was released early that year.

Post by Andrei N.Sobchuck

Post by Andrei N.Sobchuck
What was the purpose?

VB> Tag methods with properties one could search for and track their
VB> addition and removal. The first use in VW 3.0 was menu extension methods.
What about DLLCC? I think it uses the pragmas.
There was no such package before VW 3.0 or
it didn't use the pragmas?

DLLCC was there long before, but it didn't, and still doesn't, use
pragmas. It uses declarations in angle brackets which resemble pragmas
until you look closer.

One difference is that pragmas use a subset of Smalltalk syntax--what
goes inside the brackets is a message send sans the receiver, with any
literal syntax allowed as arguments. In DLLCC, what goes after "<C:" is
a subset of C.

A more important difference is that pragmas are only method labels.
They don't change how a method is executed--Smalltalk code in those
methods runs as usual. In DLLCC and primitive methods (another
pragma-like syntax) the real work is done behind the scenes, and
Smalltalk code is there only for error handling.

[Eliot Miranda]

Post by Vassili Bykov

Post by Andrei N.Sobchuck

Post by Andrei N.Sobchuck
When pragmas where introduced?

VB> VisualWorks 3.0
Is it 1998?

Yes, it was released early that year.

Post by Andrei N.Sobchuck

Post by Andrei N.Sobchuck
What was the purpose?

VB> Tag methods with properties one could search for and track their
VB> addition and removal. The first use in VW 3.0 was menu extension methods.
What about DLLCC? I think it uses the pragmas.
There was no such package before VW 3.0 or
it didn't use the pragmas?

DLLCC was there long before, but it didn't, and still doesn't, use
pragmas. It uses declarations in angle brackets which resemble pragmas
until you look closer.
One difference is that pragmas use a subset of Smalltalk syntax--what
goes inside the brackets is a message send sans the receiver, with any
literal syntax allowed as arguments. In DLLCC, what goes after "<C:" is
a subset of C.
A more important difference is that pragmas are only method labels. They
don't change how a method is executed--Smalltalk code in those methods
runs as usual. In DLLCC and primitive methods (another pragma-like
syntax) the real work is done behind the scenes, and Smalltalk code is
there only for error handling.

I don't buy this. I think of C: being a pragma and the implementation
not having caught up. #exception is a pragma (and implemented as such)
and affects the semantics. The fact that the implementation hasn't
caught up is simply historical. CPOK was introduced before we hit on a
regular implementation scheme for pragmas, at a time when for example
the primitive: pragma was implemented by bits in a method header or
specific bytecodes. If we had to do it over I think we'd be much more
regular, and all primitive: C: et al methods would answer pragma
messages, and we'd write <primitive: 123 errorCode: aTemp> as
<primitive: 123 errorCode: #aTemp>
or
<primitive: 123 errorCode: 'aTemp'>.

At least that's my take on it.

[Vassili Bykov]

Post by Eliot Miranda
I don't buy this. I think of C: being a pragma and the implementation
not having caught up.

Call me a language lawyer, but in that case I am waiting to see BNF of
our syntax that describes things like

<C: DWORD CommDlgExtendedError(void) >

:)

Post by Eliot Miranda
#exception is a pragma (and implemented as such)
and affects the semantics. The fact that the implementation hasn't
caught up is simply historical. CPOK was introduced before we hit on a
regular implementation scheme for pragmas, at a time when for example
the primitive: pragma was implemented by bits in a method header or
specific bytecodes. If we had to do it over I think we'd be much more
regular, and all primitive: C: et al methods would answer pragma
messages, and we'd write <primitive: 123 errorCode: aTemp> as
<primitive: 123 errorCode: #aTemp>
or
<primitive: 123 errorCode: 'aTemp'>.
At least that's my take on it.

We _would_ be regular, but we are not. primitive: is still implemented
by specific bytecodes, produces a regular CompiledMethod, and is not
visible when asking for a method's #attributes. Ditto for C:.

The disagreement is about terminology (or separating intention from
implementation :-). I see how much more attractive it would be to
consider C: and primitive: as pragmas like others, and say pragmas are
anything within angle brackets. Indeed I would prefer to have them that
way. But I can't seriously consider them as such until I can do

Pragma allNamed: #primitive:errorCode: from: Foo to: Object

and use the usual interface of Pragma to reflect on the results.
#primitive: wouldn't be that hard to fit into this common Pragma scheme,
but #primitive:errorCode: might be trickier, and C: even more so with
its silly pseudo-C syntax.

[Eliot Miranda]

Post by Vassili Bykov

Post by Eliot Miranda
I don't buy this. I think of C: being a pragma and the implementation
not having caught up.

Call me a language lawyer, but in that case I am waiting to see BNF of
our syntax that describes things like
<C: DWORD CommDlgExtendedError(void) >

Right. But you'd have no problem with

<C: 'WORD CommDlgExtendedError(void)'>

would you? And being able to get the type string from the pragma
instead of having to parse the method source would be useful also.

Post by Vassili Bykov

Post by Eliot Miranda
#exception is a pragma (and implemented as such) and affects the
semantics. The fact that the implementation hasn't caught up is
simply historical. CPOK was introduced before we hit on a regular
implementation scheme for pragmas, at a time when for example the
primitive: pragma was implemented by bits in a method header or
specific bytecodes. If we had to do it over I think we'd be much more
regular, and all primitive: C: et al methods would answer pragma
messages, and we'd write <primitive: 123 errorCode: aTemp> as
<primitive: 123 errorCode: #aTemp>
or
<primitive: 123 errorCode: 'aTemp'>.
At least that's my take on it.

We _would_ be regular, but we are not. primitive: is still implemented
by specific bytecodes, produces a regular CompiledMethod, and is not
visible when asking for a method's #attributes. Ditto for C:.

And so it does for the unwind methods. Its OK for there to be extra
stuff generated from the pragma. But we need all pragmas to be
accessible as pragmas. Right now primitive:[errorCode:] and C: don't
fit. I think everything else does.

Post by Vassili Bykov
The disagreement is about terminology (or separating intention from
implementation :-). I see how much more attractive it would be to
consider C: and primitive: as pragmas like others, and say pragmas are
anything within angle brackets. Indeed I would prefer to have them that
way. But I can't seriously consider them as such until I can do
Pragma allNamed: #primitive:errorCode: from: Foo to: Object
and use the usual interface of Pragma to reflect on the results.
#primitive: wouldn't be that hard to fit into this common Pragma scheme,
but #primitive:errorCode: might be trickier, and C: even more so with
its silly pseudo-C syntax.

We should definitely do this. We have backward compatibility issues
with both primitive:errorCode: and C: but these are probably minor (i.e.
we can provide auto correct on file-in and parcel load).

[Vassili Bykov]

Post by Eliot Miranda

Post by Vassili Bykov
Call me a language lawyer, but in that case I am waiting to see BNF of
our syntax that describes things like
<C: DWORD CommDlgExtendedError(void) >

Right. But you'd have no problem with
<C: 'WORD CommDlgExtendedError(void)'>
would you? And being able to get the type string from the pragma
instead of having to parse the method source would be useful also.

If we are free to fantasize, I would prefer to toss pseudo-C entirely
and have something like

<function: 'CommDlgExtendedError'
parameterTypes: #()
returnType: 'WORD'> "or #WORD"

IMHO CPOK didn't get it quite right. It uses pseudo-C syntax in methods,
which is cute but has no real advantages and some disadvantages compared
to structured pragmas like the above. Yet it doesn't support C syntax
faithfully enough where it matters: having a .h parser that would handle
complex real-world header files.

[Eliot Miranda]

This post might be inappropriate. Click to display it.

[Paolo Bonzini]

Thanks for the very enlightening history!

Post by Eliot Miranda

Post by Andrei N.Sobchuck
Do pragmas exist in other Smalltalk dialects?

As Vassili said, he did an implementation for Squeak. David Simmons has
done similar stuff in AOS and S#, but VW's pragmas are "just" messages
with literal arguments, whereas his are I think more general XML
annotations.

I have added pragmas to GNU Smalltalk too. Pragmas are called
"annotations" in GNU Smalltalk; there is no pragmas pragma at least
for now. They are a great addition at least in system code and I'm
happy of having mutuated them from VW together with ephemerons.

They're in the current beta releases 2.1x (where x is a letter from a
to g, with 2.1g released today featuring a Gtk+ browser -- shameless
plug). My first usage was to simplify exception handling (in my case
I am also using them to avoid special-casing selector names like
#on:do:), but in a more pluggable way than VisualWorks.

I supply a BlockClosure in the pragma which tells the
exception-handling machinery about the exceptions that a particular
context can catch): I've used this to implement Java exception
handlers, with handlers interspersed with the containing methods'
bytecodes and without search for an "optimal" exception handler (in
#on:do: you can specify a subclass after the superclass, while in Java
your handler would not be executed). GNU Smalltalk implements
unwinding differently (in the VM, with a special primitive), so
there's no need for the <exception: #unwind> pragma there.

[Vassili Bykov]

Post by Paolo Bonzini
I supply a BlockClosure in the pragma which tells the
exception-handling machinery about the exceptions that a particular
context can catch): [...]

This is interesting. What is the scope of such closures?

--Vassili