[PD] declare [loooooooooooong]

[Frank Barknecht]

Hallo,
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:

> There is consensus if we consider how other programming languages  
> have done it.  From what I have seen in Python, Java, and C (and  
> probably many others) there are two options:  global and local-to-the- 
> file.

Okay, now a more serious, but very long and sometimes shaky answer. 

As I see it we're dealing with some intertwined, but different issues
here, and also there still is too much guesswork involved, where we
should develop a concrete and detailed specification. The only docs in
this direction that I could find on pd.info are these two by you:
http://puredata.info/dev/PdNamespaces
http://puredata.info/docs/developer/LibdirFormatForLibrariesOfObjects

These should be fleshed out and become much more detailed, i.e. with
concrete examples and definitions of terms. Otherwise we will risk to
talk at cross-purposes. For example, even the sentences "We should get
namespaces working" or "Lets do as Lua did" are very ambigous if we
look closely.

To get back to the intertwined issues I see: 

One is the actual namespace which I for now would define as 

  A namespace is the set of class names which are available to be
  converted into concrete objects when typed into an object box in a
  patch canvas. 

Note that this is not that thing that we should "get working", it's
just a try at a definition of the term. A try at what "get working"
might mean could be this: 

  Pd should be enabled to modify the contents of the namespaces in
  ways (sic!) that make everyone happy.

We then also have another issue which is "The Path". I don't have a
good name for this yet. In my previous mails I often called it "-path"
to hint at the command line option which sets it. [declare] modifies
"The Path", which in turn modifies the namespace currently (because Pd
works that way. This isn't a requirement as Lua or Python modify
namespaces in a completly different way). "The Path" in Pd also is
responsible for other ressources like [soundfiler]'s path. (Idea: We
could introduce a Ressource Path to separate the class search path and
other search paths like for soundfiler.)

A relative of The Path, but not the same, is "The Helppath", which
lets objects call help files. You all know it. 

Let me stress again, that in my view Paths are not equivalent to the
namespace and they are not the only way to modify the namespace, see
below. In Python and Lua they just are values in variables (e.g.
"package.path" and "package.cpath" in Lua). 

The confusion about The Path and The Namespace comes from the fact,
that in Pd currently one (even the only one for abstractions) way to
modify the contents of the namespace is to modify The Path. As we all
know this has side effects, for example modifying The Path also
modifies what [soundfiler] sees.

But there are other ways to modify the contents of the namespace, not
just by modifying The Path. One is to load a library of multiclass
objects, another is to use certain loaders. I really, really like
IOhannes' approach of moving the loading of abstractions into a loader
(Patch #1990686) as it may open up a new way of thinking about
namespaces separate from just modifying The Path (which I fear may
lead into a dead end if things turn out bad ...)

Finally there are two other, more complicated concepts to maybe
consider, namely "The Environment" and "The Scope". I refer to
concepts of traditional programming languages here. For Environment
see the SCIP for example:
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-10.html#%_sec_1.1.2
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-21.html#%_sec_3.2

For Environments in Lua check this: http://www.lua.org/pil/14.html

Scope in Pd so far is easy: Everything is global, even $0-variables.
Locality is expressed in patch cords, which are as local as local gets
(except maybe in Gem). [declare] and [import] showed a possible
different way of locality: canvas-locality.  It's an open question if
this should extend to subpatches and abstractions. (In Lua, local
scope can extend into deeper regions: see non-local variables.)

The other languages mentioned have very elaborate scoping rules.  Lua
is a good example as it defaults to a global scope (like Pd) as well,
while still providing the "local" keyword to make things local to a
block, and it even has something in between ("non-local variables" or
"upvalues").  In Python it is the other way around, stuff is local as
default.

Environments are crucial for the implementation of namespaces in Lua,
as "importing" something means changing the global environment. In Pd
I have no idea how to express the concept of an Environment (maybe
language theory experts like Matju or A. Graef can help me here?) but
I guess, the fact alone, that Lua uses them for importing, means, that
we may need to find a different way when doing imports from how Lua
does it.

In the end to me means this means that this: 

> If we want to have namespaces working, then I suggest we use the  
> tried-n-true model of other languages. 

isn't as easy as it sounds. Not by far.

Well, sorry for this long and in parts very confusing/confused mail.
I myself am trying to get my head around these issues, so you see me
live coding here and please apologize any inconsistencies. But I
really think, that there's a time now to lean back for a moment, take
a deep breath and enjoy the whole scenery to then discuss and see
where we are standing and what solution would be a good long term
solution. To consider advantages and disadvantages and bring a bit of
order and some specifications into all these problems.

Oh, and maybe this should move to pd-dev?

Ciao
-- 
 Frank Barknecht                                     _ ______footils.org__