On Tue, Nov 2, 2010 at 11:08 AM, Donn Cave <donn at avvanta.com> wrote:
> 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.