Am 04.06.2011 06:20, schrieb Mehrdad:
>
> Interesting... I just saw the continuation of this thread, and wanted to make some meta-comments (I guess this should be on meta.digitalmars.com, haha):
>
>
> I admittedly didn't bother to check whether my suggestion was made before. Sorry. :(
>
> Question: Why?
>
> Answer:   Because it's really hard to search for it, and it gets really annoying past the Nth time you try to. The *only* useful way I know of for searching is to add "site:digitalmars.com" in
> my Google query, which gets _really_ annoying to type after a while...

Or you just use the search form on digitalmars.com/d and you don't have to type site:digitalmars.com yourself :-)

== Quote from Daniel Gibson (metalcaedes@gmail.com)'s article
> Am 04.06.2011 06:20, schrieb Mehrdad:
> >
> > Interesting... I just saw the continuation of this thread, and
wanted to make some meta-comments (I guess this should be on
meta.digitalmars.com, haha):
> >
> >
> > I admittedly didn't bother to check whether my suggestion was
made before. Sorry. :(
> >
> > Question: Why?
> >
> > Answer:   Because it's really hard to search for it, and it gets
really annoying past the Nth time you try to. The *only* useful way I know of for searching is to add "site:digitalmars.com" in
> > my Google query, which gets _really_ annoying to type after a
while...
> Or you just use the search form on digitalmars.com/d and you don't
have
> to type site:digitalmars.com yourself :-)

Does it search the newsgroups? More than 75% of my searches on language features fail (since it seems to ignore the language for some reason), so I haven't tried using it for the newsgroups too much...

Am 04.06.2011 10:48, schrieb Mehrdad:
> == Quote from Daniel Gibson (metalcaedes@gmail.com)'s article
>> Am 04.06.2011 06:20, schrieb Mehrdad:
>>>
>>> Interesting... I just saw the continuation of this thread, and
> wanted to make some meta-comments (I guess this should be on
> meta.digitalmars.com, haha):
>>>
>>>
>>> I admittedly didn't bother to check whether my suggestion was
> made before. Sorry. :(
>>>
>>> Question: Why?
>>>
>>> Answer:   Because it's really hard to search for it, and it gets
> really annoying past the Nth time you try to. The *only* useful way I know of for searching is to add "site:digitalmars.com" in
>>> my Google query, which gets _really_ annoying to type after a
> while...
>> Or you just use the search form on digitalmars.com/d and you don't
> have
>> to type site:digitalmars.com yourself :-)
> 
> Does it search the newsgroups? More than 75% of my searches on language features fail (since it seems to ignore the language for some reason), so I haven't tried using it for the newsgroups too much...

http://www.digitalmars.com/NewsGroup.html at least if your start here it
does search the newsgroups.
The site search never seems to return results from the language spec,
for whatever reason.

On Sat, 04 Jun 2011 02:05:14 -0400, Matthew Ong <ongbp@yahoo.com> wrote:

> Alternatively, D might want to use *some kind of voting tool online* on yahoo (group, missing) to help vote for syntax that programmer really wants. A simple solution to the long like JCP process in Java.

We have this, bugzilla allows voting, you can vote once per bug/proposal (and you have 10 votes total you can distribute):

http://d.puremagic.com/issues/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&query_format=advanced&votes=1&order=votes%2Cbug_id&query_based_on=

That is all the open bugs that have at least one vote, sorted by votes.

We also have a wiki where DIPs (D improvement proposals) can be created to flesh out ideas in a more formal fashion.  However, this system has no voting or really feedback, so I'd recommend using bugzilla or the newsgroups first.

-Steve

On 6/3/11 11:25 PM, Andrei Alexandrescu wrote:
> On 6/3/11 10:19 AM, Matthew Ong wrote:
>> On 6/3/2011 11:47 AM, Mehrdad wrote:
>>> == Quote from Jonathan M Davis (jmdavisProg@gmx.com)'s article
>>
>>>> understand templates to use D properly - especially when dealing
>>> with Phobos -
>>>> that doesn't help at all.
>>>> I see no advantages with this idea and quite a few disadvantages.
>>> This
>>>> proposal adds absolutely nothing.
>>>> - Jonathan M Davis
>>>
>>>
>>> o__o way to bash the proposal, it actually convinced me lol...
>>
>>
>> >> proposal adds absolutely nothing.
>> You will get this frequently. Especially if you identify with Java
>> development.
>>
>> Welcome to D forum, where new idea are squashed and maybe re-discussed
>> later. Look up my name as Matthew Ong. Avoid asking the same questions.
>>
>> http://www.digitalmars.com/d/
>> Notice: We *welcome feedback about the D compiler or language*,
>>
>> Not so true. Or out right should warn people as:
>>
>> Notice: Take it the way how we like it here, we are Not Burger K*ng.
>> Please see:
>> d.D.learn
>> AND MAKE sure you read this
>> d.D.NoSuchUselessSuggestion
>>
>> What do you think D forum people, at least new people here are for warn.
>> Add a bit of humor into that.
>>
>> I do see a pattern here. Just joined D forum less than 4 weeks ago.
>> Got a week off to clear my head. I think now I understand why D is still
>> such a small community in the forum.
>
> I understand how you find that an attractive conclusion to reach, but
> probably a more rational hypothesis is that some of your proposals have
> been of poor quality. That doesn't reflect poorly on your abilities, it
> just suggests that you have not yet accumulated sufficient expertise
> with D.
>
> As an example, look at the activity of a current poster who proposed
> very strongly a change in a way the intervals are handled. It was
> arguably a very poor proposal for D, and people did their best to
> explain why. That poster was outwitted by competent people with clear
> and solid arguments. Yet that poster's way to solve that cognitive
> dissonance - the low road if you ask me - was to conclude that the value
> of his proposal is high in spite of all logic and reasoning, and that
> everyone else is wrong.
>
> I suggest you don't fall for the same pattern, though clearly I
> understand how attractive it is. It slows down learning.
>
>
> Andrei


Well, in Ruby every parameter type is auto. And it works pretty well. :-)

When you invoke a method and something goes wrong, like the auto parameter doesn't have a method, it gives a sensible error message.

So:

void foo(auto parameter) {
  return parameter * 2;
}

could just be the same as

void foo(T)(T parameter) {
  return parameter * 2;
}

just with a nicer syntax (but I understand it doesn't add much).

I think a reply like: "this is the same as a template" is better than "your proposals are of poor quality". It doesn't give a nice look to D, specially coming from one of its main leaders.

Ary Manzana Wrote:

> On 6/3/11 11:25 PM, Andrei Alexandrescu wrote:
> > On 6/3/11 10:19 AM, Matthew Ong wrote:
> >> On 6/3/2011 11:47 AM, Mehrdad wrote:
> >>> == Quote from Jonathan M Davis (jmdavisProg@gmx.com)'s article
> >>
> >>>> understand templates to use D properly - especially when dealing
> >>> with Phobos -
> >>>> that doesn't help at all.
> >>>> I see no advantages with this idea and quite a few disadvantages.
> >>> This
> >>>> proposal adds absolutely nothing.
> >>>> - Jonathan M Davis
> >>>
> >>>
> >>> o__o way to bash the proposal, it actually convinced me lol...
> >>
> >>
> >> >> proposal adds absolutely nothing.
> >> You will get this frequently. Especially if you identify with Java development.
> >>
> >> Welcome to D forum, where new idea are squashed and maybe re-discussed later. Look up my name as Matthew Ong. Avoid asking the same questions.
> >>
> >> http://www.digitalmars.com/d/
> >> Notice: We *welcome feedback about the D compiler or language*,
> >>
> >> Not so true. Or out right should warn people as:
> >>
> >> Notice: Take it the way how we like it here, we are Not Burger K*ng.
> >> Please see:
> >> d.D.learn
> >> AND MAKE sure you read this
> >> d.D.NoSuchUselessSuggestion
> >>
> >> What do you think D forum people, at least new people here are for warn. Add a bit of humor into that.
> >>
> >> I do see a pattern here. Just joined D forum less than 4 weeks ago.
> >> Got a week off to clear my head. I think now I understand why D is still
> >> such a small community in the forum.
> >
> > I understand how you find that an attractive conclusion to reach, but probably a more rational hypothesis is that some of your proposals have been of poor quality. That doesn't reflect poorly on your abilities, it just suggests that you have not yet accumulated sufficient expertise with D.
> >
> > As an example, look at the activity of a current poster who proposed very strongly a change in a way the intervals are handled. It was arguably a very poor proposal for D, and people did their best to explain why. That poster was outwitted by competent people with clear and solid arguments. Yet that poster's way to solve that cognitive dissonance - the low road if you ask me - was to conclude that the value of his proposal is high in spite of all logic and reasoning, and that everyone else is wrong.
> >
> > I suggest you don't fall for the same pattern, though clearly I understand how attractive it is. It slows down learning.
> >
> >
> > Andrei
> 
> 
> Well, in Ruby every parameter type is auto. And it works pretty well. :-)
> 
> When you invoke a method and something goes wrong, like the auto parameter doesn't have a method, it gives a sensible error message.
> 
> So:
> 
> void foo(auto parameter) {
>    return parameter * 2;
> }
> 
> could just be the same as
> 
> void foo(T)(T parameter) {
>    return parameter * 2;
> }
> 
> just with a nicer syntax (but I understand it doesn't add much).
> 
> I think a reply like: "this is the same as a template" is better than "your proposals are of poor quality". It doesn't give a nice look to D, specially coming from one of its main leaders.

I agree with Ary above and would also like to add that in the ML family of languages all the variables are also default auto typed: E.g.: fun add a b = a + b

'add' would have the type ('a, 'a) -> 'a and the type inference engine will also infer that 'a must provide the + operator. I feel that this is more natural than having a dedicated function template syntax. Better yet, instead of auto parameters, just make parameter types optional (as in ML) and let the compiler generate the template.

foo(a, b) { return a + b; } // will be lowered to:
T foo(T) (T a, T b) { return a + b; }

Types are already inferred for delegate literals so why not extend this to regular functions too?

On Jun 7, 11 20:11, foobar wrote:
> I agree with Ary above and would also like to add that in the ML family of languages all the variables are also default auto typed:
> E.g.:
> fun add a b = a + b
>
> 'add' would have the type ('a, 'a) ->  'a and the type inference engine will also infer that 'a must provide the + operator.
> I feel that this is more natural than having a dedicated function template syntax.
> Better yet, instead of auto parameters, just make parameter types optional (as in ML) and let the compiler generate the template.
>

I don't think HM type inference (ML, Haskell) support implicit cast, i.e. you can't write { int a; double b; a + b; } anymore.

> foo(a, b) { return a + b; } // will be lowered to:
> T foo(T) (T a, T b) { return a + b; }
>
> Types are already inferred for delegate literals so why not extend this to regular functions too?
>

There is no type inference in delegate literal as powerful as HM, it's just "I call this function with parameters 'int' and 'float', so instantiate a new function with 'int' and 'float'." Also, type inference only work in template parameters

    struct F(alias f) {
      ...
    }
    alias F!((a,b){return a+b;}) G;

but not regular delegate literals

    auto c = (a,b){return a+b;};
    /* Error: undefined identifier a, b */

On 6/7/11 5:35 AM, Ary Manzana wrote:
> Well, in Ruby every parameter type is auto. And it works pretty well. :-)
>
> When you invoke a method and something goes wrong, like the auto
> parameter doesn't have a method, it gives a sensible error message.

It does, just at run time. The way dynamic languages and static languages set up computation is very different and as such difficult to compare something as core as function call resolution as equals for equals.

> So:
>
> void foo(auto parameter) {
> return parameter * 2;
> }
>
> could just be the same as
>
> void foo(T)(T parameter) {
> return parameter * 2;
> }
>
> just with a nicer syntax (but I understand it doesn't add much).

The counterpoint is that you seldom want to write foo() as written above. You want to clarify what family of types it is intended for.

> I think a reply like: "this is the same as a template" is better than
> "your proposals are of poor quality". It doesn't give a nice look to D,
> specially coming from one of its main leaders.

This criticism is inappropriate, but I'm sure it comes from a confusion in reading the thread. I made clear that the proposal you mention is sensible (although it has equally sensible counterarguments, which I also mentioned). My comment was referring to other proposals following an insistence of a poster that it's narrow-mindedness of the community, not the quality of his proposals, that renders them rejected.


Andrei

On 6/7/11 7:11 AM, foobar wrote:
> I agree with Ary above and would also like to add that in the ML family of languages all the variables are also default auto typed:
> E.g.:
> fun add a b = a + b
>
> 'add' would have the type ('a, 'a) ->  'a and the type inference engine will also infer that 'a must provide the + operator.
> I feel that this is more natural than having a dedicated function template syntax.

I agree it would be nice to further simplify generic function syntax. One problem with the example above is that the type deduction didn't go all that well - it forces both parameter types to be the same so it won't work with adding values of different types (different widths, mixed floating point and integrals, user-defined +). In a language without overloading, like ML, things are a fair amount easier.

> Better yet, instead of auto parameters, just make parameter types optional (as in ML) and let the compiler generate the template.
>
> foo(a, b) { return a + b; } // will be lowered to:
> T foo(T) (T a, T b) { return a + b; }
>
> Types are already inferred for delegate literals so why not extend this to regular functions too?

There are multiple issues. One is we don't have Hindley-Milner polymorphism. The D compiler doesn't really "infer" types as "propagate" them. Another is, such inference would make separate compilation difficult.


Andrei

Andrei Alexandrescu Wrote:

> On 6/7/11 7:11 AM, foobar wrote:
> > I agree with Ary above and would also like to add that in the ML family of languages all the variables are also default auto typed:
> > E.g.:
> > fun add a b = a + b
> >
> > 'add' would have the type ('a, 'a) ->  'a and the type inference engine will also infer that 'a must provide the + operator.
> > I feel that this is more natural than having a dedicated function template syntax.
> 
> I agree it would be nice to further simplify generic function syntax. One problem with the example above is that the type deduction didn't go all that well - it forces both parameter types to be the same so it won't work with adding values of different types (different widths, mixed floating point and integrals, user-defined +). In a language without overloading, like ML, things are a fair amount easier.
> 

ML is strictly typed unlike C-like languages. This is a *good* thing and is a feature. While C's implicit casts are a horrible hole in the language. Also ML has only two types: integers and floating point. There is no short vs long problems. Yes, both arguments will have the same type but this is the correct default. When adding a floating point and an integral the user should be required to specify what kind of operation is being made, either the double is converted to an integral (how? floor, round, etc? ) or the integral is converted to a floating point which can cause a loss of precision. Although overloading complicates things it doesn't mean it's impossible.

ML is explicit but only in the correct places. C-like languages have shortcuts but those are in the wrong places where it hurts and it's verbose in other places. I prefer to let the compiler infer types for me but require me to be explicit about coercion which is type safe vs. the reverse which is both more verbose and less safe.

> > Better yet, instead of auto parameters, just make parameter types optional (as in ML) and let the compiler generate the template.
> >
> > foo(a, b) { return a + b; } // will be lowered to:
> > T foo(T) (T a, T b) { return a + b; }
> >
> > Types are already inferred for delegate literals so why not extend this to regular functions too?
> 
> There are multiple issues. One is we don't have Hindley-Milner polymorphism. The D compiler doesn't really "infer" types as "propagate" them. Another is, such inference would make separate compilation difficult.
> 
> 
> Andrei

We don't Hindley-Miler _yet_. I can hope, can't I? Again, difficult != impossible. AFAIK it is working in Nemerle, isn't it?