[PD] declare [loooooooooooong]

[Hans-Christoph Steiner]

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__
>
> _______________________________________________
> Pd-list at iem.at 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