On Tue, Feb 23, 2016 at 2:26 PM, Nicolai Hess <nicolaih...@gmail.com> wrote:
> > > 2016-02-23 18:58 GMT+01:00 Eliot Miranda <eliot.mira...@gmail.com>: > >> Hi Nicolai, >> >> On Tue, Feb 23, 2016 at 7:37 AM, Nicolai Hess <nicolaih...@gmail.com> >> wrote: >> >>> >>> >>> 2015-11-20 22:57 GMT+01:00 Eliot Miranda <eliot.mira...@gmail.com>: >>> >>>> Hi Nicolai, >>>> >>>> On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <nicolaih...@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? >> > > 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' > Yes, good point. > > 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? > Right, they produce the same code. > > > >> >>> 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 >> > > -- _,,,^..^,,,_ best, Eliot
