Thread: Idea for new literal

C11 only specifies these encoding prefixes for string literals: u8, u, U, L. Hence, your b# and B# encoding prefixes would not conflict as a language extension.

The syntax specified by the standard does not provide for encoding suffixes, and you may have to consider that adjacent string literals are concatenated, so there would be conflict between your choice of L for a suffix and the standard use of L for a prefix. It may be simpler to just incorporate this into the prefix.

Another consideration is that you have what appears to be a string literal, but from 'an example is b2"-1001" will result in -9' it sounds like you have in mind integer literals. If so, this is likely to be a bad idea because it introduces inconsistency and hence possible confusion. On the other hand, if you introduce entirely different syntax to generalise integer constants, it would be yet another new syntax to learn and parse for, whereas this language extension only (?) requires understanding that the type is wildly different from what one would expect from a string literal.

Personally, I think reusing string literals for integer constants is the kind of thing that language designers will get mercilessly mocked for ten years down the road, but in the end its your choice since you're the one implementing the language extension. (And whos's to say if people will or will not like whatever alternative you might come up with? Programmers can be quite a critical bunch when it comes to their pet language peeves.)

Originally Posted by laserlight

C11 only specifies these encoding prefixes for string literals: u8, u, U, L. Hence, your b# and B# encoding prefixes would not conflict as a language extension.

Thought so, just needed to be sure

Originally Posted by laserlight

The syntax specified by the standard does not provide for encoding suffixes, and you may have to consider that adjacent string literals are concatenated, so there would be conflict between your choice of L for a suffix and the standard use of L for a prefix. It may be simpler to just incorporate this into the prefix.

To begin with this is supposed a new literal standard so a non-conforming compiler should & would actually abort compile at this point and just chuck out errors instead so I'm not too worried about that, also since I'm writing my own precompiler for this anyways peops could just use that first then pass the result onto gcc if they wanted to, either way the compiler I'm trying to write will support it properly and treat any string literals using l or L as a suffix as invalid and abort compile leaving only the errors & warnings, I originally considered extending 0b & 0B to do something similar but then it occured to me that it could confuse decimal as binary and even confuse where the base ends and the number begins, a clear means of distinguishing the value is needed to understand which base to expect, string literals were my first thought because they be macro'd into a somewhat graceful fallback to a function call instead like so:

Code:

#ifdef __misty__
#define UBASE( BASE, VAL, SFX ) b##BASE##VAL##SFX
#else
#define UBASE( BASE, VAL, SFX ) ubasestr( BASE, VAL, #SFX )
#endif
// Terrible way to use this but fully possible
int main() { return UBASE(10,"0"); }

Originally Posted by laserlight

Another consideration is that you have what appears to be a string literal, but from 'an example is b2"-1001" will result in -9' it sounds like you have in mind integer literals. If so, this is likely to be a bad idea because it introduces inconsistency and hence possible confusion. On the other hand, if you introduce entirely different syntax to generalise integer constants, it would be yet another new syntax to learn and parse for, whereas this language extension only (?) requires understanding that the type is wildly different from what one would expect from a string literal.

Well the other possibility I can think of is using the ' character, compilers will definetly complain about the length and lining it up with 'names', also generally understood to equate to an integer, fully trivial to switch to in my code so not an issue there either.

Originally Posted by laserlight

Personally, I think reusing string literals for integer constants is the kind of thing that language designers will get mercilessly mocked for ten years down the road, but in the end its your choice since you're the one implementing the language extension. (And whos's to say if people will or will not like whatever alternative you might come up with? Programmers can be quite a critical bunch when it comes to their pet language peeves.)

They can mock me all they like, I at least tried to come up with something suitable and even consulted others for their ideas and/or concerns (this thread being only instance thus far), I'd like to see them do better.

New idea, no using string either, definitely causes an error with cc (presumably redirecting to gcc) as I've just tested it:

Code:

0~62~z