[PD] list-abs and externals [was: Re: [pd] tables as patch storage]

[Jonathan Wilkes]

----- Original Message -----

> From: Frank Barknecht <fbar at footils.org>
> To: pd-list at iem.at
> Cc: 
> Sent: Tuesday, March 27, 2012 11:45 AM
> Subject: [PD] list-abs and externals [was: Re: [pd] tables as patch storage]
> 
> On Tue, Mar 27, 2012 at 11:21:15AM -0400, Mathieu Bouchard wrote:
>>  list-abs was designed to only use pd's builtins, no externs, which
>>  makes it more like academic exercises of proving that anything can
>>  be done with a Turing tape machine, rather than being designed in a
>>  pragmatic way. 
> 
> Actually I consider list-abs to be very pragmatic *because* it only uses
> builtins. This makes it highly portable and trivial to use
> everywhere, even without installing it globally.
> 
> If you treat list-abs as an interface or API, it also is very easy to 
> optimize the objects by using externals inside of the
> list-abs-abstractions without having to change the surrounding patches.

There's actually a much bigger potential benefit to using abstractions to build a 
common interface, which is that _anyone_ in the community can build the 
interface, and the guts (which may very well be filled with externals) can 
get replaced later as the internal objects necessary to support them get added 
to core Pd.

For example, I could make a symbol manipulation library, similar to all the 
subcommands of the tcl [string] command, and fill the guts either with externals 
or a crazy symbol-splitting hack using only vanilla objects (so that vanilla users 
can at least try out the interface).  Then the interface could get commented upon, 
tweaked, and changed (maybe using a different model than tcl) until it looks very 
good, and during this process, or at any point in the future when Pd's symbol 
stuff gets improved one can just change the guts of the interface to improve the 
performance/usefulness of the library.

But I find it interesting that you only imagine the guts of list-abs getting replaced 
with externals in order to improve the performance, and not with new core objects.  
I think this is because the process of getting stuff included in core Pd is 
so badly broken that it's not even worth mentioning-- unfortunate since the 
abstraction interface-building I describe would be a really nice development model.

-Jonathan

> 
> I already sketched this approach four years ago:
> http://lists.puredata.info/pipermail/pd-list/2008-12/066571.html
> 
> Ciao
> -- 
> Frank
> 
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>