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. 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 >
