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___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
