View mode: basic / threaded / horizontal-split · Log in · Help
October 04, 2012
Re: Will the D GC be awesome?
I wonder if tuple should automatically expand (flatten) into a 
list of arguments not only when used with template parameters, 
but with regular functions as well. This so, that it would enable 
composition of tuple returning functions with functions that take 
in individual arguments instead of a tuple, enabling that:

Tuple!(int, int) getTuple()
{
    //...
}

void fun(int arg1, int arg2)
{
    //...
}

void main()
{
    fun( getTuple() );
}
October 04, 2012
Re: Will the D GC be awesome?
On 10/04/2012 05:16 PM, Tommi wrote:
> I wonder if tuple should automatically expand (flatten) into a list of
> arguments not only when used with template parameters, but with regular
> functions as well. This so, that it would enable composition of tuple
> returning functions with functions that take in individual arguments
> instead of a tuple, enabling that:
>
> Tuple!(int, int) getTuple()
> {
>      //...
> }
>
> void fun(int arg1, int arg2)
> {
>      //...
> }
>
> void main()
> {
>      fun( getTuple() );
> }

No, it should not.

void main(){
    fun(getTuple().expand);
}
October 04, 2012
Re: Will the D GC be awesome?
On 2012-40-04 00:10, Tommi <tommitissari@hotmail.com> wrote:

> (tuples automatically expand if needed)

False. Typetuples do, but those cannot be returned from functions.

-- 
Simen
October 04, 2012
Re: Will the D GC be awesome?
On 2012-27-04 07:10, Walter Bright <newshound1@digitalmars.com> wrote:

>> * OpCmp returning an int is fugly I r sad
>
> How else would you return a 3 state value?

enum Comparison {
    Before = -1,
    Same = 0,
    After = 1,
    Unordered = NaN,
}

I'm not saying it should be done, but it would be more readable
(and more cmoplex to write).

-- 
Simen
October 04, 2012
Re: Will the D GC be awesome?
On Thursday, 4 October 2012 at 18:12:09 UTC, Timon Gehr wrote:
>
> void main(){
>     fun(getTuple().expand);
> }

Great, that works for me. It would be probably confusing if they 
tuples expanded automatically; non-obvious if you'd be passing 
one argument or multiple.
October 04, 2012
Re: Will the D GC be awesome?
On 2012-10-04, 20:56, Tommi wrote:

> On Thursday, 4 October 2012 at 18:12:09 UTC, Timon Gehr wrote:
>>
>> void main(){
>>     fun(getTuple().expand);
>> }
>
> Great, that works for me. It would be probably confusing if they tuples  
> expanded automatically; non-obvious if you'd be passing one argument or  
> multiple.

There's another reason:

void foo(T)(T, int, float);
void foo(T)(string, T);

Tuple!(int, float) getTuple();

foo("Hello", getTuple()); // What to call?

And:

void baz(T...)(T t);

baz(getTuple()) // Expand or not?


And while this is a constructed example, there is also the matter of
exponential possibilities for the overload system (Oh, so that didn't
work, maybe if I expand *this* tuple? No. *That* tuple? ...)

-- 
Simen
October 04, 2012
Re: Will the D GC be awesome?
On Wednesday, 3 October 2012 at 21:31:52 UTC, 
DypthroposTheImposter wrote:
>   D is pretty cool, perhaps someday I can use it instead of C++ 
> and have cool shit like fast build times, modules, no more 
> bloody headers, sane templates, CTFE, UFCS etc
>
>  But can the D GC ever be made:
>
> 1. precise
> 2. able to scale to large-ish data set(2gig+)
> 3. No long stalls(anything over a couple millisecond(<3))


This figure is quite meaningless: if I split a collection phase 
in several 2ms portion, it would be conformat yet the user would 
still see long stalls: you need to define both a period and a 
maximum period of time usable by the GC in this period.


> Q. Curious, would it be compacting?


Add VM-aware GC (http://lambda-the-ultimate.org/node/2391) and 
you'll have also my ideal but non existant GC.

That said I know two free languages with a "real time"  GC: 
SuperCollider and Nimrod.

>
>  If not then I'm stuck not using it much--
>
> Which leaves me with structs, and lets just say D struct are 
> not impressive--
>
>
> * Oh and on a totally unrelated note, D needs Multiple return 
> values. Lua has it, it's awesome.


Agreed here.

Regards,
renoX

> D doesn't want to be left out does it?
>
> * OpCmp returning an int is fugly I r sad
>
> * why is haskell so much shorter syntax, can D get that nice 
> syntax plssssssssss
>
> STAB!
October 05, 2012
Re: Will the D GC be awesome?
On 10/3/2012 11:50 PM, Jacob Carlborg wrote:
> On 2012-10-04 01:33, Alex Rønne Petersen wrote:
>
> > Use tuples. Multiple return values (as far as ABI goes) are impractical
> > because every major compiler back end (GCC, LLVM, ...) would have to be
> > adjusted for every architecture.
>
> Why can't it just be syntax sugar for returning a struct?
>

That's really the only credible way. A tuple should be an anonymous 
struct with the fields being the elements of the tuple.

The main issue for me for having perfect tuples is that the layout of 
fields in a struct is different from the layout of parameters being 
passed on the stack to a function. Ideally,

   struct S { int a; int b; }
   void foo(int p, int q);
   S s;
   foo(s);

should work (setting aside for the moment that they are different 
types). Unfortunately, the variety of function calling ABIs makes this 
impractical.

So tuples in a language like D that must conform to external ABIs is 
that tuples will always have some rough edges.
October 05, 2012
Re: Will the D GC be awesome?
> Ideally,
>    struct S { int a; int b; }
>    void foo(int p, int q);
>    S s;
>    foo(s);
>
> should work (setting aside for the moment that they are 
> different types). Unfortunately, the variety of function 
> calling ABIs makes this impractical.
> So tuples in a language like D that must conform to external 
> ABIs is that tuples will always have some rough edges.

Why not simply introduce an "expand" property for structs?
----
foo(s.expand) //equivalent to foo(s.a,s.b)
----
That would be the exact analogous of expand for tuples and would 
maintain a sane type system .
October 05, 2012
Re: Will the D GC be awesome?
On 2012-10-05 04:57, timotheecour wrote:

> Why not simply introduce an "expand" property for structs?
> ----
> foo(s.expand) //equivalent to foo(s.a,s.b)
> ----
> That would be the exact analogous of expand for tuples and would
> maintain a sane type system .

We already have the .tupleof property:

struct Foo
{
    int x;
    int y;
}

void foo (int a, int b)
{
    writeln(a, " ", b);
}

void main ()
{
    auto f = Foo(1, 2);
    foo(f.tupleof);
}

This works today and I'm pretty sure it has for a long time.

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