Use of Attributes

[Frank Maraite]

Hi Robert et all,

For those reading :

We have found the problem with Meinhards code: there is a problem handling literal character values in Attributes and Switch statements.
In this case the OptionAttribute class expects a literal character followed by a literal string, and this is not handled properly by the compiler.

We will fix this asap.

Robert

I have a discussion with Chris about a bug with chars. What's about the following for one character strings:

'A' is always System.Char
"A" is always System.String.

All other things may remain as it is.

Frank

[robert]

Frank,

'A' is always System.Char
"A" is always System.String.

All other things may remain as it is.

That is exactly what I have in my current build, with the exception that 'B', 'C', '0' etc. are also seen as System.Char (sorry could not resist :cheer: ).

The complete Antlr lexer rule is (and as you can see it quickly becomes quite complicate):

Code: Select all

CHAR_CONST		: ''' ESCAPED_CHARACTER ''';

fragment
ESCAPED_CHARACTER       : NOT_ESCAPE_SINGLE		
			| SIMPLE_ESCAPE_SEQUENCE
			| HEX_ESCAPE_SEQUENCE
			| UNICODE_ESCAPE_SEQUENCE
 			;

fragment 
NOT_ESCAPE_SINGLE	: ~( ''' | '' | 'r' | 'n' )  ;

fragment 
SIMPLE_ESCAPE_SEQUENCE	: '''	// Single quote
			| '"'		// Double quote
			| '\'	// 
			| ''		// Null
			| '' A	// Alert
			| '' B	// backspace
			| '' F	// formfeed
			| '' N	// newline
			| '' R	// linefeed
			| '' T	// tab
			| '' V	// vertical tab


fragment
HEX_ESCAPE_SEQUENCE: '' X  HEX_DIGIT (HEX_DIGIT (HEX_DIGIT (HEX_DIGIT)?)?)?;	// x+ 1 -4 digits

fragment
UNICODE_ESCAPE_SEQUENCE : '' U HEX_DIGIT HEX_DIGIT HEX_DIGIT HEX_DIGIT (HEX_DIGIT HEX_DIGIT HEX_DIGIT HEX_DIGIT)? ;	// u 4 hex or u 8 hex

fragment HEX_DIGIT	: [0-9a-fA-F];

fragment A	: 'a' | 'A';
fragment B	: 'b' | 'B';
fragment F	: 'f' | 'F';
fragment N	: 'n' | 'N';
fragment R	: 'r' | 'R';
fragment T	: 't' | 'T';
fragment U	: 'u' | 'U';
fragment V	: 'v' | 'V';
fragment X	: 'x' | 'X';

Robert

[wriedmann]

Hi Frank,

in legacy code (VO dialect IMHO) there is no char literal, only literal strings.

IMHO the interpretation of the literals should depend on the dialect:
VO dialect: only string literals, delimited both with ' and "
Vulcan and Core dialect: string literals delimited with ", char delimited with '

Another possibility could be a prefix:
c'A' and c"A" are char literals, all others string literals.

But there is a compatibility issue with legacy Vulcan code: there 'A' is always a char literal.

Wolfgang

[robert]

Wolfgang,

Maybe this is something that we can make different for different dialects:

VO (and probably later also for Harbour, Fox etc)
'A' = String

Vulcan and Core:
'A' = Char

And we could indeed add:
All dialects:
c'A' = Char
c"A" = Char (so you can use c"'" to indicate a single quote char)

Robert

[Frank Maraite]

Hi Wolfgang,

Chris mentioned

(Char)'A'

I prefer this over new prefix.

There seems no easy solution. I got an error with one character strings in VO-Array as a parameter to methods that expect System.Object.

Frank

Chris: sorry, I still did not manage a simple example for the bugreport.

[wriedmann]

Hi Robert,

yes, this could be a good idea, I think.

The dialects are very important, and I have a LOT of VO code to move over, and I'm pretty sure there are several places where I have a '"' to be used as string.
On the other side, in legacy Vulcan code, 'A' is always a char literal.

Wolfgang

[robert]

Frank

(Char)'A'

This moves the problem to detect the type of the constant from the lexer phase to the parser phase. I do not like that.
Decisions like this should be handled early in the compiler pipeline, in the Lexer when possible.

Robert

[wriedmann]

Hi Frank,

we have already the "i", "e", "ei" and "ie" prefixes on strings, so "c" seems to be the most logical one (at least to me).
(char) "A" would be only a explicit cast.

Of course, the decision is not ours, but of the devteam.

Wolfgang

[FFF]

+1 for the "c" as for reasoning of cast only

[Frank Maraite]

Hi all,

after reading this completly (but not fully understand the consequences)

https://msdn.microsoft.com/de-de/librar ... .110).aspx

it seem that 'Ä' and "Ä" (german umlaut, but other characters too) is not always the same.

"Ä" maybe one chars or two chars.

Frank, a little bit confused now.