View mode: basic / threaded / horizontal-split · Log in · Help
May 30, 2007
Suffix-based literal syntax
Here's a small thought to improve the syntax for some user-defined 
types: can we perhaps overload the suffix on literals, to give some user 
types nicer literals?

One of Walter's rationale for natively supporting complex numbers is to 
get nice looking literals:
   3 + 5i
 instead of
   3 + 5 * i
 or the more realistic
   complex(3, 5)


I propose that, for number and string literals (which already sport 
suffixes at the moment) if a suffix is found not from the language, it 
be rewritten as an opSuffix call, so
       5km
   turns into
       opSuff_km(5)

For reasons of sanity, the suffix should probably only be alphabetical, 
upper and lower case.


This isn't a general solution to literals for user types, but I can 
imagine it as useful for:

1. Complex numbers:
You could get the same syntax as we currently get, but in a library. 
That seems pretty impressive.

2. SI units libraries:
Instead of (acceptable) 5 * km, you can write 5km as a literal.

3. Some kind of native type wrapper:
Perhaps for dstring, or some other class that wraps strings, you could 
write:
   "foo"s
denoting a dstring literal, as opposed to char[]/wchar[]/dchar[] literal.

Similarly, you might want to write a vector class for this:
    [5, 4, 3]v
being the same as Vec([5, 4, 3]) but much more visually pleasing.

4. Wacky syntax extensions. I remember seeing Bill Baxter use the suffix 
'i' to denote 'inclusive' for ranges. I'm sure many other (ab)uses could 
come to mind.

----

If problems come with suffix clashes, renaming of imports could help:

import foo.string: opSuff_fs = opSuff_s;
import bar.string: opSuff_bs = opSuff_s;

...
auto a = "abc"fs; // a is a foo string
auto b = "abc"bs; // b is a bar string


I think it's kind of a nice idea, since it can give some user types a 
nicer syntax without creating any new ambiguities.


Of course, given how much is going on with const et al at the moment, I 
don't expect anything to come of this at the moment, but I hope someone 
likes it.


   -- Reiner
May 30, 2007
Re: Suffix-based literal syntax
Reiner Pope wrote:
> I propose that, for number and string literals
That should be number, string and (associative) array literals.
May 30, 2007
Re: Suffix-based literal syntax
I like it; it'd make working with JNI types a lot easier. Would this work with the current parser, though?

Reiner Pope Wrote:

> Here's a small thought to improve the syntax for some user-defined 
> types: can we perhaps overload the suffix on literals, to give some user 
> types nicer literals?
> 
> One of Walter's rationale for natively supporting complex numbers is to 
> get nice looking literals:
>     3 + 5i
>   instead of
>     3 + 5 * i
>   or the more realistic
>     complex(3, 5)
> 
> 
> I propose that, for number and string literals (which already sport 
> suffixes at the moment) if a suffix is found not from the language, it 
> be rewritten as an opSuffix call, so
>         5km
>     turns into
>         opSuff_km(5)
> 
> For reasons of sanity, the suffix should probably only be alphabetical, 
> upper and lower case.
> 
> 
> This isn't a general solution to literals for user types, but I can 
> imagine it as useful for:
> 
> 1. Complex numbers:
> You could get the same syntax as we currently get, but in a library. 
> That seems pretty impressive.
> 
> 2. SI units libraries:
> Instead of (acceptable) 5 * km, you can write 5km as a literal.
> 
> 3. Some kind of native type wrapper:
> Perhaps for dstring, or some other class that wraps strings, you could 
> write:
>     "foo"s
> denoting a dstring literal, as opposed to char[]/wchar[]/dchar[] literal.
> 
> Similarly, you might want to write a vector class for this:
>      [5, 4, 3]v
> being the same as Vec([5, 4, 3]) but much more visually pleasing.
> 
> 4. Wacky syntax extensions. I remember seeing Bill Baxter use the suffix 
> 'i' to denote 'inclusive' for ranges. I'm sure many other (ab)uses could 
> come to mind.
> 
> ----
> 
> If problems come with suffix clashes, renaming of imports could help:
> 
> import foo.string: opSuff_fs = opSuff_s;
> import bar.string: opSuff_bs = opSuff_s;
> 
> ...
> auto a = "abc"fs; // a is a foo string
> auto b = "abc"bs; // b is a bar string
> 
> 
> I think it's kind of a nice idea, since it can give some user types a 
> nicer syntax without creating any new ambiguities.
> 
> 
> Of course, given how much is going on with const et al at the moment, I 
> don't expect anything to come of this at the moment, but I hope someone 
> likes it.
> 
> 
>     -- Reiner
May 30, 2007
Re: Suffix-based literal syntax
Its a neat idea.  I wonder if the proposed transformation is the right 
way though.

>> I propose that, for number and string literals (which already sport 
>> suffixes at the moment) if a suffix is found not from the language, it 
>> be rewritten as an opSuffix call, so
>>         5km
>>     turns into
>>         opSuff_km(5)
>>

Maybe that should be

   km.opSuff(5)


--bb
May 30, 2007
Re: Suffix-based literal syntax
Bill Baxter wrote:
> Its a neat idea.  I wonder if the proposed transformation is the right 
> way though.
> 
>>> I propose that, for number and string literals (which already sport 
>>> suffixes at the moment) if a suffix is found not from the language, 
>>> it be rewritten as an opSuffix call, so
>>>         5km
>>>     turns into
>>>         opSuff_km(5)
>>>
> 
> Maybe that should be
> 
>    km.opSuff(5)
> 
> 
> --bb
I'm not convinced. The reason is that I would expect suffixes to be only 
a few letters (like km) yet the type name would normally be much longer.

I know that the rest of the overloaded operators must be defined as 
member functions of one of the types, but that doesn't really fit with 
the suffixes, given that they "operate" on the built-in types which 
already have literals.

I envisage a usage something like this:

struct LengthKM { ... }
alias LengthKM.opCall opSuff_km;
// Of course this would actually be auto generated by a template, but 
still...

class String { ... }
alias String.this opSuff_s; // does this alias actually work? It should.

With a String class, for instance, there's not much point in 'String' 
being the suffix -- I hardly think

    "abc"String

is better than

    String("abc")


My initial thought was also a transformation like:

    opSuff!("km")(5)

However, I think the main advantage that a free function has is that it 
can be renamed on importing and it separates the suffix name from the 
type name; my example from my original post is how I would actually 
expect suffixes to be used:

import foo.string: opSuff_fs = opSuff_s;
import bar.string: opSuff_bs = opSuff_s;

...
auto a = "abc"fs; // a is a foo string
auto b = "abc"bs; // b is a bar string

  -- Reiner
May 30, 2007
Re: Suffix-based literal syntax
Reiner Pope wrote:
> I envisage a usage something like this:
> 
> struct LengthKM { ... }
> alias LengthKM.opCall opSuff_km;
> // Of course this would actually be auto generated by a template, but 
> still...

Oh, and you might want:

struct Length {...}

Length opSuff_km(real r) { return Length(1000, r); }
Length opSuff_m(real r) { return Length(1, r); }
Length opSuff_mm(real r) { return Length(0.001, r); }
May 30, 2007
Re: Suffix-based literal syntax
Just had a thought: That's all well and good, but what types do these take? A number could be floating-point or not (there are multiple floating point types...), etc., etc. Operator overloading might work for some things, but since there's no return-type operator overloading, there could be ambiguity. Consider:

uint opSuff_abs(int value) { return abs >= 0 ? abs : -abs; }
ulong ofSuff_abs(long value) { return abs >= 0 ? abs : -abs; }

// ...

uint foo = -5abs; // While we know it has to call the int method; there's no return-type overloading
long bar = -5abs; // Even with return-type overloading, implicit casts still add ambiguity

Reiner Pope Wrote:

> Reiner Pope wrote:
> > I envisage a usage something like this:
> > 
> > struct LengthKM { ... }
> > alias LengthKM.opCall opSuff_km;
> > // Of course this would actually be auto generated by a template, but 
> > still...
> 
> Oh, and you might want:
> 
> struct Length {...}
> 
> Length opSuff_km(real r) { return Length(1000, r); }
> Length opSuff_m(real r) { return Length(1, r); }
> Length opSuff_mm(real r) { return Length(0.001, r); }
May 30, 2007
Re: Suffix-based literal syntax
Actually in the case you present, there is no ambiguity.  There /is/ overloading on 
return-type, just not overloading on /only/ return-type.  (I had the same impression 
initially, but not so long ago was corrected on it -- to great joy, as it happens.)

Ambiguities caused by implicit casts can be caught by enabling warnings, and for that 
matter I'd expect the compiler to say something about the double-casting going on here, 
since neither of the return types are 'long'.  (Most likely, in this case, the 'uint(int)' 
version would be selected, and since a 'uint' can fit safely in a 'long', there should be 
no mis-behavior.)

For that matter, your example is best defined as a template, seeing as the implementation 
is identical.  Probably quite a lot of these suffixes would be templates.

All in all, I'm neutral on the idea.  It might have its uses, and would certainly find 
followers amongst the mathematicians among us... but I'd bet most people would rarely if 
ever have a significant use for it.

-- Chris Nicholson-Sauls

Robert Fraser wrote:
> Just had a thought: That's all well and good, but what types do these take? A number could be floating-point or not (there are multiple floating point types...), etc., etc. Operator overloading might work for some things, but since there's no return-type operator overloading, there could be ambiguity. Consider:
> 
> uint opSuff_abs(int value) { return abs >= 0 ? abs : -abs; }
> ulong ofSuff_abs(long value) { return abs >= 0 ? abs : -abs; }
> 
> // ...
> 
> uint foo = -5abs; // While we know it has to call the int method; there's no return-type overloading
> long bar = -5abs; // Even with return-type overloading, implicit casts still add ambiguity
> 
> Reiner Pope Wrote:
> 
>> Reiner Pope wrote:
>>> I envisage a usage something like this:
>>>
>>> struct LengthKM { ... }
>>> alias LengthKM.opCall opSuff_km;
>>> // Of course this would actually be auto generated by a template, but 
>>> still...
>> Oh, and you might want:
>>
>> struct Length {...}
>>
>> Length opSuff_km(real r) { return Length(1000, r); }
>> Length opSuff_m(real r) { return Length(1, r); }
>> Length opSuff_mm(real r) { return Length(0.001, r); }
>
May 31, 2007
Re: Suffix-based literal syntax
Robert Fraser wrote:
> Just had a thought: That's all well and good, but what types do these take? A number could be floating-point or not (there are multiple floating point types...), etc., etc. Operator overloading might work for some things, but since there's no return-type operator overloading, there could be ambiguity. Consider:
> 
> uint opSuff_abs(int value) { return abs >= 0 ? abs : -abs; }
> ulong ofSuff_abs(long value) { return abs >= 0 ? abs : -abs; }
> 
> // ...
> 
> uint foo = -5abs; // While we know it has to call the int method; there's no return-type overloading
> long bar = -5abs; // Even with return-type overloading, implicit casts still add ambiguity
I'm not exactly sure on the overloading rules, but that doesn't matter. 
The way I would approach that is:

uint opSuff_abs(int value) { ... }
ulong opSuff_absL(long value) { ... }
alias opSuff_absL opSuff_abs;

auto foo = -5abs; // rewritten as abs(-5) -- compiler chooses the int 
overload
auto bar = -100000000000abs; // rewritten as abs(-1000000000000) -- 
compiler chooses long overload since that literal is long
auto bam = -5absL; // only long version is available.

So, if there is a need to specify overloads, it's up to the library 
implementor to provide specially-named suffixes.

   -- Reiner
May 31, 2007
Re: Suffix-based literal syntax
Reiner Pope wrote:
> Reiner Pope wrote:
>> I envisage a usage something like this:
>>
>> struct LengthKM { ... }
>> alias LengthKM.opCall opSuff_km;
>> // Of course this would actually be auto generated by a template, but
>> still...
> 
> Oh, and you might want:
> 
> struct Length {...}
> 
> Length opSuff_km(real r) { return Length(1000, r); }
> Length opSuff_m(real r) { return Length(1, r); }
> Length opSuff_mm(real r) { return Length(0.001, r); }

What if we just got type extensions instead?

Length km(this real r) { return Length(1000, r); }
Length m(this real r) { return Length(1000, r); }

auto distance = 15 .km; // Space to break the float literal
auto otherdis = (10).m; // Or use parens

That way, we don't need any new parsing rules, and this can be extended
to any type, to do pretty much anything you want.

	-- Daniel

-- 
int getRandomNumber()
{
   return 4; // chosen by fair dice roll.
             // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home