Hi devs...
I'm thinking about finally writing a "list" object for Pd to do jobs like "append", "any", etc. I've held off so far because I've felt unsure about the best design... and once I stick it in the "base" Pd it will be hard to change.
To avoid cluttering up the namespace I want to use just the one name, "list", and use the first argument to differentiate between functions (an idea inspired by Krzysztof's xeq object). Here are the functions I imagine:
list append - append a list to another list prepend - prepend a list to another list cat - build a list by accumulating elements list serialize - spit out elements of a list one by one list first - output first n elements list last - output last n elements list length - output number of items in list list reverse - permute elements of a list back to front list pack - synonym for 'pack' list unpack - synonym for 'unpack' list selector - change selector of a list list <no args> - "prepend" the selector list to non-list messages
The "append" option would also play the role of "any" (just bang the left inlet after putting any list in the right).
All of these would expect the "list" selector at the head of messages, with the exception of plain "list"; all of them would output "list" messages except "list selector". These would work as follows:
--------------------------- list ---------------------------------- in (real message) in (as printed) out (real message) out (as printed) list bang (same) list 1 1 (same) list foo list foo (same) foo foo list foo list foo
--------------------------- list selector bar ------------------------- in (real message) in (as printed) out (real message) out (as printed) list bang bar list 1 1 bar 1 list foo list foo bar foo foo foo (error)
There's one inconvenience with plain "list" since you can't differentiate "list foo" from "foo" using its output; you'd have to use "route list symbol" first and then do whatever you wanted to do differently ("list list foo" for example). It seemed better to leave that to the imagination of programmers, since there seem to be disagreements about it...
cheers Miller
It looks like the ASCII diagrams got butchered, but it sounds like a nice object to have in Pd. Can you make a txt or pdf document as an attachment?
On Jul 19, 2005, at 8:13 PM, Miller Puckette wrote:
Hi devs...
I'm thinking about finally writing a "list" object for Pd to do jobs like "append", "any", etc. I've held off so far because I've felt unsure about the best design... and once I stick it in the "base" Pd it will be hard to change.
To avoid cluttering up the namespace I want to use just the one name, "list", and use the first argument to differentiate between functions (an idea inspired by Krzysztof's xeq object). Here are the functions I imagine:
list append - append a list to another list prepend - prepend a list to another list cat - build a list by accumulating elements list serialize - spit out elements of a list one by one list first - output first n elements list last - output last n elements list length - output number of items in list list reverse - permute elements of a list back to front list pack - synonym for 'pack' list unpack - synonym for 'unpack' list selector - change selector of a list list <no args> - "prepend" the selector list to non-list messagesThe "append" option would also play the role of "any" (just bang the left inlet after putting any list in the right).
All of these would expect the "list" selector at the head of messages, with the exception of plain "list"; all of them would output "list" messages except "list selector". These would work as follows:
--------------------------- list ---------------------------------- in (real message) in (as printed) out (real message) out (as printed) list bang (same) list 1 1 (same) list foo list foo (same) foo foo list foo list foo
--------------------------- list selector bar
in (real message) in (as printed) out (real message) out (as printed) list bang bar list 1 1 bar 1 list foo list foo bar foo foo foo (error)
There's one inconvenience with plain "list" since you can't differentiate "list foo" from "foo" using its output; you'd have to use "route list symbol" first and then do whatever you wanted to do differently ("list list foo" for example). It seemed better to leave that to the imagination of programmers, since there seem to be disagreements about it...
cheers Miller
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hi Chris,
Just paste into a text editor and set the font to anything fixed-width (such as "courier" but not "helvetica" or "times"...
cheers Miller
On Tue, Jul 19, 2005 at 08:31:37PM -0500, chris clepper wrote:
It looks like the ASCII diagrams got butchered, but it sounds like a nice object to have in Pd. Can you make a txt or pdf document as an attachment?
On Jul 19, 2005, at 8:13 PM, Miller Puckette wrote:
Hi devs...
I'm thinking about finally writing a "list" object for Pd to do jobs like "append", "any", etc. I've held off so far because I've felt unsure about the best design... and once I stick it in the "base" Pd it will be hard to change.
To avoid cluttering up the namespace I want to use just the one name, "list", and use the first argument to differentiate between functions (an idea inspired by Krzysztof's xeq object). Here are the functions I imagine:
list append - append a list to another list prepend - prepend a list to another list cat - build a list by accumulating elements list serialize - spit out elements of a list one by one list first - output first n elements list last - output last n elements list length - output number of items in list list reverse - permute elements of a list back to front list pack - synonym for 'pack' list unpack - synonym for 'unpack' list selector - change selector of a list list <no args> - "prepend" the selector list to non-list messages
The "append" option would also play the role of "any" (just bang the left inlet after putting any list in the right).
All of these would expect the "list" selector at the head of messages, with the exception of plain "list"; all of them would output "list" messages except "list selector". These would work as follows:
--------------------------- list ---------------------------------- in (real message) in (as printed) out (real message) out (as printed) list bang (same) list 1 1 (same) list foo list foo (same) foo foo list foo list foo
--------------------------- list selector bar
in (real message) in (as printed) out (real message) out (as printed) list bang bar list 1 1 bar 1 list foo list foo bar foo foo foo (error)
There's one inconvenience with plain "list" since you can't differentiate "list foo" from "foo" using its output; you'd have to use "route list symbol" first and then do whatever you wanted to do differently ("list list foo" for example). It seemed better to leave that to the imagination of programmers, since there seem to be disagreements about it...
cheers Miller
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
There's one inconvenience with plain "list" since you can't differentiate "list foo" from "foo" using its output; you'd have to use "route list symbol" first and then do whatever you wanted to do differently ("list list foo" for example). It seemed better to leave that to the imagination of programmers, since there seem to be disagreements about it...
well, i'd suggest to forbid one-element lists as much as possible, but treat them as atoms. since pd only handles flat lists, we don't really loose features ... on the other hand it will hopefully avoid list vs. symbol/float/pointer bugs in patches ... would make it easier to write bug-free patches...
cheers ... tim
On Wed, 20 Jul 2005, Tim Blechmann wrote:
well, i'd suggest to forbid one-element lists as much as possible, but treat them as atoms. since pd only handles flat lists, we don't really loose features ...
What do you mean by all of that?
What happens with [list first 1] given that it would have to output only one atom?
,-o--------o--------o--------o-. ,---. irc.freenode.net #dataflow | | The Diagram is the Program tm| | ,-o-------------o--------------o-. `-o------------o-------------o-' | | Mathieu Bouchard (Montréal QC) | | téléphone:+1.514.383.3801`---' `-o-- http://artengine.ca/matju -'
On Wed, 20 Jul 2005, Tim Blechmann wrote:
There's one inconvenience with plain "list" since you can't differentiate "list foo" from "foo" using its output; you'd have to use "route list symbol" first and then do whatever you wanted to do differently ("list list foo" for example). It seemed better to leave that to the imagination of programmers, since there seem to be disagreements about it...
well, i'd suggest to forbid one-element lists as much as possible, but treat them as atoms. since pd only handles flat lists, we don't really loose features ... on the other hand it will hopefully avoid list vs. symbol/float/pointer bugs in patches ... would make it easier to write bug-free patches...
I don't understand what you mean by "forbid one-element lists". These are already treated as atoms: [list(, [list 1(, [list one(. Do you mean have the [list] object not accept these as input? I suppose that would depend on where the conversion from list to atom happens. If it happens before the inlet, then that would happen automatically since [list] would only accept lists on its inlet.
It seems to me that these automatic conversions cause a lot of confusion and I can't see the benefit or necessity for them. Could anyone elaborate on why this automatic conversions of lists is needed? Does anyone rely on it? I have done a lot of general message processing and I've never relied on that behavior.
.hc
cheers ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
latest mp3: kMW.mp3 http://mattin.org/mp3.html
latest cd: Goh Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
zen \ \ \[D[D[D[D
I don't understand what you mean by "forbid one-element lists". These are already treated as atoms: [list(, [list 1(, [list one(. Do you mean have the [list] object not accept these as input? I suppose that would depend on where the conversion from list to atom happens. If it happens before the inlet, then that would happen automatically since [list] would only accept lists on its inlet.
zero/one element lists are a lovely source for errors ... pd doesn't have a list type as powerful as other languages ... empty lists should be treated as bangs, one-element lists as atoms ... having no zero/one element lists internally, would make pd more robust ... and i don't see that we loose any functionality ... pd is not lisp ...
It seems to me that these automatic conversions cause a lot of confusion and I can't see the benefit or necessity for them. Could anyone elaborate on why this automatic conversions of lists is needed? Does anyone rely on it? I have done a lot of general message processing and I've never relied on that behavior.
if i'm debugging a patch and the debugging features (i.e. print) can't tell me, if i'm handling a one element list or an atom, i don't see a reason, why they should be handled differently ... of course, it's no problem to keep the behaviour as it is ... it would just avoid unnecessary bugs and make handling easier and more reliable ...
cheers ... tim
On Tue, 19 Jul 2005, Miller Puckette wrote:
Hi devs...
I'm thinking about finally writing a "list" object for Pd to do jobs like "append", "any", etc. I've held off so far because I've felt unsure about the best design... and once I stick it in the "base" Pd it will be hard to change.
But it will be well worth the effort. All in all, it seems like a useful bunch of objects. I am very happy to see this issue coming up now.
To avoid cluttering up the namespace I want to use just the one name, "list", and use the first argument to differentiate between functions (an idea inspired by Krzysztof's xeq object). Here are the functions I imagine:
Since there are currently no core Pd objects that use the [obj action] syntax, I think we should try to avoid introducing it for a number of reasons. For example, I think these functions would work fine as individual objects, and in many cases they would be generally useful with things besides lists, like undefined sets for example.
As for the namespace question, that would be solved with some method of dealing with the namespace rather than more obscure names. I think that Pd would work very well with a Java-style namespace, using the Geiger namespace as a starting place. The core objects would be included in the namespace by default. Any object could be called in the geiger namespace style at anytime [maxlib/average] for example. Then collections of externals could be imported, so if a patch had [import maxlib] then [average] would be the same as [maxlib/average]. The main missing piece to implementing this is an [import] or some similar mechanism. Guenter already has a global version of this working (I think its called [declare]?). Then there would be an order of precedence for local names. Java's is: 0) local names 1) imported names 2) core names, with local names being able to override imported names and core names, and so on.
list append - append a list to another
A general purpose [append] would be very handy too.
list prepend - prepend a list to another
Krzysztof's [prepend] works quite well for this, and works with anything.
list cat - build a list by accumulating elements
This could be done simply with [prepend] or [append] and a list storage object.
list serialize - spit out elements of a list one by one list first - output first n elements list last - output last n elements list length - output number of items in list list reverse - permute elements of a list back to front
It would be nice if these functions worked with all sets, not just lists. That's the way [zl] works. It could work so that if it receives lists, it will output lists. If it receives undefined sets (i.e. sets that begin with a symbol) then it would output sets without "list" prepended.
list pack - synonym for 'pack' list unpack - synonym for 'unpack'
What would these do differently that the originals?
list selector - change selector of a list
Sounds handy, but also, it would be handy for undefined sets as well.
list <no args> - "prepend" the selector list to non-list messagesThe "append" option would also play the role of "any" (just bang the left inlet after putting any list in the right).
How about [list] being a storage object too, like [symbol], [int], [float], [pointer]? [list( = [bang( seems to cause more trouble than not.
.hc
All of these would expect the "list" selector at the head of messages, with the exception of plain "list"; all of them would output "list" messages except "list selector". These would work as follows:
--------------------------- list ---------------------------------- in (real message) in (as printed) out (real message) out (as printed) list bang (same) list 1 1 (same) list foo list foo (same) foo foo list foo list foo
--------------------------- list selector bar ------------------------- in (real message) in (as printed) out (real message) out (as printed) list bang bar list 1 1 bar 1 list foo list foo bar foo foo foo (error)
There's one inconvenience with plain "list" since you can't differentiate "list foo" from "foo" using its output; you'd have to use "route list symbol" first and then do whatever you wanted to do differently ("list list foo" for example). It seemed better to leave that to the imagination of programmers, since there seem to be disagreements about it...
zen \ \ \[D[D[D[D
On Wed, 20 Jul 2005, Hans-Christoph Steiner wrote:
Since there are currently no core Pd objects that use the [obj action] syntax, I think we should try to avoid introducing it for a number of reasons. For example, I think these functions would work fine as individual objects, and in many cases they would be generally useful with things besides lists, like undefined sets for example.
What's an undefined set?
What does it have to do with Pd internals?
How would it be represented in memory?
How is polymorphism a key feature of Pd ? e.g. why does [pipe] only allows floats, and not other kinds of atoms ?
What would you like as other changes to other Pd internals so that become consistent with that vision of polymorphism ?
list cat - build a list by accumulating elementsThis could be done simply with [prepend] or [append] and a list storage object.
Except that [list cat] has the opportunity to do n appends in O(n) time instead of O(n^2) time. In the first decade of Tcl there was only a O(n^2) means, namely "set a [concat $a [list $b]]", but then proc lappend was added because the situation really sucked.
It would be nice if these functions worked with all sets, not just lists. That's the way [zl] works. It could work so that if it receives lists, it will output lists. If it receives undefined sets (i.e. sets that begin with a symbol) then it would output sets without "list" prepended.
Oof, so that's what you call "undefined sets" ? why have you chosen that name?
,-o--------o--------o--------o-. ,---. irc.freenode.net #dataflow | | The Diagram is the Program tm| | ,-o-------------o--------------o-. `-o------------o-------------o-' | | Mathieu Bouchard (Montréal QC) | | téléphone:+1.514.383.3801`---' `-o-- http://artengine.ca/matju -'
On Wed, Jul 20, 2005 at 12:07:22PM -0700, Miller Puckette wrote:
How is polymorphism a key feature of Pd ? e.g. why does [pipe] only allows floats, and not other kinds of atoms ?
Oops! I must have been in a hurry that day. On the dolist it goes.
imo the limitations are of the available atom types, not [pipe] (which is probably my favorite object and amazingly its one of tte internals)
example: because length varies, my sequencer joins lists via an odd delimiter to push through pipe, since afaik there is no other auto-sorting nonlinear message scheduler in PD.. sequence data is actually stored in a list of lists (with yet another unique-or-it-breaks delimiter), like:
{234 {x 114.0} {vol 0.89} {filename /samples/blahblah.wav} {stretch 0.7} {loop 0.44 0.96}} == (in pd-compatible mode): 234^x|114.0^vol|0.89^filename|/samples/blahblah.wav^stretch|0.7^loop|0.44|0.96
its absolutely imperative that the entire message is pushed around as one chunk, since the namespace of the storage object is often already changed by the time it would want to read it back (say if just a integer array key was sent thru the pipe, without the s2l nonsense) afaik the only other solution to play multiple parts, would involve dynamically creating lots of qlists or structs...ok, so pipe supports fixed-length lists so i could pass the namespace as a symbol and yadda, but is pd not a messaging system, it should allow robust message passing...
after its fed through pipe and peeled apart off it goes, and everythign works great - symbol-creation overhead, its requisite memleaks, and the requirement of toxy (since the built in GUI sucks) zexy (to get around the flat list limitation) cyclone (for prepend/append) and PDContainer (for storage) aside. and since DSP and arrays are broken on amd64, all the messages are sent off to sooperlooper and OM anyways...of course i'd love to use PD for more than just a host for 3rd party objects...and have sharable patches...i think the biggest move towards this would be embeddable lists, strings, acceptable internal storage objects..and beyond that the ability to create user-supplied views & controllers for the 'data' modeled via patching together struct definitions or what have you.
speaking of which, PDContainer is the most suitable thing to storing data, since it accepts list as array keys, so at least the above message can stored, albeit as a bunch of smaller items..
almost cheers, C
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
It would be nice if these functions worked with all sets, not just lists. That's the way [zl] works. It could work so that if it receives lists, it will output lists. If it receives undefined sets (i.e. sets that begin with a symbol) then it would output sets without "list" prepended.
This is a good point actually, or at least a point to consider. For example when I work with OSC messages, these are what you call undefined sets, that is, they are lists without a "list" selector. Typically they look like: "/o/s/c 1 2 3 something 4".
I normally do the same operations on these "list"-less lists as I would do on real "list"-lists. It would be nice to be able to use the new "list" object for this kind of messages as well without having to first send them through an object that adds the "list" selector, which would need to be stripped off again later anyways.
Ciao
Hans-Christoph Steiner wrote:
On Tue, 19 Jul 2005, Miller Puckette wrote:
To avoid cluttering up the namespace I want to use just the one name, "list", and use the first argument to differentiate between functions (an idea inspired by Krzysztof's xeq object). Here are the functions I imagine:
Since there are currently no core Pd objects that use the [obj action] syntax, I think we should try to avoid introducing it for a number of reasons. For example, I think these functions would work fine as
i totally agree with hc, that suddenly introducing the [obj action] syntax might be very confusing. i'd rather not have it and prefer some other way (like obj_action).
additionally i would prefer the core pd objects to _not_ have their action settable via messages (like changing [obj action1] to [obj action2]): this would make everything far more unreadable (although you could probably do things in less "lines" of code)
just my 4¢
mfg.ads.r IOhannes
On Tue, 19 Jul 2005, Miller Puckette wrote:
I'm thinking about finally writing a "list" object for Pd to do jobs like "append", "any", etc. I've held off so far because I've felt unsure about the best design... and once I stick it in the "base" Pd it will be hard to change.
and use the first argument to differentiate between functions (an idea inspired by Krzysztof's xeq object).
this idea is also found in [zl] and in many objects found in GridFlow, e.g. [# +] vs [# *].
list serialize - spit out elements of a list one by one
In other languages, serialize already means to take any structure (e.g. nested lists) and make a string out of it, or write it directly to a stream.
In GridFlow this functionality is called [foreach].
In many other languages this is called either "foreach", "for", or "each" (see: Tcl, Perl, Python, Ruby, Bash, Java, Javascript, C#, ...)
,-o--------o--------o--------o-. ,---. irc.freenode.net #dataflow | | The Diagram is the Program tm| | ,-o-------------o--------------o-. `-o------------o-------------o-' | | Mathieu Bouchard (Montréal QC) | | téléphone:+1.514.383.3801`---' `-o-- http://artengine.ca/matju -'
hi miller ...
what happened to this:
list strip - send message with leading symbol as selector
i'm frequently using an abstraction doing this ...
tim
Hi Tim,
I renamed it "trim" after I kept confusing the words "split" and "strip"...
cheers Miller
On Tue, Aug 02, 2005 at 04:18:41PM +0200, Tim Blechmann wrote:
hi miller ...
what happened to this:
list strip - send message with leading symbol as selector
i'm frequently using an abstraction doing this ...
tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
latest mp3: kMW.mp3 http://mattin.org/mp3.html
latest cd: Goh Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
I renamed it "trim" after I kept confusing the words "split" and "strip"...
oh ... i misinterpreted the following description ... my poor english:
list strip - send message with leading symbol as selector
i read: send (cdr list) to the objects bound to the receive symbol (car list)
anyway, this would be a handy feature (maybe named |list send|)
cheers ... tim
-
carmen -
chris clepper -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Mathieu Bouchard -
Miller Puckette -
Tim Blechmann