Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-

Haskell Development

Name: Anonymous 2009-03-18 23:12

Hey /prog/, tell me things about Haskell.

How is Haskell's support for the type of interactive development that I, as a Lisper, demand? Sometimes I look at Haskell for a while but it has all kinds of syntax and I've gotten the impression that developing in Haskell requires a step backwards to batch compilation, so I give it a rest pretty quickly.

Could some nomads either confirm or disabuse me of my notions?

Name: Anonymous 2009-03-18 23:31

FUN FACT: Haskell used to be strictly an interpreted language.

It's very common to load a file into GHCi (with :load or :module +) and play around with the functions. That includes writing off-the-cuff tests for them. You'll see people doing this on IRC every so often if you lurk in #haskell, too.

Name: Anonymous 2009-03-18 23:33

>>2
Yes, I'm aware of the interpreter. I'm not asking if you can dick around in the interpreter for a while then write your program for real. I'm asking about Haskell's support for interactive development.

Name: Anonymous 2009-03-18 23:44

>>3
Define "interactive development." If you mean what I think you mean, you want to be able to define and redefine functions in the REPL until you have a complete running program, and then save that image to disk.

You can't do that in Haskell, unfortunately. It would be nice, though; ask a #haskell hacker to implement it.

Name: Anonymous 2009-03-18 23:59

I don't necessarily want to save that image to disk, although this can be useful. I'm happy enough using files to hold my code.

I do want to be able to load new code into my program as it runs, replace functions at any time, and load single functions from source files as I change them (this being more an editor feature). All this operating on my program in "finished form", so to speak, meaning compiled code (including code I load at run-time) and behavior otherwise identical to what I'd get from a production build.

Name: Anonymous 2009-03-19 0:09

>>5
You can :reload files that have been changed on disk. You can also launch an editor from within the interpreter, and load additional files as they become available. Note that you have to stick to "one module per file" in order for this to work; you can't write module Foo where ... foo = ... in one file, and then write bar = ... in another file, and load bar as a function in module Foo.

The other caveat you probably won't like is that there's always a chance that a bug in the compiler or the interpreter will cause compiled code and interpreted code to behave differently. This is rare, though, aside from the performance issues.

Name: Anonymous 2009-03-19 0:33

>>6
So what I'm getting is that you can either do interactive stuff in the interpreter (still having to load whole files at a time), or you can have compiled code, but you can't hack on a normal, compiled, running program?

Name: Anonymous 2009-03-19 0:42

>>7
Correct, you cannot "break into" a compiled, running program (or even a running function inside the interpreter) and modify it. You can provide hooks in your compiled program for evaluating interpreted code (it's still typechecked, naturally) and use that to modify data structures. However, you cannot redefine functions.

Name: Anonymous 2009-03-19 0:46

you can't hack on a normal, compiled, running program
What does this mean? You do know that compiled Haskell programs are executable binary programs. This is like asking if you can hack on a compiled C program while it's running: it's possible if that's what you really want.

Name: Anonymous 2009-03-19 0:51

>>9
You do know that compiled Haskell programs are executable binary programs.
This is where Lispfags give you that special, condescending smile, and tell you that compiled Lisp functions are just entities in the REPL like any other.

Name: Anonymous 2009-03-19 0:56

>>10
Oh, I was thinking about GHC binaries. Apparently, GHCi and Hugs can act as REPL interpreters.

Name: Anonymous 2009-03-19 1:05

>>11
But GHCi doesn't compile user modules down to machine code.

..... Does it?

Name: Anonymous 2009-03-19 1:07

>>12
Yes

Name: Anonymous 2009-03-19 1:08

>>13
OH SHI-

How do I enable that? It always says "interpreted"

Name: Anonymous 2009-03-19 1:44

>>14
by "interpreted", they mean compiled in memory and then run.
perl isn't really interpreted either.

Name: Anonymous 2009-03-19 1:50

>>15
Perl is compiled to bytecode, and the bytecode is executed on a slow VM. I assumed the same was true of GHCi.

Name: Anonymous 2009-03-19 1:56

>>13
This thread is suddenly interesting. I would like to know more about this.

Name: Anonymous 2009-03-19 2:20

>>17
JOIN #haskell

Name: Anonymous 2009-03-19 2:28

>>13
Loading your files in ghci still does not produce compiled binaries on disk

Name: Anonymous 2009-03-19 2:40

>>19
Who cares if they're on disk?

Name: Anonymous 2009-03-19 2:40

>>18
Absolutely not.

Name: Anonymous 2009-03-19 2:44

>>21
It is egregious to resist

#haskell and /prog/ will soon be as one

Name: Anonymous 2009-03-19 3:12

>>22
It is egregious to resist
I find something unsettling about this wording. However I barely Usenet, and I definitely have not gotten into this IRC thing.

Name: Anonymous 2009-03-19 3:37

>>19
Of course it does.  Are you illiterate?

Name: Anonymous 2009-03-19 10:49

>>22
Over my dead dog

Name: Anonymous 2009-03-19 10:51

>>22
Over my dead dog

Name: Anonymous 2009-03-19 12:14

>>23
That wording isn't horrorshow, but it effects change
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode -