Patches item #1405137, was opened at 2006-01-13 20:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1405137...
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: wishlist Status: Open Resolution: None Priority: 5 Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: multiple $arg-expansion
Initial Comment: currently $args can only be at the beginning of a A_DOLLARSYM.
this patch allows to have multiple $args within 1 A_DOLLARSYM. e.g. with "foo bar me" the symbol "$1-bla-$3/$2" will expand to "foo-bla-me/bar"
the patch only modifies binbuf_realizedollsym() in m_binbuf.c (and adds another non-exported helper function binbuf_expanddollsym())
the patch is straightforward, but probably i misunderstood the meaning of "tonew" and implemented it in a wrong way (so you should check that)
caveat: the A_DOLLARSYM still has to start with "$[0-9]". this is the way, pd determines whether a given symbol should be $-expanded or not. furthermore, the leading $ is usually stripped by pd. e.g. if you type [$1-bar-$2], the symbol "1-bar-$2" is stored as A_DOLLARSYM. this means that the beginning of the dollarsymbol always has to be expanded. furthermore, [bar-$2] will _never_ be expanded (since pd thinks it is an ordinary symbol).
i didn't dare to change this behaviour since SETDOLLARSYM() and binbuf_realizedollsym() are exposed in m_pd.h and probably used in externals which would then break. however, whenever this might change, binbuf_expanddollsym() is prepared (just need to "#if 1")
----------------------------------------------------------------------
You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1405137...
now that is most likely even cooler than the abstraction-classname-binding...
please do some testing...
mfg.asdr IOhannes
SourceForge.net wrote:
Initial Comment: currently $args can only be at the beginning of a A_DOLLARSYM.
this patch allows to have multiple $args within 1 A_DOLLARSYM. e.g. with "foo bar me" the symbol "$1-bla-$3/$2" will expand to "foo-bla-me/bar"
the patch only modifies binbuf_realizedollsym() in m_binbuf.c (and adds another non-exported helper function binbuf_expanddollsym())
the patch is straightforward, but probably i misunderstood the meaning of "tonew" and implemented it in a wrong way (so you should check that)
caveat: the A_DOLLARSYM still has to start with "$[0-9]". this is the way, pd determines whether a given symbol should be $-expanded or not. furthermore, the leading $ is usually stripped by pd. e.g. if you type [$1-bar-$2], the symbol "1-bar-$2" is stored as A_DOLLARSYM. this means that the beginning of the dollarsymbol always has to be expanded. furthermore, [bar-$2] will _never_ be expanded (since pd thinks it is an ordinary symbol).
i didn't dare to change this behaviour since SETDOLLARSYM() and binbuf_realizedollsym() are exposed in m_pd.h and probably used in externals which would then break. however, whenever this might change, binbuf_expanddollsym() is prepared (just need to "#if 1")
Am 13.01.2006 um 20:40 schrieb IOhannes m zmoelnig:
now that is most likely even cooler than the abstraction-classname-binding...
please do some testing...
Today, when doing a workshop with some pd newcomers i was once more embarassed about the tricks i needed to use $0 inside a message. Since $0 is special anyway, is there a real reason for it?
greetings, Thomas
Thomas Grill wrote:
Am 13.01.2006 um 20:40 schrieb IOhannes m zmoelnig:
now that is most likely even cooler than the abstraction-classname-binding...
please do some testing...
Today, when doing a workshop with some pd newcomers i was once more embarassed about the tricks i needed to use $0 inside a message. Since $0 is special anyway, is there a real reason for it?
do you mean, is there a reason for my patch, a reason for $0 or a reason for $0 being "different" in messages?
mfg.ad.r IOhannes
Am 14.01.2006 um 20:09 schrieb IOhannes m zmoelnig:
Thomas Grill wrote:
Am 13.01.2006 um 20:40 schrieb IOhannes m zmoelnig:
now that is most likely even cooler than the abstraction-classname-binding...
please do some testing...
Today, when doing a workshop with some pd newcomers i was once more embarassed about the tricks i needed to use $0 inside a message. Since $0 is special anyway, is there a real reason for it?
do you mean, is there a reason for my patch, a reason for $0 or a reason for $0 being "different" in messages?
the latter (your patch is great, although i'd like to have even more flexible $args-processing). Sorry for continuing in your thread.
best greetings, Thomas
Thomas Grill wrote:
do you mean, is there a reason for my patch, a reason for $0 or a reason for $0 being "different" in messages?
the latter (your patch is great, although i'd like to have even more
well i think this is very consistent: $args in messages refer _only_ to parameters of incoming messages, while $args in objects refer only to parameters of upstream objects. (and $0 is bound to the class instance)
however, i think that "$0" is a bad name. i would have liked it better if $0 was the selector (in messages) and the classname (in abstractions). probably "$$" would have been better for a uniq id (well, i know that this is a bashism (its the process-id in bash), but that is not necessarily bad)
flexible $args-processing).
this is on my todo-list. 1st thing todo (soon!) is to remove the restriction that dollsyms have to start with $ (while this restriction makes parsing trivial it is cumbersome at the best) 2nd thing todo (LATER!) is a mechanism for stacked $args, like ${$1-2}
Sorry for continuing in your thread.
better in this thread than never...
mfmgasdr IOhannes
IOhannes m zmoelnig wrote:
however, i think that "$0" is a bad name. i would have liked it better if $0 was the selector (in messages) and the classname (in abstractions). probably "$$" would have been better for a uniq id (well, i know that this is a bashism (its the process-id in bash), but that is not necessarily bad)
forgot to add that these are just thoughts that will never (probability=99.9%) be implemented in pd, since the names have been there for quite some times, and this change would break an awful lot of patches. it's a pity.
but i would still like to have the possibilities to get the selector of a message (as a symbol) and to get the classname of an abstraction.
of course we could just use "$$" for *that* (but it would be no bashism any more)
mf.asdr. IOhannes
Am 15.01.2006 um 10:22 schrieb IOhannes m zmoelnig:
IOhannes m zmoelnig wrote:
however, i think that "$0" is a bad name. i would have liked it better if $0 was the selector (in messages) and the classname (in abstractions). probably "$$" would have been better for a uniq id (well, i know that this is a bashism (its the process-id in bash), but that is not necessarily bad)
forgot to add that these are just thoughts that will never (probability=99.9%) be implemented in pd, since the names have been there for quite some times, and this change would break an awful lot of patches. it's a pity.
but i would still like to have the possibilities to get the selector of a message (as a symbol) and to get the classname of an abstraction.
of course we could just use "$$" for *that* (but it would be no bashism any more)
I think nothing would be broken if $0 in messages means the canvas ID. So far $0 in messages hasn't been used, or has it? To my mind that would be a fairly clear extension.
best greetings, Thomas
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
I think nothing would be broken if $0 in messages means the canvas ID. So far $0 in messages hasn't been used, or has it? To my mind that would be a fairly clear extension.
Nothing would break, of course, but getting the canvas ID into a message already is easily possible with $-replacements as in [f $0]--[$1(
And just adding $0 to messages would still not solve accessing abstraction arguments in messages.
What I would be interested in more is being able to use $0 and other $x *literally*, for example to be able to dynamically create objects which use $0 as argument like:
[obj 100 100 f $0( | [s pd-subpatch]
to create a [f $0] in [pd subpatch] and not a [f 1001]. This would of course conflict with replacing $0 by its current value in messages as well.
So my vote still would be some #x.
Ciao
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
What I would be interested in more is being able to use $0 and other $x *literally*, for example to be able to dynamically create objects which use $0 as argument like:
[obj 100 100 f $0( | [s pd-subpatch]
to create a [f $0] in [pd subpatch] and not a [f 1001].
Ah, scrap that: Using "$0" this way in messages is not good, as it would be too different from how "$1,..." are used. Of course it's not possible nor useful to create a [f $1] by using "obj 100 100 f $1" This stuff needs proper escaping.
So what about this, which tries to keep a bit of backwards compatibility:
* Object arguments change from $x to #x with x in 0(sic!),1,...,n
* $x in objects are kept for a while for compatibility
* Messages will get additional placeholders for canvas-properties, that start with a #hash and directly correspond to the object arguments from above. They will keep $-placeholders starting from 1(sic!) as in the past.
* There will be no $0 anymore in the long run.
Ciao
On Jan 15, 2006, at 9:28 AM, Frank Barknecht wrote:
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
What I would be interested in more is being able to use $0 and other $x *literally*, for example to be able to dynamically create objects which use $0 as argument like:
[obj 100 100 f $0( | [s pd-subpatch]
to create a [f $0] in [pd subpatch] and not a [f 1001].
Ah, scrap that: Using "$0" this way in messages is not good, as it would be too different from how "$1,..." are used. Of course it's not possible nor useful to create a [f $1] by using "obj 100 100 f $1" This stuff needs proper escaping.
So what about this, which tries to keep a bit of backwards compatibility:
Object arguments change from $x to #x with x in 0(sic!),1,...,n
$x in objects are kept for a while for compatibility
Messages will get additional placeholders for canvas-properties, that start with a #hash and directly correspond to the object arguments from above. They will keep $-placeholders starting from 1(sic!) as in the past.
There will be no $0 anymore in the long run.
I personally don't like expanding Pd's syntax with the #, I think one of Pd's strength is minimal syntax.
$ args are expandable arguments, whether in objects or in messages. You can break down everything in Pd to those two basic categories: objects and messages. When you want an expandable argument, then use a $ arg. Since objects and messages are different things, it makes sense that $ args don't expand to the same thing within objects and messages. That seems nicely logical and compact to me. I think if people have trouble with that, they are likely not understanding the distinction between messages and objects rather than the $ args themselves.
But using the instance ID in messages would be a handy shortcut, so $$ could be the instance ID for both objects and messages without breaking anything AFAIK. It would make $ arg parsing perhaps more tricky, but I that code could be lifted from BSD's sh, for example, since its tried-n-true and released under a BSD license.
.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 Sun, 15 Jan 2006, Hans-Christoph Steiner wrote:
$ args are expandable arguments, whether in objects or in messages. You can break down everything in Pd to those two basic categories: objects and messages. When you want an expandable argument, then use a $ arg. Since objects and messages are different things, it makes sense that $ args don't expand to the same thing within objects and messages.
messageboxes are not messages. a messagebox is a t_object. a message is a selector and then zero or more t_atom arguments.
That seems nicely logical and compact to me. I think if people have trouble with that, they are likely not understanding the distinction between messages and objects rather than the $ args themselves.
Objects are constructed using a selector and a list of zero or more t_atom arguments. The text written in an objectbox is a message. The classname is a selector for a method in object ";objectmaker". A constructor is a message.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Jan 15, 2006, at 9:28 AM, Frank Barknecht wrote:
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
What I would be interested in more is being able to use $0 and other $x *literally*, for example to be able to dynamically create objects which use $0 as argument like:
[obj 100 100 f $0( | [s pd-subpatch]
to create a [f $0] in [pd subpatch] and not a [f 1001].
Ah, scrap that: Using "$0" this way in messages is not good, as it would be too different from how "$1,..." are used. Of course it's not possible nor useful to create a [f $1] by using "obj 100 100 f $1" This stuff needs proper escaping.
I forgot to add, I agree here, proper escaping is the way to solve this. Then it would be consistent with all dollar args.
.hc
So what about this, which tries to keep a bit of backwards compatibility:
Object arguments change from $x to #x with x in 0(sic!),1,...,n
$x in objects are kept for a while for compatibility
Messages will get additional placeholders for canvas-properties, that start with a #hash and directly correspond to the object arguments from above. They will keep $-placeholders starting from 1(sic!) as in the past.
There will be no $0 anymore in the long run.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
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
Frank Barknecht wrote:
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
So what about this, which tries to keep a bit of backwards compatibility:
Object arguments change from $x to #x with x in 0(sic!),1,...,n
$x in objects are kept for a while for compatibility
Messages will get additional placeholders for canvas-properties, that start with a #hash and directly correspond to the object arguments from above. They will keep $-placeholders starting from 1(sic!) as in the past.
There will be no $0 anymore in the long run.
so what would #0 be? a uniq id again?? this seems so wrong to me.
personally i have to admit, that i don't have problems with $ in objects and $ in messages. for me it really emphasizes the difference between a message (an event; only exists _now_; no knowledge of its environment) and an object (a process (a storage); persistant; ...)
i like the idea with the [message] object, as it seems to be in line with this separation.
mfgm.bzrt.-rz IOhannes
On Sun, 15 Jan 2006 18:24:06 +0100 IOhannes m zmoelnig zmoelnig@iem.at wrote:
personally i have to admit, that i don't have problems with $ in objects and $ in messages. for me it really emphasizes the difference between a message (an event; only exists _now_; no knowledge of its environment) and an object (a process (a storage); persistant; ...)
well, i distinguishing # and $ for messages / objects would increase the expressive power of the language pd, since two different language features are expressed differently ...
reusing keywords for different features makes a language lot easier to read / understand ... just compare with the different semantic of the keyword 'static' in c++ ...
just my 1.5707963¢ ... tim
On Jan 15, 2006, at 1:37 PM, Tim Blechmann wrote:
On Sun, 15 Jan 2006 18:24:06 +0100 IOhannes m zmoelnig zmoelnig@iem.at wrote:
personally i have to admit, that i don't have problems with $ in objects and $ in messages. for me it really emphasizes the difference between a message (an event; only exists _now_; no knowledge of its environment) and an object (a process (a storage); persistant; ...)
well, i distinguishing # and $ for messages / objects would increase the expressive power of the language pd, since two different language features are expressed differently ...
I don't see how adding # variables would give you anything but a shortcut. I don't think it would give you anything that you can't do currently with Pd. Do you have any examples?
reusing keywords for different features makes a language lot easier to read / understand ... just compare with the different semantic of the keyword 'static' in c++ ...
The C/C++ static keyword is bad yes, but Pd's $ args are much simpler. $ args are variables that are replaced on instantiation. Messages are instantiated at a different time than objects, hence the confusion. But the definition of Pd's $ args is quite simple.
.hc
just my 1.5707963¢ ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
Which is more musical, a truck passing by a factory or a truck passing by a music school? John Cage _______________________________________________ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
"Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies." - Amy Smith
On Sun, 15 Jan 2006, Hans-Christoph Steiner wrote:
I don't see how adding # variables would give you anything but a shortcut. I don't think it would give you anything that you can't do currently with Pd. Do you have any examples?
[metro] is already a shortcut for [delay]-[t a a]-[spigot] triangle... why does [metro] exist? because it's a nice shortcut.
however i don't advocate using the "#" character for that, for obvious reasons... though i don't know which one else would be picked instead.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Jan 16, 2006, at 3:34 AM, Mathieu Bouchard wrote:
On Sun, 15 Jan 2006, Hans-Christoph Steiner wrote:
I don't see how adding # variables would give you anything but a shortcut. I don't think it would give you anything that you can't do currently with Pd. Do you have any examples?
[metro] is already a shortcut for [delay]-[t a a]-[spigot] triangle... why does [metro] exist? because it's a nice shortcut.
however i don't advocate using the "#" character for that, for obvious reasons... though i don't know which one else would be picked instead.
If you want to call writing objects a shortcut, that's fine. But that's the basis of programming in Pd. Specifically, I mean that the # args are a shortcut to avoid patching something in Pd.
.hc
________________________________________________________________________ ____
There is no way to peace, peace is the way. -A.J. Muste
On Mon, 16 Jan 2006, Hans-Christoph Steiner wrote:
If you want to call writing objects a shortcut, that's fine. But that's the basis of programming in Pd. Specifically, I mean that the # args are a shortcut to avoid patching something in Pd.
Hmm, abstractions are also a shortcut to avoid patching something in Pd...
More generally, nowadays, most of the effort of writing code is about avoiding to write more code.
I think the debate is more about which shortcuts pay off and which don't.
For example, most shortcuts in Perl only pay off if you write text-processing one-liners like people did when Perl was only seen as a replacement for the AWK language. Nowadays, Perl5 is used as an extremely general-purpose language, and for most of the typical situations of use of Perl5, those shortcuts are useless are may be seen as warts, especially as some sorely needed general-purpose shortcuts never ever came to Perl5 in all of the last decade.
Contrast this with Ruby. Most shortcuts in Ruby pay off no matter the kind of programming you do. For me that was an important reason to switch from Perl5 to Ruby.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
personally i have to admit, that i don't have problems with $ in objects and $ in messages.
Note that my suggestion would allow *both* $x and #x in messages next to each other! #x would expand to an object's #x which would be, what $x currently is in an object. And $x in a message will stay as it is.
Example: a message [; #1-x $1( would send the first element of an incoming message list ($1) to a receiver, that is taken from the surrounding abstraction's first argument (#1-x). This may be easier to understand than the current way to do this:
[pack 0 $1-x] | [; $2 $1(
(I know, I'm a bit cheating by not using [s $1-x] here)
Note that I'm not convinced myself if all this is worth the effort, it is just food for thought. I'm also not convinced that we need $0 in messages, though.
Ciao
On Jan 15, 2006, at 2:53 PM, Frank Barknecht wrote:
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
personally i have to admit, that i don't have problems with $ in objects and $ in messages.
Note that my suggestion would allow *both* $x and #x in messages next to each other! #x would expand to an object's #x which would be, what $x currently is in an object. And $x in a message will stay as it is.
Example: a message [; #1-x $1( would send the first element of an incoming message list ($1) to a receiver, that is taken from the surrounding abstraction's first argument (#1-x). This may be easier to understand than the current way to do this:
[pack 0 $1-x] | [; $2 $1(
(I know, I'm a bit cheating by not using [s $1-x] here)
Note that I'm not convinced myself if all this is worth the effort, it is just food for thought. I'm also not convinced that we need $0 in messages, though.
If we are talking about the current $ arg situation being confusing, then I don't think that [; #1-x $1( would help that. The only advantage I can see to the addition of # args is shortcuts. But that would be at the expense of syntactic and logical simplicity, and my guess is that it would make code harder to read rather than easier.
.hc
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
There is no way to peace, peace is the way. -A.J. Muste
Hey all,
The only advantage I can see to the addition of # args is shortcuts.
that's one advantage and it's an important one. When building more complex messages the [unpack], [f $x], [pack], [msg x $1 y $2( thing is a real pain, both for performance and for the eye.
But that would be at the expense of syntactic and logical simplicity, and my guess is that it would make code harder to read rather than easier.
i can't follow that argument. I just returned from a beginner's workshop and the fact that $x means different things in the same patch was obviously confusing for the people. It's much easier to read and understand that $x are always message parameters and #x are always abstraction arguments.
greetings, Thomas
On Jan 15, 2006, at 6:49 PM, Thomas Grill wrote:
Hey all,
The only advantage I can see to the addition of # args is shortcuts.
that's one advantage and it's an important one. When building more complex messages the [unpack], [f $x], [pack], [msg x $1 y $2( thing is a real pain, both for performance and for the eye.
Programming with Pd is done with connecting objects and message boxes, so I think that we should stay true to this instead of making shortcuts which are more suited to a text language. I have done a lot of complex message handling in Pd I haven't found this to be a major hinderance. What is a major hinderance is the list vs. undefined set quandary. Much if not most of this problem was caused by the shortcut of allowing sets starting with a float to be lists. So shortcuts can do real harm.
But that would be at the expense of syntactic and logical simplicity, and my guess is that it would make code harder to read rather than easier.
i can't follow that argument. I just returned from a beginner's workshop and the fact that $x means different things in the same patch was obviously confusing for the people. It's much easier to read and understand that $x are always message parameters and #x are always abstraction arguments.
I suppose the visual nature of Pd makes seeing $1 in a quick scan confusing whether its in an object box or a message box. But because beginners find something confusing is not reason enough to change it in my book. If people have real problems learning it, then its a problem. Many aspects of programming are confusing to beginners, but they pay off in the long run. I found the messaging in object oriented programming quite confusing when I started, functions seem more straightforward.
Having # and $ could cause new confusions for beginners and others, like forgetting when to use # and when to use $. I think once people understand Pd's messaging, then it becomes much easier to read $ args.
.hc
________________________________________________________________________ ____
"The arc of history bends towards justice." - Dr. Martin Luther King, Jr.
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Much if not most of this problem was caused by the shortcut of allowing sets starting with a float to be lists. So shortcuts can do real harm.
I don't agree here (anymore), as [list trim] and [list] fix all of this confusion. If you want to make sure, you get a list-list, use [list] beforehand, if you want to make sure to get a "set", insert a [list trim]. In many other cases Pd will do TheRightThing itself.
Having # and $ could cause new confusions for beginners and others, like forgetting when to use # and when to use $.
That's a valid and important point. (I was just using # because it's used in Max.)
Ciao
On Jan 16, 2006, at 5:42 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Much if not most of this problem was caused by the shortcut of allowing sets starting with a float to be lists. So shortcuts can do real harm.
I don't agree here (anymore), as [list trim] and [list] fix all of this confusion. If you want to make sure, you get a list-list, use [list] beforehand, if you want to make sure to get a "set", insert a [list trim]. In many other cases Pd will do TheRightThing itself.
A [list] object is a step in the right direction, but it doesn't address the list issues with [route]. They are documented in all_about_lists_vs_anythings.pd, in the subpatch "pd has some odd cases of list handling". I attached a copy too.
.hc
Having # and $ could cause new confusions for beginners and others, like forgetting when to use # and when to use $.
That's a valid and important point. (I was just using # because it's used in Max.)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
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.
On Mon, 16 Jan 2006, Hans-Christoph Steiner wrote:
What is a major hinderance is the list vs. undefined set quandary.
One major hinderance is your insistence on calling them undefined sets. The fact is that they're neither undefined nor sets. In PureData those things are called messages. Messages have selectors. Selectors are used to select methods.
Suppose that the Pd of your dreams comes to existence, and that may mean without any so-called "undefined sets". Every message would be a "list". Then how would you send a message like "set $1" or "color $1 $2" to an object? somehow the list method (which is then the only method in each class) would have to deal with all messages. Then a neat idea to break down the code in more manageable bits would be to select one of several C functions depending on the first element of the received list. This first argument could be called a "selector". But now, what about a list-processing object that really needs to be able to receive a list in the same inlet as you would use to do "set" and "color" and such? To disambiguate this, let's prefix the lists intended for list-processing with a special selector that we might call "list".
Thus messages would be called lists and former lists would be called something else like "really lists" but there might be better names. And then again there would be things that are lists but not "really lists" and there appear again the "undefined sets" that aren't undefined nor sets.
Or have I missed any important detail?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Mon, 16 Jan 2006, Hans-Christoph Steiner wrote:
What is a major hinderance is the list vs. undefined set quandary.
One major hinderance is your insistence on calling them undefined sets.
I like to call lists with a list selector "list-lists".
Suppose that the Pd of your dreams comes to existence, and that may mean without any so-called "undefined sets". Every message would be a "list".
Actually I believe, the only real practical problem that lists/messages and list-lists had in the past was, that it was a bit hard to make a list-list out of a general list/message. (Stripping the list-selector and converting back to a message-list is possible, too, with [list trim], but was possible with [route list] as well.) [list $1 $2...( could be ambigious and it didn't work with arbitrary length message-lists.
But with pd-0.39 this issue is solved thanks to the [list] object, that automatically converts everything to a full-blown list-list, if one is needed. This is another reason to upgrade to 0.39 soon, if someone hasn't done so yet.
Ciao
But with pd-0.39 this issue is solved thanks to the [list] object,
justa bout every patch i've made (from 0.36 to 0.39) involves :
- an inordinate amount of objects just adding and removing selectors eg turning lists into non-lists and vice-versa
- crazy dances to get into get instance variables into messages alongside and mixed with local variables (i was appalled that the documentation suggests using a bunch of [symbol $0] [float $0] and unwieldy chained series of makefilenames (since theres only one substitution per object, and even though youre not making filenames) when later discovering this could all be reduced to a single [sprintf] but this object was never mentioned in the docs)
- similar crazy dances to things like asd-$0 instead of $0-asd, the equivalent of say indices [1..3] of a list but sometimes its [2..5] and simulating nested lists
- simulating key / value stuff and naming list elements (via fake nested lists) so that you dont have to worry so much about ordering stuff, esp when reusing abstractions in difft places, and to be able to think in terms of named variables instead of rememerbing wtf $3 was
i love Mathieu's idea of a documentation for the similarities that all or most classes share - learning all these peculiarities up front would have removed a big barrier of entry in terms of getting up and running fast..
imo a few additions to the message syntax would solve most of these problems and make it much easier to see what a patch does by glancing at it
who does that best? C's sprintf? "or #{@ruby} " or maybe "ecma"+script?
On Jan 21, 2006, at 6:27 PM, cdr wrote:
But with pd-0.39 this issue is solved thanks to the [list] object,
justa bout every patch i've made (from 0.36 to 0.39) involves :
- an inordinate amount of objects just adding and removing selectors
eg turning lists into non-lists and vice-versa
Indeed. When I work with variable data sets, I generally try to stay out of the realm of lists entirely, and use "undefined sets" and [prepend].
- crazy dances to get into get instance variables into messages
alongside and mixed with local variables (i was appalled that the documentation suggests using a bunch of [symbol $0] [float $0] and unwieldy chained series of makefilenames (since theres only one substitution per object, and even though youre not making filenames) when later discovering this could all be reduced to a single [sprintf] but this object was never mentioned in the docs)
That's because [sprintf] is a cyclone object, so its an external.
- similar crazy dances to things like asd-$0 instead of $0-asd, the
equivalent of say indices [1..3] of a list but sometimes its [2..5] and simulating nested lists
This is fixed in a patch from IOhannes.
.hc
- simulating key / value stuff and naming list elements (via fake
nested lists) so that you dont have to worry so much about ordering stuff, esp when reusing abstractions in difft places, and to be able to think in terms of named variables instead of rememerbing wtf $3 was
i love Mathieu's idea of a documentation for the similarities that all or most classes share - learning all these peculiarities up front would have removed a big barrier of entry in terms of getting up and running fast..
imo a few additions to the message syntax would solve most of these problems and make it much easier to see what a patch does by glancing at it
who does that best? C's sprintf? "or #{@ruby} " or maybe "ecma"+script?
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
"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
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Indeed. When I work with variable data sets, I generally try to stay out of the realm of lists entirely, and use "undefined sets" and [prepend].
Since pd-0.39 I actually patch exactly the other way around: Everything gets converted to a list using [list] in the beginning, then I operate around, and in the end, there is a [list trim] if I want to get a selector-less list back, otherwise I use the resulting list-list and rely on Pd's automatic conversions of one-element lists to symbols or floats, because I practically always want symbols and floats if I get a one-element list-list.
I don't use [prepend] anymore.
Ciao
On Jan 26, 2006, at 1:43 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Indeed. When I work with variable data sets, I generally try to stay out of the realm of lists entirely, and use "undefined sets" and [prepend].
Since pd-0.39 I actually patch exactly the other way around: Everything gets converted to a list using [list] in the beginning, then I operate around, and in the end, there is a [list trim] if I want to get a selector-less list back, otherwise I use the resulting list-list and rely on Pd's automatic conversions of one-element lists to symbols or floats, because I practically always want symbols and floats if I get a one-element list-list.
I don't use [prepend] anymore.
Since we are talking about definitions, I just want to point out that AFAIK, there is no such thing as a "selector-less list".
- There are messages that have the type selector [list this is my list(, [symbol mysymbol(, and [float 4(
- there are messages that imply the selector [1 2 3( and [5(,
- there are messages that have a selector that is not a type: [this message is an undefined type(. The selector is "my" in that case. or [undefined(, the selector is "undefined".
Just the fact that we can't even agree on a definition of the behavior is a good indicator of its whackiness...
.hc
________________________________________________________________________ ____
News is what people want to keep hidden and everything else is publicity.
- Bill Moyers
Hans-Christoph Steiner wrote:
there are messages that imply the selector [1 2 3( and [5(,
there are messages that have a selector that is not a type: [this
message is an undefined type(. The selector is "my" in that case. or [undefined(, the selector is "undefined".
Just the fact that we can't even agree on a definition of the behavior is a good indicator of its whackiness...
i think that we are basically all agree on what we mean... however, matju tries to be exact when it comes to definitions. calling messages with an selector that is not defined as a standard a "undefined set" is not correct in a mathematical sense (were mathieu seems to spend some time; i believe him) i think that we should get terms right if we want to define a consistent programming language. i also think that mathieu's objections are funny and should be taken with a grain of salt (i enjoy his objections, so i try to not be offensive)
mfg.ad IOhannes
On Fri, 3 Feb 2006, IOhannes m zmoelnig wrote:
i think that we are basically all agree on what we mean... however, matju tries to be exact when it comes to definitions. calling messages with an selector that is not defined as a standard a "undefined set" is not correct in a mathematical sense
It's not just making it mathematical. Think of how "undefined" relates to "set". My guess, after a while of reading Hans on "undefined sets", is that it's "undefined" in the sense of "it has a selector that is not one of the five magic selectors of pd", and that doesn't even mean those that are not defined internally in pd, because that would exclude "set", "reset", and a few dozen others. That's a quite peculiar use of the word "undefined", and not any of my first 242 guesses of what "undefined" might mean in Pd.
i think that we should get terms right if we want to define a consistent programming language.
and a consistent documentation...
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Since we are talking about definitions, I just want to point out that AFAIK, there is no such thing as a "selector-less list".
True, "selector-less list" is a bad name for what I meant, too. What I meant with it was, just to clarify, lists of more than two elements (including selector) whose first element (the selecotr) is another word than "list".
Maybe analogous to my use of "list-list" I should call them "non-list-list".
(I agree with Matju, that the name "set" should be avoided, as sets are something very different from lists not only in the mathematical sense, but also in the specification of data structures in programming languages like C++. (cf. <set> vs. <list> in the STL))
Ciao
On Jan 21, 2006, at 5:29 PM, Frank Barknecht wrote:
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Mon, 16 Jan 2006, Hans-Christoph Steiner wrote:
What is a major hinderance is the list vs. undefined set quandary.
One major hinderance is your insistence on calling them undefined sets.
I like to call lists with a list selector "list-lists".
Suppose that the Pd of your dreams comes to existence, and that may mean without any so-called "undefined sets". Every message would be a "list".
Actually I believe, the only real practical problem that lists/messages and list-lists had in the past was, that it was a bit hard to make a list-list out of a general list/message. (Stripping the list-selector and converting back to a message-list is possible, too, with [list trim], but was possible with [route list] as well.) [list $1 $2...( could be ambigious and it didn't work with arbitrary length message-lists.
But with pd-0.39 this issue is solved thanks to the [list] object, that automatically converts everything to a full-blown list-list, if one is needed. This is another reason to upgrade to 0.39 soon, if someone hasn't done so yet.
Sadly, this doesn't fix the problems [route] and [print] have with lists. See [pd has some odd cases of list handling] in doc/pddp/all_about_lists_vs_anythings.pd
.hc
________________________________________________________________________ ____
There is no way to peace, peace is the way. -A.J. Muste
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
But with pd-0.39 this issue is solved thanks to the [list] object, that automatically converts everything to a full-blown list-list, if one is needed. This is another reason to upgrade to 0.39 soon, if someone hasn't done so yet.
Sadly, this doesn't fix the problems [route] and [print] have with lists. See [pd has some odd cases of list handling] in doc/pddp/all_about_lists_vs_anythings.pd
Maybe I'm just too used to the way lists and selectors work in Pd, but I don't see where the problem with [route] is (I agree, that [print] sucks.)
First: [prepend] is an external so it has its own rules and cannot be an argument against the way, Pd handles selectors and lists .The Pd object to use is [list prepend]. It always outputs list-lists.
That takes care of two examples in the pddp-patch.
"one 2 three" vs. "list one 2 three":
[route one] behaves correctly here. If one wants to get "2 three" as a result for the second message, then one should use [list trim] in front of route. Fixing the complaint in the pddp-patch actually would make [route one] imply a [route list] or [list trim] internally which is inconsistent and not always wanted so it's better to keep it explicit with [list trim].
"1 two 3" vs. "list 1 two 3"
If one can accept that numbers can never be selectors, then the automatic conversion of selector-less lists starting with a float to list-lists is not unusual. And once it is accepted, that "1 two 3" actually is *the same* as "list 1 two 3" in the same way, that "float 3.141" is the same as "3.141" I also don't see a real problem.
The only possible difficulty is to understand, that "one 2 three" is *not* the same as "list one 2 three" and that [route] thus will behave differently here.
The only case where I could follow the difficulties is the automatic conversion of "list x" to "symbol x" in [route]. This is consistent with converting "list 1" to "float 1" but of course is different from the auto-conversion of "1" to "float 1" because "x" is not the same as "symbol x" immediatly.
However: In my view "list x" being equivalent to "symbol x" has advantages in practice, because if after some operations you end up with a list-list containing only one symbol, you probably want a symbol actually. At least that is my experience.
Btw: While testing around some cases, I actually think I found a bug in [select] which is illustrated in attached patch.
Ciao
On Jan 26, 2006, at 1:36 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
But with pd-0.39 this issue is solved thanks to the [list] object, that automatically converts everything to a full-blown list-list, if one is needed. This is another reason to upgrade to 0.39 soon, if someone hasn't done so yet.
Sadly, this doesn't fix the problems [route] and [print] have with lists. See [pd has some odd cases of list handling] in doc/pddp/all_about_lists_vs_anythings.pd
Maybe I'm just too used to the way lists and selectors work in Pd, but I don't see where the problem with [route] is (I agree, that [print] sucks.)
First: [prepend] is an external so it has its own rules and cannot be an argument against the way, Pd handles selectors and lists .The Pd object to use is [list prepend]. It always outputs list-lists.
That takes care of two examples in the pddp-patch.
"one 2 three" vs. "list one 2 three":
[route one] behaves correctly here. If one wants to get "2 three" as a result for the second message, then one should use [list trim] in front of route. Fixing the complaint in the pddp-patch actually would make [route one] imply a [route list] or [list trim] internally which is inconsistent and not always wanted so it's better to keep it explicit with [list trim].
"1 two 3" vs. "list 1 two 3"
If one can accept that numbers can never be selectors, then the automatic conversion of selector-less lists starting with a float to list-lists is not unusual. And once it is accepted, that "1 two 3" actually is *the same* as "list 1 two 3" in the same way, that "float 3.141" is the same as "3.141" I also don't see a real problem.
The only possible difficulty is to understand, that "one 2 three" is *not* the same as "list one 2 three" and that [route] thus will behave differently here.
The only case where I could follow the difficulties is the automatic conversion of "list x" to "symbol x" in [route]. This is consistent with converting "list 1" to "float 1" but of course is different from the auto-conversion of "1" to "float 1" because "x" is not the same as "symbol x" immediatly.
However: In my view "list x" being equivalent to "symbol x" has advantages in practice, because if after some operations you end up with a list-list containing only one symbol, you probably want a symbol actually. At least that is my experience.
Btw: While testing around some cases, I actually think I found a bug in [select] which is illustrated in attached patch.
Now that this behavior is all mapped out, its not impossible to figure it out and understand. But I find that when I am working with processing messages, its far from intuitive. And it was not straightforward to learn.
My quick answer to the above is that I think that [route symbol] should always output a symbol and [route list] should always output a list just like how [route bang] always outputs a bang and [route float] always outputs a float. That seems consistent and logical to me. Then if I want to convert lists to bangs, symbols, floats, or undefined sets, I could do so afterwards, with [list] or whatever.
I'll have to explore the 0.39 [list] object a bit more to see how it changes my concerns with the list processing stuff.
.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 Jan 21, 2006, at 2:34 PM, Mathieu Bouchard wrote:
On Mon, 16 Jan 2006, Hans-Christoph Steiner wrote:
What is a major hinderance is the list vs. undefined set quandary.
One major hinderance is your insistence on calling them undefined sets. The fact is that they're neither undefined nor sets. In PureData those things are called messages. Messages have selectors. Selectors are used to select methods.
Suppose that the Pd of your dreams comes to existence, and that may mean without any so-called "undefined sets". Every message would be a "list". Then how would you send a message like "set $1" or "color $1 $2" to an object? somehow the list method (which is then the only method in each class) would have to deal with all messages. Then a neat idea to break down the code in more manageable bits would be to select one of several C functions depending on the first element of the received list. This first argument could be called a "selector". But now, what about a list-processing object that really needs to be able to receive a list in the same inlet as you would use to do "set" and "color" and such? To disambiguate this, let's prefix the lists intended for list-processing with a special selector that we might call "list".
Thus messages would be called lists and former lists would be called something else like "really lists" but there might be better names. And then again there would be things that are lists but not "really lists" and there appear again the "undefined sets" that aren't undefined nor sets.
Or have I missed any important detail?
"undefined sets" are sets of atoms that are not a symbol, float, pointer, or list. A message can be made up of a symbol, float, pointer, list, or a set of atoms that is none of those types. All of these are messages, all with selectors (albeit sometimes its an implied selector). "A set of atoms that is not a symbol, float, pointer, or list" is an "undefined set".
Check out [pd some odd cases of list handling] in doc/pddp/all_about_lists_vs_anythings.pd if you want to see specific examples of problems caused by this
It seems to me that the heart of the problem is the implied selectors, i.e. [1 2 3( == [list 1 2 3(. Also, there is inconsistent behavior with lists in a number of key objects, like [route] and [print].
.hc ________________________________________________________________________ ____
"I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits." - Martin Luther King, Jr.
On Thu, 26 Jan 2006, Hans-Christoph Steiner wrote:
On Jan 21, 2006, at 2:34 PM, Mathieu Bouchard wrote:
One major hinderance is your insistence on calling them undefined sets. The fact is that they're neither undefined nor sets. In PureData those things are called messages. Messages have selectors. Selectors are used to select methods.
[...]
Or have I missed any important detail?
"undefined sets" are sets of atoms that are not a symbol, float, pointer, or list. A message can be made up of a symbol, float, pointer, list, or a set of atoms that is none of those types. All of these are messages, all with selectors (albeit sometimes its an implied selector). "A set of atoms that is not a symbol, float, pointer, or list" is an "undefined set".
What you state is again what I already know. You don't explain what is so undefined about them. You don't explain why you call them sets without an adjective saying that they're totally ordered ($1,$2,$3,...), which is a big no-no in comp.sci. Anything called just "set" in comp.sci or standard math is assumed to not have an order assigned to it.
Just because miscellaneous messages aren't selected by your [route bang float symbol list] and labeling the last outlet with "UNDEFINED" doesn't make miscellaneous messages less defined, whatever "defined" means in this case.
Btw, in that help patch:
* you forgot to handle the pointer case, which forms a triad with the float and symbol cases.
* you don't need to doublequote the word "selector" everywhere. I think that it's a pretty standard word when talking about messages in an OOP context.
* when you say "with a cast" and "withOUT a cast" you don't say what a cast is.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Feb 3, 2006, at 4:56 AM, Mathieu Bouchard wrote:
On Thu, 26 Jan 2006, Hans-Christoph Steiner wrote:
On Jan 21, 2006, at 2:34 PM, Mathieu Bouchard wrote:
One major hinderance is your insistence on calling them undefined sets. The fact is that they're neither undefined nor sets. In PureData those things are called messages. Messages have selectors. Selectors are used to select methods.
[...]
Or have I missed any important detail?
"undefined sets" are sets of atoms that are not a symbol, float, pointer, or list. A message can be made up of a symbol, float, pointer, list, or a set of atoms that is none of those types. All of these are messages, all with selectors (albeit sometimes its an implied selector). "A set of atoms that is not a symbol, float, pointer, or list" is an "undefined set".
What you state is again what I already know. You don't explain what is so undefined about them. You don't explain why you call them sets without an adjective saying that they're totally ordered ($1,$2,$3,...), which is a big no-no in comp.sci. Anything called just "set" in comp.sci or standard math is assumed to not have an order assigned to it.
Just because miscellaneous messages aren't selected by your [route bang float symbol list] and labeling the last outlet with "UNDEFINED" doesn't make miscellaneous messages less defined, whatever "defined" means in this case.
If its not an "undefined set", then feel free to suggest alternatives. "undefined list" and "list list" just seems whacky to me. But I guess its as whacky as Pd's list handling.
Btw, in that help patch:
- you forgot to handle the pointer case, which forms a triad with the float and symbol cases.
Please add it.
- you don't need to doublequote the word "selector" everywhere. I
think that it's a pretty standard word when talking about messages in an OOP context.
The idea was to quote keywords related to Pd.
- when you say "with a cast" and "withOUT a cast" you don't say what a cast is.
I think there is a link to the all_about that talks about casting.
The all_abouts are not finished by any means. They are mostly a sketchpad at this point.
.hc
________________________________________________________________________ ____
"Computer science is no more related to the computer than astronomy is related to the telescope." -Edsger Dykstra
On Fri, 3 Feb 2006, Hans-Christoph Steiner wrote:
- you forgot to handle the pointer case, which forms a triad with the float and symbol cases.
Please add it.
BTW, if I change one of your helpfiles (or any .pd file in cvs), and your copy is changed locally, how do you resolve a conflict upon update?
And because .pd files are considered as text files with line-oriented diffs, and because merging almost always break a patcher if changes happen in both copies of the patcher, how do people work with big patches in a CVS ?
Shouldn't pd have its own diff/diff3/patch tool? How would it work?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Feb 5, 2006, at 3:37 AM, Mathieu Bouchard wrote:
On Fri, 3 Feb 2006, Hans-Christoph Steiner wrote:
- you forgot to handle the pointer case, which forms a triad with
the float and symbol cases.
Please add it.
BTW, if I change one of your helpfiles (or any .pd file in cvs), and your copy is changed locally, how do you resolve a conflict upon update?
And because .pd files are considered as text files with line-oriented diffs, and because merging almost always break a patcher if changes happen in both copies of the patcher, how do people work with big patches in a CVS ?
Yeah, you should turn off automatic merging on .pd files. I don't remember how to do this tho...
Shouldn't pd have its own diff/diff3/patch tool? How would it work?
That would be very nice, but quite difficult. I wrote an extremely simplified version of a pd-diff in /scripts/pd-diff. One thing, there should be a flag to change whether it shows position changes (i.e. #X 234 452) or not. Most of the time you don't want to see that.
.hc ________________________________________________________________________ ____
"The arc of history bends towards justice." - Dr. Martin Luther King, Jr.
On Mon, 16 Jan 2006, Hans-Christoph Steiner wrote:
Programming with Pd is done with connecting objects and message boxes, so I think that we should stay true to this instead of making shortcuts which are more suited to a text language.
How much is Pd supposed to be a non-text language? It's already much more textish than a bunch of existing dataflow tools (GStreamer, OmSynth, BuzzTracker, ...)
Much if not most of this problem was caused by the shortcut of allowing sets starting with a float to be lists. So shortcuts can do real harm.
I don't think that shortcuts cause as much harm as the failure to teach them. It seems that most every course in Pd avoid to teach the real thing because somehow the students aren't programmers and it's supposed that they don't need to learn Pd that deeply and anyway Pd's own documentation doesn't necessarily go that deep.
Having # and $ could cause new confusions for beginners and others, like forgetting when to use # and when to use $. I think once people understand Pd's messaging, then it becomes much easier to read $ args.
In the debate between #,$ args and $-only args, what matters most is not how easy it is to read a single arg; instead it is how easy it is to read (and/or write) an arrangement of those args in a practical situation where you have to get something done.
Many aspects of programming are confusing to beginners, but they pay off in the long run. I found the messaging in object oriented programming quite confusing when I started, functions seem more straightforward.
I've read many bad tutorials on OOP, and in the light of this I think it's no wonder that people are confused about it. Lots of pop ontology, pop epistemology, and broken hierarchies of animal species and geometric shapes. The worst OOP tutorials are of course the ones that assert that JAVA is pure OOP and that (even worse) pure OOP _is_ JAVA.
PS: in standard math, sets are assumed to be unordered unless specified otherwise. Sometimes sets get extended with some comparison relation on their elements (making them "ordered sets") but then they get given special names:
1. posets aka partially-ordered sets 2. tosets aka totally-ordered sets 3. wosets aka well-ordered sets aka sequences
both Pd messages and Pd lists can be considered finite sequences.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Thomas Grill wrote:
do you mean, is there a reason for my patch, a reason for $0 or a reason for $0 being "different" in messages?
the latter (your patch is great, although i'd like to have even more
well i think this is very consistent: $args in messages refer _only_ to parameters of incoming messages, while $args in objects refer only to parameters of upstream objects. (and $0 is bound to the class instance)
It is consistent and the problem may lie elsewhere: messages are the only "objects", that do not have access to abstraction properties like abstraction arguments and $0. It is hard to give them access, because $x already is used for a different purpose in messages.
One solution could be a "message object", that does both, something like a [makemessage] which could be a mix of [makefilename] on steroids and a standard [message( - and maybe could reintroduce Max's #x.
Ciao
On Sun, 15 Jan 2006, Frank Barknecht wrote:
It is consistent and the problem may lie elsewhere: messages are the only "objects", that do not have access to abstraction properties like abstraction arguments and $0. It is hard to give them access, because $x already is used for a different purpose in messages. One solution could be a "message object", that does both, something like a [makemessage] which could be a mix of [makefilename] on steroids and a standard [message( - and maybe could reintroduce Max's #x.
Note that there's another related notation already used in Pd. It's in [expr] and goes like:
$f1 means float in first inlet $v2 means signal in second inlet etc
and it could be reused, but then there are two things to take care of:
the type specifiers f,v, must be complemented by other specifiers s=symbol, p=pointer, and some other letter to mean atom (but not "anything" in the sense of general message).
there has to be a correspondence between the multi-inlet context of [expr] and the single-inlet context of the messagebox.
Alternately, the latter issue could be skipped completely if $1 was replaced not by $f1 or $s1, but by $a1[1] meaning first element of the message in the first inlet. This notation is also consistent with [expr~]. $a1[0] would access the selector. Here, "a" really stands for "anything" as it is normally in Pd (that is, except for the [bang}->[t a] bug)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Jan 15, 2006, at 4:01 AM, IOhannes m zmoelnig wrote:
Thomas Grill wrote:
do you mean, is there a reason for my patch, a reason for $0 or a reason for $0 being "different" in messages?
the latter (your patch is great, although i'd like to have even more
well i think this is very consistent: $args in messages refer _only_ to parameters of incoming messages, while $args in objects refer only to parameters of upstream objects. (and $0 is bound to the class instance)
however, i think that "$0" is a bad name. i would have liked it better if $0 was the selector (in messages) and the classname (in abstractions). probably "$$" would have been better for a uniq id (well, i know that this is a bashism (its the process-id in bash), but that is not necessarily bad)
This sounds logical. I have a question about the selector tho. So if I send [1 2 3(, would the $0 selector be "list" or would it be "1"?
As for implementing this, we could add $$ as the instance ID, and $0 in messages as the selector. Then have $0 default to classname in objects, but have a startup flag that reverted $0 to the old behavior for running old patches. Why we are at it, $# for number of arguments and $@ for all arguments would be nice too.
flexible $args-processing).
this is on my todo-list. 1st thing todo (soon!) is to remove the restriction that dollsyms have to start with $
Yes, this would be good.
(while this restriction makes parsing trivial it is cumbersome at the best) 2nd thing todo (LATER!) is a mechanism for stacked $args, like ${$1-2}
Stacked args would complicate things more than its worth. I think it is getting away from the graphical nature of Pd programming and I can't think of any parallel structure in any language that uses $ variables. Couldn't you just use stacked messages with regular $ args? That would be much more Pd-ish.
.hc
Sorry for continuing in your thread.
better in this thread than never...
mfmgasdr IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
"Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies." - Amy Smith
Hans-Christoph Steiner wrote:
On Jan 15, 2006, at 4:01 AM, IOhannes m zmoelnig wrote:
This sounds logical. I have a question about the selector tho. So if I send [1 2 3(, would the $0 selector be "list" or would it be "1"?
of course it would be "list", since that'sthe selector of [list 1 2 3(. [1 2 3( is just a shortcut for [list 1 2 3(
As for implementing this, we could add $$ as the instance ID, and $0 in messages as the selector. Then have $0 default to classname in objects, but have a startup flag that reverted $0 to the old behavior
well this would be simple, though i am not really convinced that it is practical - but then, hey, it might really make things better on the long run (an alternative would be to make it a compile.time option ;-))
for running old patches. Why we are at it, $# for number of arguments and $@ for all arguments would be nice too.
yes of course, i just forgot to mention that.
2nd thing todo (LATER!) is a mechanism for stacked $args, like ${$1-2}
Stacked args would complicate things more than its worth. I think it is getting away from the graphical nature of Pd programming and I can't think of any parallel structure in any language that uses $ variables.
ähm, bash? like in: ~$ i=3; j=4; echo $[i+2] $[i*$[j+1]]
Couldn't you just use stacked messages with regular $ args? That would be much more Pd-ish.
i was thinking of objects where i cannot change the arguments via messages. [block~] used to be like that (but since 0.39 (or was it 0.38) you can now set the blocksiz,... via messages, which makes my argument somewhat obsolete; but anyhow...) writing an abstraction with variable blocksize which is a multiple of the variable(!) blocksize of its parent patch would need that. (while this sounds a bit weird, i am pretty sure i needed to do so several times in the past; of course i don't remember the exact context) btw, there is even an open feature request in the sf-tracker regarding this.
but as i said, it is not very high priority on my todo list
mfg.adsr. IOhannes
On Jan 15, 2006, at 12:38 PM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
On Jan 15, 2006, at 4:01 AM, IOhannes m zmoelnig wrote: This sounds logical. I have a question about the selector tho. So if I send [1 2 3(, would the $0 selector be "list" or would it be "1"?
of course it would be "list", since that'sthe selector of [list 1 2 3(. [1 2 3( is just a shortcut for [list 1 2 3(
As for implementing this, we could add $$ as the instance ID, and $0 in messages as the selector. Then have $0 default to classname in objects, but have a startup flag that reverted $0 to the old behavior
well this would be simple, though i am not really convinced that it is practical - but then, hey, it might really make things better on the long run (an alternative would be to make it a compile.time option ;-))
for running old patches. Why we are at it, $# for number of arguments and $@ for all arguments would be nice too.
yes of course, i just forgot to mention that.
2nd thing todo (LATER!) is a mechanism for stacked $args, like ${$1-2}
Stacked args would complicate things more than its worth. I think it is getting away from the graphical nature of Pd programming and I can't think of any parallel structure in any language that uses $ variables.
ähm, bash? like in: ~$ i=3; j=4; echo $[i+2] $[i*$[j+1]]
Ah, I guess I am stuck on good ol' bourne shell ;). But isn't that bash stuff just a hack to get math into bourne shell syntax? I don't think its the kind of thing we want to emulate.
Couldn't you just use stacked messages with regular $ args? That would be much more Pd-ish.
i was thinking of objects where i cannot change the arguments via messages. [block~] used to be like that (but since 0.39 (or was it 0.38) you can now set the blocksiz,... via messages, which makes my argument somewhat obsolete; but anyhow...) writing an abstraction with variable blocksize which is a multiple of the variable(!) blocksize of its parent patch would need that. (while this sounds a bit weird, i am pretty sure i needed to do so several times in the past; of course i don't remember the exact context) btw, there is even an open feature request in the sf-tracker regarding this.
but as i said, it is not very high priority on my todo list
I think that its much cleaner to make the objects receive messages on inlets than get into the whacky bash syntax.
.hc
________________________________________________________________________ ____
"Information wants to be free." -Stewart Brand
On Sun, 15 Jan 2006, Hans-Christoph Steiner wrote:
Ah, I guess I am stuck on good ol' bourne shell ;). But isn't that bash stuff just a hack to get math into bourne shell syntax? I don't think its the kind of thing we want to emulate.
It depends on whether you prefer just-a-hack in the language itself or just-a-hack in every patch that can't use the language hack.
Doing message-based math in Pd can be pretty tortuous sometimes, and few people are really trained into converting math formulas into small Pd objects like [+] [*] [swap] [pack] [unpack].
For the rest of us (mere mortals) there is [expr].
In PureUnity I can't use [expr] in situations where the point is to test [+] [*] etc, so I do all the tortuous stuff.
I think that its much cleaner to make the objects receive messages on inlets than get into the whacky bash syntax.
Yeah, I wouldn't especially pick bash's syntax in this case but I don't know what else it could be. My current favourite is the one like $a1[1] that I described in another email today. That syntax doesn't do any arithmetic but it introduces multi-inlet messageboxes. (for the arithmetic, [expr] is good enough for me)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Sun, 15 Jan 2006, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
Stacked args would complicate things more than its worth. I think it is getting away from the graphical nature of Pd programming and I can't think of any parallel structure in any language that uses $ variables.
ähm, bash? like in: ~$ i=3; j=4; echo $[i+2] $[i*$[j+1]]
also Tcl is sort of like that but inside out:
set i 3; set j 4; puts "[expr $i+2] [expr $i*($j+1)]"
but then some lisp-weirdos define Tcl procs for + * etc, resulting in:
set i 3; set j 4; puts "[+ $i 2] [* $i [+ $j 1]]"
i think i recall jMax2 had it like:
[var i: 3] [var j: 4]
[list ($i+2) ($i*($j+1)) } | [print]
and similarly with $1 $2 instead of $i $j
(but jMax4 had a different sin-tax that I don't even recall.)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Sun, 15 Jan 2006, IOhannes m zmoelnig wrote:
however, i think that "$0" is a bad name. i would have liked it better if $0 was the selector (in messages)
I agree. It's especially nice as most anythings are accepted by messageboxes (except those starting by methodnames of messageboxes such as "set").
Yesterday at PureData Montréal 16, someone wrote $0 in a messagebox and printed it. It was garbage because the output wasn't a valid t_symbol*. He was expecting it to output the selector.
and the classname (in abstractions).
I agree that it should be the classname in order to be consistent with the above use of messageboxes, and because it's very intuitive: if you write [foo 42 bar] then $0 should be foo just like $1 is 42 and $2 is bar.
probably "$$" would have been better for a uniq id (well, i know that this is a bashism (its the process-id in bash), but that is not necessarily bad)
I would have preferred "$$" too. That slashed S symbol called "dollar" is a mnemonic in several languages, for a word that starts with S: in BASIC it meant String, in Perl it means Scalar, in Ruby it might mean Special (because Sglobal isn't quite a word). In Bash, Tcl and Pd it means Substitution. Possibly that "$$" could be remembered as Substitute Self.
2nd thing todo (LATER!) is a mechanism for stacked $args, like ${$1-2}
What does that mean?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
IOhannes m zmoelnig wrote:
caveat: the A_DOLLARSYM still has to start with "$[0-9]". this is the way, pd determines whether a given symbol should be $-expanded or not. furthermore, the leading $ is usually stripped by pd. e.g. if you type [$1-bar-$2], the symbol "1-bar-$2" is stored as A_DOLLARSYM. this means that the beginning of the dollarsymbol always has to be expanded. furthermore, [bar-$2] will _never_ be expanded (since pd thinks it is an ordinary symbol).
i didn't dare to change this behaviour since SETDOLLARSYM() and binbuf_realizedollsym() are exposed in m_pd.h and probably used in externals which would then break. however, whenever this might change, binbuf_expanddollsym() is prepared (just need to "#if 1")
actually it is binbuf_realizedollsym() that is prepared.
however, i did some quick greps over the entire CVS, and it seems that if we want to get rid of the restriction that A_DOLLARSYM has to start with "$" there are only very few "external" files that need to be modified, namely: externals/iemlib/src/iemlib2/iem_pbank_csv.c externals/miXed/shared/common/port.c externals/miXed/shared/common/lex.c externals/grill/flext/source/flattr_ed.cpp externals/grill/flext/source/flatom_pr.cpp
so that's only 3 libraries. i guess i will do it (if nobody finds a convincing argument to stop all this)
mf.a.ast IOhannes
On Jan 14, 2006, at 2:16 PM, IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
caveat: the A_DOLLARSYM still has to start with "$[0-9]". this is the way, pd determines whether a given symbol should be $-expanded or not. furthermore, the leading $ is usually stripped by pd. e.g. if you type [$1-bar-$2], the symbol "1-bar-$2" is stored as A_DOLLARSYM. this means that the beginning of the dollarsymbol always has to be expanded. furthermore, [bar-$2] will _never_ be expanded (since pd thinks it is an ordinary symbol).
i didn't dare to change this behaviour since SETDOLLARSYM() and binbuf_realizedollsym() are exposed in m_pd.h and probably used in externals which would then break. however, whenever this might change, binbuf_expanddollsym() is prepared (just need to "#if 1")
actually it is binbuf_realizedollsym() that is prepared.
however, i did some quick greps over the entire CVS, and it seems that if we want to get rid of the restriction that A_DOLLARSYM has to start with "$" there are only very few "external" files that need to be modified, namely: externals/iemlib/src/iemlib2/iem_pbank_csv.c externals/miXed/shared/common/port.c externals/miXed/shared/common/lex.c externals/grill/flext/source/flattr_ed.cpp externals/grill/flext/source/flatom_pr.cpp
so that's only 3 libraries. i guess i will do it (if nobody finds a convincing argument to stop all this)
Sounds good to me. Just an FYI: externals/grill is just a mirror of Thomas' repository, so you have to submit a patch to him rather than committing the changes to CVS.
.hc ________________________________________________________________________ ____
"The arc of history bends towards justice." - Dr. Martin Luther King, Jr.
IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
i didn't dare to change this behaviour since SETDOLLARSYM() and binbuf_realizedollsym() are exposed in m_pd.h and probably used in externals which would then break. however, whenever this might change, binbuf_expanddollsym() is prepared (just need to "#if 1")
after some initial trials to make "bla-$1" be recognized as A_DOLLARSYM i have to admit that it might take longer than i thought....
mf.asdr IOhannes
Wow.
I like this.
.b.
SourceForge.net wrote:
Patches item #1405137, was opened at 2006-01-13 20:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1405137...
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: wishlist Status: Open Resolution: None Priority: 5 Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: multiple $arg-expansion
Initial Comment: currently $args can only be at the beginning of a A_DOLLARSYM.
this patch allows to have multiple $args within 1 A_DOLLARSYM. e.g. with "foo bar me" the symbol "$1-bla-$3/$2" will expand to "foo-bla-me/bar"
the patch only modifies binbuf_realizedollsym() in m_binbuf.c (and adds another non-exported helper function binbuf_expanddollsym())
the patch is straightforward, but probably i misunderstood the meaning of "tonew" and implemented it in a wrong way (so you should check that)
caveat: the A_DOLLARSYM still has to start with "$[0-9]". this is the way, pd determines whether a given symbol should be $-expanded or not. furthermore, the leading $ is usually stripped by pd. e.g. if you type [$1-bar-$2], the symbol "1-bar-$2" is stored as A_DOLLARSYM. this means that the beginning of the dollarsymbol always has to be expanded. furthermore, [bar-$2] will _never_ be expanded (since pd thinks it is an ordinary symbol).
i didn't dare to change this behaviour since SETDOLLARSYM() and binbuf_realizedollsym() are exposed in m_pd.h and probably used in externals which would then break. however, whenever this might change, binbuf_expanddollsym() is prepared (just need to "#if 1")
You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1405137...
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-
B. Bogart -
cdr -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Mathieu Bouchard -
SourceForge.net -
Thomas Grill -
Tim Blechmann