Differences Compiler vs. OpalCompiler (or parser)

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 ?

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.

Hi Nicolai,

On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <[hidden email]> 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

On 20 Nov 2015, at 22:37, Nicolai Hess <[hidden email]> 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 ?

it actually is compiled as a literal… maybe the idea was that it follows how literal arrays work? #(thisisasymbol).

But yes, it it confusing and should be changed.

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 ?

We just use RBParser (or started with RBParser). I think it is intended.

Do we want to keep it?

Yes, I actually like it.

NBNativeCodeGen
parseOptions: optionsArray

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

for caseOf arguments.

The old parser does not accept this.

I would say that we change it to be like the old and change set one user.

Marcus

2015-11-20 22:57 GMT+01:00 Eliot Miranda <[hidden email]>:

Hi Nicolai,

On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <[hidden email]> 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.

 

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

On Sat, Nov 21, 2015 at 3:25 PM, Nicolai Hess <[hidden email]> wrote:

2015-11-20 22:57 GMT+01:00 Eliot Miranda <[hidden email]>:

Hi Nicolai,

On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <[hidden email]> 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.

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

Hi Nicolai,

On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <[hidden email]> 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

2015-11-20 22:57 GMT+01:00 Eliot Miranda <[hidden email]>:

Hi Nicolai,

On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <[hidden email]> 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.

Scanner and/or parser explicit check for the name

<primitive: ....>

of the pragma of this error var.

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

Hi Nicolai,

On Tue, Feb 23, 2016 at 7:37 AM, Nicolai Hess <[hidden email]> wrote:

2015-11-20 22:57 GMT+01:00 Eliot Miranda <[hidden email]>:

Hi Nicolai,

On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <[hidden email]> 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

2016-02-23 18:58 GMT+01:00 Eliot Miranda <[hidden email]>:

Hi Nicolai,

On Tue, Feb 23, 2016 at 7:37 AM, Nicolai Hess <[hidden email]> wrote:

2015-11-20 22:57 GMT+01:00 Eliot Miranda <[hidden email]>:

Hi Nicolai,

On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <[hidden email]> 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?

Hi Eliot,

Yes, thats fine, but this part of the parser is independent from how we use the pragma

For

 <primitive:'func' module:'lib' error:#errorCode>

or
 <primitive:'func' module:'lib' error:errorCode>

or
 <primitive:'func' module:'lib' error:'errorCode'>

the code generation is always the same.

But for getting

 <primitive:'func' module:'lib' error:errorCode>

as valid code, we have to use another special code in

Parser>>#pragmaLiteral: selectorSoFar

"This nicety allows one to supply a primitive error
     temp as a variable name, rather than a string."
    ((selectorSoFar beginsWith: 'primitive:')
     and: [(selectorSoFar endsWith: 'error:')

     and: [hereType == #word]]) ifTrue:
        [^self advance].

without this extra check,

 <primitive:'func' module:'lib' error:errorCode>

would raise an error
'Literal constant expected'

In pharo, opal compilers parser accepts both, errorCode without quote or # and class names.

 <primitive:'func' module:'lib' error:errorCode>  - valid

 <someotherpragma keyword:Point>  - valid too

If I change opals parser to not allow the second pragma, I need some special handlign

for the primitive:module:error: pragma - I don't like this.

Is there any difference between
 <primitive:'func' module:'lib' error:errorCode>

and
 <primitive:'func' module:'lib' error:'errorCode'>

both will generate the same code, right?

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