[PD-dev] abstractions

[Mathieu Bouchard]

On Sat, 12 Jul 2008, Albert Graef wrote:

> So what? Most FPLs deal with state just fine. Even purely functional 
> languages do, through special abstractions like streams or monads.

Do talk to Claude about whether it's worth the effort.

> Pd objects are just boxes taking inputs and producing outputs

That's not the Pd I know.

> My point is that it would be nice to have just a little infrastructure 
> to better support language interfaces in general,

I always agreed with that.

>> Well, it depends a lot. Functional problems will have short functional
>> solutions, and imperative problems will have short imperative solutions.
> Well, I wouldn't talk about "functional" or "imperative problems" here,
> but it's certainly true that some stuff tends to be easier in one
> language and other stuff in another one.

This is exactly what I mean.

> However, that just illustrates my point that it's better to have an 
> interface that accomodates different scripting languages, instead of 
> singling out Tcl as the be all and end all of it.

Agreeing on a most interesting scripting language, and agreeing on new 
support for scripting (and other) languages, is two different things.

>> You can't wait for Pd to support anything in particular.
> I won't. But would it really hurt if [declare] supported, say, a -script
> option so that a language external could inspect that attribute of a
> patch and use it as the name of a script to be loaded?

This is redundant... -lib already does it, together with loader_t. (yes, 
it's called loader_t, as opposed to all other Pd C types).

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec