View mode: basic / threaded / horizontal-split · Log in · Help
May 13, 2008
Re: Safer casts
2008/5/13 Frits van Bommel <fvbommel@remwovexcapss.nl>:
>  Overloading works fine without a class:
>  You're probably thinking of overriding, which requires a virtual method in
> a base class.

If you'd read a few posts on you would have realised I corrected that
mistake within /seconds/ of the original post. :-)
May 13, 2008
Re: Safer casts
Janice Caron wrote:
> 2008/5/13 Frits van Bommel <fvbommel@remwovexcapss.nl>:
>>  Overloading works fine without a class:
>>  You're probably thinking of overriding, which requires a virtual method in
>> a base class.
> 
> If you'd read a few posts on you would have realised I corrected that
> mistake within /seconds/ of the original post. :-)

And if you'd replied to your own post with that correction instead of 
re-replying to the parent post, I *would* have read that first :P.

Anyway, I'd already canceled my post when you posted yours...
May 13, 2008
Re: Safer casts
Janice Caron escribiĆ³:
> 2008/5/13 Yigal Chripun <yigal100@gmail.com>:
>>  Good Points! I thought about the IDE issue, but I wasn't sure how the
>>  IDE handles this.
> 
> I don't have an IDE, but in my text editor,
> 
>     "a < b"
> 
> is colored like a string, but
> 
>     q{ a < b }
> 
> is colored like D code throughout. So I can choose my quoting method
> depending on how I want my code colored. This works, not because my
> IDE is smart, but precisely because it isn't! It doesn't realise that
> q{...} is a string, so it gets colored like code.

That's just because normally most editors are configured so that "" and 
'' are colored as strings, so Walter chose an uncommon combination that 
won't get colored. But Descent colors q{...} as a string because it 
understands D and because... because it *is* a string! :-)

Also, same comment as Yigal: the coloring is the least important feature 
in my previous post.
May 13, 2008
Re: Safer casts
Janice Caron wrote:
> 2008/5/13 Yigal Chripun <yigal100@gmail.com>:
>>  the main thing for me is the syntax:
>>  look at Nemerle, for example.
>>  Here's a snippet:
>>
>>  class MoreFunctions {
>>    static run_twice (f : int -> int, v : int) : int
>>    {
>>      f (f (v))
>>    }
>>
>>    static run_adder (x : int) : void
>>    {
>>      def f (y : int) : int { x + y }; // <==== this is a nested function
>>      System.Console.WriteLine ("{0}", run_twice (f, 1))
>>    }
>>
>>    public static Run () : void
>>    {
>>      run_adder (1);
>>      run_adder (2);
>>    }
>>   }
> 
> And the same thing in D:
> 
>     class MoreFunctions
>     {
>         static run_twice!(alias f)(int v)
>         {
>             f(f(v))
>         }
> 
>         static run_adder (x : int) : void
>         {
>             int f(int y) { return x + y; };
>             writefln("{0}", run_twice!(f)(1))
>         }
> 
>         void main()
>         {
>             run_adder(1);
>             run_adder(2);
>         }
>     }
> 
> What's your point?
exactly. the point was for Dee about other languages that provide the
same functionality.
May 13, 2008
Re: Safer casts
Janice Caron wrote:
> 2008/5/13 Yigal Chripun <yigal100@gmail.com>:
>> <snip> Lots of stuff about inlining
> 
> Please don't confuse inlining with instantiation. This does not help
> the discussion.
> 
> Whether or not a compiler inlines a function or not is a decision made
> at the call site, however the function body must still exist elsewhere
> in the object file, in case other functions in other modules need to
> call it non-inlined.
> 
> If nothing calls it non-inlined, the linker should remove it when
> building the executable.
> 
> This has nothing whatsoever to do with template instantiation.
> Inlining may or may not happen with either functions or delegates, but
> it has no bearing whatsoever on the "to template or not" discussion.

you know, it's not easy to have two parallel conversations with two
different persons about almost the same thing, while one is is making
one point and another makes a different point.
concurrency is hard!!

Dee talks about inlining, and here I completely agree with you about:

> Inlining may or may not happen with either functions or delegates,
> but it has no bearing whatsoever on the "to template or not"
> discussion.

for me the question is how a template parametrized on the entire
delegate (i.e. an alias) compares with a template parametrized on the
element type of the array (which is how I would have done this, I think)
in regard to the number of instantiations of both solutions. I'd like to
hear your explanation comparing the two.

Thanks for your patience (is this spelled right?)

--Yigal
May 13, 2008
Re: Safer casts
On Tue, 13 May 2008 11:59:16 +0400, Yigal Chripun <yigal100@gmail.com>  
wrote:
> foo _is_ a delegate.
> there is no difference: As I explained in a different post, a delegate
> is simply two pointers where the context pointer either points to the
> surrounding function for nested functions or to the this pointer for
> methods.

No, it is not. It's just a function, that takes additional  
pointer-to-environment passed as a first (hidden) parameter (just like  
`this` inside member functions).
Note that you can't call it outside of the scope (since there would be no  
context pointer) unless you make delegate out of it (taking its address).  
That way, scope pointer stored in a delegate as well. That's all.
May 13, 2008
Re: Safer casts
Yigal Chripun Wrote:

> Janice Caron wrote:
> > 2008/5/13 Yigal Chripun <yigal100@gmail.com>:
> >>  the main thing for me is the syntax:
> >>  look at Nemerle, for example.
> >>  Here's a snippet:
> >>
> >>  class MoreFunctions {
> >>    static run_twice (f : int -> int, v : int) : int
> >>    {
> >>      f (f (v))
> >>    }
> >>
> >>    static run_adder (x : int) : void
> >>    {
> >>      def f (y : int) : int { x + y }; // <==== this is a nested function
> >>      System.Console.WriteLine ("{0}", run_twice (f, 1))
> >>    }
> >>
> >>    public static Run () : void
> >>    {
> >>      run_adder (1);
> >>      run_adder (2);
> >>    }
> >>   }
> > 
> > And the same thing in D:
> > 
> >     class MoreFunctions
> >     {
> >         static run_twice!(alias f)(int v)
> >         {
> >             f(f(v))
> >         }
> > 
> >         static run_adder (x : int) : void
> >         {
> >             int f(int y) { return x + y; };
> >             writefln("{0}", run_twice!(f)(1))
> >         }
> > 
> >         void main()
> >         {
> >             run_adder(1);
> >             run_adder(2);
> >         }
> >     }
> > 
> > What's your point?
> exactly. the point was for Dee about other languages that provide the
> same functionality.

I do not know Nemerle. But the way run_twice looks it is not parameterized statically. So all calls to run_twice will pass a pointer to function and go to the same body. Many languages do it. It is very different from D run_twice which is parameterized statically. There is big difference.

Also you said I talk about inlining. No. Janice is right. I talk about instantiation.

I write too much but I think I can not explain things well. Maybe better I stop in this discussion. Sorry, Dee Girl
May 13, 2008
Re: Safer casts
2008/5/13 Koroskin Denis <2korden@gmail.com>:
> > foo _is_ a delegate.
>
>  No, it is not. It's just a function, that takes additional
> pointer-to-environment passed as a first (hidden) parameter

I'm sure Yigal intended to mean "&foo _is_ a delegate". I understood
him, anyway.
May 13, 2008
Re: Safer casts
Janice Caron wrote:
> 2008/5/13 Yigal Chripun <yigal100@gmail.com>:
>>  I want the following API:
>>  (I don't care now for the internal implementation and the wrapper
>>  functions/aliases should be provided by the standard library)
>>
>>  array.sort; //same as array.sort(ASC);
> 
>     That one already works.
> 
>>  array.sort(DESC);
> 
>     alias std.algorithm.sort!("b<a") sort_reverse;
>     array.sort_reverse;
> 
> Is that close enough?
> 
> 
>>  array.sort(someStaticComperator);
>>  array.sort(aDelegateComperator);
>>  array.someOtherfunction(params);
> 
> That will never be possible either with or without templates.
> 
> Guess why?
> 
> Well, to save you guessing, I'll tell you. It's because "sort" is a
> built-in property of D's dynamic arrays. (Like length and ptr are
> built in). In general, we can define a function foo upon arrays which
> can be called as either
> 
>     foo(array,otherParams);
>     array.foo(otherParams);
> 
> But unfortunately, you can't do that if the function happens to be
> named "sort". (Likewise "length", "ptr", "init", and so on). As I
> said, this is /not/ a limitation of templates.

Wow, then tango.core.Array.sort must work by magic!  I had no idea Tango 
had such powers:

    C:\code\src\d\test>cat test.d
    import tango.core.Array;

    void main()
    {
        int[] buf = ([1,2,3]).dup;

        buf.sort( (int a, int b){ return a < b; } );
    }

    C:\code\src\d\test>dmd test

    C:\code\src\d\test>


Sean
May 13, 2008
Re: Safer casts
Janice Caron wrote:
> 2008/5/13 Koroskin Denis <2korden@gmail.com>:
>>> foo _is_ a delegate.
>>  No, it is not. It's just a function, that takes additional
>> pointer-to-environment passed as a first (hidden) parameter
> 
> I'm sure Yigal intended to mean "&foo _is_ a delegate". I understood
> him, anyway.

:-)
12 13 14 15 16 17
Top | Discussion index | About this forum | D home