October 05, 2008
On Sun, 05 Oct 2008 20:09:25 +0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Bent Rasmussen wrote:
>> Somewhere there is the dream of a pure function call syntax
>>     abs(real) sqrt(abs(real) x);
>>  Total unification. And possibly total impossibility.
>>  Looks beautiful tho.
>
> It does look beautiful. It won't as soon as "!" enters the picture.
>
> Andrei

I second that. It also brings templates and functions together:

int x = sqrt(42); // what is sqrt - a CT-function of a template? I don't care!
October 05, 2008
On Sun, 05 Oct 2008 20:09:25 +0400, Andrei Alexandrescu
<SeeWebsiteForEmail@erdani.org> wrote:

> Bent Rasmussen wrote:
>> Somewhere there is the dream of a pure function call syntax
>>     abs(real) sqrt(abs(real) x);
>>  Total unification. And possibly total impossibility.
>>  Looks beautiful tho.
>
> It does look beautiful. It won't as soon as "!" enters the picture.
>
> Andrei

I second that. It also brings templates and functions closer:

int x = sqrt(42); // what is sqrt - a CT-function or a template? I don't
care!
October 05, 2008
downs wrote:
> Andrei Alexandrescu wrote:
>> The problem I see with "!" as a template instantiation is not technical.
>> I write a fair amount of templated code and over years the "!" did not
>> grow on me at all. I was time and again consoled by Walter than one day
>> that will happen, but it never did. I also realized that Walter didn't
>> see a problem with it because he writes only little template code.
>>
> 
> FWIW: I write large volumes of template code and I like the ! just fine.
> 

Don't take this endorsement lightly. When downs says he writes large volumes of template code, he means volumes in the literary sense: You could fill a fairly-large bookshelf with his tomes of template code.

 - Gregor Richards
October 05, 2008
Andrei Alexandrescu wrote:
>> ... It looks like it should yield a tuple containing bar and baz :P
>>
>>
>> foo!(bar, baz)   <-  distinct, no issue.
> 
> Looks great until you have twenty or thirty of these on a code screen. Then you're like, boy this is one ugly language. Believe me, I *tried* to put up with it.

Hm, I didn't think so when working on ctrace or Bind...
I could similarly say that parentheses look bad and we should change them to something else because a screenful of them looks ugly when calling lots of functions.


>> I would not like to have compile-time and run-time merged visually in code.
This statement was likely misleading, sorry for that. I don't see it as a bad thing that some functions will be running at compile-time 'behind my back'. I just wouldn't like the visual distinction between normal function calls and template evaluations to go away as long as they are fundamentally different.


> You already do in template argument deduction.

Point. But for a different purpose - eliminating a lot of redundant code and making some meta programming feasible. It's a bit different from pretending template evaluation is like function calls.


> The times go against the style of coding that separates compile-time stuff from run-time stuff.

The times? I'd say that these times have already been ;) You may not have this distinction e.g. in Lisp. But if you consider that D only has one 'compile time', while you could freely operate on anything at any time in Lisp, it makes more sense to have the compile-time phase stand out a bit. Especially because template code is still very different than normal D code (it's functional and memoized, after all). I'd be tempted to change my mind here if D had more meta-facilities, but at the current state of things, I'd say that the 'times' are pretty stagnant for D.


>> Let's also keep in mind what Ary said, that using "." will cause problems for IDEs.
> 
> No it won't.

Would you elaborate on this? I'd rather believe Ary if nothing else is provided to your point. Ary is the creator of the most advanced IDE for D as far as I know.


>> What's the point in pretending that run-time is the same as compile-time?
> 
> Because you shouldn't care.

I wish I could! But then, I can't process types at run-time.


>> You can't instantiate compile-time constructs with run-time arguments, the costs are very different, too. Heck, when I see too many "!" in the code, it indicates that there may be a design issue and some massive bloat involved. I would not like this additional insight into the code removed from my eyes.
> 
> Conversely, if you have too few of those, I come and say you're doing too much manual work.

Or the code is a 'normal' module that mixes some meta constructs and standard non-parametrized stuff. The "!" may be very common in modules such as std.algorithm, but you won't see as many in the usual stuff, like, most of Tango.


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode
October 05, 2008
Gregor Richards wrote:
> KennyTM~ wrote:
>> Michel Fortin wrote:
>>> On 2008-10-05 01:14:17 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:
>>>
>>>> I don't favor "." any more than the next guy, but I am glad there is awareness of how unfit a choice "!" is. If you have any ideas, please post them! Ah! I! Exclaimed! Again!
>>>
>>> Hum, I don't think we have much choice, it'll have to be something in this lot:
>>>
>>>     Positive!(real)(joke);
>>>     Positive.(real)(joke);
>>>     Positive#(real)(joke);
>>>     Positive@(real)(joke);
>>>     Positive&(real)(joke);
>>>     Positive`(real)(joke);
>>>     Positive´(real)(joke);
>>>     Positive^(real)(joke);
>>>     Positive¨(real)(joke);
>>>     Positive\(real)(joke);
>>>
>>> Anything else I forgot?
>>>
>>> Or we could use special delimiter characters:
>>>
>>>     Positive<real>(joke);
>>>     Positive“real”(joke);
>>>     Positive«real»(joke);
>>>     Positive#real@(joke);
>>>
>>> Each having its own problem though.
>>>
>>> My preference still goes to "!(".
>>>
>>> - - -
>>>
>>> The ".(" syntax makes me think more of something like this:
>>>
>>>     void func(T, alias methodOfT, A...)(T obj, A args)
>>>     {
>>>         obj.(methodOfT)(args);
>>>     }
>>>
>>> which I which I could do. If methodOfT was a string, I suppose I could use string mixins, but it pushes diagnostics about misnamed methods further in the template and requires adding quotes to the template parameter when instanciating.
>>>
>>
>> Argh, actually I once have a strong desire making
>>
>>   f«T»(x);
>>
>> a valid construct, and to workaround that « and » can't be easily typed you could substitute it with
>>
>>   f\<T\>(x);
> 
> Yes. Trigraphs were such a good idea in C, let's bring them to D X_X
> 
>  - Gregor Richards

It has been done with Pascal ( {comment} = (*comment*) } already. And the \ character is used to escape stuffs already, so no problem like writing "what??!" in C. And technically it's just a digraph, so at most it is only 67% as evil as trigraphs <g>.

OK I'm just joking :p.
October 05, 2008
Tom S wrote:
> Andrei Alexandrescu wrote:
>>> ... It looks like it should yield a tuple containing bar and baz :P
>>>
>>>
>>> foo!(bar, baz)   <-  distinct, no issue.
>>
>> Looks great until you have twenty or thirty of these on a code screen. Then you're like, boy this is one ugly language. Believe me, I *tried* to put up with it.
> 
> Hm, I didn't think so when working on ctrace or Bind...
> I could similarly say that parentheses look bad and we should change them to something else because a screenful of them looks ugly when calling lots of functions.

You couldn't because f(a, b) is already used in math for function
invocation. "Word!" is already used. For shouting that is.

>>> I would not like to have compile-time and run-time merged visually in code.
> This statement was likely misleading, sorry for that. I don't see it as a bad thing that some functions will be running at compile-time 'behind my back'. I just wouldn't like the visual distinction between normal function calls and template evaluations to go away as long as they are fundamentally different.

They are and they stay different. One oughtn't be shouting at you though.

>> You already do in template argument deduction.
> 
> Point. But for a different purpose - eliminating a lot of redundant code and making some meta programming feasible. It's a bit different from pretending template evaluation is like function calls.

Well parens are already used for more than function calls and nobody
seems to mind.

>> The times go against the style of coding that separates compile-time stuff from run-time stuff.
> 
> The times? I'd say that these times have already been ;) You may not have this distinction e.g. in Lisp. But if you consider that D only has one 'compile time', while you could freely operate on anything at any time in Lisp, it makes more sense to have the compile-time phase stand out a bit. Especially because template code is still very different than normal D code (it's functional and memoized, after all). I'd be tempted to change my mind here if D had more meta-facilities, but at the current state of things, I'd say that the 'times' are pretty stagnant for D.

More meta-facilities are coming D's way, not less. As far as Lisp is
concerned, at least in Scheme (I forgot how you do it in Lisp) macro
invocation isn't distinguished in any way. For example "and" in (and a b
c) is a macro.

>>> Let's also keep in mind what Ary said, that using "." will cause problems for IDEs.
>>
>> No it won't.
> 
> Would you elaborate on this? I'd rather believe Ary if nothing else is provided to your point. Ary is the creator of the most advanced IDE for D as far as I know.

A template name without arguments has no members, except inside the very
template definition, when you'd rarely use it.

>>> What's the point in pretending that run-time is the same as compile-time?
>>
>> Because you shouldn't care.
> 
> I wish I could! But then, I can't process types at run-time.

Well then here's the distinction that you wanted :o).

>>> You can't instantiate compile-time constructs with run-time arguments, the costs are very different, too. Heck, when I see too many "!" in the code, it indicates that there may be a design issue and some massive bloat involved. I would not like this additional insight into the code removed from my eyes.
>>
>> Conversely, if you have too few of those, I come and say you're doing too much manual work.
> 
> Or the code is a 'normal' module that mixes some meta constructs and standard non-parametrized stuff. The "!" may be very common in modules such as std.algorithm, but you won't see as many in the usual stuff, like, most of Tango.

By and large we'd want seamless and smooth integration of various styles
and techniques, wouldn't we? Shouting doesn't fit into this.


Andrei

October 05, 2008
Andrei Alexandrescu escribió:
> KennyTM~ wrote:
>> Andrei Alexandrescu wrote:
>>> Michel Fortin wrote:
>>>> On 2008-10-05 01:14:17 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:
>>>>
>>>> -- snip --
>>>>
>>>> Or we could use special delimiter characters:
>>>>
>>>>     Positive<real>(joke);
>>>>     Positive“real”(joke);
>>>>     Positive«real»(joke);
>>>>     Positive#real@(joke);
>>>>
>>>> Each having its own problem though.
>>>>
>>>> My preference still goes to "!(".
>>>
>>> There was also Positive{real}(joke), with which I couldn't find an ambiguity.
>>  >
>>
>> Ohhhh. Why isn't it considered then? (Suppose we already knew Positive is not a keyword and not preceded by the keywords struct, class, etc.)
> 
> I believe it should be considered. At some point there was discussion on accepting a last parameter of delegate type outside the function parens. The idea was to allow user-defined code to define constructs similar to e.g. if and foreach.
> 
> But I think that has many other problems (one of which is that the delegate can't reasonably specify parameters), so we can safely discount that as a problem.
> 
> I'd want to give it a try. How do others feel about Template{arguments}?

I thought no one read my post, now I see you are discussing it in another thread. :-P

After I posted, I also remembered the possibility of allowing delegate invocation in a nicer way, and that conflicts with Foo{T}. :-(
October 05, 2008
Ary Borenszweig wrote:
> Andrei Alexandrescu escribió:
>> KennyTM~ wrote:
>>> Andrei Alexandrescu wrote:
>>>> Michel Fortin wrote:
>>>>> On 2008-10-05 01:14:17 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:
>>>>>
>>>>> -- snip --
>>>>>
>>>>> Or we could use special delimiter characters:
>>>>>
>>>>>     Positive<real>(joke);
>>>>>     Positive“real”(joke);
>>>>>     Positive«real»(joke);
>>>>>     Positive#real@(joke);
>>>>>
>>>>> Each having its own problem though.
>>>>>
>>>>> My preference still goes to "!(".
>>>>
>>>> There was also Positive{real}(joke), with which I couldn't find an ambiguity.
>>>  >
>>>
>>> Ohhhh. Why isn't it considered then? (Suppose we already knew Positive is not a keyword and not preceded by the keywords struct, class, etc.)
>>
>> I believe it should be considered. At some point there was discussion on accepting a last parameter of delegate type outside the function parens. The idea was to allow user-defined code to define constructs similar to e.g. if and foreach.
>>
>> But I think that has many other problems (one of which is that the delegate can't reasonably specify parameters), so we can safely discount that as a problem.
>>
>> I'd want to give it a try. How do others feel about Template{arguments}?
> 
> I thought no one read my post, now I see you are discussing it in another thread. :-P
> 
> After I posted, I also remembered the possibility of allowing delegate invocation in a nicer way, and that conflicts with Foo{T}. :-(

I think we can drop that. Even if we allow that, there will be parens needed before the delegate body, at least for passing it arguments.

Andrei
October 05, 2008
Andrei Alexandrescu escribió:
> Tom S wrote:
>> Andrei Alexandrescu wrote:
>>>> ... It looks like it should yield a tuple containing bar and baz :P
>>>>
>>>>
>>>> foo!(bar, baz)   <-  distinct, no issue.
>>>
>>> Looks great until you have twenty or thirty of these on a code screen. Then you're like, boy this is one ugly language. Believe me, I *tried* to put up with it.
>>
>> Hm, I didn't think so when working on ctrace or Bind...
>> I could similarly say that parentheses look bad and we should change them to something else because a screenful of them looks ugly when calling lots of functions.
> 
> You couldn't because f(a, b) is already used in math for function
> invocation. "Word!" is already used. For shouting that is.
> 
>>>> I would not like to have compile-time and run-time merged visually in code.
>> This statement was likely misleading, sorry for that. I don't see it as a bad thing that some functions will be running at compile-time 'behind my back'. I just wouldn't like the visual distinction between normal function calls and template evaluations to go away as long as they are fundamentally different.
> 
> They are and they stay different. One oughtn't be shouting at you though.
> 
>>> You already do in template argument deduction.
>>
>> Point. But for a different purpose - eliminating a lot of redundant code and making some meta programming feasible. It's a bit different from pretending template evaluation is like function calls.
> 
> Well parens are already used for more than function calls and nobody
> seems to mind.
> 
>>> The times go against the style of coding that separates compile-time stuff from run-time stuff.
>>
>> The times? I'd say that these times have already been ;) You may not have this distinction e.g. in Lisp. But if you consider that D only has one 'compile time', while you could freely operate on anything at any time in Lisp, it makes more sense to have the compile-time phase stand out a bit. Especially because template code is still very different than normal D code (it's functional and memoized, after all). I'd be tempted to change my mind here if D had more meta-facilities, but at the current state of things, I'd say that the 'times' are pretty stagnant for D.
> 
> More meta-facilities are coming D's way, not less. As far as Lisp is
> concerned, at least in Scheme (I forgot how you do it in Lisp) macro
> invocation isn't distinguished in any way. For example "and" in (and a b
> c) is a macro.
> 
>>>> Let's also keep in mind what Ary said, that using "." will cause problems for IDEs.
>>>
>>> No it won't.
>>
>> Would you elaborate on this? I'd rather believe Ary if nothing else is provided to your point. Ary is the creator of the most advanced IDE for D as far as I know.
> 
> A template name without arguments has no members, except inside the very
> template definition, when you'd rarely use it.

I don't think it's because of that, but the IDE could check that if what's before the "." is a template, suggest instantiation. So after thinking about it again, I agree with you that it won't be problematic.

Anyway, I don't like the .() syntax. :-P
October 05, 2008
Ary Borenszweig wrote:
> Andrei Alexandrescu escribió:
>> Tom S wrote:
>>> Andrei Alexandrescu wrote:
>>>>> ... It looks like it should yield a tuple containing bar and baz :P
>>>>>
>>>>>
>>>>> foo!(bar, baz)   <-  distinct, no issue.
>>>>
>>>> Looks great until you have twenty or thirty of these on a code screen. Then you're like, boy this is one ugly language. Believe me, I *tried* to put up with it.
>>>
>>> Hm, I didn't think so when working on ctrace or Bind...
>>> I could similarly say that parentheses look bad and we should change them to something else because a screenful of them looks ugly when calling lots of functions.
>>
>> You couldn't because f(a, b) is already used in math for function
>> invocation. "Word!" is already used. For shouting that is.
>>
>>>>> I would not like to have compile-time and run-time merged visually in code.
>>> This statement was likely misleading, sorry for that. I don't see it as a bad thing that some functions will be running at compile-time 'behind my back'. I just wouldn't like the visual distinction between normal function calls and template evaluations to go away as long as they are fundamentally different.
>>
>> They are and they stay different. One oughtn't be shouting at you though.
>>
>>>> You already do in template argument deduction.
>>>
>>> Point. But for a different purpose - eliminating a lot of redundant code and making some meta programming feasible. It's a bit different from pretending template evaluation is like function calls.
>>
>> Well parens are already used for more than function calls and nobody
>> seems to mind.
>>
>>>> The times go against the style of coding that separates compile-time stuff from run-time stuff.
>>>
>>> The times? I'd say that these times have already been ;) You may not have this distinction e.g. in Lisp. But if you consider that D only has one 'compile time', while you could freely operate on anything at any time in Lisp, it makes more sense to have the compile-time phase stand out a bit. Especially because template code is still very different than normal D code (it's functional and memoized, after all). I'd be tempted to change my mind here if D had more meta-facilities, but at the current state of things, I'd say that the 'times' are pretty stagnant for D.
>>
>> More meta-facilities are coming D's way, not less. As far as Lisp is
>> concerned, at least in Scheme (I forgot how you do it in Lisp) macro
>> invocation isn't distinguished in any way. For example "and" in (and a b
>> c) is a macro.
>>
>>>>> Let's also keep in mind what Ary said, that using "." will cause problems for IDEs.
>>>>
>>>> No it won't.
>>>
>>> Would you elaborate on this? I'd rather believe Ary if nothing else is provided to your point. Ary is the creator of the most advanced IDE for D as far as I know.
>>
>> A template name without arguments has no members, except inside the very
>> template definition, when you'd rarely use it.
> 
> I don't think it's because of that, but the IDE could check that if what's before the "." is a template, suggest instantiation. So after thinking about it again, I agree with you that it won't be problematic.
> 
> Anyway, I don't like the .() syntax. :-P

And why should I care? I got superdan's drunken vote! :oD

Andrei