tuple sumlimation

Kevin Bealer kevinbealer at gmail.com
Wed Feb 14 12:43:52 PST 2007


== Quote from Bill Baxter (dnewsgroup at billbaxter.com)'s article
> Kevin Bealer wrote:
> > Currently, Tuples are sublimated into argument lists.  What do people
> > think of using an operator (say, *) to prevent this?  The reason I ask
> > is that the current technique makes it hard to pass multiple tuples on
> > the same function call.
> >
> > I think it's not absolutely required; currently you can pass the tuple
> > lengths, let the tuples melt together, and then split them with slicing.
> >
> > Kevin
>
> I think Walter and Andrei are very aware that the inability to make
> Tuples hierarchical is a hindrance to many kinds of algorithms.
> But definitely some way to make hierarchical tuples is a must.  Lisp
> without nested lists is close to useless.
>
> The * type of syntax is used in Python to control expansion of tuples
> into arguments.  Though I think it's kind of backwards from what you're
> saing -- func(*args) causes args to be passed as separate arguments,
> func(args) passes it as a single argument that is a tuple.  Personally I
> think that makes more sense.   Automatically expanding as the default is
> kind of odd.  No other argument type modifies itself in funky ways when
> you pass it to a function.
>
> --bb

Yeah, this is what I had in mind but somehow I wrote a post that implied the
opposite.  The python way looks better if its okay to with break the current
tuple-using code.  If backward compatibility is needed, "&" could be used by
analogy, to do the opposite, i.e. ask for a tuple to stay 'wrapped up'.  This
seems wrong though because taking a pointer to a tuple should be possible.

If it's needed to work with pointers to tuples, maybe a different syntax
could be found.

Kevin



More information about the Digitalmars-d mailing list