Mathieu Bouchard wrote:
You got to be kidding. Perhaps you are using another definition of functional language. The Pd/MAX message system (non-signal) is most likely the most stateful (non-functional) dataflow language around.
So what? Most FPLs deal with state just fine. Even purely functional languages do, through special abstractions like streams or monads. At the end of the day, Pd objects are just boxes taking inputs and producing outputs, which can be programmed in FPLs quite easily. And FPLs provide the tools to express such transformations in a convenient way, such as pattern-matching (a.k.a. symbolic rewriting) and higher order functions.
But my point was certainly *not* to propose an FPL as Pd's default scripting language. My point is that it would be nice to have just a little infrastructure to better support language interfaces in general, no matter whether Pd will provide some default scripting interface in the future or not.
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. 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.
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? That just needs one routine in the plugin API which allows externals to read the attributes of a patch (which might be there already, I haven't checked lately).
Cheers, Albert