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

Mathieu Bouchard matju at artengine.ca
Thu Nov 2 01:30:31 CET 2006


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

> 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


More information about the Pd-dev mailing list