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.

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