I am very new to the D language and have not dug in too deep either.  I am impressed with what I have seen so far.  Since D is still under developmet, I would like to know if D has the following features.  If not, then the plasuability of incorporating them at some point in the future.

1) Multiple return values (like Matlab)

    eg.   (float[] data, string name, string unit) = getChannel(DataFile
file, int chanNo) ;

    This would eliminate alot a repetitive coding.  Also, as an option, the
compiler could force all LHS args to be 'outs' and RHS args to be 'ins'.

2) Variable argument lists for the caller and callee with type information automatically attached.

    eg.   CALLER:
            delegate myDelegate = func ;
            .
            .
            .
            param[] args ;
            args ~= 1.0 ;
            args ~=  "hello" ;
            myDelegate(args) ;

            CALLEE:
            /* I throw an exception if types do not match */
            func(float a, string message) {
                /* do something */
            }

    eg.    CALLER:
            func2("albert", 1916, "GR") ;

            CALLEE:
            func2( param[] args) {
                switch (args[0].type) {
                    case int:
                    /*etc */
                }
            }

    eg. Use variable argument lists on LHS too.

        CALLER:
        (param[] outArgs) = myDelegate(param[] inArgs) ;

        CALLEE:
        (param[] outArgs) = func(param[] inArgs)  {
            param[] myRetVals ;
            .
            .
            .
            myRetvals ~= result1 ;
            myRetvals ~= result2 ;
            return (myRetVals) ;
        }

3) Native support for plugin modules.  Allow plugin overloading.

    eg. myPict = openPicture("lion.gif") ;
          display(hWind, myPict) ;

        This call is to an abstract proxy class which when called searches
and catalogues all available plugins which have the proper interface.  It
asks each if it can successfully handle the case passed to the abstract
proxy class (eg. can you open a GIF?).  If it can, then it loads the plugin,
instantiates the concrete derived class and returns a reference to it.  All
subsequent calls are handled directly by the plugin.

Thank you,

Mark

"Mark Brudnak" <malibrud@provide.net> wrote in message news:bq3scc$28tl$1@digitaldaemon.com...
> I am very new to the D language and have not dug in too deep either.  I am impressed with what I have seen so far.

Thanks! Glad you're here.

>  Since D is still under developmet,
> I would like to know if D has the following features.  If not, then the
> plasuability of incorporating them at some point in the future.
>
> 1) Multiple return values (like Matlab)
>
>     eg.   (float[] data, string name, string unit) = getChannel(DataFile
> file, int chanNo) ;
>
>     This would eliminate alot a repetitive coding.  Also, as an option,
the
> compiler could force all LHS args to be 'outs' and RHS args to be 'ins'.

No. But it does have 'out' parameters, which does much the same thing.

> 2) Variable argument lists for the caller and callee with type information automatically attached.
>
>     eg.   CALLER:
>             delegate myDelegate = func ;
>             .
>             .
>             .
>             param[] args ;
>             args ~= 1.0 ;
>             args ~=  "hello" ;
>             myDelegate(args) ;
>
>             CALLEE:
>             /* I throw an exception if types do not match */
>             func(float a, string message) {
>                 /* do something */
>             }
>
>     eg.    CALLER:
>             func2("albert", 1916, "GR") ;
>
>             CALLEE:
>             func2( param[] args) {
>                 switch (args[0].type) {
>                     case int:
>                     /*etc */
>                 }
>             }
>
>     eg. Use variable argument lists on LHS too.
>
>         CALLER:
>         (param[] outArgs) = myDelegate(param[] inArgs) ;
>
>         CALLEE:
>         (param[] outArgs) = func(param[] inArgs)  {
>             param[] myRetVals ;
>             .
>             .
>             .
>             myRetvals ~= result1 ;
>             myRetvals ~= result2 ;
>             return (myRetVals) ;
>         }

No. There's been a lot of discussion about this, though.

> 3) Native support for plugin modules.  Allow plugin overloading.
>
>     eg. myPict = openPicture("lion.gif") ;
>           display(hWind, myPict) ;
>
>         This call is to an abstract proxy class which when called searches
> and catalogues all available plugins which have the proper interface.  It
> asks each if it can successfully handle the case passed to the abstract
> proxy class (eg. can you open a GIF?).  If it can, then it loads the
plugin,
> instantiates the concrete derived class and returns a reference to it.
All
> subsequent calls are handled directly by the plugin.

That seems like it would be a library feature. Would you care to write one?

> > 3) Native support for plugin modules.  Allow plugin overloading.
> >
> >     eg. myPict = openPicture("lion.gif") ;
> >           display(hWind, myPict) ;
> >
> >         This call is to an abstract proxy class which when called
searches
> > and catalogues all available plugins which have the proper interface.
It
> > asks each if it can successfully handle the case passed to the abstract proxy class (eg. can you open a GIF?).  If it can, then it loads the
> plugin,
> > instantiates the concrete derived class and returns a reference to it.
> All
> > subsequent calls are handled directly by the plugin.
>
> That seems like it would be a library feature.

Most definitely

> > 1) Multiple return values (like Matlab)

Boost has accomplished these 'tuples' through some template magic, perhaps the same can be done with D, although i agree I would LOVE to see a language that implemented this.

C


"Walter" <walter@digitalmars.com> wrote in message news:bq8rtf$l6o$1@digitaldaemon.com...
>
> "Mark Brudnak" <malibrud@provide.net> wrote in message news:bq3scc$28tl$1@digitaldaemon.com...
> > I am very new to the D language and have not dug in too deep either.  I
am
> > impressed with what I have seen so far.
>
> Thanks! Glad you're here.
>
> >  Since D is still under developmet,
> > I would like to know if D has the following features.  If not, then the
> > plasuability of incorporating them at some point in the future.
> >
> > 1) Multiple return values (like Matlab)
> >
> >     eg.   (float[] data, string name, string unit) = getChannel(DataFile
> > file, int chanNo) ;
> >
> >     This would eliminate alot a repetitive coding.  Also, as an option,
> the
> > compiler could force all LHS args to be 'outs' and RHS args to be 'ins'.
>
> No. But it does have 'out' parameters, which does much the same thing.
>
> > 2) Variable argument lists for the caller and callee with type
information
> > automatically attached.
> >
> >     eg.   CALLER:
> >             delegate myDelegate = func ;
> >             .
> >             .
> >             .
> >             param[] args ;
> >             args ~= 1.0 ;
> >             args ~=  "hello" ;
> >             myDelegate(args) ;
> >
> >             CALLEE:
> >             /* I throw an exception if types do not match */
> >             func(float a, string message) {
> >                 /* do something */
> >             }
> >
> >     eg.    CALLER:
> >             func2("albert", 1916, "GR") ;
> >
> >             CALLEE:
> >             func2( param[] args) {
> >                 switch (args[0].type) {
> >                     case int:
> >                     /*etc */
> >                 }
> >             }
> >
> >     eg. Use variable argument lists on LHS too.
> >
> >         CALLER:
> >         (param[] outArgs) = myDelegate(param[] inArgs) ;
> >
> >         CALLEE:
> >         (param[] outArgs) = func(param[] inArgs)  {
> >             param[] myRetVals ;
> >             .
> >             .
> >             .
> >             myRetvals ~= result1 ;
> >             myRetvals ~= result2 ;
> >             return (myRetVals) ;
> >         }
>
> No. There's been a lot of discussion about this, though.
>
> > 3) Native support for plugin modules.  Allow plugin overloading.
> >
> >     eg. myPict = openPicture("lion.gif") ;
> >           display(hWind, myPict) ;
> >
> >         This call is to an abstract proxy class which when called
searches
> > and catalogues all available plugins which have the proper interface.
It
> > asks each if it can successfully handle the case passed to the abstract proxy class (eg. can you open a GIF?).  If it can, then it loads the
> plugin,
> > instantiates the concrete derived class and returns a reference to it.
> All
> > subsequent calls are handled directly by the plugin.
>
> That seems like it would be a library feature. Would you care to write
one?
>
>

"Charles Sanders" <sanders-consulting@comcast.net> wrote in message news:bq8vs3$qos$1@digitaldaemon.com...
> > > 1) Multiple return values (like Matlab)
>
> Boost has accomplished these 'tuples' through some template magic, perhaps the same can be done with D, although i agree I would LOVE to see a
language
> that implemented this.
>
> C
>

I am surprised that Java or C# did not incorporate this feature.  The idea is not new and I think that semantically it is cleaner than in, out, inout. For complicated function calls with multiple ins and outs I usually define an in-structure and out-structure to facilitate same thing.  This however forces the declaration, allocation and stuffing/unstuffing on the part of the caller and callee (a lot of extra code).  For functions which return two or three values, this is overkill.  In these cases I have seen functions which return one value, be modified to return two values, one by value, one by reference.

i.e.    myResult = calculateIt( x, y, z) ;

becomes:  myResult = calculateIt(x, y, z, t, &anotherResult) ;  /* easiest
path to add another out */

with multiple return values the code would likely grow as follows

myResult = calculateIt( x, y, z) ;

becomes:  (myResult, anotherResult)  = calculateIt(x, y, z, t) ;  /* much
better ! */

"Charles Sanders" <sanders-consulting@comcast.net> wrote in message news:bq8vs3$qos$1@digitaldaemon.com...
> > > 1) Multiple return values (like Matlab)
>
> Boost has accomplished these 'tuples' through some template magic, perhaps the same can be done with D, although i agree I would LOVE to see a
language
> that implemented this.

I'd rather see it in the language, but if it's not I've no doubt it'll find its way in when the templates get a serious shake.

Matthew Wilson wrote:
> I'd rather see it in the language, but if it's not I've no doubt it'll find
> its way in when the templates get a serious shake.

With explicit intantiation we're probably back at custom return structs...

So better allow for simple type inference (Sather's ::= operator) and anonymous structs. Call them tuples then if you like.

-eye

Just a thought: I work in Matlab so I use the multiple return parameters. However, there are a few issues:

-concerning the "C"/"D" return values (i.e. using "return x;" would have to be
chnaged too, to accept multiple parameters). else, using a more "Pascal"-like
approach, i.e. returning the output parameters with the last value they have
before quiting the fcn. will simply change some fondamental concepts.
-in Matlab, one feature missing is the non-reference parameters transfer. This
means that, for each function affecting x you must write x=domsmthngto(x). IMO,
this should be avoided in "D". Is not very cool.


Felix




In article <bq9e98$1f9f$1@digitaldaemon.com>, Matthew Wilson says...
>
>
>"Charles Sanders" <sanders-consulting@comcast.net> wrote in message news:bq8vs3$qos$1@digitaldaemon.com...
>> > > 1) Multiple return values (like Matlab)
>>
>> Boost has accomplished these 'tuples' through some template magic, perhaps the same can be done with D, although i agree I would LOVE to see a
>language
>> that implemented this.
>
>I'd rather see it in the language, but if it's not I've no doubt it'll find its way in when the templates get a serious shake.
>
>
>

The syntax should be:

(int, float, double) funct( char[] foo, int bar) {
    int result1 ;
    float result2;
    double result3 ;

    /* do stuff */

    return (result1, result2, result3) ;
}

This would ofcourse impose a special meaning on the parenthesis and comma for the return statement.  I assume that D did away with the C-"comma operator" so there would be no ambiguity in the syntax.  This amounts to nothing more than a compiler generated struct used only for the passing of parameters on return.

mark.


"Felix" <Felix_member@pathlink.com> wrote in message news:bqesvv$310k$1@digitaldaemon.com...
> Just a thought: I work in Matlab so I use the multiple return parameters. However, there are a few issues:
>
> -concerning the "C"/"D" return values (i.e. using "return x;" would have
to be
> chnaged too, to accept multiple parameters). else, using a more
"Pascal"-like
> approach, i.e. returning the output parameters with the last value they
have
> before quiting the fcn. will simply change some fondamental concepts. -in Matlab, one feature missing is the non-reference parameters transfer.
This
> means that, for each function affecting x you must write x=domsmthngto(x).
IMO,
> this should be avoided in "D". Is not very cool.
>
>
> Felix
>
>
>
>
> In article <bq9e98$1f9f$1@digitaldaemon.com>, Matthew Wilson says...
> >
> >
> >"Charles Sanders" <sanders-consulting@comcast.net> wrote in message news:bq8vs3$qos$1@digitaldaemon.com...
> >> > > 1) Multiple return values (like Matlab)
> >>
> >> Boost has accomplished these 'tuples' through some template magic,
perhaps
> >> the same can be done with D, although i agree I would LOVE to see a
> >language
> >> that implemented this.
> >
> >I'd rather see it in the language, but if it's not I've no doubt it'll
find
> >its way in when the templates get a serious shake.
> >
> >
> >
>
>

Mark Brudnak wrote:
> 
> I am surprised that Java or C# did not incorporate this feature.  The idea
> is not new and I think that semantically it is cleaner than in, out, inout.
> For complicated function calls with multiple ins and outs I usually define
> an in-structure and out-structure to facilitate same thing.  This however
> forces the declaration, allocation and stuffing/unstuffing on the part of
> the caller and callee (a lot of extra code).  For functions which return two
> or three values, this is overkill.  In these cases I have seen functions
> which return one value, be modified to return two values, one by value, one
> by reference.
> 
> i.e.    myResult = calculateIt( x, y, z) ;
> 
> becomes:  myResult = calculateIt(x, y, z, t, &anotherResult) ;  /* easiest
> path to add another out */
> 
> with multiple return values the code would likely grow as follows
> 
> myResult = calculateIt( x, y, z) ;
> 
> becomes:  (myResult, anotherResult)  = calculateIt(x, y, z, t) ;  /* much
> better ! */


Honestly, I have not even thought about a feature like this...  Practlically
speaking, how would you call such a beast in the client code?

(foo, bar) = calculateIt( x, y, z, t );

and if we wanted to explicitly ignore a value:

(,bar) = calculateIt( x, y, z, t );

???