On Tue, Nov 2, 2010 at 11:08 AM, Donn Cave
The quotes around "scripts" are well chosen, since it sounds like you might be using the word in a different sense of `small program', vs. the extension language notion of a programmable UI.
Haskell's suitability for something like this has come up before. The worries about its complexity and giant learning curve seem misplaced to me - as a scripting extension it would have less to do, so there would be less to learn, I think - but it's all hand-waving without more concrete ideas about the typical application.
And it's a moot point if there's no way to do it.
If (and this is a big if) the type of extensions you want the user to provide are well captured in a simple combinator-style DSL you can write an AST and interpreter for, then as a first pass Read/Show over the AST is sufficient. If the syntax and parser messages are too confusing, then a parsec-based parser can get you the rest of the way. Once you grok the principles, writing your own functional mini-language in Haskell (including as an external DSL) is in many ways more straightforward than binding to any sort of external runtime. That said, some sort of slow but low-footprint "mini-hask" for extension languages would be pretty awesome. I'm seeing a function like -- evalMiniHask :: Environment -> String -> Either ParseOrTypeError Dynamic. where type Environment = ([DataRep], [FunctionRep]) and type DataType = (String,TyCon,Dynamic) -- the latter being the concrete type constructor, wrapped in a dynamic type FunctionType = (String, TypeRep, Dynamic) -- the latter being the concrete function, wrapped in a dynamic I can see a number of use cases in my own code already Cheers, Sterl.