hi all,
Thanks for all the discussion, which changed my mind on a number of points.
I've uploaded a first attempt at a "list" object to CVS... see the help window, which also provides some examples. So far, I implemented these options:
list append - append a list to another list prepend - prepend a list to another list split - first n elements to first outlet, rest to second outlet list trim - trim off "list" selector
I'm not sure whether to keep the "list <function>" format or not now; the list seems divided over it and so am I. The advantage is it's the least visually cluttered way to name them. I can't use "append", "prepend", or "split" as names in their own right (they're already used, and using namespaces to alias well-known names would cause endless confusion!) The advantage to Iohannes's suggestion (list_append, etc.) is that external objects could supply list_whatever objects that could belong naturally to the series.
I think I have an adequate way to deal with non-list messages; they're converted to lists on input, and the "list trim" object can be used to explicitly convert back. I still think it's better style to use "true" lists wherever possible, but this will probably never find general agreement. My only advice is that, if you want to use non-list messages, just never, ever name a file "bang"!
cheers Miller
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:
I think I have an adequate way to deal with non-list messages; they're converted to lists on input, and the "list trim" object can be used to explicitly convert back.
[list trim] sounds like a very good idea. I made a little check and replaced all [prepend]s in Memento with [list prepend] and [list trim] and it's working very well in a short test. As I will need the prepend/trim combination several times, this is ideally solved with a little abstraction.
I still think it's better style to use "true" lists wherever possible, but this will probably never find general agreement.
One reason I found for needing "false" lists in Memento is because I dynamically generate messages for other selectors. For example the pool external, which stores key/value pairs, requires a message like "set a 1" in its first inlet to store a value "1" at key "a". Using "list set a 1" in this case does not work. An even simpler example might be to generate a "set 42" message to set a float atom. In this case, "list set 42" also will not set the float atom to 42. However with [list trim] this can be made to work. (Of course this example is rather academic.)
My only advice is that, if you want to use non-list messages, just never, ever name a file "bang"!
Hhm, not that I would want to do that, but why is that so? And what would happen?
Ciao
Frank Barknecht wrote:
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:
I think I have an adequate way to deal with non-list messages; they're converted to lists on input, and the "list trim" object can be used to explicitly convert back.
"list set a 1" in this case does not work. An even simpler example might be to generate a "set 42" message to set a float atom. In this case, "list set 42" also will not set the float atom to 42. However with [list trim] this can be made to work. (Of course this example is rather academic.)
even though working in academic environments, i don't feel like this problem is academic; it appears to me every other day.
the only thing that i don't understand is, why you cannot uses [route list]; this has worked for me for years. i don't see any realy reason to re-invent core objects for functionality that is already in the core set of objects. (of course there are many ways to achieve a certain thing esp. within pd, but i still don't think that this is a reason to introduce a whole new object.)
otoh, [l.trim] could be implemented as an abstraction...
mfg.ad.r IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
"list set a 1" in this case does not work. An even simpler example might be to generate a "set 42" message to set a float atom. In this case, "list set 42" also will not set the float atom to 42. However with [list trim] this can be made to work. (Of course this example is rather academic.)
even though working in academic environments, i don't feel like this problem is academic; it appears to me every other day.
Maybe because you're an academic? ;)
I meant, that to generate a message "set 42" in front of a float atom one would normally not use [list prepend set] or similar but a simple [set $1( message.
Ciao
On Mon, 25 Jul 2005, Frank Barknecht wrote:
I meant, that to generate a message "set 42" in front of a float atom one would normally not use [list prepend set] or similar but a simple [set $1( message.
If there would be a dollar argument that takes a whole list, this could be solved very elegantly, like:
[set $@(
just builds a message that starts with set and then comes the list.
Guenter
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: "plak" @ http://footils.org/cms/show/44
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hallo, Guenter Geiger hat gesagt: // Guenter Geiger wrote:
On Mon, 25 Jul 2005, Frank Barknecht wrote:
I meant, that to generate a message "set 42" in front of a float atom one would normally not use [list prepend set] or similar but a simple [set $1( message.
If there would be a dollar argument that takes a whole list, this could be solved very elegantly, like:
[set $@(
just builds a message that starts with set and then comes the list.
Well, a float atom just accepts one single argument anyways, so $@ is not needed in that case.
Generating arbitrary length "set" messages is possible with [list prepend set]---[list trim] or [route list]. The $@ however could be useful if you want to use "send-messages" like for example:
[list with unknown length( | | [f $0] | | | [makefilename pd-%d-subpatch] | | | [list $1( | | [list prepend] | [; $1 obj 10 10 myobj $@ (
I don't see a way this can be done except by using something like [send13] or [sprinkler], however often there are some other ways to work around a problem like this anyways (e.g. "add2" and "list serialize").
Ciao
On Mon, 25 Jul 2005, Frank Barknecht wrote:
If there would be a dollar argument that takes a whole list, this could be solved very elegantly, like:
[set $@(
just builds a message that starts with set and then comes the list.
Well, a float atom just accepts one single argument anyways, so $@ is not needed in that case.
I know, I was not talking about that, but about the original problem of dynamically generating messages. Sorry if that was not obvious.
Let me explain: In order to convert lists to messages I normally use message boxes with $ arguments. E.g if I send a list "foo 2" to [set $1 $2( it will construct a message that reads [set foo 2(, similar with a 3 element list and $1,$2,$3. Now, my proposal is to introduce a $@ dollar symbol which accepts lists of any length, this way it is not necessary to know the length of a list before converting it into a message. Hope this makes it clearer.
Cheers, Guenter
Generating arbitrary length "set" messages is possible with [list prepend set]---[list trim] or [route list]. The $@ however could be useful if you want to use "send-messages" like for example:
[list with unknown length( | | [f $0] | | | [makefilename pd-%d-subpatch] | | | [list $1( | | [list prepend] | [; $1 obj 10 10 myobj $@ (
I don't see a way this can be done except by using something like [send13] or [sprinkler], however often there are some other ways to work around a problem like this anyways (e.g. "add2" and "list serialize").
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: "plak" @ http://footils.org/cms/show/44
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hallo, Guenter Geiger hat gesagt: // Guenter Geiger wrote:
Let me explain: In order to convert lists to messages I normally use message boxes with $ arguments. E.g if I send a list "foo 2" to [set $1 $2( it will construct a message that reads [set foo 2(, similar with a 3 element list and $1,$2,$3. Now, my proposal is to introduce a $@ dollar symbol which accepts lists of any length, this way it is not necessary to know the length of a list before converting it into a message.
However with the new list processing objects the need to to use something like $@ will show up much less often because [list prepend set]---[list trim] would be the same as [set $@( in almost every case. The only exception I can think of currently are "send"-messages, i.e. those starting with ";". Still I agree, that $@ would be a useful feature, let alone to save some typing: [set $@( is much shorter than [set $1 $2 $3 $4 $5 $6 $7 $8 $9 $10 $11 $12 $13 $14 $15 $16 $17 $18(
Ciao
Frank Barknecht wrote:
Hallo, Guenter Geiger hat gesagt: // Guenter Geiger wrote:
Let me explain: In order to convert lists to messages I normally use message boxes with $ arguments. E.g if I send a list "foo 2" to [set $1 $2( it will construct a message that reads [set foo 2(, similar with a 3 element list and $1,$2,$3. Now, my proposal is to introduce a $@ dollar symbol which accepts lists of any length, this way it is not necessary to know the length of a list before converting it into a message.
and since there are some parallels between message-$-args and object-$-args, having a "$@" would also mean that you could have argument-lists of arbitrary length in abstractions in abstractions. [l $1 $2 $3 $4 $5] is not the same as [l $@].
so yes, i would vote for $@ and $# (well, the latter can be made with a general $@ and [l.length])
(and speaking of this i would also appreciate a mechanism to allow $args within! a symbol. something like $1_$2_$3 (i wouldn't mind ${1}_${2}_${3} (we could use some other bracket instead of the curly ones, they just bashed through my mind))
mfg.a.sdr IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
and since there are some parallels between message-$-args and object-$-args, having a "$@" would also mean that you could have argument-lists of arbitrary length in abstractions in abstractions. [l $1 $2 $3 $4 $5] is not the same as [l $@].
Now *THAT* would be mighty cool. I'm quite fond of IEM's [dollarg] already.
Ciao
On Jul 25, 2005, at 11:27 AM, Frank Barknecht wrote:
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
and since there are some parallels between message-$-args and object-$-args, having a "$@" would also mean that you could have argument-lists of arbitrary length in abstractions in abstractions. [l $1 $2 $3 $4 $5] is not the same as [l $@].
Now *THAT* would be mighty cool. I'm quite fond of IEM's [dollarg] already.
Yes, this would be really good. It would be nice to have that flexibility. It would make it much easier to build more complicated objects in Pd.
.hc
________________________________________________________________________ ____
"If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it."
- Thomas Jefferson
On Jul 25, 2005, at 8:23 AM, Frank Barknecht wrote:
Hallo, Guenter Geiger hat gesagt: // Guenter Geiger wrote:
Let me explain: In order to convert lists to messages I normally use message boxes with $ arguments. E.g if I send a list "foo 2" to [set $1 $2( it will construct a message that reads [set foo 2(, similar with a 3 element list and $1,$2,$3. Now, my proposal is to introduce a $@ dollar symbol which accepts lists of any length, this way it is not necessary to know the length of a list before converting it into a message.
However with the new list processing objects the need to to use something like $@ will show up much less often because [list prepend set]---[list trim] would be the same as [set $@( in almost every case. The only exception I can think of currently are "send"-messages, i.e. those starting with ";". Still I agree, that $@ would be a useful feature, let alone to save some typing: [set $@( is much shorter than [set $1 $2 $3 $4 $5 $6 $7 $8 $9 $10 $11 $12 $13 $14 $15 $16 $17 $18(
But [set $@( and [set $1 $2 $3 $4 $5 $6 $7 $8 $9 $10 $11 $12 $13 $14 $15 $16 $17 $18( would produce different results since the message's unused dollar args would be initialized to 0.
[one two three( | [set $1 $2 $3 $4 $5 $6 $7 $8 $9 $10 $11 $12 $13 $14 $15 $16 $17 $18( | [one two three 0 0 0 0 0 0 0 0 0 0 0 0 0 0(
While $@ should do this:
[one two three( | [set $@( | [one two three(
.hc
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: "plak" @ http://footils.org/cms/show/44
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
"The arc of history bends towards justice." - Dr. Martin Luther King, Jr.
Frank Barknecht wrote:
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
even though working in academic environments, i don't feel like this problem is academic; it appears to me every other day.
Maybe because you're an academic? ;)
got me ;-)
I meant, that to generate a message "set 42" in front of a float atom one would normally not use [list prepend set] or similar but a simple [set $1( message.
yes you are absolutely right. i was blinded by simplicity.
mfg.asd.r IOhannes
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:
The advantage to Iohannes's suggestion (list_append, etc.) is that external objects could supply list_whatever objects that could belong naturally to the series.
I forgot to add: I'm also undecided in this question, however if single names would be used, I as a user of a keyboard layout, which requires the Shift-key to type "_", would prefer another divider. The "." comes to my mind, maybe even with aliasses like:
list.append l.append
list.trim l.trim
etc.
I think, on all common keyboards the "." is input with its own key without any modifiers.
Ciao
hi miller, hi devs ...
a few comments:
list append - append a list to another
i'm not sure, if it's handy to have |list| as alias of list append ... personally, i'd prefer an object |list| to be an alias for a function like |zl reg|, which works only as storage object. i think, it's important to distinguish between storage functionality (i don't recall any other language which where storing a list has the side effect of appending)
list split - first n elements to first outlet, rest to secondoutlet
i'd propose to include negative arguments to split list from both the front and from the back ...
oh ... and i like the idea of a $@ or $* that expands in the dollar arguments of an abstraction and in the whole list in message boxes ...
cheers ... tim
ps: i just added the list objects to devel ...
On Jul 24, 2005, at 3:51 PM, Miller Puckette wrote:
hi all,
Thanks for all the discussion, which changed my mind on a number of points.
I am definitely glad you are working on this! This is something that will greatly improve message handling in Pd.
I've uploaded a first attempt at a "list" object to CVS... see the help window, which also provides some examples. So far, I implemented these options:
list append - append a list to another list prepend - prepend a list to another list split - first n elements to first outlet, rest to secondoutlet list trim - trim off "list" selector
I'm not sure whether to keep the "list <function>" format or not now; the list seems divided over it and so am I. The advantage is it's the least visually cluttered way to name them. I can't use "append", "prepend", or "split" as names in their own right
At pd~conf, we discussed renaming Pd's [append] for data structures to [add] so it would match [get] and [set]. Then [append] could be made to match [prepend]. Also, the current [append]'s help file describes it as "add an item to a list", so [add] makes sense. There is no existing [add] that I know of.
(they're already used, and using namespaces to alias well-known names would cause endless confusion!)
Such namespaces work well in many languages like Java, C, C++, perl, etc. etc. I think there would be rough-ish bits in transition, but in the long run would work much better for managing externals. It would also allow external writers to do whatever they want with their externals yet still be able to interoperate. The centralized management of a single namespace would no longer be necessary, it would be split up into chunks managed by individuals. And it would push Pd to the next step of becoming a fully fledged programming language.
This would also allow Pd to have its own distinct namespace without breaking Max compatibility. If you import cyclone in a patch, then cyclone's [split] would override Pd's. Then you could rename it to [cyclone/split] and you could take out the import statement and both splits would work. Or vice versa, with something like [pd/split].
The advantage to Iohannes's suggestion (list_append, etc.) is that external objects could supply list_whatever objects that could belong naturally to the series.
Its not so pretty but it would work.
I think I have an adequate way to deal with non-list messages; they're converted to lists on input, and the "list trim" object can be used to explicitly convert back. I still think it's better style to use "true" lists wherever possible, but this will probably never find general agreement. My only advice is that, if you want to use non-list messages, just never, ever name a file "bang"!
One of the core problems with message handling using lists is that they are not interpreted consistently across objects. For example, objects like [route] and [print] only interpret the first element 'list' when the following body of the message is an implied list, i.e. a set of atoms with a float as the first element. This means you can't use [route] to deal with a message stream that has both lists and undefined sets. If this was fixed, it would make mixed message handling in Pd much easier. With [print], this is a bummer because it means that there is no method within Pd that allows you to see the actual raw messages as Pd sees them.
This leads to me something that can be very confusing when dealing with message streams made up of lists, atoms, and "undefined sets": there are some objects that work with lists and some that work with "undefined sets" and its often not easily apparent to see which is which. Examples are [route], [print], [prepend]. I attached a patch to illustrate this.
.hc
________________________________________________________________________ ____
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously.
- Benjamin Franklin
I updated the attached patch to make my point much clearer. The first attempt wasn't so clear.
.hc
On Jul 25, 2005, at 5:36 PM, Hans-Christoph Steiner wrote:
On Jul 24, 2005, at 3:51 PM, Miller Puckette wrote:
hi all,
Thanks for all the discussion, which changed my mind on a number of points.
I am definitely glad you are working on this! This is something that will greatly improve message handling in Pd.
I've uploaded a first attempt at a "list" object to CVS... see the help window, which also provides some examples. So far, I implemented these options:
list append - append a list to another list prepend - prepend a list to another list split - first n elements to first outlet, rest to secondoutlet list trim - trim off "list" selector
I'm not sure whether to keep the "list <function>" format or not now; the list seems divided over it and so am I. The advantage is it's the least visually cluttered way to name them. I can't use "append", "prepend", or "split" as names in their own right
At pd~conf, we discussed renaming Pd's [append] for data structures to [add] so it would match [get] and [set]. Then [append] could be made to match [prepend]. Also, the current [append]'s help file describes it as "add an item to a list", so [add] makes sense. There is no existing [add] that I know of.
(they're already used, and using namespaces to alias well-known names would cause endless confusion!)
Such namespaces work well in many languages like Java, C, C++, perl, etc. etc. I think there would be rough-ish bits in transition, but in the long run would work much better for managing externals. It would also allow external writers to do whatever they want with their externals yet still be able to interoperate. The centralized management of a single namespace would no longer be necessary, it would be split up into chunks managed by individuals. And it would push Pd to the next step of becoming a fully fledged programming language.
This would also allow Pd to have its own distinct namespace without breaking Max compatibility. If you import cyclone in a patch, then cyclone's [split] would override Pd's. Then you could rename it to [cyclone/split] and you could take out the import statement and both splits would work. Or vice versa, with something like [pd/split].
The advantage to Iohannes's suggestion (list_append, etc.) is that external objects could supply list_whatever objects that could belong naturally to the series.
Its not so pretty but it would work.
I think I have an adequate way to deal with non-list messages; they're converted to lists on input, and the "list trim" object can be used to explicitly convert back. I still think it's better style to use "true" lists wherever possible, but this will probably never find general agreement. My only advice is that, if you want to use non-list messages, just never, ever name a file "bang"!
One of the core problems with message handling using lists is that they are not interpreted consistently across objects. For example, objects like [route] and [print] only interpret the first element 'list' when the following body of the message is an implied list, i.e. a set of atoms with a float as the first element. This means you can't use [route] to deal with a message stream that has both lists and undefined sets. If this was fixed, it would make mixed message handling in Pd much easier. With [print], this is a bummer because it means that there is no method within Pd that allows you to see the actual raw messages as Pd sees them.
This leads to me something that can be very confusing when dealing with message streams made up of lists, atoms, and "undefined sets": there are some objects that work with lists and some that work with "undefined sets" and its often not easily apparent to see which is which. Examples are [route], [print], [prepend]. I attached a patch to illustrate this.
.hc
<list_catalog.pd> _______________________________________________________________________ _____
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously.
- Benjamin Franklin
________________________________________________________________________ ____
"Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism."
- retired U.S. Army general, William Odom
Hey all,
I've been barely able to keep up with this thread. Lots of ideas and changes. Here I agree with everything that HC has to say.
I'm also a bit confused (anoyed) about the whole list vs nonlist things just for the reasons HC mentions. Miller, you said it is probably "better" to use lists rather than lists that do not start with "list" as the first element, non-lists. Why is this?? I think a list should be:
* interpreted in many cases as a non-list. (ie creating OSC names for example, [list send /hello/blah value] automatically gets rid of the "list" part because it knows what to do about it.
* be able to contain a mix of symbols and float atoms
* there be only be one "list-like" thing, I don't know what this would make a non-list into... an undefined list? One would not need a non-list if the first point above was true and the "list" part not considered part of the list. (NOT the first element, but something invisible that you never need to see, like "float [float]" where I have never had the need to worry about it but the damn list selector comes up all the time. :(
Thats all for me.
b>
Hans-Christoph Steiner wrote:
On Jul 24, 2005, at 3:51 PM, Miller Puckette wrote:
hi all,
Thanks for all the discussion, which changed my mind on a number of points.
I am definitely glad you are working on this! This is something that will greatly improve message handling in Pd.
I've uploaded a first attempt at a "list" object to CVS... see the help window, which also provides some examples. So far, I implemented these options:
list append - append a list to another list prepend - prepend a list to another list split - first n elements to first outlet, rest to second outlet list trim - trim off "list" selectorI'm not sure whether to keep the "list <function>" format or not now; the list seems divided over it and so am I. The advantage is it's the least visually cluttered way to name them. I can't use "append", "prepend", or "split" as names in their own right
At pd~conf, we discussed renaming Pd's [append] for data structures to [add] so it would match [get] and [set]. Then [append] could be made to match [prepend]. Also, the current [append]'s help file describes it as "add an item to a list", so [add] makes sense. There is no existing [add] that I know of.
(they're already used, and using namespaces to alias well-known names would cause endless confusion!)
Such namespaces work well in many languages like Java, C, C++, perl, etc. etc. I think there would be rough-ish bits in transition, but in the long run would work much better for managing externals. It would also allow external writers to do whatever they want with their externals yet still be able to interoperate. The centralized management of a single namespace would no longer be necessary, it would be split up into chunks managed by individuals. And it would push Pd to the next step of becoming a fully fledged programming language.
This would also allow Pd to have its own distinct namespace without breaking Max compatibility. If you import cyclone in a patch, then cyclone's [split] would override Pd's. Then you could rename it to [cyclone/split] and you could take out the import statement and both splits would work. Or vice versa, with something like [pd/split].
The advantage to Iohannes's suggestion (list_append, etc.) is that external objects could supply list_whatever objects that could belong naturally to the series.
Its not so pretty but it would work.
I think I have an adequate way to deal with non-list messages; they're converted to lists on input, and the "list trim" object can be used to explicitly convert back. I still think it's better style to use "true" lists wherever possible, but this will probably never find general agreement. My only advice is that, if you want to use non-list messages, just never, ever name a file "bang"!
One of the core problems with message handling using lists is that they are not interpreted consistently across objects. For example, objects like [route] and [print] only interpret the first element 'list' when the following body of the message is an implied list, i.e. a set of atoms with a float as the first element. This means you can't use [route] to deal with a message stream that has both lists and undefined sets. If this was fixed, it would make mixed message handling in Pd much easier. With [print], this is a bummer because it means that there is no method within Pd that allows you to see the actual raw messages as Pd sees them.
This leads to me something that can be very confusing when dealing with message streams made up of lists, atoms, and "undefined sets": there are some objects that work with lists and some that work with "undefined sets" and its often not easily apparent to see which is which. Examples are [route], [print], [prepend]. I attached a patch to illustrate this.
.hc
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously.
- Benjamin Franklin
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Wed, Jul 27, 2005 at 08:52:10AM -0400, B. Bogart wrote:
Hey all,
I've been barely able to keep up with this thread. Lots of ideas and changes. Here I agree with everything that HC has to say.
I'm also a bit confused (anoyed) about the whole list vs nonlist things just for the reasons HC mentions. Miller, you said it is probably "better" to use lists rather than lists that do not start with "list" as the first element, non-lists. Why is this?? I think a list should be:
interpreted in many cases as a non-list. (ie creating OSC names for example, [list send /hello/blah value] automatically gets rid of the "list" part because it knows what to do about it.
be able to contain a mix of symbols and float atoms
there be only be one "list-like" thing, I don't know what this would make a non-list into... an undefined list? One would not need a non-list if the first point above was true and the "list" part not considered part of the list. (NOT the first element, but something invisible that you never need to see, like "float [float]" where I have never had the need to worry about it but the damn list selector comes up all the time. :(
Thats all for me.
Well, there's an attempt to straighten this out in a subpatch of the "list" help window...
cheers Miller
On Jul 27, 2005, at 1:30 PM, Miller Puckette wrote:
On Wed, Jul 27, 2005 at 08:52:10AM -0400, B. Bogart wrote:
Hey all,
I've been barely able to keep up with this thread. Lots of ideas and changes. Here I agree with everything that HC has to say.
I'm also a bit confused (anoyed) about the whole list vs nonlist things just for the reasons HC mentions. Miller, you said it is probably "better" to use lists rather than lists that do not start with "list" as the first element, non-lists. Why is this?? I think a list should be:
interpreted in many cases as a non-list. (ie creating OSC names for example, [list send /hello/blah value] automatically gets rid of the "list" part because it knows what to do about it.
be able to contain a mix of symbols and float atoms
there be only be one "list-like" thing, I don't know what this would make a non-list into... an undefined list? One would not need a non-list if the first point above was true and the "list" part not considered part of the list. (NOT the first element, but something invisible that you never need to see, like "float [float]" where I have never had the need to worry about it but the damn list selector comes up all the time. :(
Thats all for me.
Well, there's an attempt to straighten this out in a subpatch of the "list" help window...
How much would it change things to make a message with a "list" selector always behave as a list? (i.e. the [print] and [route] examples that I gave and the [x.wav 44100( example that you gave) I think that alone would go a really long way to making the whole list/non-list thing much easier to work with. If I could just [prepend list] to everything and everything would then be treated as a list everywhere, I would be much happier.
Just out of curiosity, is Max/MSP setup the same way or are things different with list/non-lists?
.hc
________________________________________________________________________ ____
"Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism."
- retired U.S. Army general, William Odom
On Jul 27, 2005, at 1:30 PM, Miller Puckette wrote:
On Wed, Jul 27, 2005 at 08:52:10AM -0400, B. Bogart wrote:
Hey all,
I've been barely able to keep up with this thread. Lots of ideas and changes. Here I agree with everything that HC has to say.
I'm also a bit confused (anoyed) about the whole list vs nonlist things just for the reasons HC mentions. Miller, you said it is probably "better" to use lists rather than lists that do not start with "list" as the first element, non-lists. Why is this?? I think a list should be:
interpreted in many cases as a non-list. (ie creating OSC names for example, [list send /hello/blah value] automatically gets rid of the "list" part because it knows what to do about it.
be able to contain a mix of symbols and float atoms
there be only be one "list-like" thing, I don't know what this would make a non-list into... an undefined list? One would not need a non-list if the first point above was true and the "list" part not considered part of the list. (NOT the first element, but something invisible that you never need to see, like "float [float]" where I have never had the need to worry about it but the damn list selector comes up all the time. :(
Thats all for me.
Well, there's an attempt to straighten this out in a subpatch of the "list" help window...
Ok, I just did a quick survey of Max/MSP's behavior. Max handles the [route one] example properly (both output from the left outlet):
[one 2 three( | [list one 2 three( |/ [route one]
Max does [route list] badly, Pd outputs on the correct outlets (but it seems a little odd to me that [route list] would not output a list on its left outlet):
[1 two 3] | [list 1 two three( | /[one 2 three( | //[list one 2 three( |/// [route list]
(which outlet) Max Pd ----------------------------------------- 1 two 3 left left list 1 two 3 left left one 2 three right right list one 2 three right left
And lastly, [print]. Max is more consistent, but it would be nice to see the selectors when they exist:
[1 two 3] | [list 1 two three( | /[one 2 three( | //[list one 2 three( |/// [print] Max Pd ----------------------------------------- 1 two 3 1 two 3 1 two 3 list 1 two 3 1 two 3 1 two 3 one 2 three one 2 three one 2 three list one 2 three one 2 three list one 2 three
This investigation lead me to another odd behavior: [route symbol] outputs a symbol on its left outlet, while [route list] outputs a non-list. While it is definitely useful to have an object with can strip off the "list" selector, I don't think it should be called [route list]. [route list] should output a list for every list it receives on its inlet.
I added an example of this to my collection:
.hc
________________________________________________________________________ ____
¡El pueblo unido jamás será vencido!
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
This investigation lead me to another odd behavior: [route symbol] outputs a symbol on its left outlet, while [route list] outputs a non-list. While it is definitely useful to have an object with can strip off the "list" selector, I don't think it should be called [route list]. [route list] should output a list for every list it receives on its inlet.
But
[something which is a kind of list( | [route something]
will strip of the "something" part, so stripping off "list" with "route list" is consistent with that behaviour.
Apart from that, using [route list] to trim lists of "list" is probably very common (Iohannes does it, I did it) so changing it would mean breaking patches.
Ciao
Apart from that, using [route list] to trim lists of "list" is probably very common (Iohannes does it, I did it) so changing it would mean breaking patches.
yep, i use route list too, and prepend list occasionally, which, if the goal of not introducing string types (which may confuse a user between string and symbol) or int or other data types alongside float, then having pseudolists and real lists is inconsistent with this paradigm. it took me a while to figure out 'this is not a list' 'list is however' for one..
On Jul 28, 2005, at 5:54 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
This investigation lead me to another odd behavior: [route symbol] outputs a symbol on its left outlet, while [route list] outputs a non-list. While it is definitely useful to have an object with can strip off the "list" selector, I don't think it should be called [route list]. [route list] should output a list for every list it receives on its inlet.
But
[something which is a kind of list( | [route something]
will strip of the "something" part, so stripping off "list" with "route list" is consistent with that behaviour.
Apart from that, using [route list] to trim lists of "list" is probably very common (Iohannes does it, I did it) so changing it would mean breaking patches.
These two points are definitely true, I am not saying that it would be an easy change. But I think [route list] would have to always output a list on its left outlet in order for Miller's suggestion to work, which was to try to treat everything as a list when doing message handling. I could be wrong, but I think we should try it.
Also, [route symbol] does not trim the selector "symbol", so there is a precedence here. We can look at the reserved words in Pd: "bang", "float", "symbol", and "list". [route bang], [route float], [route symbol] all output the same data type on their left inlet. [route list] does not always output a list, even though it is interpreting incoming lists, not merely routing by keyword. More example patches!
In the process, I documented some more behaviors of Pd related to all this. [trigger list] outputs a list for everything except sets starting with a symbol that is not "list". It also interprets lists on input, like [route list] (i.e. [list 1 2 3( is [1 2 3( on the outlet).
According to [route bang float symbol list], [float( remains a float and is inited to 0. [symbol( remains a blank symbol. [list( is converted to a bang.
And another: [float 1( remains a float; [float 1 2 3( remains a float, but is cut to one element; [list 1 2 3( remains a list; and [list 1( is converted to a float. (It would be nice to have a warning when [float 1 2 3( is chopped to one element, that could help with debugging perhaps).
And lastly: [print] interprets all floats (i.e. [1( and [float 1( both output "1"). [print] does not interpret symbols (i.e. [symbol test( prints "symbol test", [symbol( prints "symbol") and only interprets lists whose first element is a float.
I am not saying that all these things I am documenting must change, I am trying to demonstrate what makes handling data in Pd so confusing at times, especially when working with lists. Things do not always behave consistently or intuitively.
In order for things to get better, there will have to be some changes that will break backwards compatibility. But that's why Pd is version 0, right? Plus for old patches, you can always use old versions of Pd. Many programs break backwards compatibility in the quest for 1.0, its too be expected. Its the only way to make real progress.
.hc
________________________________________________________________________ ____
¡El pueblo unido jamás será vencido!
Hi,
I agree with hc that a "route list" should not strip of the list, if we want to be consistent. But if people use it that much, then there is nothing to do about it. It might be impossible to remove all the ambiguities in the message and type system anyhow.
Guenter
On Thu, 28 Jul 2005, Hans-Christoph Steiner wrote:
On Jul 28, 2005, at 5:54 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
This investigation lead me to another odd behavior: [route symbol] outputs a symbol on its left outlet, while [route list] outputs a non-list. While it is definitely useful to have an object with can strip off the "list" selector, I don't think it should be called [route list]. [route list] should output a list for every list it receives on its inlet.
But
[something which is a kind of list( | [route something]
will strip of the "something" part, so stripping off "list" with "route list" is consistent with that behaviour.
Apart from that, using [route list] to trim lists of "list" is probably very common (Iohannes does it, I did it) so changing it would mean breaking patches.
These two points are definitely true, I am not saying that it would be an easy change. But I think [route list] would have to always output a list on its left outlet in order for Miller's suggestion to work, which was to try to treat everything as a list when doing message handling. I could be wrong, but I think we should try it.
Also, [route symbol] does not trim the selector "symbol", so there is a precedence here. We can look at the reserved words in Pd: "bang", "float", "symbol", and "list". [route bang], [route float], [route symbol] all output the same data type on their left inlet. [route list] does not always output a list, even though it is interpreting incoming lists, not merely routing by keyword. More example patches!
One more example patch, I guess I can't stop: [trigger list] always outputs a list for any list it accepts:
.hc
On Jul 28, 2005, at 4:05 PM, Guenter Geiger wrote:
Hi,
I agree with hc that a "route list" should not strip of the list, if we want to be consistent. But if people use it that much, then there is nothing to do about it. It might be impossible to remove all the ambiguities in the message and type system anyhow.
Guenter
On Thu, 28 Jul 2005, Hans-Christoph Steiner wrote:
On Jul 28, 2005, at 5:54 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
This investigation lead me to another odd behavior: [route symbol] outputs a symbol on its left outlet, while [route list] outputs a non-list. While it is definitely useful to have an object with can strip off the "list" selector, I don't think it should be called [route list]. [route list] should output a list for every list it receives on its inlet.
But
[something which is a kind of list( | [route something]
will strip of the "something" part, so stripping off "list" with "route list" is consistent with that behaviour.
Apart from that, using [route list] to trim lists of "list" is probably very common (Iohannes does it, I did it) so changing it would mean breaking patches.
These two points are definitely true, I am not saying that it would be an easy change. But I think [route list] would have to always output a list on its left outlet in order for Miller's suggestion to work, which was to try to treat everything as a list when doing message handling. I could be wrong, but I think we should try it.
Also, [route symbol] does not trim the selector "symbol", so there is a precedence here. We can look at the reserved words in Pd: "bang", "float", "symbol", and "list". [route bang], [route float], [route symbol] all output the same data type on their left inlet. [route list] does not always output a list, even though it is interpreting incoming lists, not merely routing by keyword. More example patches!
________________________________________________________________________ ____
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
-
B. Bogart -
Frank Barknecht -
Guenter Geiger -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
ix＠replic.net -
Miller Puckette -
Tim Blechmann