October 08, 2008
Simen Kjaeraas wrote:
> Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> 
>> Leandro Lucarella wrote:
>>> "enum" as the way to declare manifest constants were much more ugly than
>>> "!(", and most of the people were against it. I don't see why ".(" should
>>> be introduced.
>>
>> Ugly or not, enumerated symbols were manifest constants to begin with. That's kinda hard to argue against because it's a sheer fact.
> 
> All bears are animals, so lets call all animals bears. See where this is wrong?

The correct reasoning to apply is, if you see a white bear, would you call it a different way?

Andrei
October 08, 2008
On Wed, 08 Oct 2008 22:02:18 +0200, Simen Kjaeraas <simen.kjaras@gmail.com> wrote:

> On Mon, 06 Oct 2008 12:39:29 +0200, Benji Smith <dlanguage@benjismith.net> wrote:
>
>> Andrei Alexandrescu wrote:
>>> One morning I woke up with the sudden realization of what the problem was: the shouting.
>>
>> Here's my (nutty) opinion:
>>
>> Neither the "!" nor the "." really want to be there. I think the language really *wants* to be using a bare set of parens for templates. Because the language actually wants templates and functions to converge.
>>
>> Instead of a special-case syntax for templates, and a set of special rules for CTFE, and a whole set of parallel "static" statements (if, else, foreach) and a special compile-type-only type construct (tuples), just let D be D, either at runtime or compile type.
>>
>> If a function could return a Type, and if that type could be used in a Type Constructor, then you'd have all the magic template sauce you'd need, and templates could happily converge themselves with regular functions.
>>
>> Hey! I told you it was going to be nutty!!!
>>
>> <g>
>>
>> --benji
>
> That would only work for templated functions, though. What about templated types?
>

Forget I ever let my ass do the thinking. I'd really like to see how this would look, but I feel it'd make for uglier syntax.

-- 
Simen
October 08, 2008
On Tue, 07 Oct 2008 16:27:00 +0200, Benji Smith <dlanguage@benjismith.net> wrote:

> Jarrett Billingsley wrote:
>> On Mon, Oct 6, 2008 at 6:59 AM, Denis Koroskin <2korden@gmail.com> wrote:
>>
>>> If we don't omit parenthesises, the ambiguity goes away:
>>>
>>> foo()(5)
>>> foo(5)()
>>>
>>  No it doesn't.
>>  Stdout("foo")("bar!").newline;
>
> This is one of the main reasons I dislike opCall.
>
> Combined with optional-parentheses for function invocation, opCall is a poison-pill that creates a lot of potential ambiguities and prevents the implementation of more compelling features.
>
> --benji

void delegate() foo()
{
	return delegate void() {);};
}

?

-- 
Simen
October 08, 2008
Simen Kjaeraas wrote:
> On Wed, 08 Oct 2008 22:02:18 +0200, Simen Kjaeraas <simen.kjaras@gmail.com> wrote:
> 
>> On Mon, 06 Oct 2008 12:39:29 +0200, Benji Smith <dlanguage@benjismith.net> wrote:
>>
>>> Andrei Alexandrescu wrote:
>>>> One morning I woke up with the sudden realization of what the problem was: the shouting.
>>>
>>> Here's my (nutty) opinion:
>>>
>>> Neither the "!" nor the "." really want to be there. I think the language really *wants* to be using a bare set of parens for templates. Because the language actually wants templates and functions to converge.
>>>
>>> Instead of a special-case syntax for templates, and a set of special rules for CTFE, and a whole set of parallel "static" statements (if, else, foreach) and a special compile-type-only type construct (tuples), just let D be D, either at runtime or compile type.
>>>
>>> If a function could return a Type, and if that type could be used in a Type Constructor, then you'd have all the magic template sauce you'd need, and templates could happily converge themselves with regular functions.
>>>
>>> Hey! I told you it was going to be nutty!!!
>>>
>>> <g>
>>>
>>> --benji
>>
>> That would only work for templated functions, though. What about templated types?
>>
> 
> Forget I ever let my ass do the thinking. I'd really like to see how this would look, but I feel it'd make for uglier syntax.

I don't really know how it would work, but the syntax is easy to imagine:

   Type Dictionary = HashMap(char[], char[]);
   Dictionary d = new Dictionary();

In this case, HashMap is just a function (executable at compile-time through CTFE), which returns a type. Once the type has been returned, objects of that type can be instantiated.

This idea first occurred to me when CTFE was introduced. I thought to myself "if we can have compile-time function exectuion", why can't we also have "runtime template instantiation"? Why is it only possible to define a new type (or to choose which type) at compile time?

In languages like Ruby, you can attach new methods to an object at runtime. In .NET, you can generate, compile, and load new bytecode instructions on the fly.

It's hard to think of cases where you'd really want to construct a new type at runtime. But maybe....automatically generating a library of types by querying a database schema?

--benji
October 08, 2008
Benji Smith <dlanguage@benjismith.net> wrote:

> This idea first occurred to me when CTFE was introduced. I thought to myself "if we can have compile-time function exectuion", why can't we also have "runtime template instantiation"? Why is it only possible to define a new type (or to choose which type) at compile time?
>
> In languages like Ruby, you can attach new methods to an object at runtime. In .NET, you can generate, compile, and load new bytecode instructions on the fly.
>
> It's hard to think of cases where you'd really want to construct a new type at runtime. But maybe....automatically generating a library of types by querying a database schema?
>
> --benji

The reasons for such things are to be found in the compiler. Optimizing
an expression whose types you do not know, and allocating space for a
type that may change its size under your feet - sounds to me like tricky
business.

-- 
Simen
October 08, 2008
Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Simen Kjaeraas wrote:
>> Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>>
>>> Leandro Lucarella wrote:
>>>> "enum" as the way to declare manifest constants were much more ugly than
>>>> "!(", and most of the people were against it. I don't see why ".(" should
>>>> be introduced.
>>>
>>> Ugly or not, enumerated symbols were manifest constants to begin with. That's kinda hard to argue against because it's a sheer fact.
>>
>> All bears are animals, so lets call all animals bears. See where this is wrong?
>
> The correct reasoning to apply is, if you see a white bear, would you call it a different way?
>
> Andrei

Mayhaps. But to me, a manifest constant is not just a bear of a
different color, but possibly one with six legs, a prehensile tail,
bat wings, and riding a helicopter. And I'm pretty sure I would not
classify that as a bear, even if it still had fur and powerful jaws,
and would make for a fun teddy.

-- 
Simen
October 08, 2008
Simen Kjaeraas wrote:
> On Tue, 07 Oct 2008 16:27:00 +0200, Benji Smith <dlanguage@benjismith.net> wrote:
> 
>> Jarrett Billingsley wrote:
>>> On Mon, Oct 6, 2008 at 6:59 AM, Denis Koroskin <2korden@gmail.com> wrote:
>>>
>>>> If we don't omit parenthesises, the ambiguity goes away:
>>>>
>>>> foo()(5)
>>>> foo(5)()
>>>>
>>>  No it doesn't.
>>>  Stdout("foo")("bar!").newline;
>>
>> This is one of the main reasons I dislike opCall.
>>
>> Combined with optional-parentheses for function invocation, opCall is a poison-pill that creates a lot of potential ambiguities and prevents the implementation of more compelling features.
>>
>> --benji
> 
> void delegate() foo()
> {
>     return delegate void() {);};
> }
> 
> ?
> 

Is that supposed to be legal code?

I'll assume this is what you meant to write:

   void delegate() foo()
   {
      return delegate void() { };
   }

...and that you're making the point that opCall introduces no more ambiguities than delegate-call syntax. And I suppose you're right.

But people use opCall *everywhere* for all sorts of crazy crap, and I think it makes the code far less readable. When the call syntax is used for actual delegates, I don't really mind. But I think call-chaining with opCall is a huge eye-sore:

   object(x)("hello")();

I guess my ambiguity argument is invalidated by wanting to keep the delegate-call syntax. I just hate when it's applied to non-delegates.

--benji
October 08, 2008
Simen Kjaeraas wrote:
> Benji Smith <dlanguage@benjismith.net> wrote:
> 
>> This idea first occurred to me when CTFE was introduced. I thought to myself "if we can have compile-time function exectuion", why can't we also have "runtime template instantiation"? Why is it only possible to define a new type (or to choose which type) at compile time?
>>
>> In languages like Ruby, you can attach new methods to an object at runtime. In .NET, you can generate, compile, and load new bytecode instructions on the fly.
>>
>> It's hard to think of cases where you'd really want to construct a new type at runtime. But maybe....automatically generating a library of types by querying a database schema?
>>
>> --benji
> 
> The reasons for such things are to be found in the compiler. Optimizing
> an expression whose types you do not know, and allocating space for a
> type that may change its size under your feet - sounds to me like tricky
> business.

Yep. I totally understand why it's not currently possible.

You'd have to have an instance of the compiler always available at runtime; compiling, loading, and linking on the fly.

Tricky stuff. But it'd be cool.

It wasn't a real suggestion. Just a musing.

--benji
October 08, 2008
Simen Kjaeraas wrote:
> Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> 
>> Simen Kjaeraas wrote:
>>> Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>>>
>>>> Leandro Lucarella wrote:
>>>>> "enum" as the way to declare manifest constants were much more ugly than
>>>>> "!(", and most of the people were against it. I don't see why ".(" should
>>>>> be introduced.
>>>>
>>>> Ugly or not, enumerated symbols were manifest constants to begin with. That's kinda hard to argue against because it's a sheer fact.
>>>
>>> All bears are animals, so lets call all animals bears. See where this is wrong?
>>
>> The correct reasoning to apply is, if you see a white bear, would you call it a different way?
>>
>> Andrei
> 
> Mayhaps. But to me, a manifest constant is not just a bear of a
> different color, but possibly one with six legs, a prehensile tail,
> bat wings, and riding a helicopter. And I'm pretty sure I would not
> classify that as a bear, even if it still had fur and powerful jaws,
> and would make for a fun teddy.

But you just agreed that enum is a manifest constant.

Andrei
October 08, 2008
On Wed, 08 Oct 2008 23:11:14 +0200, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Simen Kjaeraas wrote:
>> Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>>
>>> Simen Kjaeraas wrote:
>>>> Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>>>>
>>>>> Leandro Lucarella wrote:
>>>>>> "enum" as the way to declare manifest constants were much more ugly than
>>>>>> "!(", and most of the people were against it. I don't see why ".(" should
>>>>>> be introduced.
>>>>>
>>>>> Ugly or not, enumerated symbols were manifest constants to begin with. That's kinda hard to argue against because it's a sheer fact.
>>>>
>>>> All bears are animals, so lets call all animals bears. See where this is wrong?
>>>
>>> The correct reasoning to apply is, if you see a white bear, would you call it a different way?
>>>
>>> Andrei
>>  Mayhaps. But to me, a manifest constant is not just a bear of a
>> different color, but possibly one with six legs, a prehensile tail,
>> bat wings, and riding a helicopter. And I'm pretty sure I would not
>> classify that as a bear, even if it still had fur and powerful jaws,
>> and would make for a fun teddy.
>
> But you just agreed that enum is a manifest constant.
>
> Andrei

Indeed. But my point is that not all manifest constants are enumerations,
as the name enum seems to suggest. That is my gripe with the choice. And
I fear it will continue like that.

-- 
Simen