Haskell and scripting

older
Mechanics of type-level proxies...

Limestraël

3 May 2010 3 May '10

12:51 p.m.

Hello Café, I don't know if you know conkyhttp://en.wikipedia.org/wiki/Conky_%28software%29. It's a well-known open-source system monitor (a software that displays information on the desktop, like CPU frequency, disk usage, network rate, etc.). It is quite good, but it's very descriptive, and even if you can call shell commands it's clearly not made for being scripted. What I would do is to make a similar system monitor, which base would be compiled Haskell code, but that would be scriptable with some DSL, or already existing interpreted language. I've thought about a Lisp/Scheme language, since those languages are functional, dynamically typed and simple (so enable a quick scripting) and I'm not very keen on making my own DSL What I would like to know is: 1) If you have other solutions 2) How do haskellers usually script their applications

Attachments:

attachment.html (text/html — 928 bytes)

Show replies by date

Martin Erwig

3 May 3 May

2:07 p.m.

One of my students has worked on scripting approach in Haskell: http://web.engr.oregonstate.edu/~erwig/papers/abstracts.html#SLE09 -- Martin On May 3, 2010, at 9:51 AM, Limestraël wrote:

...

Hello Café,

I don't know if you know conky. It's a well-known open-source system monitor (a software that displays information on the desktop, like CPU frequency, disk usage, network rate, etc.). It is quite good, but it's very descriptive, and even if you can call shell commands it's clearly not made for being scripted. What I would do is to make a similar system monitor, which base would be compiled Haskell code, but that would be scriptable with some DSL, or already existing interpreted language. I've thought about a Lisp/Scheme language, since those languages are functional, dynamically typed and simple (so enable a quick scripting) and I'm not very keen on making my own DSL

What I would like to know is: 1) If you have other solutions 2) How do haskellers usually script their applications _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

minh thu

4:29 p.m.

Hi, You can take the xmonad approach: the configuration file is written in Haskell and compiled, so no need for another language. Cheers, Thu 2010/5/3 Martin Erwig :

...

One of my students has worked on scripting approach in Haskell:

http://web.engr.oregonstate.edu/~erwig/papers/abstracts.html#SLE09

-- Martin

On May 3, 2010, at 9:51 AM, Limestraël wrote:

...
Hello Café,

I don't know if you know conky. It's a well-known open-source system monitor (a software that displays information on the desktop, like CPU frequency, disk usage, network rate, etc.). It is quite good, but it's very descriptive, and even if you can call shell commands it's clearly not made for being scripted. What I would do is to make a similar system monitor, which base would be compiled Haskell code, but that would be scriptable with some DSL, or already existing interpreted language. I've thought about a Lisp/Scheme language, since those languages are functional, dynamically typed and simple (so enable a quick scripting) and I'm not very keen on making my own DSL

What I would like to know is: 1) If you have other solutions 2) How do haskellers usually script their applications _______________________________________________ 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

Kyle Murphy

5:47 p.m.

That's also the approach Yi uses. I'm fairly certain there's a library on hackage that makes writing up programs in that style fairly trivial, although I can't remember the details right now. I'd look up Yi as a starting point. -R. Kyle Murphy -- Curiosity was framed, Ignorance killed the cat. On Mon, May 3, 2010 at 16:29, minh thu wrote:

...

Hi,

You can take the xmonad approach: the configuration file is written in Haskell and compiled, so no need for another language.

Cheers, Thu

2010/5/3 Martin Erwig :

...
One of my students has worked on scripting approach in Haskell:

http://web.engr.oregonstate.edu/~erwig/papers/abstracts.html#SLE09 http://web.engr.oregonstate.edu/%7Eerwig/papers/abstracts.html#SLE09

...
-- Martin

On May 3, 2010, at 9:51 AM, Limestraël wrote:

...
Hello Café,

I don't know if you know conky. It's a well-known open-source system

monitor (a software that displays information on the desktop, like CPU frequency, disk usage, network rate, etc.).

...
...
It is quite good, but it's very descriptive, and even if you can call shell commands it's clearly not made for being scripted. What I would do is to make a similar system monitor, which base would be compiled Haskell code, but that would be scriptable with some DSL, or already existing interpreted language. I've thought about a Lisp/Scheme language, since those languages are functional, dynamically typed and simple (so enable a quick scripting) and I'm not very keen on making my own DSL

What I would like to know is: 1) If you have other solutions 2) How do haskellers usually script their applications _______________________________________________ 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

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

Gwern Branwen

5:51 p.m.

On Mon, May 3, 2010 at 5:47 PM, Kyle Murphy wrote:

...

That's also the approach Yi uses. I'm fairly certain there's a library on hackage that makes writing up programs in that style fairly trivial,

http://hackage.haskell.org/package/dyre -- gwern

Limestraël

6:45 p.m.

Thank you all, that's very interesting. Martin, I've started reading the paper, I like the way you think about what a scripting language should provide ("traceability, error handling and a type system"). But, hold me if I'm wrong, but at no moment in the paper you made you own language? It's a EDSL, not a DSL, so I don't see where is the scripting, since the program will always have to be recompiled, won't it? Minh, Kyle, Gwern, the dyre approach seems to be very interesting too. But if I understood well, we also have to recompile at run-time the configuration haskell script? So the final application (Yi, for instance) will need GHC to be installed to run? Or did I miss something? By the way, I had never heard of Yi, but can I deduce from its name its a Vi(m)-like (which I am a big fan of)? Moreover, the idea of scripting my editor in Haskell appeals me. 2010/5/3 Gwern Branwen

...

On Mon, May 3, 2010 at 5:47 PM, Kyle Murphy wrote:

...
That's also the approach Yi uses. I'm fairly certain there's a library on hackage that makes writing up programs in that style fairly trivial,

http://hackage.haskell.org/package/dyre

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

Martin Erwig

11:38 p.m.

On May 3, 2010, at 3:45 PM, Limestraël wrote:

...

Thank you all, that's very interesting.

Martin, I've started reading the paper, I like the way you think about what a scripting language should provide ("traceability, error handling and a type system"). But, hold me if I'm wrong, but at no moment in the paper you made you own language? It's a EDSL, not a DSL,

That's correct. We have defined a DSEL, but in my view this is still a DSL; the "E" only refers to a specific way of implementing it.

...

so I don't see where is the scripting, since the program will always have to be recompiled, won't it?

I may have misunderstood your goals and what you mean by "scripting". Our DSEL is intended to be used for expressing all kinds of scripting tasks. -- Martin

Maciej Piechotka

4 May 4 May

1:52 a.m.

On Tue, 2010-05-04 at 00:45 +0200, Limestraël wrote:

...

Minh, Kyle, Gwern, the dyre approach seems to be very interesting too. But if I understood well, we also have to recompile at run-time the configuration haskell script? So the final application (Yi, for instance) will need GHC to be installed to run? Or did I miss something? By the way, I had never heard of Yi, but can I deduce from its name its a Vi(m)-like (which I am a big fan of)? Moreover, the idea of scripting my editor in Haskell appeals me.

1. Yi is more emacs-like in the internals (i.e. have embedded scripting language - Haskell - to configure. See emacs goodness on yi haskell wiki page) but on the skit it can use both emacs and yi style (or anything you happen to configure it with IIRC). 2. I haven't tried to run it w/out GHC but it recompiles it as it needs so if there is no change in configuration file and there is compiled program it just runs it. 3. It sounds better then it is IMHO. Don't get me wrong - Haskell is wonderful language and in syntax/libraries it suits scripting well. However GHC do not. After change of file you have to wait a long time as it compiles and links with yi. On my system (1 GB of RAM taken by system + 1 GB 'free' + 2 GB swaps, x86-64) it could in some situations it caused OOM. I'd prefer if the code was interpreted by ghci instead of compiled by GHC in this case (it should be as fast as most of the code was compiled anyway). Regards

Yitzchak Gale

5 May 5 May

11:05 a.m.

Maciej Piechotka wrote:

...

After change of file you have to wait a long time as it compiles and links with yi.

But Yi is a far bigger application than what Limestraël is talking about. One of my computers is very old and much less powerful than yours (let's just say that it has far less than 1 Gb memory in total). On that machine, xmonad, still much larger than Limestraël's app, recompiles its configuration file almost instantaneously. And of course, even that fast recompile only happens when I change the configuration, which is almost never. I would try the xmonad approach to scripting in Haskell. It is much simpler to implement than any of the others, and much neater if you find that it works well. Regards, Yitz

Limestraël

4:29 p.m.

Yes, the xmonad approach is very neat, but I see 2 major (IMO) drawbacks to it: 1) The end-user has to have GHC, and all the necessary libraries to compile the configuration 2) A scripting language should be simple and QUICK to learn : Haskell is clean, powerful but its learning takes time Uwe, I noticed kind of recently the haskeem package, I have not tried it yet and I didn't know its usability. If you say it's not made for that, then I believe you. 2010/5/5 Yitzchak Gale

...

Maciej Piechotka wrote:

...
After change of file you have to wait a long time as it compiles and links with yi.

But Yi is a far bigger application than what Limestraël is talking about. One of my computers is very old and much less powerful than yours (let's just say that it has far less than 1 Gb memory in total). On that machine, xmonad, still much larger than Limestraël's app, recompiles its configuration file almost instantaneously. And of course, even that fast recompile only happens when I change the configuration, which is almost never.

I would try the xmonad approach to scripting in Haskell. It is much simpler to implement than any of the others, and much neater if you find that it works well.

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

Kyle Murphy

5:18 p.m.

Concerning your second point, I think just about any functional language isn't going to be simple or quick to learn. It's simply not a way of approaching problems that your average person (even your average programmer) is used to dealing with. Things like fold and map, the work horses of functional programming, are simply too foreign to most peoples imperative way of approaching problems. -R. Kyle Murphy -- Curiosity was framed, Ignorance killed the cat. On Wed, May 5, 2010 at 16:29, Limestraël wrote:

...

Yes, the xmonad approach is very neat, but I see 2 major (IMO) drawbacks to it: 1) The end-user has to have GHC, and all the necessary libraries to compile the configuration 2) A scripting language should be simple and QUICK to learn : Haskell is clean, powerful but its learning takes time

Uwe, I noticed kind of recently the haskeem package, I have not tried it yet and I didn't know its usability. If you say it's not made for that, then I believe you.

2010/5/5 Yitzchak Gale

Maciej Piechotka wrote:

...
...
After change of file you have to wait a long time as it compiles and links with yi.

But Yi is a far bigger application than what Limestraël is talking about. One of my computers is very old and much less powerful than yours (let's just say that it has far less than 1 Gb memory in total). On that machine, xmonad, still much larger than Limestraël's app, recompiles its configuration file almost instantaneously. And of course, even that fast recompile only happens when I change the configuration, which is almost never.

I would try the xmonad approach to scripting in Haskell. It is much simpler to implement than any of the others, and much neater if you find that it works well.

Regards, Yitz _______________________________________________ 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

Limestraël

5:36 p.m.

I do agree, but you will not object if I say that scheme is quicker to learn than Haskell. Most of all, I think Haskell is far too rigorous to serve scripting purposes for my app. "Quick and dirty" is clearly not the Haskell way. And is think its the very intrinsic nature of scripting to be done fast. Nevertheless, I'm not a bigot ^^, if you people think Lua is an appropriate language for what I'm trying to do, and if it is convenient to use with Haskell, then I'm willing to give it a go. 2010/5/5 Kyle Murphy

...

Concerning your second point, I think just about any functional language isn't going to be simple or quick to learn. It's simply not a way of approaching problems that your average person (even your average programmer) is used to dealing with. Things like fold and map, the work horses of functional programming, are simply too foreign to most peoples imperative way of approaching problems.

-R. Kyle Murphy -- Curiosity was framed, Ignorance killed the cat.

On Wed, May 5, 2010 at 16:29, Limestraël wrote:

...
Yes, the xmonad approach is very neat, but I see 2 major (IMO) drawbacks to it: 1) The end-user has to have GHC, and all the necessary libraries to compile the configuration 2) A scripting language should be simple and QUICK to learn : Haskell is clean, powerful but its learning takes time

Uwe, I noticed kind of recently the haskeem package, I have not tried it yet and I didn't know its usability. If you say it's not made for that, then I believe you.

2010/5/5 Yitzchak Gale

Maciej Piechotka wrote:

...
...
After change of file you have to wait a long time as it compiles and links with yi.

But Yi is a far bigger application than what Limestraël is talking about. One of my computers is very old and much less powerful than yours (let's just say that it has far less than 1 Gb memory in total). On that machine, xmonad, still much larger than Limestraël's app, recompiles its configuration file almost instantaneously. And of course, even that fast recompile only happens when I change the configuration, which is almost never.

I would try the xmonad approach to scripting in Haskell. It is much simpler to implement than any of the others, and much neater if you find that it works well.

Regards, Yitz _______________________________________________ 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

Daniel Fischer

6:09 p.m.

On Wednesday 05 May 2010 23:36:26, Limestraël wrote:

...

but you will not object if I say that scheme is quicker to learn than Haskell.

Well, I do object. Learning Haskell went like a breeze (not to perfection, but well enough). Only Python was nearly as easy and quick to learn. Learning Lisp dialects is much harder (to a large part because of the parentheses, which makes them near impossible to parse).

Gregory Crosswhite

6:25 p.m.

On May 5, 2010, at 3:09 PM, Daniel Fischer wrote:

...

Learning Lisp dialects is much harder (to a large part because of the parentheses, which makes them near impossible to parse).

On the contrary, the whole point of parentheses is that it makes Lisp *easier* to parse... for computers. :-) Cheers, Greg

Ivan Miljenovic

8:24 p.m.

On 6 May 2010 08:25, Gregory Crosswhite wrote:

...

On May 5, 2010, at 3:09 PM, Daniel Fischer wrote:

...
Learning Lisp dialects is much harder (to a large part because of the parentheses, which makes them near impossible to parse).

On the contrary, the whole point of parentheses is that it makes Lisp *easier* to parse... for computers. :-)

With the added advantage of making it easier for text editors to do automatic indentation properly for precisely the same reason (this is probably the only flaw with Haskell's indentation-centric coding style). -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

Pierre-Etienne Meunier

9:49 p.m.

Fifty years ago someone came up with this idea of lisp and parentheses. By now in year 2010, I have never heard of any programmer who never made jokes about it. Now imagine the discussions in 2060 : - ahah, you're still programming with monads. lol - no but theyre ok for dirty scripting. - all these >>=, significative indentation, You're from the past dude. - Wtf !!? haskell's easy to compile. - So what ? ... good luck limestraël ;-) El 05/05/2010, a las 18:25, Gregory Crosswhite escribió:

...

On May 5, 2010, at 3:09 PM, Daniel Fischer wrote:

...
Learning Lisp dialects is much harder (to a large part because of the parentheses, which makes them near impossible to parse).

On the contrary, the whole point of parentheses is that it makes Lisp *easier* to parse... for computers. :-)

Cheers, Greg

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

Limestraël

6 May 6 May

10:32 a.m.

^^ That's an interesting debate: How do you imagine the future programming languages? But not today's topic. It's strange that, since Lisp is still used now, especially for teaching purposes, and since everybody complains about parenthesises, nobody developed a Lisp-like just based on indentation... To my mind, I think that as long as you lay out well your code, Lisp is quite readable. I don't see why the parenthesises would make it harder to learn. Daniel, prior to learn Haskell, did you know other functional languages? Cause I didn't, and let me tell you that the functional way of coding wasn't obvious while beginning (now I can't do without), especially the whole monad thing. Problem: Haskell without monads (or structures even more unusual, like Arrows) is no longer Haskell (can be subject to debate, too), so you have to get the point if you want to use properly the language. Or else you stuck to quicksort-like algorithms which show the beauty of the language, but not its power. 2010/5/6 Pierre-Etienne Meunier

...

Fifty years ago someone came up with this idea of lisp and parentheses. By now in year 2010, I have never heard of any programmer who never made jokes about it. Now imagine the discussions in 2060 :

- ahah, you're still programming with monads. lol - no but theyre ok for dirty scripting. - all these >>=, significative indentation, You're from the past dude. - Wtf !!? haskell's easy to compile. - So what ?

... good luck limestraël ;-)

El 05/05/2010, a las 18:25, Gregory Crosswhite escribió:

...
On May 5, 2010, at 3:09 PM, Daniel Fischer wrote:

...
Learning Lisp dialects is much harder (to a large part because of the parentheses, which makes them near impossible to parse).

On the contrary, the whole point of parentheses is that it makes Lisp

*easier* to parse... for computers. :-)

...
Cheers, Greg

_______________________________________________ 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

Daniel Fischer

11:10 a.m.

On Thursday 06 May 2010 16:32:50, Limestraël wrote:

...

^^ That's an interesting debate: How do you imagine the future programming languages? But not today's topic. It's strange that, since Lisp is still used now, especially for teaching purposes, and since everybody complains about parenthesises, nobody developed a Lisp-like just based on indentation...

Readable Lisp. Now, that could be an interesting language :)

...

To my mind, I think that as long as you lay out well your code, Lisp is quite readable. I don't see why the parenthesises would make it harder to learn.

It's idiosyncratic. I just don't manage to see through them. If you don't get distracted by the parentheses, good for you.

...

Daniel, prior to learn Haskell, did you know other functional languages?

No. Just some faint memories of Pascal from twenty years before and a bit of Java. Haskell just matched the natural way of thinking pretty closely. It might have something to do with the fact that I studied mathematics.

...

Cause I didn't, and let me tell you that the functional way of coding wasn't obvious while beginning (now I can't do without), especially the whole monad thing. Problem: Haskell without monads (or structures even more unusual, like Arrows) is no longer Haskell (can be subject to debate, too), so you have to get the point if you want to use properly the language. Or else you stuck to quicksort-like algorithms which show the beauty of the language, but not its power.

2010/5/6 Pierre-Etienne Meunier

...
Fifty years ago someone came up with this idea of lisp and parentheses. By now in year 2010, I have never heard of any programmer who never made jokes about it.

I don't remember ever making a joke about it. But I'm not a programmer, so I'm not a counterexample.

...

...
... good luck limestraël ;-)

Seconded.

Limestraël

12:17 p.m.

Don Cave said:

...

We've been through the generalities of this discussion before - is "map" hard, are "for" loops easy? what if you never learned an imperative language, does that make a difference, aren't functional languages the most natural because everyone knows about equations, ... etc.

Oh yes. The problem comes from the sole fact that -- generally -- we sadly start by the imperative paradigm. I now there are a few universities, in France, which teaches to the beginners Lisp or Ocaml, but they are not countless. Moreover, call me an integrist but beginning students are usually dumb (I was, so no offense): either they are stubborn and reject programmation whatever the language is, or they are geeks who swear by "regular" languages (*), mostly because gamemakers or software companies use them. They follow the crowd. Time to change some minds. But, hey, by swearing by functional programming I'm kind of a nonconformist geek, too. (*) Been there. I'm digressing. 2010/5/6 Daniel Fischer

...

Haskell just matched the natural way of thinking pretty closely.

I agree. Especially with datatypes. I personnaly don't think naturally in objects, with notions of inheritance and such. IMO, it is much more human to express in terms of alternatives. A door is either unlocked or locked with a key: data Door = Unlocked | Locked Key (maybe not the best example but it's just the one that went through my mind) 2010/5/6 Daniel Fischer

...

...
...
... good luck limestraël ;-)

Seconded.

I chose the Dyre method. The easy path. ^^ If I was trying to make a game, I should be trying hslua. Just sad I didn't find an easy way to script in functional (*). (*) Nonconformist geek hit again.

Donn Cave

11:08 a.m.

Quoth =?ISO-8859-1?Q?Limestra=EBl?= ,

...

That's an interesting debate: How do you imagine the future programming languages? But not today's topic.

I think you're in a position to make the premise much more interesting, by elaborating the kind of programming interface you want to expose. We've been through the generalities of this discussion before - is "map" hard, are "for" loops easy? what if you never learned an imperative language, does that make a difference, aren't functional languages the most natural because everyone knows about equations, ... etc. Oh, and let's talk about LISP and decide whether it's a success or failure! Scripting interfaces are an unusual twist, though. Different audience, different ambitions. Who would pick Tcl for a programming language? but it has been popular for scripting (still? don't know.) It would be interesting to look at some hypothetical examples that script your application, using Haskell vs. Lua or whatever. Haskell might look pretty good. For example, you'll probably expose some application data, and a programmer could easily be confused about whether a variable is application global data or not, or confused about whether operations on that variable are global in effect. I'm guessing this would turn out clearer in Haskell, along with other things having to do with "variables." Donn Cave, donn@avvanta.com

Brandon S. Allbery KF8NH

7 May 7 May

7:37 p.m.

On May 6, 2010, at 11:08 , Donn Cave wrote:

...

different ambitions. Who would pick Tcl for a programming language? but it has been popular for scripting (still? don't know.) It would

I think Lua has superseded it, because it has the compactness advantage and easy embeddability of of the Tcl core but is enormously easier to write code in. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Brandon S. Allbery KF8NH

7:31 p.m.

On May 5, 2010, at 21:49 , Pierre-Etienne Meunier wrote:

...

- all these >>=, significative indentation, You're from the past dude.

Careful, or Guido (van Rossum) is going to show up on your doorstep.... -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Pierre-Etienne Meunier

8:43 p.m.

Shit ! I'll have to explain him how to add monads in python 3 ;-) El 07/05/2010, a las 19:31, Brandon S. Allbery KF8NH escribió:

...

On May 5, 2010, at 21:49 , Pierre-Etienne Meunier wrote:

...
- all these >>=, significative indentation, You're from the past dude.

Careful, or Guido (van Rossum) is going to show up on your doorstep....

-- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Andy Stewart

9:07 p.m.

...

On Wednesday 05 May 2010 23:36:26, Limestraël wrote:

...
but you will not object if I say that scheme is quicker to learn than Haskell.

Well, I do object. Learning Haskell went like a breeze (not to perfection, but well enough). Only Python was nearly as easy and quick to learn. Learning Lisp dialects is much harder (to a large part because of the parentheses, which makes them near impossible to parse). Perhaps you need perfect lisp editor (emacs) to help you parse those

Daniel Fischer writes: parentheses. :) Looks below extension to highlight parentheses if you're emacser. It help you parse parentheses when you through *parentheses forest*. http://www.emacswiki.org/emacs/HighlightParentheses -- Andy

Maciej Piechotka

6 May 6 May

1:36 p.m.

On Wed, 2010-05-05 at 17:18 -0400, Kyle Murphy wrote:

...

Concerning your second point, I think just about any functional language isn't going to be simple or quick to learn. It's simply not a way of approaching problems that your average person (even your average programmer) is used to dealing with. Things like fold and map, the work horses of functional programming, are simply too foreign to most peoples imperative way of approaching problems.

-R. Kyle Murphy

Sorry - I wanted to respond to many posts in this thread but I choose the first post: 1. While doing fold/map may not be what is simple for average programmer I guess pattern matching/some HL functions can be relatively simple for others (pureness on the other hand do not). For example average person thinks "Add 1 to each element of list". Imperative way: for i = 0 to l.length: l[i] = l[i] + 1 # WTF? There is no x such that x = x + 1 Functional way: callOnEvery _ [] = [] callOnEvery f (x:xs) = f x:xs -- Built-in function 'map' -- Name could be 'better' add1 x = x + 1 add1ToEachElement xs = callOnEvery add1 xs Please note that I heard about person who wrote 'awesome game' in .exe file (definitely _declarative_ style of programming ;) ) and expected it to run ;) [Although fortunately it was 'hobbiest']. 2. Lisp readability depends much on formatting. While I cannot write LISP I'm usually able to read it) (defun hello-world () (format t "hello, world")) Is a merge between: def hello_world(): print "hello, world" and void hello_world() { println("hello, world") } Of course you can write obfuscation competition entries in LISP. 3. For the list of universities that first teaches functional programming - ICL begins with Haskell and from non-imperative languages Prolog is in the first year curriculum. Regards

Gwern Branwen

5 May 5 May

5:38 p.m.

On Wed, May 5, 2010 at 4:29 PM, Limestraël wrote:

...

Yes, the xmonad approach is very neat, but I see 2 major (IMO) drawbacks to it: 1) The end-user has to have GHC, and all the necessary libraries to compile the configuration 2) A scripting language should be simple and QUICK to learn : Haskell is clean, powerful but its learning takes time

For basic customization, many XMonad users (judging by questions on #xmonad) have little to no Haskell experience and get by. Further, it's easier to step down the power than to increase it; because we use Haskell, it's possible to have simpler configuration options like xmonad-light* * http://braincrater.wordpress.com/2008/08/28/announcing-xmonad-light/ isn't a very good explanation of xmonad-light, but I don't know of any others -- gwern

Limestraël

5:44 p.m.

Well, it is clear that, for me, the dyre approach is clearly the simplest to implement, since everything is in Haskell. Maybe I could start with it, and see if it suits me... (Sorry, I know, ^^ I keep changing my mind...) 2010/5/5 Gwern Branwen

...

On Wed, May 5, 2010 at 4:29 PM, Limestraël wrote:

...
Yes, the xmonad approach is very neat, but I see 2 major (IMO) drawbacks to it: 1) The end-user has to have GHC, and all the necessary libraries to compile the configuration 2) A scripting language should be simple and QUICK to learn : Haskell is clean, powerful but its learning takes time

For basic customization, many XMonad users (judging by questions on #xmonad) have little to no Haskell experience and get by. Further, it's easier to step down the power than to increase it; because we use Haskell, it's possible to have simpler configuration options like xmonad-light*

* http://braincrater.wordpress.com/2008/08/28/announcing-xmonad-light/ isn't a very good explanation of xmonad-light, but I don't know of any others

-- gwern

Brandon S. Allbery KF8NH

7 May 7 May

7:22 p.m.

On May 4, 2010, at 01:52 , Maciej Piechotka wrote:

...

After change of file you have to wait a long time as it compiles and links with yi. On my system (1 GB of RAM taken by system + 1 GB 'free' + 2 GB swaps, x86-64) it could in some situations it caused OOM. I'd prefer if the code was interpreted by ghci instead of compiled by GHC in this case (it should be as fast as most of the code was compiled anyway).

On the one hand, this is doable with the GHC API. On the other, that more or less means your program contains what amounts to a full copy of GHC. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Limestraël

7:51 p.m.

There is the package hint, which embeds the calls to GHC API. Quite easy to use: Let's say your configuration file (cfg/Script.hs) contains a function "script" that you want to get: type ScriptFun = IO () loadScript :: IO ScriptFun loadScript = do liftM (either (error . show) id) $ runInterpreter $ do path <- get searchPath set [searchPath := ("./cfg":path)] loadModules ["Script"] setTopLevelModules ["Script"] exports <- getModuleExports "Script" if Fun "script" `elem` exports then *interpret "script" (as :: ScriptFun)* else error "script function not found" There is just the line I put in bold that bothers me. Can't we get the action "script" more easily than by re-interpreting some code? 2010/5/8 Brandon S. Allbery KF8NH

...

On May 4, 2010, at 01:52 , Maciej Piechotka wrote:

...
After change of file you have to wait a long time as it compiles and links with yi. On my system (1 GB of RAM taken by system + 1 GB 'free' + 2 GB swaps, x86-64) it could in some situations it caused OOM. I'd prefer if the code was interpreted by ghci instead of compiled by GHC in this case (it should be as fast as most of the code was compiled anyway).

On the one hand, this is doable with the GHC API. On the other, that more or less means your program contains what amounts to a full copy of GHC.

-- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

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

Brandon S. Allbery KF8NH

8:12 p.m.

On May 7, 2010, at 19:51 , Limestraël wrote:

...

then interpret "script" (as :: ScriptFun)

There is just the line I put in bold that bothers me. Can't we get the action "script" more easily than by re-interpreting some code?

Make up your mind: you don't want to have to compile the script, but you don't want to have to interpret the script. What exactly is supposed to be left? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Pierre-Etienne Meunier

8:51 p.m.

There is a also a problem with polymorphic actions of functions. The GHC API is typesafe only when returning elements of the Typeable class. Else you can do an unsafeCoerce, but I assume that hint uses Typeable, with a wrapper class to ensure monomorphism. But if your "script" action returns a monomorphic type, you can use the GHC API directly instead and unsafeCoerce. El 07/05/2010, a las 20:12, Brandon S. Allbery KF8NH escribió:

...

On May 7, 2010, at 19:51 , Limestraël wrote:

...
then interpret "script" (as :: ScriptFun)

There is just the line I put in bold that bothers me. Can't we get the action "script" more easily than by re-interpreting some code?

Make up your mind: you don't want to have to compile the script, but you don't want to have to interpret the script. What exactly is supposed to be left?

-- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

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

Limestraël

10:18 p.m.

You might have misunderstood me. When using hint, one wants the script to be interpreted. It is interpreted when called " loadModules ["Script"] ", but if we call later " interpret *something* (as :: Something) ", the *something *can be any Haskell code, not just a function name, which means hint has also to interpret the *something*. So, IMO, a double interpretation is done when a function such as "getSymbol *functionName *(as :: FuncType)", which would simply get the function, would be sufficient. I don't know if hint/GHC API allows to do such a thing... 2010/5/8 Brandon S. Allbery KF8NH

...

On May 7, 2010, at 19:51 , Limestraël wrote:

then *interpret "script" (as :: ScriptFun)*

There is just the line I put in bold that bothers me. Can't we get the action "script" more easily than by re-interpreting some code?

Make up your mind: you don't want to have to compile the script, but you don't want to have to interpret the script. What exactly is supposed to be left?

-- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Brandon S. Allbery KF8NH

8 May 8 May

12:01 a.m.

On May 7, 2010, at 22:18 , Limestraël wrote:

...

When using hint, one wants the script to be interpreted. It is interpreted when called " loadModules ["Script"] ", but if we call later " interpret something (as :: Something) ", the something can be any Haskell code, not just a function name, which means hint has also to interpret the something.

Not entirely clear to me, actually: the earlier one might generate bytecode and the later one run it. (I haven't looked at hint, but have some idea of what GHC-API can do.)

...

So, IMO, a double interpretation is done when a function such as "getSymbol functionName (as :: FuncType)", which would simply get the function, would be sufficient. I don't know if hint/GHC API allows to do such a thing...

GHC API should let you look up names directly; as above, I don't know if hint does. hs-plugins used to do this also but it is obsolete (was far too dependent on GHC internal data and had to be rewritten for every GHC release; the GHC API is more stable). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Pierre-Etienne Meunier

7 May 7 May

8:47 p.m.

By the way, I do not know the GHC API well enough to say if it is possible to embed a super small bytecode interpreter, but : - If it is the case, then users who do not want to write scripts can use it. Others would want to compile haskell code, therefore they need GHC anyway. - If it is not, then a cool thing to do for the GHC team would be to add one ;-) In both cases, if someone on haskell-cafe knows the answer, could he write it on the wiki in the page about the ghc api ? Cheers, PE El 07/05/2010, a las 19:22, Brandon S. Allbery KF8NH escribió:

...

On May 4, 2010, at 01:52 , Maciej Piechotka wrote:

...
After change of file you have to wait a long time as it compiles and links with yi. On my system (1 GB of RAM taken by system + 1 GB 'free' + 2 GB swaps, x86-64) it could in some situations it caused OOM. I'd prefer if the code was interpreted by ghci instead of compiled by GHC in this case (it should be as fast as most of the code was compiled anyway).

On the one hand, this is doable with the GHC API. On the other, that more or less means your program contains what amounts to a full copy of GHC.

-- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

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

Evan Laforge

8 May 8 May

1:38 a.m.

...

On the one hand, this is doable with the GHC API. On the other, that more or less means your program contains what amounts to a full copy of GHC.

And the result is that your binary will grow by 35mb, add a few seconds to launch time, the first expression will take 3 or 4 seconds to evaluate, and add around 10 seconds to the link time. After that it's pretty reasonable though. I've actually thought of embedding a version of hugs, that should be smaller and faster, but as soon as you want to use significant amounts of libraries it gets to be a hassle to keep the source around and it may not even be hugs compatible anyway. GHC's big advantage is it can load the same binary libraries the rest of the program uses. I don't know if hugs was really designed to be embedded anyway.

Limestraël

23 May 23 May

9:40 a.m.

As some people were advising me to peek in Lua, I did so. Well, I find it far too laxist and bug prone : weak-typing, variables which are global by default, non-existing variables which contain nil when we access them instead of failing... I mean, I like Haskell especially because it is rigorous and because the type-system continually saves the day: Lua is the total opposite. I don't hope to enjoy Haskell's tightness with a scripting language, but being interpreted and dynamically typed doesn't prevent to be somewhat painstaking (Python is, for instance)**.

minh thu

4 May 4 May

3:15 a.m.

2010/5/4 Limestraël :

...

...

Minh, Kyle, Gwern, the dyre approach seems to be very interesting too. But if I understood well, we also have to recompile at run-time the configuration haskell script? So the final application (Yi, for instance) will need GHC to be installed to run? Or did I miss something? By the way, I had never heard of Yi, but can I deduce from its name its a Vi(m)-like (which I am a big fan of)? Moreover, the idea of scripting my editor in Haskell appeals me.

Yes GHC is needed. But if your goal is to produce something with the benefits of a complete language for configuration, I think it's fine. Numerous games include for instance a complete Lua interpreter, SketchUp includes a ruby interpreter (or maybe it is python), Blender uses python, Common Lisp programs can use Common Lisp, and so on. A complete language needs a complete implementation. If you want to make your own (non-embedded) DSL, you will either provide less than a "complete" language or have to implement a lot of stuff. Cheers, Thu

Limestraël

4:45 a.m.

...

A complete language needs a complete implementation.

No, Minh, I was not talking about re-implementing a whole Lisp/Scheme language interpreter in Haskell. (I know there is BTW a Scheme interpreter made in Haskell : http://jonathan.tang.name/files/scheme_in_48/tutorial/overview.html). But what I really wanted to know is how usually haskellers do to script their applications. For instance (as you say), many games made in C/C++ use Lua (for AI or for configuration). That is the kind of scripting I'm talking about : a compiled program (in Haskell) reading an interpreting a script (in some already existing interpreted language (*) or some DSL especially made for this purpose). (*) functional language, because I want to keep the benefit of functional programming for scripting. So no Lua, no Python...

...

I may have misunderstood your goals and what you mean by "scripting". Our DSEL is intended to be used for expressing all kinds of scripting tasks.

Martin, I did not understand your meaning of "scripting". IMO, a program can be scripted if it provides a way to alter (a part of) its configuration without having to recompile it entirely. If need be it recompiles the configuration files, but I think it's better if those files are interpreted (speeds up the program lauching, since it doesn't have to compile and link again (*)) (*) Yi, for instance, takes a little time to recompile its configuration, and when it re-links its executable, it weighs 38Mo! (and dynamic linking is still not perfect in Haskell) Plus, end-users have to install the compiler (GHC, which is not lightweight), even if they have the statically-linked executable of the application. 2010/5/4 minh thu

...

2010/5/4 Limestraël :

...
...

Minh, Kyle, Gwern, the dyre approach seems to be very interesting too. But if I understood well, we also have to recompile at run-time the configuration haskell script? So the final application (Yi, for instance) will need GHC to be installed to run? Or did I miss something? By the way, I had never heard of Yi, but can I deduce from its name its a Vi(m)-like (which I am a big fan of)? Moreover, the idea of scripting my editor in Haskell appeals me.

Yes GHC is needed. But if your goal is to produce something with the benefits of a complete language for configuration, I think it's fine. Numerous games include for instance a complete Lua interpreter, SketchUp includes a ruby interpreter (or maybe it is python), Blender uses python, Common Lisp programs can use Common Lisp, and so on.

A complete language needs a complete implementation.

If you want to make your own (non-embedded) DSL, you will either provide less than a "complete" language or have to implement a lot of stuff.

Cheers, Thu

Niclas W

5 May 5 May

4:40 a.m.

Limestraël writes:

...

(*) functional language, because I want to keep the benefit of functional programming for scripting. So no Lua, no Python...

You might want to take another look at lua. It is pretty darn functional. Also fast, small, and seems to be even easier to embed in haskell than in c.

Limestraël

8:36 a.m.

How do you embed Lua in Haskell? 2010/5/5 Niclas W

...

Limestraël writes:

...
(*) functional language, because I want to keep the benefit of functional programming for scripting. So no Lua, no Python...

You might want to take another look at lua. It is pretty darn functional. Also fast, small, and seems to be even easier to embed in haskell than in c.

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

Ivan Lazar Miljenovic

8:43 a.m.

Limestraël writes:

...

How do you embed Lua in Haskell?

http://hackage.haskell.org/package/hslua -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

Limestraël

8:58 a.m.

Thanks! However, I don't forget that my goal is to get a system monitor configuration language. Lua may have some functional components, it remains imperative, I think a more declarative language like Scheme would be more appropriate (and there is also a scheme interpreter, haskeem). What do you think about it? 2010/5/5 Ivan Lazar Miljenovic

...

Limestraël writes:

...
How do you embed Lua in Haskell?

http://hackage.haskell.org/package/hslua

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

Uwe Hollerbach

10:48 a.m.

As the author of haskeem, I'm thrilled that you are considering it, but to be honest I'm not quite sure it's embeddable in the way (I think) you want. If you want to give it a try, though, I'd be more than happy to try to help. best, Uwe On 5/5/10, Limestraël wrote:

...

Thanks!

However, I don't forget that my goal is to get a system monitor configuration language.

Lua may have some functional components, it remains imperative, I think a more declarative language like Scheme would be more appropriate (and there is also a scheme interpreter, haskeem). What do you think about it?

2010/5/5 Ivan Lazar Miljenovic

...
Limestraël writes:

...
How do you embed Lua in Haskell?

http://hackage.haskell.org/package/hslua

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

Bulat Ziganshin

8:59 a.m.

New subject: Re[2]: Re: Haskell and scripting

Hello Ivan, Wednesday, May 5, 2010, 4:43:48 PM, you wrote:

...

...
How do you embed Lua in Haskell? http://hackage.haskell.org/package/hslua

tutorial: http://haskell.org/haskellwiki/HsLua -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Bulat Ziganshin

4 May 4 May

9:41 a.m.

New subject: Re[2]: Haskell and scripting

Hello minh, Tuesday, May 4, 2010, 11:15:03 AM, you wrote:

...

Numerous games include for instance a complete Lua interpreter,

that's just one 100 kb dll :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

zaxis

3 May 3 May

8:07 p.m.

xmonad is my favorite WM. BTW, why canot i receive any email from its mailinglist (i have subscribed from http://www.haskell.org/mailman/listinfo/xmonad)? minh thu wrote:

...

Hi,

You can take the xmonad approach: the configuration file is written in Haskell and compiled, so no need for another language.

Cheers, Thu

2010/5/3 Martin Erwig :

...
One of my students has worked on scripting approach in Haskell:

http://web.engr.oregonstate.edu/~erwig/papers/abstracts.html#SLE09

-- Martin

On May 3, 2010, at 9:51 AM, Limestraël wrote:

...
Hello Café,

I don't know if you know conky. It's a well-known open-source system monitor (a software that displays information on the desktop, like CPU frequency, disk usage, network rate, etc.). It is quite good, but it's very descriptive, and even if you can call shell commands it's clearly not made for being scripted. What I would do is to make a similar system monitor, which base would be compiled Haskell code, but that would be scriptable with some DSL, or already existing interpreted language. I've thought about a Lisp/Scheme language, since those languages are functional, dynamically typed and simple (so enable a quick scripting) and I'm not very keen on making my own DSL

What I would like to know is: 1) If you have other solutions 2) How do haskellers usually script their applications _______________________________________________ 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

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

----- e(π⋅i) + 1 = 0 -- View this message in context: http://old.nabble.com/Haskell-and-scripting-tp28437468p28441722.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

Michael Lazarev

5 May 5 May

2:23 p.m.

I'm still not always sure how things are done in Haskell, but I'd like to propose another alternative, or, saying more correctly, I'd like to question how real this alternative is. What if scripting would be done with something like lambdabot, mueval or hint? Do scripts always need to be compiled?

Pierre-Etienne Meunier

3:27 p.m.

Actually lambdabot and mueval use the GHC api, and hint is supposed to be a wrapper around it. But using the API directly is quite simple, and the scripts are indeed compiled. I believe that the purpose of scripting an application is adding fun factor to it. How many haskell programmers are able to find fun in lua programming ? El 05/05/2010, a las 14:23, Michael Lazarev escribió:

...

I'm still not always sure how things are done in Haskell, but I'd like to propose another alternative, or, saying more correctly, I'd like to question how real this alternative is. What if scripting would be done with something like lambdabot, mueval or hint? Do scripts always need to be compiled? _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

5478

Age (days ago)

5498

Last active (days ago)

List overview

Download

47 comments

21 participants

participants (21)

Andy Stewart
Brandon S. Allbery KF8NH
Bulat Ziganshin
Daniel Fischer
Donn Cave
Evan Laforge
Gregory Crosswhite
Gwern Branwen
Ivan Lazar Miljenovic
Ivan Miljenovic
Kyle Murphy
Limestraël
Maciej Piechotka
Martin Erwig
Michael Lazarev
minh thu
Niclas W
Pierre-Etienne Meunier
Uwe Hollerbach
Yitzchak Gale
zaxis