On Jul 30, 2008, at 3:35 PM, Frank Barknecht wrote: > 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.
I edited this and added it to the PdNamespaces wiki. http://puredata.info/dev/PdNamespaces > 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. It seems to me that using the canvas-local and global paths for everything that opens a file isn't really a good idea. You never know where a file could come from. But that is entrenched, so it is not going anywhere. Personally I think [soundfiler] should only look in the current directory of the patch if it is a relative path. If you need to use more complicated paths, you can use [getdir]. But I think we should let this issue rest and just focus on the namespace for loading objectclasses. > 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. The Lua-style "environment" in Pd is basically just the global path and the global helppath. There aren't really any other global variables that I can think of. > 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? That's what this wiki page is for, let's start documenting ideas and cataloging behaviors. This is not such a hard problem. It just needs some careful cataloging of the possibilities and a little research into how others have solved this issues. Most of the work will be implementing it. http://puredata.info/dev/PdNamespaces .hc > > Ciao > -- > Frank Barknecht _ > ______footils.org__ > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/ > listinfo/pd-list ------------------------------------------------------------------------ ---- News is what people want to keep hidden and everything else is publicity. - Bill Moyers _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
