If I build one of my lexical rules in the following form:

SYMBOL = (‘A’ | ‘B’ | ‘C’ | ‘D’ | ‘E’ | ‘F’ | ‘G’)

to allow for case-insensitive alteration between these elements, I get the following error:

BUILD FAILED
C:\development\DSL\DSL\SCLT\build.generated.xml:435: The following error occurred while executing this line:
bundleresource://1061.fwk257260599:26/org/strategoxt/antcontrib/strategoxt-antlib.xml:56: The following error occurred while executing this line:
bundleresource://1061.fwk257260599:26/org/strategoxt/antcontrib/strategoxt-antlib.xml:58: org.strategoxt.lang.StrategoException: Exception in execution of primitive ‘SSL_newname’

If I reduce the amount of case-insensitive elements in this rule to 5 or lower the error disappears, either by deleting elements or turning them into case sensitive.

Submitted on 4 September 2015 at 17:23

On 4 September 2015 at 17:33 Eelco Visser commented:

Have you tried using character classes, e.g. [A-G]?


On 4 September 2015 at 17:42 Jeffrey Goderie commented:

Well, in the example that would be possible, my bad, but in the actual language this involves strings:

TYPE = (‘BOOL’ | ‘INT’ | …. | ‘STRING’)

Doing this in character classes become pretty large and unreadable. It is by-passable by splitting the alternatives over 2 lexical rules with the same name, so it is not unfixable, but I figured I would inform you about the errors I encountered.


On 4 September 2015 at 18:02 Eelco Visser commented:

Ah, so this

TYPE = ‘BOOL’
TYPE = ‘INT’

TYPE = ‘STRING’

fixes it?

Shouldn’t you use context-free rules for these anyway? That would give you constructors instead of string literals.

TYPE.BoolT = ‘BOOL’

(And as a matter of style, using capitalized (e.g. Type) as opposed to all-caps sorts gives more readable syntax definitions.)


On 4 September 2015 at 18:25 Jeffrey Goderie commented:

The full rule is:

Constant = (‘BOOL’ | ‘BYTE’ | ‘WORD’ | ‘DWORD’ | ‘DW’ | ‘B’ | ‘W’) ’#" [0-9]+

So it’s actually a value(-identifier) in the PLC language, and as such is part of the lexical syntax, at least in the provided syntax.

My examples were a bit cryptic because I didn’t know whether CERN had any confidentiality rules, but apparently they don’t. And as for the fix, even:

Constant = (‘BOOL’ | ‘BYTE’ | ‘WORD’ | ‘DWORD’) # [0-9]+
Constant = (‘B’ | ‘W’ | ‘DW’) # [0-9]+

fixes it, as long as there are 5 or less case-insensitive elements (in the same alternatives-section, haven’t tested otherwise)


On 4 September 2015 at 20:05 Jeff Smits commented:

I just avoid the | at all times, because it (at least used to) blow up build. I vaguely remember there was a legacy SDF grammar transformation that would consider ‘BOOL’ | ‘BYTE’ | ‘WORD’ | ‘DWORD’ | ‘DW’ | ‘B’ | ‘W’ a single sort and generates these rules:

‘BOOL’ | ‘BYTE’ | ‘WORD’ | ‘DWORD’ | ‘DW’ | ‘B’ | ‘W’ = ‘W’
‘BOOL’ | ‘BYTE’ | ‘WORD’ | ‘DWORD’ | ‘DW’ | ‘B’ | ‘W’ = ‘BOOL’ | ‘BYTE’ | ‘WORD’ | ‘DWORD’ | ‘DW’ | ‘B’

‘BOOL’ | ‘BYTE’ | ‘WORD’ | ‘DWORD’ | ‘DW’ | ‘B’ = ‘B’
‘BOOL’ | ‘BYTE’ | ‘WORD’ | ‘DWORD’ | ‘DW’ | ‘B’ = ‘BOOL’ | ‘BYTE’ | ‘WORD’ | ‘DWORD’ | ‘DW’

‘BOOL’ | ‘BYTE’ | ‘WORD’ | ‘DWORD’ | ‘DW’ = ‘DW’
‘BOOL’ | ‘BYTE’ | ‘WORD’ | ‘DWORD’ | ‘DW’ = ‘BOOL’ | ‘BYTE’ | ‘WORD’ | ‘DWORD’

‘BOOL’ | ‘BYTE’ | ‘WORD’ | ‘DWORD’ = ‘DWORD’
‘BOOL’ | ‘BYTE’ | ‘WORD’ | ‘DWORD’ = ‘BOOL’ | ‘BYTE’ | ‘WORD’

‘BOOL’ | ‘BYTE’ | ‘WORD’ = ‘WORD’
‘BOOL’ | ‘BYTE’ | ‘WORD’ = ‘BOOL’ | ‘BYTE’

‘BOOL’ | ‘BYTE’ = ‘BYTE’
‘BOOL’ | ‘BYTE’ = ‘BOOL’

I’m not sure this legacy transformation still exists in the newest Spoofax. But it’s better to write the new sort yourself and do:

Constant = TYPE '#' [0-9]+
TYPE = 'BOOL'
TYPE = 'BYTE'
TYPE = 'WORD'
TYPE = 'DWORD'
TYPE = 'DW'
TYPE = 'B'
TYPE = 'W'

On 4 September 2015 at 22:00 Jeffrey Goderie commented:

Thanks for the advice, @jeffsmits and @eelcovisser, I will definitely use it!

Log in to post comments