-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/2/10 03:33 , Permjacov Evgeniy wrote:

Forth is quite easy to implement, but can it be used as extension language? Wiki describes it as quite low level...

It's low level but rather easy to build up more complex stuff. It's never been that popular in general due to its RPN nature, but is quite popular for extensions in low memory situations: it's *extremely* compact when "compiled" (that is, when source code consisting solely of word definitions is executed, the result is quite tiny). To give one example of the latter, look at FreeBSD's boot loader. - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzUq3sACgkQIn7hlCsL25UxZwCePgTpKGFnxZB+AJHugIAkXSbd FTUAnjl2FJEjyp9bxr3rh3Nmql3O0y22 =ncJH -----END PGP SIGNATURE-----

Because he would have either to recompile the whole program or to use things like hint, both implying that GHC must be installed on the user side (600Mo+ for GHC 6.12.3) 2010/11/2 Lennart Augustsson

I don't understand. Why don't you use Haskell as the scripting language?

On Tue, Nov 2, 2010 at 7:04 AM, Permjacov Evgeniy wrote:

...

Let us think, that we need some scripting language for our pure haskell project and configure-compile-run is not a way. In such a case a reasonably simple, yet standartized and wide known language should be implemented. What such language may be? R(4/5/6)RS ? EcmaScript ? Some other ? _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 2/11/2010 9:05 PM, Steffen Schuldenzucker wrote:

...

Because he would have either to recompile the whole program or to use things like hint, both implying that GHC must be installed on the user side (600Mo+ for GHC 6.12.3) Isn't there a way to use some stripped-down version of ghc and the base

On 11/02/2010 10:40 AM, Yves Parès wrote: libraries, providing only what the user really needs, in versions which are known to work, and supply that together with the application?

there is hugs, which is a small, fast haskell interpreter. It is embeddable ( exposes a C api for embedding - it is written in C), supports many language extensions and can be stripped down (in terms of libraries) as far as you like, but is now often forgotten, overlooked in so far as haskell implementations go.

I'd love to use haskell as a configuration language, provide some combinators and effectively get the rest for free. But it is not acceptable for a user to go through the mess of installing a ghc environment on, say, Windows, only to change some settings.

...

2010/11/2 Lennart Augustsson mailto:lennart@augustsson.net>

I don't understand. Why don't you use Haskell as the scripting language?

On Tue, Nov 2, 2010 at 7:04 AM, Permjacov Evgeniy mailto:permeakra@gmail.com> wrote:

...

Let us think, that we need some scripting language for our pure haskell project and configure-compile-run is not a way. In such a case a reasonably simple, yet standartized and wide known language should be implemented. What such language may be? R(4/5/6)RS ? EcmaScript ? Some other ? _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto:Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto:Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Tue, 2 Nov 2010, Henning Thielemann wrote:

Yves Parès schrieb:

...

Because he would have either to recompile the whole program or to use things like hint, both implying that GHC must be installed on the user side (600Mo+ for GHC 6.12.3)

Hugs is great for running small Haskell "scripts".

I like to add: Especially 'runhugs' runs a Haskell program in contrast to the interactive session of 'hugs'. You can also run Haskell programs with 'runghc' but this needs more startup time and GHC certainly demands more resources.

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