[PD-dev] BUG: namespace prefixes broken in 0.40
hans at eds.org
Thu Nov 2 04:39:50 CET 2006
On Nov 1, 2006, at 7:30 PM, Mathieu Bouchard wrote:
> On Wed, 1 Nov 2006, Hans-Christoph Steiner wrote:
>>> [declare -import (foo bar)] <- GF-style nested lists
>>> [declare -import foo bar] <- use dash-prefixed symbols as
>>> [declare, import foo bar] <- use comma as delimiter
>> One very important aspect of Pd is its very minimal syntax.
> It depends on which part of Pd you're looking at. Let's say that
> you're looking at everything that confirms your point; then you're
> not looking at datastructures. For example:
> [plot -y amp(0:100)(0:100) a 500 2 5 30]
> I advocate use of consistent syntax all over pd. Consistency is
> more important than minimality. If pd's syntax is too minimal, it
> encourages small syntax hacks that aren't portable to the rest of
> the pd system, such as -y amp(0:100)(0:100).
That is strange, I hadn't seen that before. I also have not seen
gridflow before. I should say, then I am talking about things in
common usage. There is definitely a lot of stuff shoe-horned into
some of those draw and plot boxes. I wonder how to make that stuff
work without the new syntax?
I don't quite get the scaling stuff, so I guess its hard to see why
it needs to be done that way. Perhaps there could be a scaling
standard variable like float x, float y, and float w. It could be an
array of 4 values, or two values, a ratio and offset.
Another difference between [declare] and data structures/gridflow is
that obstensibly, [declare] will be used everywhere, while DS/GF
would be a special topic. For special areas, special syntax is
perhaps more excusable than something used everywhere.
>> I think its quite important to preserve that.
> Pd's syntax doesn't so much deserve to be called "simple" ...
> "simplistic" is more like it. Any non-recursive grammar is bound to
> get to a dead-end in which small syntax hacks proliferate.
>> but I don't really like any of the above options. Pd is not Ruby,
>> Tcl, C, UNIX, etc. and it shouldn't follow those conventions
>> without really good reasons to break the current syntax.
> This is called "Not Invented Here", the concept that one system
> should not borrow conventions from another system. It's an
> important concept that has been used for designing many systems,
> and ironically, one that many systems designers have borrowed from
> each other. (http://en.wikipedia.org/wiki/Not_Invented_Here)
> It's not possible to break the current syntax because there's no
> current syntax.
>> Adding commas and () in object boxes is totally unprecedented
> GridFlow is a precedent for both initbang commas and nested lists,
> but it doesn't count because it was not designed by Miller. There
> is also precedent for @ keywords in the work of Thomas Grill and
> also of Joshua K Clayton but it doesn't count because it was not
> designed by Miller. There is also precedent for - keywords in the
> work of Krzysztof Czaja but it doesn't count because it was not
> designed by Miller.
>> and I can't see any benefit.
> because it's not designed by Miller and because you're not thinking
> about any of the other object classes that could benefit from those
> syntax extensions. Even though [plot] would have needed it, [plot]
> introduces its own precedent which is sufficient justification by
> itself, because it was designed by Miller.
>> I definitely agree we should have a standard way of doing this
>> kind of thing,
> By reading you, I doubt that you mean that we should have a
> standard way of doing keyword arguments. Is it that you are only
> thinking about namespaces and nothing else? I'm not only thinking
> about namespaces. You're replying to a mail where more than just
> namespaces are considered.
>> Perhaps this extended syntax is useful in other situations, but I
>> think this situation could easily be taken care of using only
>> current syntax:
> Right, we don't absolutely need keyword arguments, nested lists and
> initbang messages in objectboxes. I'm only talking about those
> things because a syntax similar to keyword arguments has been
> proposed and because I've seen similar patterns occur in the pd
> world, but I don't mean the pd world that has just Miller in it, I
> mean all externals, and not just the subset of pd-extended that
> agrees with Miller's practice (minus [plot]).
>> I think it could make more sense to have the global settings
>> controlled by messages.
>> [;pd import foo bar( [;pd path foo bar(
> [import foo bar(
> [s $0-canvas]
> [namecanvas $0-canvas]
> _ _ __ ___ _____ ________ _____________ _____________________ ...
> | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
> | Freelance Digital Arts Engineer, Montréal QC Canada
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.
More information about the Pd-dev