Hi Nicolai,

On Tue, Feb 23, 2016 at 7:37 AM, Nicolai Hess <nicolaihess@gmail.com> wrote:

2015-11-20 22:57 GMT+01:00 Eliot Miranda <eliot.miranda@gmail.com>:

Hi Nicolai,

On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:

GTDummyExamples class
d: anInteger
������ <gtExample>
������ <label: 'Dummy #d:, depends #c:'>
������ <description: 'should raise an exception as the argument is not anInteger'>
������ <depends: #c:>
������ <raises: Literal constant expected -> MessageNotUnderstood>
������
������ ^ 1 + anInteger

The old Parser complains about the class name "MessageNotUnderstood" used as a pragma

argument without being a string or symbol

Opal does not complain

Is Opals behavior intended ?

IMO no.�� The pragma design is that the only valid syntax is of a message pattern with only literal arguments except for the one piece of syntactic sugar where the error temporary name in a primitive call with an error can be given as an identifier, e.g.

But this means smalltalks scanner and parser needs some very special handling just for this pragma.

It turns out to be not that bad. ��because all the pragmas with error codes are associated with methods that have primitives (either a numbered primitive or a named primitive from a plaugin) the parser has to handle them specially anyway.�� So here's what the code looks like in Squeak's compiler:

Parser class>>primitivePragmaSelectors

"Answer the selectors of pragmas that specify VM primitives.

Needed for compile and decomple."

^#(primitive:

primitive:error:

primitive:error:module:

primitive:module:

primitive:module:error:)

and then for each of those there's a method such as

Parser>>primitive: aNameString module: aModuleStringOrNil error: errorCodeVariableOrNil

"Create named primitive with optional error code."

(aNameString isString and: [ aModuleStringOrNil isNil or: [ aModuleStringOrNil isString ] ])

ifFalse: [ ^ self expected: 'Named primitive' ].

self allocateLiteral: (Array��

with: (aModuleStringOrNil isNil��

ifFalse: [ aModuleStringOrNil asSymbol ])

with: aNameString asSymbol

with: 0 with: 0).

errorCodeVariableOrNil ifNotNil:

[encoder floatTemp: (encoder bindTemp: errorCodeVariableOrNil) nowHasDef].

^117

that answers the number of the primitive for the method.�� So there are three methods that contain "errorCodeVariableOrNil ifNotNil: [encoder floatTemp: (encoder bindTemp: errorCodeVariableOrNil) nowHasDef]" to declare the error temp.�� I think that's acceptable.�� What do you think?

Scanner and/or parser explicit check for the name

<primitive: ....>

of the pragma of this error var.

��

Right, which is why it is simple to handle.

addressField

<primitive: 'primAddressField' module: 'IA32ABI' error: errorCode>

^self primitiveFailed

instead of��

addressField

<primitive: 'primAddressField' module: 'IA32ABI' error: 'errorCode'>

^self primitiveFailed

The issues are class reference, class redefinition, class removal etc.�� I guess we could extend the pragma syntax to allow class references but there's a lot of impact.�� I would prefer if we keep things restricted.�� There's nothing to stop one using a symbol and mapping it to a class name, e.g.

GTDummyExamples class
d: anInteger
������ <gtExample>
������ <label: 'Dummy #d:, depends #c:'>
������ <description: 'should raise an exception as the argument is not anInteger'>
������ <depends: #c:>
������ <raises: #MessageNotUnderstood>
��������
������ ^ 1 + anInteger

Also, I *hate* this style of pragma.�� Why not

GTDummyExamples class
d: anInteger
������ <gtExampleLabel: 'Dummy #d:, depends #c:'
�� �� ��description: 'should raise an exception as the argument is not anInteger'
�� �� ��depends: #c:
�� �� ��raises: #MessageNotUnderstood>
��������
������ ^ 1 + anInteger

?

That's how the system is designed to be used.�� Then the message can be implemented by a builder which performs the selector from a visitor.

From squeaks bugtracker : http://bugs.squeak.org/view.php?id=7770

Cascading message sends to super.

Compiler refuses to compile
super
��������initialize;
��������setListProperties

It looks like Opal would compile this to

super initialize.

super setListProperties.

Intended ? Do we want to keep it?

NBNativeCodeGen
parseOptions: optionsArray

uses association symbol -> block instead of block -> block

for caseOf arguments.

The old parser does not accept this.

--

_,,,^..^,,,_

best,��Eliot

--

_,,,^..^,,,_

best,��Eliot