How easy would it be to make / would anybody care / has somebody already made ... in Haskell? - Blogging software. (Because there isn't enough of it in the world yet.) - A wiki program. (Ditto.) - A general CMS. - An interactive function plotter. (GNUplot is nice, but it can't plot recursive functions...) - A "graphical programming tool". (You add boxes and put in lines, it constructs a "program" that you can run.)
Hi
- Blogging software. (Because there isn't enough of it in the world yet.)
Hope (google: Haskell Hope)
- A wiki program. (Ditto.)
Flippi (google: Haskell Flippi)
- A general CMS.
Hope
- An interactive function plotter. (GNUplot is nice, but it can't plot recursive functions...)
None that I know of.
- A "graphical programming tool". (You add boxes and put in lines, it constructs a "program" that you can run.)
You mean a programming tool with a horrible syntax and user interface? If you want to remove the joy from programming, just use Ada. Alternatively, use PureData, which can be extended with Haskell, and gives boxes and lines. http://haskell.org/haskellwiki/AngloHaskell/2007#Abstracts Thanks Neil
Neil Mitchell wrote:
- A wiki program. (Ditto.)
Flippi (google: Haskell Flippi)
...and yet haskell.org uses WikiMedia? (Which is written in something bizzare like Perl...)
- A general CMS.
Hope
Woo! I'll have to go play with this for a while...
- An interactive function plotter. (GNUplot is nice, but it can't plot recursive functions...)
None that I know of.
Mmm, OK. I would have thought it would be a nice project for somebody...
- A "graphical programming tool". (You add boxes and put in lines, it constructs a "program" that you can run.)
You mean a programming tool with a horrible syntax and user interface?
LOL! That's not entirely what I meant... ;-) Have you ever played with KLogic? You draw boxes and lines, and it makes some logic. (As in the digital electronics sense of "logic".) I have some (very expensive) software called Reaktor. You draw boxes and lines, it does DSP algorithms. You build synthesizers and effects boxes with it. You get the idea. (The trouble with KLogic is its utter buggyness... I'd love to have a tool like it that actually works properly!)
If you want to remove the joy from programming, just use Ada.
Or Perl. Or Java. Or C. Or C++. Or VB. Or...
Alternatively, use PureData, which can be extended with Haskell, and gives boxes and lines. http://haskell.org/haskellwiki/AngloHaskell/2007#Abstracts
OK, I'll take a cool.
Hi
Flippi (google: Haskell Flippi)
...and yet haskell.org uses WikiMedia? (Which is written in something bizzare like Perl...)
Yes, but WikiMedia is a result of years of work, Flippi is a lot less. Wikipedia uses WikiMedia - its a tried and proven solution.
- A "graphical programming tool". (You add boxes and put in lines, it constructs a "program" that you can run.)
Have you ever played with KLogic? You draw boxes and lines, and it makes some logic. (As in the digital electronics sense of "logic".)
I have some (very expensive) software called Reaktor. You draw boxes and lines, it does DSP algorithms. You build synthesizers and effects boxes with it.
That sounds exactly like PureData - you can also do graphics as well with PureData, the demo I saw was very cool. Of course, PureData is written in C with Haskell as an extension language. The last two ideas you mentioned require a graphical user interface, which is an area of Haskell which is comparatively weak, compared to the rest of Haskell. Thanks Neil PS: Apologies to Andrew for 2 copies of this message.
On Sat, 25 Aug 2007, Neil Mitchell wrote:
Hi
Flippi (google: Haskell Flippi)
...and yet haskell.org uses WikiMedia? (Which is written in something bizzare like Perl...)
Yes, but WikiMedia is a result of years of work, Flippi is a lot less.
The original version was the result of a certain amount of thinking, an overnight hack and a few tweaks :-)
Have you ever played with KLogic? You draw boxes and lines, and it makes some logic. (As in the digital electronics sense of "logic".)
I have some (very expensive) software called Reaktor. You draw boxes and lines, it does DSP algorithms. You build synthesizers and effects boxes with it.
That sounds exactly like PureData - you can also do graphics as well with PureData, the demo I saw was very cool. Of course, PureData is written in C with Haskell as an extension language.
Reaktor is rather nicer to use than PureData though, in that it's designed to work with mainstream sequencers (or any VST - I work with trackers myself) and be used by non-hackers. Also, I'm not entirely sure it's fair to say that it has Haskell as an extension language as such - but Claude's slides'll give a better explanation than I can.
The last two ideas you mentioned require a graphical user interface, which is an area of Haskell which is comparatively weak, compared to the rest of Haskell.
Yep. It would be nice to have a library for doing that kind of stuff though, I suspect there're many nifty projects that would be easy to implement once that was done - Haskell's good at manipulating the underlying structures. -- flippa@flippac.org "The reason for this is simple yet profound. Equations of the form x = x are completely useless. All interesting equations are of the form x = y." -- John C. Baez
Philippa Cowderoy wrote:
I have some (very expensive) software called Reaktor. You draw boxes and lines, it does DSP algorithms. You build synthesizers and effects boxes with it.
That sounds exactly like PureData - you can also do graphics as well with PureData, the demo I saw was very cool. Of course, PureData is written in C with Haskell as an extension language.
Reaktor is rather nicer to use than PureData though, in that it's designed to work with mainstream sequencers (or any VST - I work with trackers myself) and be used by non-hackers. Also, I'm not entirely sure it's fair to say that it has Haskell as an extension language as such - but Claude's slides'll give a better explanation than I can.
Reaktor has a few limitations though. 1. It's virtually impossible to debug the thing! (I.e., if your synth doesn't work... good luck working out why.) 2. It lacks looping capabilities. For example, you cannot build a variable-size convolution block - only a fixed-size one. (If you want to draw *a lot* of wires!) If you look through the standard library, you'll find no end of instruments that use a "hack" of using voice polyphony to crudely simulate looping... but it's not too hot. Would be nice if I could build something in Haskell that overcomes these. OTOH, does Haskell have any way to talk to the audio hardware?
Reaktor has a few limitations though.
1. It's virtually impossible to debug the thing! (I.e., if your synth doesn't work... good luck working out why.)
2. It lacks looping capabilities. For example, you cannot build a variable-size convolution block - only a fixed-size one. (If you want to draw *a lot* of wires!) If you look through the standard library, you'll find no end of instruments that use a "hack" of using voice polyphony to crudely simulate looping... but it's not too hot.
Would be nice if I could build something in Haskell that overcomes these. OTOH, does Haskell have any way to talk to the audio hardware?
Nyquist is a music language from a whlie back that I liked (in theory, not so much in practice). It has a functional model in that "instruments" are just functions that return sample streams, so there's no difference between signal processing and signal generating functions (or orchestra and score, for the csounders out there). This was made efficient by lazily evaluating the streams and some custom hackery where it would e.g. notice that one signal going into (+) had ended and simply unlink the entire operation from the call graph, and some gc hackery to reclaim sound blocks quickly. The other interesting feature was "behaviours" which were just dynamically scoped variables that would propagate down to the nearest function that cared to interpret them, e.g. (transpose 5 (seq (melody 1) (melody 2))) would transpose the tones generated by (melody) by setting a dynamic variable that would later be read by the underlying oscillators or whatever that melody used. "seq" used the mechanism to shift or scale the beginnings end endings of notes. It was also more powerful than e.g. csound, supecollider, or reaktor style languages because in the former you have to compile a static call graph (the "orchestra") and then "play" it with signals dynamically (the "score"), whereas in nyquist there's no orchestra and score division. The disadvantage is that the immutable signals made it hard to implement real-time synthesis. The practical problem was that it was implemented in a hacked up XLisp which was primitive and hard to debug. Added to that, you had to be careful to wrap signals in functions or macros so the eager interpreter wouldn't evaluate the whole signal and kill performance. To get this back to haskell, at the time I wondered if a more natural implementation might be possible in haskell, seeing as it was more naturally lazy. Not sure how to implement the behaviours though (which were simply macros around a let of *dynamic-something*). I'm sure people have done plenty of signal processing, and there's always haskore... but what about a sound generation language like csound or clm or nyquist? It could fit in nicely below haskore. Also, as another reaktor user I agree it would have been so much nicer were it simply a real language. Drawing those boxes and lines and the complete lack of abstraction (beyond copy and paste) is a real pain. Supercollider is more promising in that way, but less polished of course. It also has that two-level imperative model though where you create and modify your signal graph with imperative techniques, then run it, rather than your program *being* the signal graph.
Evan Laforge wrote:
To get this back to haskell, at the time I wondered if a more natural implementation might be possible in haskell, seeing as it was more naturally lazy. Not sure how to implement the behaviours though (which were simply macros around a let of *dynamic-something*). I'm sure people have done plenty of signal processing, and there's always haskore... but what about a sound generation language like csound or clm or nyquist? It could fit in nicely below haskore.
Indeed, you can write certain DSP algorithms beautifully in Haskell. Now, if only it could talk to the audio hardware... (Or just use common file formats even.)
Also, as another reaktor user I agree it would have been so much nicer were it simply a real language. Drawing those boxes and lines and the complete lack of abstraction (beyond copy and paste) is a real pain. Supercollider is more promising in that way, but less polished of course. It also has that two-level imperative model though where you create and modify your signal graph with imperative techniques, then run it, rather than your program *being* the signal graph.
Reaktor has abstraction. You can build a gizmo that does something useful, call it a macro, and then use it whereever you want. If you want to build a gizmo that takes a siganl "x" and computes "8*x*x*x - 8*x*x + 1" (i.e., the 4th Chebyshev polynomial), you've going to have to draw *a lot* of wires! It would be nice if there was some feature for quickly building complicated chunks of pure algebra like that. It would also be nice if there were some way to *programmatically* construct the graph... but never mind. (Maybe in Reaktor 6?)
Indeed, you can write certain DSP algorithms beautifully in Haskell. Now, if only it could talk to the audio hardware... (Or just use common file formats even.)
Oh, that's easy. I wrote an FFI interface to portaudio a while back to write a delay-looping type utility in haskell. It was pretty trivial. You could do the same for libsndfile or whatever. The only thing I'm uncertain about is whether it would have good enough time and space performance. All the real work is writing yet another set of basic envelope, oscillator, and fft primitives. You *should* be able to go all the way down to the samples in pure haskell though, which would be more elegant than those other languages :)
Reaktor has abstraction. You can build a gizmo that does something useful, call it a macro, and then use it whereever you want.
Well, except that if you then change your macro you have re-copy it into every instrument or ensemble or other macro that uses it. So I consider the macros basically a copy and paste mechanism.
Evan Laforge writes:
Indeed, you can write certain DSP algorithms beautifully in Haskell. Now, if only it could talk to the audio hardware... (Or just use common file formats even.)
Oh, that's easy. I wrote an FFI interface to portaudio a while back to write a delay-looping type utility in haskell. It was pretty trivial. You could do the same for libsndfile or whatever.
The only thing I'm uncertain about is whether it would have good enough time and space performance. All the real work is writing yet another set of basic envelope, oscillator, and fft primitives. You *should* be able to go all the way down to the samples in pure haskell though, which would be more elegant than those other languages :)
== Well, if you want to see what you can do with a lazy functional language, not necessarily Haskell, but Clean (sorry for advertizing a competitor on this list...), perhaps have a look on my PADL paper http://users.info.unicaen.fr/~karczma/arpap/cleasyn.pdf I generated .wav files as output, from lazy streams, so the sound was off-line. My ambition was to code in a very, very compact way some musical instruments, with looping replaced by co-recursion. It cannot be extremely efficient, but it seems quite elegant and powerful. Jerzy Karczmarczuk
On Sat, 2007-08-25 at 23:36 +0200, jerzy.karczmarczuk@info.unicaen.fr wrote:
Evan Laforge writes:
Indeed, you can write certain DSP algorithms beautifully in Haskell. Now, if only it could talk to the audio hardware... (Or just use common file formats even.)
Oh, that's easy. I wrote an FFI interface to portaudio a while back to write a delay-looping type utility in haskell. It was pretty trivial. You could do the same for libsndfile or whatever.
The only thing I'm uncertain about is whether it would have good enough time and space performance. All the real work is writing yet another set of basic envelope, oscillator, and fft primitives. You *should* be able to go all the way down to the samples in pure haskell though, which would be more elegant than those other languages :)
==
Well, if you want to see what you can do with a lazy functional language, not necessarily Haskell, but Clean (sorry for advertizing a competitor on this list...), perhaps have a look on my PADL paper
http://users.info.unicaen.fr/~karczma/arpap/cleasyn.pdf
I generated .wav files as output, from lazy streams, so the sound was off-line. My ambition was to code in a very, very compact way some musical instruments, with looping replaced by co-recursion. It cannot be extremely efficient, but it seems quite elegant and powerful.
Last week I did exactly that. Using lazy streams and a quickly hacked up .wav file output, I played with some of the extended Karplus-Strong plucked string/drum synthesis algorithms.
Evan Laforge wrote:
Indeed, you can write certain DSP algorithms beautifully in Haskell. Now, if only it could talk to the audio hardware... (Or just use common file formats even.)
Oh, that's easy. I wrote an FFI interface to portaudio a while back to write a delay-looping type utility in haskell. It was pretty trivial. You could do the same for libsndfile or whatever.
Well, since I can't do C... (What I typically end up doing in these situations is to write a small server program in some language that *does* have the feature I want, and then talk to it over TCP from the language that *doesn't* have the feature. But it's typically quite a lot of typing... and the only language I know of that supports sound (other than C) is Java. And it's *very* complicated...)
The only thing I'm uncertain about is whether it would have good enough time and space performance. All the real work is writing yet another set of basic envelope, oscillator, and fft primitives. You *should* be able to go all the way down to the samples in pure haskell though, which would be more elegant than those other languages :)
Heh. FFT is tricky. But I got it to work one time... ;-)
Reaktor has abstraction. You can build a gizmo that does something useful, call it a macro, and then use it whereever you want.
Well, except that if you then change your macro you have re-copy it into every instrument or ensemble or other macro that uses it. So I consider the macros basically a copy and paste mechanism.
True, true...
On Sun, 26 Aug 2007, Andrew Coppin wrote:
The only thing I'm uncertain about is whether it would have good enough time and space performance. All the real work is writing yet another set of basic envelope, oscillator, and fft primitives. You *should* be able to go all the way down to the samples in pure haskell though, which would be more elegant than those other languages :)
Heh. FFT is tricky. But I got it to work one time... ;-)
There's already an extensive FFT implementation in Haskell by Matt Donadio: http://haskelldsp.sourceforge.net/ (I'm working on some clean up at http://darcs.haskell.org/dsp/Numeric/Transform/Fourier/ )
Evan Laforge wrote:
The only thing I'm uncertain about is whether it would have good enough time and space performance. All the real work is writing yet another set of basic envelope, oscillator, and fft primitives. You *should* be able to go all the way down to the samples in pure haskell though, which would be more elegant than those other languages :)
I've been playing with using Arrows as stream processors for audio, and the dataflow syntax of arrows is quite nice for sample manipulation: -- low pass filter (1-zero)
lop i = proc (x, f) -> do sr <- readState -< SampleRate let c = clip (2 * pi * f / sr) 0 1 rec y <- delay i -< o let o = x * c + (1 - c) * y returnA -< o
lop :: (ArrowCircuit a, ArrowReader b a, Floating b, Ord b) => b -> a (b, b) b
Unfortunately it's *very* slow - to render a 5s sine oscillator sweep from 20Hz to 20000Hz through a low pass filter at 44100Hz sampling rate takes around 17s. Admittedly 40% of the time is spent outputting the numbers to a text file, but it's still far far from realtime, and churns through 7GB of memory in the process (the total memory usage at any one time is constant and small, however). Claude -- http://claudiusmaximus.goto10.org
On Sat, 25 Aug 2007, Andrew Coppin wrote:
Evan Laforge wrote:
To get this back to haskell, at the time I wondered if a more natural implementation might be possible in haskell, seeing as it was more naturally lazy. Not sure how to implement the behaviours though (which were simply macros around a let of *dynamic-something*). I'm sure people have done plenty of signal processing, and there's always haskore... but what about a sound generation language like csound or clm or nyquist? It could fit in nicely below haskore.
Indeed, you can write certain DSP algorithms beautifully in Haskell. Now, if only it could talk to the audio hardware... (Or just use common file formats even.)
I invoke a variety of sound converters/players (sox, alsaplayer, ecasound) in order to fix this problem. Writing and playing this way is easy. Reading files is problematic because the converters cannot output header information. 'http://darcs.haskell.org/synthesizer/src/Sox/File.hs' 'http://darcs.haskell.org/synthesizer/src/Sox/Play.hs' 'http://darcs.haskell.org/dafx/src/Presentation.hs'
On Sat, 25 Aug 2007, Evan Laforge wrote:
Reaktor has a few limitations though.
1. It's virtually impossible to debug the thing! (I.e., if your synth doesn't work... good luck working out why.)
2. It lacks looping capabilities. For example, you cannot build a variable-size convolution block - only a fixed-size one. (If you want to draw *a lot* of wires!) If you look through the standard library, you'll find no end of instruments that use a "hack" of using voice polyphony to crudely simulate looping... but it's not too hot.
Would be nice if I could build something in Haskell that overcomes these. OTOH, does Haskell have any way to talk to the audio hardware?
...
To get this back to haskell, at the time I wondered if a more natural implementation might be possible in haskell, seeing as it was more naturally lazy. Not sure how to implement the behaviours though (which were simply macros around a let of *dynamic-something*). I'm sure people have done plenty of signal processing, and there's always haskore... but what about a sound generation language like csound or clm or nyquist? It could fit in nicely below haskore.
I'm playing around with Haskore controlling signal synthesis implemented in pure Haskell for some time now: http://darcs.haskell.org/synthesizer/src/Haskore/Interface/Signal/ It works, but it's still slow and hard to install. This discussion is certainly also of interest for the haskell-art mailing list. http://lists.lurk.org/mailman/listinfo/haskell-art
On Sat, 25 Aug 2007, Andrew Coppin wrote:
Would be nice if I could build something in Haskell that overcomes these. OTOH, does Haskell have any way to talk to the audio hardware?
It would definitely be nice if someone wrote a binding to the VST SDK or a wrapper for it. Unfortunately I suspect it's too windows-specific for most of those on the list, and there isn't a sufficiently good portable and widely-used/available alternative. -- flippa@flippac.org "The reason for this is simple yet profound. Equations of the form x = x are completely useless. All interesting equations are of the form x = y." -- John C. Baez
On Sat, 2007-08-25 at 22:51 +0100, Philippa Cowderoy wrote:
On Sat, 25 Aug 2007, Andrew Coppin wrote:
Would be nice if I could build something in Haskell that overcomes these. OTOH, does Haskell have any way to talk to the audio hardware?
It would definitely be nice if someone wrote a binding to the VST SDK or a wrapper for it. Unfortunately I suspect it's too windows-specific for most of those on the list, and there isn't a sufficiently good portable and widely-used/available alternative.
I recently wrote a binding to LADSPA. I just need to finish packaging it and upload it to Hackage.
On Sat, 25 Aug 2007, Andrew Coppin wrote:
Would be nice if I could build something in Haskell that overcomes these. OTOH, does Haskell have any way to talk to the audio hardware?
Maybe a JACK interface? http://haskell.org/haskellwiki/Applications_and_libraries/Music_and_sound
On Saturday 25 August 2007 20:49, Andrew Coppin wrote:
[...] Would be nice if I could build something in Haskell that overcomes these. OTOH, does Haskell have any way to talk to the audio hardware?
Depending on what you are exactly trying to do, the OpenAL/ALUT packages might be of interest. Slighty dated online docs are here: http://haskell.org/HOpenGL/newAPI/OpenAL/Sound-OpenAL.html http://haskell.org/HOpenGL/newAPI/ALUT/Sound-ALUT.html Cheers, S.
On Sat, 25 Aug 2007, Andrew Coppin wrote:
Neil Mitchell wrote:
- A wiki program. (Ditto.)
Flippi (google: Haskell Flippi)
...and yet haskell.org uses WikiMedia? (Which is written in something bizzare like Perl...)
Flippi is... rather minimalistic. And fugly. You can tell it was written by someone who has trouble getting things done! I get the impression it did a certain amount of good as a proof of concept and a reminder that doing things the old-fashioned way still works though.
- A general CMS.
Hope
Woo! I'll have to go play with this for a while...
While I haven't looked at it much, Hope's seeing a lot more actual use. -- flippa@flippac.org Society does not owe people jobs. Society owes it to itself to find people jobs.
Philippa Cowderoy wrote:
Flippi is... rather minimalistic. And fugly. You can tell it was written by someone who has trouble getting things done! I get the impression it did a certain amount of good as a proof of concept and a reminder that doing things the old-fashioned way still works though.
Ah yes, nothing like a good proof-of-concept implementation. Except that you usually can't do any "real" stuff with it. ;-) Some of you may remember a few years back, it seemed that Java was a programming language invented for implementing Tic-Tac-Toe programs...
- A "graphical programming tool". (You add boxes and put in lines, it constructs a "program" that you can run.)
You mean a programming tool with a horrible syntax and user interface? If you want to remove the joy from programming, just use Ada.
For programmers or scientists, I agree. For designers/artists who want to make cool stuff without learning a textual programming language, I totally disagree. Look at Apple Shake, SideFX Houdini, Werkzeug, Shader FX, Unreal 3, or even National Instruments Labview, and more... They all have a (albeit very limited) visual programming language. People get real "procedural" work done with these tools. Almost every 3D movie uses at least one of tools I mentioned. Peter
- A "graphical programming tool". (You add boxes and put in lines, it constructs a "program" that you can run.)
I'm not entirely exactly sure what you mean by this. If you mean one can create programs by creating them visually then perhaps you could consider Vital: http://www.cs.kent.ac.uk/projects/vital/ It's a document-centered implementation of Haskell. Allowing one to display and directly manipulate Haskell data structures in real-time. Chris.
C.M.Brown wrote:
- A "graphical programming tool". (You add boxes and put in lines, it constructs a "program" that you can run.)
I'm not entirely exactly sure what you mean by this.
I wasn't especially specific about it, that's true enough. I actually had several different things in mind...
If you mean one can create programs by creating them visually then perhaps you could consider Vital:
http://www.cs.kent.ac.uk/projects/vital/
It's a document-centered implementation of Haskell. Allowing one to display and directly manipulate Haskell data structures in real-time.
Looks very interesting... and very low-tech visuals. :-/
Andrew Coppin wrote:
C.M.Brown wrote:
If you mean one can create programs by creating them visually then perhaps you could consider Vital:
http://www.cs.kent.ac.uk/projects/vital/
It's a document-centered implementation of Haskell. Allowing one to display and directly manipulate Haskell data structures in real-time.
Looks very interesting... and very low-tech visuals. :-/
Hang on a minute... it's written in Java... and it can run Haskell code...? o_O Now that's interesting! (Re. the other thread about "we should have an automatic expression reducing program"...)
I tried vital, and at first sight it is very nice, but they only support a very limited subset of Haskell, perform no type checking at all, don't support the indent rule, etc... Anyway it is an amazing piece of work. Regarding your question about visual programming, GEM Cutter from the Open Quark Framework is also nice. http://labs.businessobjects.com/cal. But they also wrote their own Haskell98 (with some Hugs extension) compiler in... Java. Cheers, Peter Verswyvelen -----Original Message----- From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Andrew Coppin Sent: Saturday, August 25, 2007 9:37 PM To: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Ideas Andrew Coppin wrote:
C.M.Brown wrote:
If you mean one can create programs by creating them visually then perhaps you could consider Vital:
http://www.cs.kent.ac.uk/projects/vital/
It's a document-centered implementation of Haskell. Allowing one to display and directly manipulate Haskell data structures in real-time.
Looks very interesting... and very low-tech visuals. :-/
Hang on a minute... it's written in Java... and it can run Haskell code...? o_O Now that's interesting! (Re. the other thread about "we should have an automatic expression reducing program"...) _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Peter Verswyvelen wrote:
I tried vital, and at first sight it is very nice, but they only support a very limited subset of Haskell, perform no type checking at all, don't support the indent rule, etc... Anyway it is an amazing piece of work.
Regarding your question about visual programming, GEM Cutter from the Open Quark Framework is also nice. http://labs.businessobjects.com/cal. But they also wrote their own Haskell98 (with some Hugs extension) compiler in... Java.
Cheers, Peter Verswyvelen
Vital seems to have a really damn nice concept behind it. The visuals don't look quite so hot though... ;-) If I could figure out how to do the whole "drag boxes around, draw lines" stuff with Gtk2hs, I might have a go at bettering this myself... but that's unlikely. GEM Cutter also falls into the category of "hey, that's interesting, I should go find out about this stuff..." ;-)
I tried vital, and at first sight it is very nice, but they only support a very limited subset of Haskell, perform no type checking at all, don't support the indent rule, etc... Anyway it is an amazing piece of work.
I believe that type-sensitive manipulation was certainly being investigated; however, I can't confirm as to how far it *was* investigated. What intriged me mostly was how it can display infinite data structures lazily. I think it's certainly a great tool for teaching some aspects of functional programming: helping newbies to understand and define data structures, say. Chris.
What intriged me mostly was how it can display infinite data structures lazily. I think it's certainly a great tool for teaching some aspects of functional programming: helping newbies to understand and define data Structures, say.
Definitely! It's really cool stuff. But something like that for real Haskell (e.g. GHC) would be even better :) I could be an offline downloadable application. It would be a very nice tool: create postscript (or PDF, or LaTex, whatever rich text format) documents with Haskell "boxes" inside. Real literate programming... Oh well ;)
Definitely! It's really cool stuff. But something like that for real Haskell (e.g. GHC) would be even better :) I could be an offline downloadable application. It would be a very nice tool: create postscript (or PDF, or LaTex, whatever rich text format) documents with Haskell "boxes" inside. Real literate programming... Oh well ;)
I would personally say Haskell 98 is "real" Haskell (well, until Haskell Prime comes out). It becomes difficult for tool developers to cater for non-standard languages; Haskell is quite complicated enough without having to cater for all the little nuances and idiomatic extensions that are constantly added with each release of a compiler. I believe it does work as an offline downloadable tool... http://www.cs.kent.ac.uk/projects/vital/install/index.html Chris.
Chris wrote:
I would personally say Haskell 98 is "real" Haskell (well, until Haskell... I believe it does work as an offline downloadable tool... http://www.cs.kent.ac.uk/projects/vital/install/index.html
With "real Haskell" I ment strong type checking and indentation for determining scope; without the former, it becomes a different experience IMO. Avoiding runtime errors because types don't match is one the main advantages of Haskell; without this, I'm afraid it is difficult to get a good feeling of the Haskell programming language, be it Haskell98 Peter
- Blogging software. (Because there isn't enough of it in the world yet.)
In addition (because a little competition can't help ;), I'm going to be experimenting with writing a blog engine for my final year project at Uni next year - 2007/08. Hopefully some good will come of it, i.e. something that people (I) can actually use. It'll probably be more blog less CMS than Hope. At the minute I'm looking at using HAppS for most of it. Should be fun! Iain ps. Sorry for the spam Andrew.
On Sat, 25 Aug 2007, Andrew Coppin wrote:
How easy would it be to make / would anybody care / has somebody already made ... in Haskell?
- An interactive function plotter. (GNUplot is nice, but it can't plot recursive functions...)
I'm be interested to use such a library.
- A "graphical programming tool". (You add boxes and put in lines, it constructs a "program" that you can run.)
Would be nice for editing signal processing that is coded in Haskell.
+++ Andrew Coppin [Aug 25 07 12:50 ]:
How easy would it be to make / would anybody care / has somebody already made ... in Haskell?
- A wiki program. (Ditto.)
I wrote a simple wiki using HAppS and pandoc. See demonstration #15 on the pandoc web page: http://sophos.berkeley.edu/macfarlane/pandoc/examples.html It's by no means a finished product, but might serve as a good base if you decide to work on a wiki. John
John MacFarlane wrote:
+++ Andrew Coppin [Aug 25 07 12:50 ]:
I wrote a simple wiki using HAppS and pandoc. See demonstration #15 on the pandoc web page:
o Hey ! that s exactly whatI had in mind.. cool indeed, I am toying with the idea to - produce book, nicely (automatically) typeset with Latex or docbook - out of a wiki as interface ( as wikibook for instance) - with either free and informal text , - or formally ( automatically produced) sets or reference or docs ( a bit like literate programming embed code into the text), but these table would be more and more refined set of requirement.. This last point was with a software ingeniering backgroud in mind, ie to produce the requirement, and specification of software, , imagine a lot of reference and cross reference to manage, and to establish tracability..( if you heard about Cleanroom, just to examplify ) may i ask you what did you had in mind as an application when you started that ? -- View this message in context: http://www.nabble.com/Ideas-tf4327747.html#a12337130 Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
may i ask you what did you had in mind as an application when you started that ?
This was just recreational programming: I wanted to see what writing a web application in Haskell would be like. I think it would be great to have a fully featured wiki program in Haskell, but I don't have time to do it myself. Your idea sounds very interesting. Feel free to extend pandocwiki if that works for you; it's GPL. John
thanks John for replying...
when building , i cannot find the lcs mentionned in the cabal file not
on hasckage nor on goggle.
could you help?
( your papers on philosophy looks quite serious .. impressive you are
in haskell too .. math backgroud ? logics ?)
2007/8/26, John MacFarlane
may i ask you what did you had in mind as an application when you started that ?
This was just recreational programming: I wanted to see what writing a web application in Haskell would be like. I think it would be great to have a fully featured wiki program in Haskell, but I don't have time to do it myself. Your idea sounds very interesting. Feel free to extend pandocwiki if that works for you; it's GPL.
John
lcs can be found at http://urchin.earth.li/darcs/igloo/lcs/ +++ Luc TAESCH [Aug 26 07 23:45 ]:
when building , i cannot find the lcs mentionned in the cabal file not on hasckage nor on goggle. could you help?
All went finally fine. wiki is live. thanks for your help. great example. this helped me progressing my understanding of happs. This should conveniently go on the happs tutorial wiki., or at least be referred to . (I have seen alex is doing some tutorial on a wiki in the latest head release, so definitively this is the topic of the day !!) fyi, the cabal run (runghc) could not find the Diff file ( in the same directory anyway) o_o but ghc --make PanDocwiki.hs had it ok.) John MacFarlane wrote:
lcs can be found at http://urchin.earth.li/darcs/igloo/lcs/
+++ Luc TAESCH [Aug 26 07 23:45 ]:
when building , i cannot find the lcs mentionned in the cabal file not on hasckage nor on goggle. could you help?
Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- View this message in context: http://www.nabble.com/Ideas-tf4327747.html#a12344039 Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
Hi, Am Samstag, den 25.08.2007, 12:50 +0100 schrieb Andrew Coppin:
How easy would it be to make / would anybody care / has somebody already made ... in Haskell?
- A wiki program. (Ditto.)
I wrote a wiki in haskell, but it focuses on full-sized LaTeX-Documents, so the “regular” wiki party is rather limited. But of course it can be extended... (It’s based on subversion, and the small CGI-part is written in python). Wiki (self-hosting): http://latexki.nomeata.de/ Application: http://mitschriebwiki.nomeata.de/ Greetings, Joachim -- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: joachimbreitner@amessage.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org
participants (16)
-
Andrew Coppin -
C.M.Brown -
Claude Heiland-Allen -
Derek Elkins -
Evan Laforge -
Henning Thielemann -
Iain Lane -
jerzy.karczmarczuk＠info.unicaen.fr -
Joachim Breitner -
John MacFarlane -
Luc TAESCH -
luc.taesch -
Neil Mitchell -
Peter Verswyvelen -
Philippa Cowderoy -
Sven Panne