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