View mode: basic / threaded / horizontal-split · Log in · Help
November 14, 2012
Re: Growing a Language (applicable to @attribute design)
On Wednesday, 14 November 2012 at 00:54:07 UTC, Walter Bright 
wrote:
> On 11/13/2012 12:56 PM, Walter Bright wrote:
>> An insightful talk by Guy Steele on what makes a language 
>> successful.
>>
>> http://www.youtube.com/watch?v=_ahvzDzKdB0
>
> Guy says something interesting in there that's applicable to 
> one of our current discussions.
>
> Particularly, should we allow:
>
>    @identifier
>
> as a user-defined attribute, in potential conflict with future 
> reserved attribute words, or not?
>
> Guy makes the argument that users need to be able to extend the 
> vocabulary of a language and have those new words look like 
> built-in ones. We have that today, of course, with the ability 
> of defining new types. There is no special syntax that says 
> "this is a user-defined type, not a keyword."
>
> I think this is a compelling argument, and tips the scales in 
> its favor. Probably we've been excessively worried about the 
> problems of adding a new builtin attribute type.

I think an example to watch is how Java has been evolving.

Since attributes were added to the language, new features tend to 
be introduced via new attributes (e.g. @Overload, @NotNull, ...) 
to avoid collisions with existing code.

While it makes sense from the backwards compatibility point of 
view, and Python3 is a good example people don't like rewriting 
legacy code, it leads to attribute definition explosion.

--
Paulo
November 14, 2012
Re: Growing a Language (applicable to @attribute design)
On 11/14/2012 3:06 AM, Simen Kjaeraas wrote:
> On 2012-43-14 11:11, Walter Bright <newshound2@digitalmars.com> wrote:
>
>> On 11/14/2012 1:49 AM, renoX wrote:
>>> That's not strictly true: type inference works better for built-in types than
>>> for user-defined types, with "auto x = 1;" x is an int, how do I have the same
>>> type of syntax for MyInt?
>>
>> You can have user-defined literals in D:
>>
>>     auto x = MyInt(1);
>>
>
> But the syntax for built-in types is better, in that you don't need to
> write:
>
> auto x = int(1);
>

If you're going to argue that D should have some facility to create user-defined 
literals that are arbitrary sequences of arbitrary characters, I think you're 
taking Guy's advice way beyond the breaking point.

This is pretty much true about every "principle" of language design. If you use 
that principle to blindly override everything else, you do not get anything useful.

All design is a compromise of competing goals.
November 14, 2012
Re: Growing a Language (applicable to @attribute design)
On 11/14/2012 3:18 AM, Timon Gehr wrote:
> template Foo(alias a){ }
> struct S{}
>
> alias S X;     // ok
> alias int Y;   // ok
> mixin Foo!S;   // ok
> mixin Foo!int; // not ok
>
> Please fix that. (Everything should be ok.)

Please file a bugzilla for that.
November 15, 2012
Re: Growing a Language (applicable to @attribute design)
On 11/14/2012 11:24 PM, Walter Bright wrote:
> On 11/14/2012 3:18 AM, Timon Gehr wrote:
>> template Foo(alias a){ }
>> struct S{}
>>
>> alias S X;     // ok
>> alias int Y;   // ok
>> mixin Foo!S;   // ok
>> mixin Foo!int; // not ok
>>
>> Please fix that. (Everything should be ok.)
>
> Please file a bugzilla for that.
>

http://d.puremagic.com/issues/show_bug.cgi?id=9029
November 15, 2012
Re: Growing a Language (applicable to @attribute design)
On 11/14/2012 12:06 PM, Simen Kjaeraas wrote:
> But the syntax for built-in types is better, in that you don't need to
> write:
>
> auto x = int(1);

.... suppose I want a size_t?
November 15, 2012
Re: Growing a Language (applicable to @attribute design)
On 11/15/2012 2:24 AM, Joseph Rushton Wakeling wrote:
> On 11/14/2012 12:06 PM, Simen Kjaeraas wrote:
>> But the syntax for built-in types is better, in that you don't need to
>> write:
>>
>> auto x = int(1);
>
> .... suppose I want a size_t?
>

size_t x = 1;
November 15, 2012
Re: Growing a Language (applicable to @attribute design)
On Wednesday, 14 November 2012 at 22:23:17 UTC, Walter Bright 
wrote:
> On 11/14/2012 3:06 AM, Simen Kjaeraas wrote:
>> But the syntax for built-in types is better, in that you don't 
>> need to write:
>>
>> auto x = int(1);
>>
>
> If you're going to argue that D should have some facility to 
> create user-defined literals that are arbitrary sequences of 
> arbitrary characters, I think you're taking Guy's advice way 
> beyond the breaking point.

 Hmmm... Correct me if I'm wrong, but you can create/use 
opAssign, correct? Although that doesn't work during 
initialization...

struct MyInt
{
  int i;
  ref MyInt opAssign(int rhs) {
    i = rhs;
    return this;
  }
}

MyInt x = MyInt(10);
MyInt y; // = 15; //cannot implicity convert
y = 15;

writeln(x);
writeln(y);
November 15, 2012
Re: Growing a Language (applicable to @attribute design)
On 2012-11-15 20:32, Era Scarecrow wrote:

>   Hmmm... Correct me if I'm wrong, but you can create/use opAssign,
> correct? Although that doesn't work during initialization...
>
> struct MyInt
> {
>    int i;
>    ref MyInt opAssign(int rhs) {
>      i = rhs;
>      return this;
>    }
> }
>
> MyInt x = MyInt(10);
> MyInt y; // = 15; //cannot implicity convert
> y = 15;

That's what a construtor is for:

struct MyInt
{
    int i;

    this (int i)
    {
        this.i = i;
    }

    ref MyInt opAssign(int rhs) {
        i = rhs;
        return this;
    }
}

void main()
{
    MyInt i = 3;
}

-- 
/Jacob Carlborg
November 15, 2012
Re: Growing a Language (applicable to @attribute design)
On 11/15/2012 11:54 AM, Walter Bright wrote:
> size_t x = 1;

Complete misunderstanding there -- I'd interpreted Simen's remark as saying that 
e.g. auto x = 1; would automatically assign the correct type where builtins were 
concerned, and I was pointing out that this wouldn't cover all builtins.  Though 
I guess auto x = 1UL; would work.

I wasn't asking how to create a size_t per se, which I do know how to do ... :-)

I once came an awful cropper due to lack of UL in an integer assignment.  I'd 
got a bit of C(++) code like this:

     size_t p = 1 << m;

where m was chosen such that p would be the largest power of 2 on the system 
that could (i) be multiplied by 2 without integer wraparound and (ii) was within 
the range of the uniform integer random number generator in use.

And that worked fine ... until I installed a 64-bit OS, and suddenly, all the 
numbers were coming out different.

They shouldn't have been, because the RNG in use was still based around int32_t 
and so the same constraints on m and p should have been in place ... and then I 
discovered what was happening: 1 << m; wasn't taking a size_t (unsigned long) 
and bitshifting it by m places, it was taking a regular int and bitshifting it 
by m places ... which given the value of m, was causing integer wraparound, the 
result of which was then converted to a size_t.

It just so happened that on 32-bit this was taking the value back to where it 
was supposed to be anyway.  But on 64-bit the wraparound made 1 << m a negative 
number which in turn corresponded to a far too _large_ value when converted into 
a size_t.

And so I learned that I had to use 1UL << m; instead ... :-P
November 16, 2012
Re: Growing a Language (applicable to @attribute design)
On 2012-11-15 22:08, Joseph Rushton Wakeling wrote:

> Complete misunderstanding there -- I'd interpreted Simen's remark as
> saying that e.g. auto x = 1; would automatically assign the correct type
> where builtins were concerned, and I was pointing out that this wouldn't
> cover all builtins.  Though I guess auto x = 1UL; would work.

Should this give you an unsigned long regardless of architecture? 
"size_t" is unsigned int on 32bit platforms and unsigned long on 64bit 
platforms.

-- 
/Jacob Carlborg
1 2 3 4
Top | Discussion index | About this forum | D home