On Wed, 24 Mar 2004, Mathieu Bouchard wrote:
Hi, I would need some input on extending the .pd format. I would also like that some modifications get made to Pd to support extensibility. Here's the plan for now:
- "#X connect" lines would take any number of extra arguments, which
would have to be preserved by attaching an atom list to each connection and save that list when saving the connection. Ideally this would have to be put in all versions of Pd. Now, miller+devel branches may actually just ignore those extra arguments, and the impd branch would do something else with it.
.. so this means no changes, right ? Surely a possible extension.
- all GUI objects should support additional arguments in pretty much the
same way.
- Alternately, (1) and (2) can be replaced by having a new #-code (like
#E standing for extra) that applies to the last #X. This would be especially good for adding properties to GUI objects that already have a use for any number of arguments (messageboxes, objectboxes themselves, and comments).
- In any case, I think it would be good to have those extras as key/value
pairs, because 23 unnamed arguments (#X obj 0 0 vsl blah blah blah) is already a bit hard to follow sometimes, and it sounds silly to me to add more of those unnamed arguments, especially since in most cases, default values still would be used, just like they already are in the case of half of the 23 unnamed arguments right now.
You are right, actually most of the arguments that do not form part of the functionality should be key/value pairs.
- There's a problem with the above idea (4) when it comes to counting a
list as a value. One way to resolve this is to introduce sublists, which would be a good idea anyway, and use the {} characters (that are currently dropped, and so unused) for that purpose, just like how they are used in jMax2 and Tcl already (or parens in LISP, or [] in many others).
if the {} do not present problems for the tcl/tk interpreter they seem to be the best choice. I am not sure though if pd supports nested lists.
- However I don't know how much code would have to be changed for (5) to
be completed. If I didn't care about compatibility, I would introduce {}'s all over the place, but if I have to make it easier for other (miller+devel) branches, then i'd ask to only support them in #E's for now, and delay their other potential uses in the rest of Pd (inside normal "#X obj" arguments, etc), though using parens with spaces around them (in GF/Pd) still looks silly anytime.
I think you would only have to change the parser, and the converter from pd internal types to text representation. This should not introduce changes in too many places.
Ok, the above are my most important ideas, but below are some extra nonneglectible ideas that I'm less sure what to do about.
- If doublequotes changed meaning to quoting symbols in pretty much
C/Tcl/etc allow, it would be an incompatibility, but I suspect the end result of most of the affected patches would actually remain the same, just going through different semantics, such that "foo bar" would just be a 7-character symbol instead of two 3-character symbols.
Sounds good.
- However I would prefer doublequotes to mean _string literals_ instead,
and maybe use some other character for symbol quoting: LISP uses [], but LISP isn't too familiar to most Pd users anyway. I might suggest backticks or singlequotes. String literals might be difficult to introduce neatly into Pd, because it would be great if they could be used (magically) instead of symbols whenever possible, and have automatic conversion, but I guess all the code checking for T_SYMBOL won't support it...
Considering that the language itself should be kept as simple as possible (everyone is happy that we do not have integer and float types anymore), I think, at least for the user, there should not be a distinction between symbols and strings. Where would we want to have strings ?
Guenter
Mathieu Bouchard http://artengine.ca/matju
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev