[PD-dev] BUG: namespace prefixes broken in 0.40

[Hans-Christoph Steiner]

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  
>>> delimiters
>>>  [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.

.hc







>
>> 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.