[PD] standard library (was Re: [PD-announce] Pd-extended 0.43.4 released!)

[Hans-Christoph Steiner]

On 01/31/2013 03:38 AM, IOhannes m zmoelnig wrote:
> On 2013-01-30 22:40, Hans-Christoph Steiner wrote:
>> A quick internet translations makes me think that I agree with what
>> cyrille is saying.  The preferences shouldn't be used for loading
>> libraries, as they have been in pd and especially Pd-extended for a
>> long time.  Pd-extended no longer lets you set libraries to load from
>> the preferences, this is one step to get us on the right direction.
>> I've been thinking about other things as well,
> 
> i'm still very skeptic about the possibility that there is "one" right 
> direction.
> 
>> here's how I'm thinking:
> 
>> * new standard library that is larger and more consistent than what's
>> in vanilla, things like all math and logic objects both message and
>> signal included, rather than needed to load a library (i.e. zexy) for
>> some of them.
> 
> i'm not sure i really understand the sentence. but i guess it is mainly
> suggesting to move objects of general value to a so called "standard
> library" that provides the basic needs.

move, not copy.  I wouldn't change any existing libraries.


> one question os of course, what a "basic" need is. e.g. personally i
> would vote for a minimum set of math-like operators, rather than
> high-level user-friendly objects. e.g. [>~] but not [moog~]. others might
> think very differently about this.

I totally agree.  We'll have to work out what is required in the basic
library.  I think all math and logic are the obvious starting point, and
moog~ is obviously still an external.  I think that the standard library
will be broader than other programming languages because Pd aims to be
simpler, smaller, and easier to learn.  So I would definitely include all
symbol and list manipulations (symbol2list, makesymbol, list-append,
list-prepend, split, etc.).

I also think that all of the objects should flexibly work with both floats
and symbols wherever appropriate.  zexy/pack is a great example of this.
[select] should be like that too.


>> It would prioritize correctness and consistency over backwards 
>> compatibility.
> 
> i agree, that a so called "standard library" is a *must*.

The hard part is agreeing on what's correct ;)


>> * no libraries but the standard library loaded by default.
> 
> note that many languages (including C and python) don't automatically 
> load their standard libraries. however, they do have a standard library. 
> and they provide primitives that allows you to use the language even 
> without any standard library.

To clarify here, by "standard library" I mean the commands that are
available without specifically loading anything.  So this is different than
what python calls its "standard library" which included things loaded by
default and many things that have to be loaded.


> from the users's perspective it's probably a good "default" to load a 
> stdlib, but one could easily introduce a "-nostdlib" flag to override 
> that.

Yes the transition will be a long slow process.  I'm thinking it could be a
separate build, and leave Pd-extended as the name of the old way.  This
would be like python2 vs python3.  So I guess "built-in" might be a better
name for it: http://docs.python.org/2/library/functions.html

And 'builtin' is actually a loadable module too:
http://docs.python.org/2/library/__builtin__.html

I want to include functionality like this in Pd-extended, or the new
python3-style thing if we go that route, so that it would be possible to
load a vanilla or extended compatibility mode.


>> * all of Pd-vanilla's objects as a separate 'vanilla' library.
> 
> how would that be different from the standard library? i guess the stdlib
> most likely will contain more objects than vanilla, and some
> objectclasses would not be part of stdlib or under another name
> ([makefilename] springs to my mind).

yes, exactly.  Then things like [hip~], [log], etc. that have changed over
the years in incompatible ways, they would only include the correct method.
 I would also replace [list append], etc. since it is the only set of
objects that violate the "first word is the object name" rule.

.hc