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