Hi Andrei,

On Dec 4, 2015, at 11:29 AM, Andrei Chis <chisvasileandrei@gmail.com> wrote:



On Sat, Nov 21, 2015 at 3:25 PM, 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.

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

Thanks eliot

Yes, we have this code too, I think, using the global var instead of a symbol happened by accident.

@andrei (and stefan?) can you check the GTDummyExamples methods
and replace classes with symbol names.

After this is removed I will change the parser to notify about this.

I updated the pragmas to use symbols.

They should be instances of Message, and the Message should hold onto the selector symbol and the argument.  There should also be a Pragma class with an api that supports access.  I'll gather up the relevant Squeak code (including tests) as a guide.  Ok?


Cheers,
Andrei
 

 

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

?

no idea.

 

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