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__