Re: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler)

newer
Speakers for a kickoff meetup on...

Olaf Klinke

28 Sep 2016 28 Sep '16

5:39 p.m.

I did not intend to start a Python-bashing thread. Most people on this list will agree on which language is superior. I did not intend to suggest that Haskell is still mainly a research language, nor that it should remain to be. I'd love to see more problems to be tackled with lenses, FRP or GADTs, just to show that it can be done this way. Maybe one day an idiom will prove superior to its competitors and take its place in whatever is the equivalent of base then. I am happy to have packages coexist that use either of String, Text, ByteString.Lazy or ByteString.Strict. I am a fan of the Unix philosophy: Do one thing, and do it well. There are modules in base that are very good examples of this: Data.Map provides just one data structure with a very easy interface, no newtypes, no typeclasses. The user needs no knowledge of how it is implemented, but the internals can be exposed if necessary. Control.DeepSeq provides one single typeclass to provide one single functionality. In Unix the glue between programs are streams of bytes. I feel that the glue between Haskell libraries should be lambda calculus and algebraic datatypes. So when you write a library that processes HTTP traffic as conduits: Provide a wrapper function whose type does not mention the conduit classes. When you write another efficient text library, provide fromString and toString functions, even if they are inefficient. As to what kind of batteries should be included: * I feel that Haskell already has an excellent set of containers for all sorts of tasks. * It has excellent parsers. * The web stuff seems less uniform, and my complaints about idioms apply. * To compete with other recent teaching languages, a really simple GUI library to use within ghci would be fine. (diagrams and GTK?) Quick Basic included "line" and "circle" commands to play with, even though the rest of the language did not prepare me for more advanced languages. * I know too little about the state of Haskell's number crunching libraries, but it seems that Vector is reasonably efficient nowadays. But what should I use to solve A*x = b? This is a problem so basic that is should be solved by a basic library. I like Peter's suggestion of an official wiki highlighting the state-of-the-art packages for common tasks. As to the versioning and backward compatibility issues of a standard library: In my eyes the whole concept of version numbers is broken. Dependencies should be stated in terms of type signatures. Olaf

Show replies by date

Brandon Allbery

28 Sep 28 Sep

5:45 p.m.

New subject: Batteries included (Was: GHC is a monopoly compiler)

On Wed, Sep 28, 2016 at 5:39 PM, Olaf Klinke wrote:

...

* To compete with other recent teaching languages, a really simple GUI library to use within ghci would be fine. (diagrams and GTK?) Quick Basic included "line" and "circle" commands to play with, even though the rest of the language did not prepare me for more advanced languages.

This turns out to be much easier if you assume that Windows and OS X are not worth supporting, or are happy with forcing users on those platforms to jump through annoying hoops (*especially* Windows; there are reasonable ways to get gtk on OS X, even though it doesn't come with the system, but Windows is still the Wild West as far as third party libraries are concerned --- Chocolatey notwithstanding). :/

...

As to the versioning and backward compatibility issues of a standard library: In my eyes the whole concept of version numbers is broken. Dependencies should be stated in terms of type signatures.

And ghc in fact uses hashes generated from this. But this has to include the signatures of internals because they can leak out for inlining --- so you still have more problems than other languages do. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

Tony Day

6:35 p.m.

New subject: Batteries included (Was: GHC is a monopoly compiler)

My solution to the lack of graphics is ipython or a workflow that looks like it - a loop that renders charts, runs code and places results in a markdown file, then rendered in the browser. That's about as live as you can get mixing Windows and open source. On Thu, Sep 29, 2016 at 7:46 AM Brandon Allbery wrote:

...

On Wed, Sep 28, 2016 at 5:39 PM, Olaf Klinke wrote:

...
* To compete with other recent teaching languages, a really simple GUI library to use within ghci would be fine. (diagrams and GTK?) Quick Basic included "line" and "circle" commands to play with, even though the rest of the language did not prepare me for more advanced languages.

This turns out to be much easier if you assume that Windows and OS X are not worth supporting, or are happy with forcing users on those platforms to jump through annoying hoops (*especially* Windows; there are reasonable ways to get gtk on OS X, even though it doesn't come with the system, but Windows is still the Wild West as far as third party libraries are concerned --- Chocolatey notwithstanding). :/

...
As to the versioning and backward compatibility issues of a standard library: In my eyes the whole concept of version numbers is broken. Dependencies should be stated in terms of type signatures.

And ghc in fact uses hashes generated from this. But this has to include the signatures of internals because they can leak out for inlining --- so you still have more problems than other languages do.

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Joachim Durchholz

8:40 p.m.

New subject: Batteries included (Was: GHC is a monopoly compiler)

Am 29.09.2016 um 00:35 schrieb Tony Day:

...

My solution to the lack of graphics is ipython or a workflow that looks like it - a loop that renders charts, runs code and places results in a markdown file, then rendered in the browser. That's about as live as you can get mixing Windows and open source.

There was a time when this was correct, but it has been gone for almost a decade now. Today, you can even choose the abstraction level: - GTK++ for GUI - SDL for multimedia - OpenGL for 3d Graphics

Tony Day

8:46 p.m.

New subject: Batteries included (Was: GHC is a monopoly compiler)

Ok, as live as you can get mixing native Haskell and windows, without the skills to DIY tooling. Are we that far behind? On Thu, Sep 29, 2016 at 10:40 AM Joachim Durchholz wrote:

...

Am 29.09.2016 um 00:35 schrieb Tony Day:

...
My solution to the lack of graphics is ipython or a workflow that looks like it - a loop that renders charts, runs code and places results in a markdown file, then rendered in the browser. That's about as live as you can get mixing Windows and open source.

There was a time when this was correct, but it has been gone for almost a decade now. Today, you can even choose the abstraction level: - GTK++ for GUI - SDL for multimedia - OpenGL for 3d Graphics

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Joachim Durchholz

9:18 p.m.

New subject: Batteries included (Was: GHC is a monopoly compiler)

If there's DIY tooling involved, then yes that is pretty far behind. I don't think that's necessary; I dimly recall somebody mentioned that Haskell does have a call interface to C code. The main challenge is to find ways to "Haskellize" those strictly imperative APIs so they become useful for the application programmer; I'd categorize that as "incommensurable" rather than "behind". Am 29.09.2016 um 02:46 schrieb Tony Day:

...

Ok, as live as you can get mixing native Haskell and windows, without the skills to DIY tooling. Are we that far behind? On Thu, Sep 29, 2016 at 10:40 AM Joachim Durchholz mailto:jo@durchholz.org> wrote:

Am 29.09.2016 um 00:35 schrieb Tony Day: > My solution to the lack of graphics is ipython or a workflow that looks > like it - a loop that renders charts, runs code and places results in a > markdown file, then rendered in the browser. > That's about as live as you can get mixing Windows and open source.

There was a time when this was correct, but it has been gone for almost a decade now. Today, you can even choose the abstraction level: - GTK++ for GUI - SDL for multimedia - OpenGL for 3d Graphics

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Theodore Lief Gannon

6:47 p.m.

New subject: Batteries included (Was: GHC is a monopoly compiler)

On Wed, Sep 28, 2016 at 2:45 PM, Brandon Allbery wrote:

...

This turns out to be much easier if you assume that Windows and OS X are not worth supporting, or are happy with forcing users on those platforms to jump through annoying hoops (*especially* Windows; there are reasonable ways to get gtk on OS X, even though it doesn't come with the system, but Windows is still the Wild West as far as third party libraries are concerned --- Chocolatey notwithstanding). :/

GTK on Windows is trivial at this point, with stack and LTS 7+. Try it yourself: stack exec -- pacman -S mingw-w64-x86_64-gtk3 stack install gtk2hs-buildtools stack install gtk3 --flag gtk3:build-demos gtk2hs-demo-carsim (I didn't start 100% clean but I don't *think* there are any other pacman packages required...)

Tillmann Rendel

30 Sep 30 Sep

10:36 a.m.

New subject: Batteries included (Was: GHC is a monopoly compiler)

Hi, Theodore Lief Gannon wrote:

...

GTK on Windows is trivial at this point, with stack and LTS 7+. Try it yourself:

stack exec -- pacman -S mingw-w64-x86_64-gtk3 stack install gtk2hs-buildtools stack install gtk3 --flag gtk3:build-demos gtk2hs-demo-carsim

(I didn't start 100% clean but I don't *think* there are any other pacman packages required...)

I had to first work around a pacman issue: stack exec -- pacman -Sy stack exec -- pacman -S pacman-mirrors And then I had to install pkg-config: stack exec -- pacman -S mingw-w64-x86_64-pkg-config Then the installation commands you provided worked for me. However, I could not just run gtk2hs-demo-carsim but had to run the following to expose the GTK DLLs to the executable: stack exec -- gtk2hs-demo-carsim Not trivial, but certainly much better than it used to be. (Still too hard for beginners in some setups. For example, in Tübingen, we have an introductionary programming lecture with 500 students. We cannot provide installation support that scales to that number of students, so our programming environment has to install flawlessly on stock Windows laptops, preferably without having to use the command line at all. We want to spend the first lab session programming, not setting up.) Tillmann

Theodore Lief Gannon

5:23 p.m.

New subject: Batteries included (Was: GHC is a monopoly compiler)

D'oh, pkg-config of course. And I took an initial 'pacman -Syu' for granted but I suppose that's not documented anywhere specific to Stack... probably worth doing. Interesting that you had to invoke through stack exec, tho... do you have dynamic linking in your global config? AFAIK static is default on Windows, so the DLLs don't matter after linking. On Fri, Sep 30, 2016 at 7:36 AM, Tillmann Rendel < rendel@informatik.uni-tuebingen.de> wrote:

...

Hi,

Theodore Lief Gannon wrote:

...
GTK on Windows is trivial at this point, with stack and LTS 7+. Try it yourself:

stack exec -- pacman -S mingw-w64-x86_64-gtk3 stack install gtk2hs-buildtools stack install gtk3 --flag gtk3:build-demos gtk2hs-demo-carsim

(I didn't start 100% clean but I don't *think* there are any other pacman packages required...)

I had to first work around a pacman issue:

stack exec -- pacman -Sy stack exec -- pacman -S pacman-mirrors

And then I had to install pkg-config:

stack exec -- pacman -S mingw-w64-x86_64-pkg-config

Then the installation commands you provided worked for me.

However, I could not just run gtk2hs-demo-carsim but had to run the following to expose the GTK DLLs to the executable:

stack exec -- gtk2hs-demo-carsim

Not trivial, but certainly much better than it used to be.

(Still too hard for beginners in some setups. For example, in Tübingen, we have an introductionary programming lecture with 500 students. We cannot provide installation support that scales to that number of students, so our programming environment has to install flawlessly on stock Windows laptops, preferably without having to use the command line at all. We want to spend the first lab session programming, not setting up.)

Tillmann

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Tillmann Rendel

6:35 p.m.

New subject: Batteries included (Was: GHC is a monopoly compiler)

Hi, Theodore Lief Gannon wrote:

...

D'oh, pkg-config of course. And I took an initial 'pacman -Syu' for granted but I suppose that's not documented anywhere specific to Stack... probably worth doing.

So installing gtk is trivial ... ... assuming you know how to operate pacman and setup pkg-config in a mingw environment? Almost there, almost. ;)

...

Interesting that you had to invoke through stack exec, tho... do you have dynamic linking in your global config? AFAIK static is default on Windows, so the DLLs don't matter after linking.

I didn't change any global config options related to linking. Note that the issue is with the gtk DLLs, not ghc-produced DLLs. I guess gtk is always dynamically linked, and you didn't run into this when you tested because you have GTK installed system-wide, too. Tillmann

Theodore Lief Gannon

8:08 p.m.

New subject: Batteries included (Was: GHC is a monopoly compiler)

There's only one top-level installation involved (stack), and no conditional branches on the process, so I'd say it's hit "trivial with step-by-step instructions" at least. I just failed to write them. ;) I'll have to check whether I have global GTK. I'm 95% sure I don't, but on the other hand it's been a couple of years since my last full reinstall so I could well have just forgotten about it. On Fri, Sep 30, 2016 at 3:35 PM, Tillmann Rendel < rendel@informatik.uni-tuebingen.de> wrote:

...

Hi,

Theodore Lief Gannon wrote:

...
D'oh, pkg-config of course. And I took an initial 'pacman -Syu' for granted but I suppose that's not documented anywhere specific to Stack... probably worth doing.

So installing gtk is trivial ...

... assuming you know how to operate pacman and setup pkg-config in a mingw environment? Almost there, almost. ;)

Interesting that you had to invoke through stack exec, tho... do you

...
have dynamic linking in your global config? AFAIK static is default on Windows, so the DLLs don't matter after linking.

I didn't change any global config options related to linking.

Note that the issue is with the gtk DLLs, not ghc-produced DLLs. I guess gtk is always dynamically linked, and you didn't run into this when you tested because you have GTK installed system-wide, too.

Tillmann

Tillmann Rendel

9:05 p.m.

New subject: Batteries included (Was: GHC is a monopoly compiler)

Hi, Theodore Lief Gannon wrote:

...

There's only one top-level installation involved (stack), and no conditional branches on the process, so I'd say it's hit "trivial with step-by-step instructions" at least. I just failed to write them. ;)

Ok, good point. Hopefully my experiments can lead to a more complete instruction being put somewhere. In my experience, many programming beginners on Windows cannot use the command line at all, so the whole situation of using stack is new to them. Also, the default support for copy-and-paste for the Windows command line is so bad that beginners will probably try to follow the step-by-step instructions by typing out the commands letter by letter. Therefore, a long list of simple commands but somewhat cryptic commands is still not really "trivial". So I think my question is: Could stack be persuaded somehow to make `stack install gtk3` "just work" by doing all the necessary incantations? I'm aware why `cabal install gtk3` can neither install gtk2hs-buildtools nor install the C library, but maybe stack could make a different tradeoff there. Tillmann

Theodore Lief Gannon

10:51 p.m.

New subject: Batteries included (Was: GHC is a monopoly compiler)

On Fri, Sep 30, 2016 at 6:05 PM, Tillmann Rendel < rendel@informatik.uni-tuebingen.de> wrote:

...

So I think my question is: Could stack be persuaded somehow to make `stack install gtk3` "just work" by doing all the necessary incantations? I'm aware why `cabal install gtk3` can neither install gtk2hs-buildtools nor install the C library, but maybe stack could make a different tradeoff there.

I've actually put direct thought into this. I'm partially responsible for the relative ease on Windows now -- previously Stack wasn't setting up the environment correctly for MinGW -- it was providing an MSYS environment instead, which means full POSIX emulation rather than just a mostly-sufficient translation layer. This distinction is also why there are separate 'pkg-config' and 'mingw-w64-x86_64-pkg-config' (and unfortunately you want the latter, here). I almost added the system update and pkg-config (since .cabal files directly reference it) to the msys installation process in my PR, but I was dissuaded from it by some comments about issues they had trying to do the same with git: 1. it can fail due to network issues, and getting a consistent state with good user feedback out of a return code inside a sub-shell is more work than anyone's wanted to do yet. 2. the fact that msys includes an arbitrary set of packages, and in fact can upgrade itself without stack's permission or even knowledge, is damaging to the intended promise of reproducible builds. On top of that, this is solely a Windows concern -- stack doesn't have any desire or reason to be a system package manager elsewhere. So I decided the better option is a separate windows-specific tool, which knows how to deal with stack environments (that's in public library code, so yay) and provides a convenience wrapper for pacman which, among other things, attaches the correct big ugly prefix to package names for you. I got as far as deciding that it would either be named "stacman" or "Jenga" and then put it on the shelf because, with the environment stuff worked out, plain stack is no longer too much of a hassle for me personally. But, I'm certain it's a plausible and not even particularly difficult project.

Herbert Valerio Riedel

3 Oct 3 Oct

3:45 a.m.

New subject: Batteries included

On 2016-10-01 at 03:05:23 +0200, Tillmann Rendel wrote: [...]

...

I'm aware why `cabal install gtk3` can neither install gtk2hs-buildtools nor install the C library

If you're referring to `cabal` not being able to solve for build-tools and installing them: that's being addressed in 'cabal new-build', right now latest cabal new-build can already install the well-known build-tools (alex, happy, etc...). If you want cabal to install C libraries, you have to package them as Cabal packages first. I did that e.g. with http://hackage.haskell.org/package/lzma-clib for Windows' sake, but it's still an unsatisfying workaround for lack of a proper system package management for C libraries in Windows. I hope that something like Chocolatey will become the de-facto standard on Windows in the foreseeable future.

Joachim Durchholz

4:37 a.m.

New subject: Batteries included

Am 03.10.2016 um 09:45 schrieb Herbert Valerio Riedel:

...

On 2016-10-01 at 03:05:23 +0200, Tillmann Rendel wrote:

[...]

lack of a proper system package management for C libraries in Windows. I hope that something like Chocolatey will become the de-facto standard on Windows in the foreseeable future.

I woudn't hold my breath (yet). Packaging systems are barely mature enough to offer satisfactory support simplified use cases like single ABI (Linux package managers) or single programming language (Cabal, Maven, SBT). Throwing in mixed-language support can be made to work easily (even Maven does this, in a half-assed way), but making it work well is still a "need more experience" topic. Regards, Jo

Jerzy Karczmarczuk

28 Sep 28 Sep

7 p.m.

New subject: Batteries included

Le 28/09/2016 à 23:39, Olaf Klinke a écrit :

...

I did not intend to start a Python-bashing thread. Most people on this list will agree on which language is superior. Do you really need to issue religious statements on this forum? Please... It is as bad, or worse than such claims as "from XXX you cannot learn anything useful!" /.../ it seems that Vector is reasonably efficient nowadays. But what should I use to solve A*x = b? This is a problem so basic that is should be solved by a basic library. Are you sure? The same "basic" library for a 3*3 equation, and for some enormous radiosity computation, and for ill-conditioned matrices, and for equations with constraints, and for Moore-Penrose pseudoinverses, and ... etc. ? ...

Libraries must, and will evolve and adapt/split, since new algorithms are constructed every week. And if you like cute citations, such as "doing one thing well" (of course, everybody knows the meaning of "well", which is universal and eternal, no?...), I'll give you my favourite: "There is one truth, which should be obvious to everybody: - *all* truth which is obvious to some, is far from being obvious to others". Jerzy Karczmarczuk

Heinrich Apfelmus

29 Sep 29 Sep

11:33 a.m.

New subject: Batteries included (Was: GHC is a monopoly compiler)

...

* To compete with other recent teaching languages, a really simple GUI library to use within ghci would be fine. (diagrams and GTK?) Quick Basic included "line" and "circle" commands to play with, even though the rest of the language did not prepare me for more advanced languages.

You mean, like this? http://apfelmus.nfshost.com/temp/hyper-haskell-sneak-peek.png It's a project that I'm currently working on, called HyperHaskell - the strongly hyped Haskell interpreter - Well, it's supposed to be strongly hyped, but currently, only few people know about it. Could you give me a hand with, uh, hyping this? I'm not good at this. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com Olaf Klinke wrote:

...

I did not intend to start a Python-bashing thread. Most people on this list will agree on which language is superior.

I did not intend to suggest that Haskell is still mainly a research language, nor that it should remain to be. I'd love to see more problems to be tackled with lenses, FRP or GADTs, just to show that it can be done this way. Maybe one day an idiom will prove superior to its competitors and take its place in whatever is the equivalent of base then. I am happy to have packages coexist that use either of String, Text, ByteString.Lazy or ByteString.Strict.

I am a fan of the Unix philosophy: Do one thing, and do it well. There are modules in base that are very good examples of this: Data.Map provides just one data structure with a very easy interface, no newtypes, no typeclasses. The user needs no knowledge of how it is implemented, but the internals can be exposed if necessary. Control.DeepSeq provides one single typeclass to provide one single functionality. In Unix the glue between programs are streams of bytes. I feel that the glue between Haskell libraries should be lambda calculus and algebraic datatypes. So when you write a library that processes HTTP traffic as conduits: Provide a wrapper function whose type does not mention the conduit classes. When you write another efficient text library, provide fromString and toString functions, even if they are inefficient.

As to what kind of batteries should be included:

* I feel that Haskell already has an excellent set of containers for all sorts of tasks. * It has excellent parsers. * The web stuff seems less uniform, and my complaints about idioms apply. * To compete with other recent teaching languages, a really simple GUI library to use within ghci would be fine. (diagrams and GTK?) Quick Basic included "line" and "circle" commands to play with, even though the rest of the language did not prepare me for more advanced languages. * I know too little about the state of Haskell's number crunching libraries, but it seems that Vector is reasonably efficient nowadays. But what should I use to solve A*x = b? This is a problem so basic that is should be solved by a basic library.

I like Peter's suggestion of an official wiki highlighting the state-of-the-art packages for common tasks.

As to the versioning and backward compatibility issues of a standard library: In my eyes the whole concept of version numbers is broken. Dependencies should be stated in terms of type signatures.

Olaf _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Moritz Angermann

10:04 p.m.

New subject: Batteries included (Was: GHC is a monopoly compiler)

...

http://apfelmus.nfshost.com/temp/hyper-haskell-sneak-peek.png

It's a project that I'm currently working on, called

HyperHaskell - the strongly hyped Haskell interpreter -

Well, it's supposed to be strongly hyped, but currently, only few people know about it. Could you give me a hand with, uh, hyping this? I'm not good at this.

Nifty! - How does this compare to jupyter (ipython) with the haskell kernel? - Is it on GitHub or somewhere? Cheers, Moritz

Heinrich Apfelmus

30 Sep 30 Sep

4:22 a.m.

New subject: Batteries included (Was: GHC is a monopoly compiler)

...

...
HyperHaskell

Nifty!

- How does this compare to jupyter (ipython) with the haskell kernel?

The overall goal is obviously very similar. To me, the main differences are * HyperHaskell should be easy to install (e.g. only cabal and a binary download) * HyperHaskell behaves more like a desktop application, e.g. worksheets are loaded from and saved to the local file system. The latter point is actually the main reason why I couldn't get into Jupyter at all: It insisted that I manage worksheets in some kind of database in the browser. Ugh! (There may be other front-ends nowadays, but last I checked, I didn't find anything official or popular, that's why I decided to write my own thing.) On the flip side, HyperHaskell is specialized to Haskell -- you can't use it with other languages.

...

- Is it on GitHub or somewhere?

Not yet, it's still in the "hype" phase. ;-) Expect the following location https://github.com/HeinrichApfelmus/hyper-haskell to fill with code in a week or two. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com Moritz Angermann wrote:

...

...
http://apfelmus.nfshost.com/temp/hyper-haskell-sneak-peek.png

It's a project that I'm currently working on, called

HyperHaskell - the strongly hyped Haskell interpreter -

Well, it's supposed to be strongly hyped, but currently, only few people know about it. Could you give me a hand with, uh, hyping this? I'm not good at this.

Nifty!

- How does this compare to jupyter (ipython) with the haskell kernel? - Is it on GitHub or somewhere?

Cheers, Moritz

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

David McBride

4:44 a.m.

New subject: Batteries included (Was: GHC is a monopoly compiler)

Consider me hyped. I could never get jupyter to work. On Fri, Sep 30, 2016 at 4:22 AM, Heinrich Apfelmus < apfelmus@quantentunnel.de> wrote:

...

HyperHaskell

...
...
Nifty!

- How does this compare to jupyter (ipython) with the haskell kernel?

The overall goal is obviously very similar. To me, the main differences are

* HyperHaskell should be easy to install (e.g. only cabal and a binary download)

* HyperHaskell behaves more like a desktop application, e.g. worksheets are loaded from and saved to the local file system.

The latter point is actually the main reason why I couldn't get into Jupyter at all: It insisted that I manage worksheets in some kind of database in the browser. Ugh! (There may be other front-ends nowadays, but last I checked, I didn't find anything official or popular, that's why I decided to write my own thing.)

On the flip side, HyperHaskell is specialized to Haskell -- you can't use it with other languages.

- Is it on GitHub or somewhere?

...
Not yet, it's still in the "hype" phase. ;-) Expect the following location

https://github.com/HeinrichApfelmus/hyper-haskell

to fill with code in a week or two.

Best regards, Heinrich Apfelmus

-- http://apfelmus.nfshost.com

Moritz Angermann wrote:

...
http://apfelmus.nfshost.com/temp/hyper-haskell-sneak-peek.png

...
It's a project that I'm currently working on, called

HyperHaskell - the strongly hyped Haskell interpreter -

Well, it's supposed to be strongly hyped, but currently, only few people know about it. Could you give me a hand with, uh, hyping this? I'm not good at this.

Nifty!

- How does this compare to jupyter (ipython) with the haskell kernel? - Is it on GitHub or somewhere?

Cheers, Moritz

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Heinrich Apfelmus

2 Oct 2 Oct

11 a.m.

New subject: Batteries included (Was: GHC is a monopoly compiler)

Dear hyped, I have uploaded the code to https://github.com/HeinrichApfelmus/hyper-haskell It's not a release yet, so no one-click installer yet, but it should be very easy to get it running after cloning the repository (and downloading the Electron application). Let me know what you think! Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com David McBride wrote:

...

Consider me hyped. I could never get jupyter to work.

On Fri, Sep 30, 2016 at 4:22 AM, Heinrich Apfelmus < apfelmus@quantentunnel.de> wrote:

...
HyperHaskell

...
Nifty!

- How does this compare to jupyter (ipython) with the haskell kernel?

The overall goal is obviously very similar. To me, the main differences are

* HyperHaskell should be easy to install (e.g. only cabal and a binary download)

* HyperHaskell behaves more like a desktop application, e.g. worksheets are loaded from and saved to the local file system.

The latter point is actually the main reason why I couldn't get into Jupyter at all: It insisted that I manage worksheets in some kind of database in the browser. Ugh! (There may be other front-ends nowadays, but last I checked, I didn't find anything official or popular, that's why I decided to write my own thing.)

On the flip side, HyperHaskell is specialized to Haskell -- you can't use it with other languages.

- Is it on GitHub or somewhere? Not yet, it's still in the "hype" phase. ;-) Expect the following location

https://github.com/HeinrichApfelmus/hyper-haskell

to fill with code in a week or two.

Best regards, Heinrich Apfelmus

-- http://apfelmus.nfshost.com

Moritz Angermann wrote:

...
http://apfelmus.nfshost.com/temp/hyper-haskell-sneak-peek.png

...
It's a project that I'm currently working on, called

HyperHaskell - the strongly hyped Haskell interpreter -

Well, it's supposed to be strongly hyped, but currently, only few people know about it. Could you give me a hand with, uh, hyping this? I'm not good at this.

Nifty!

- How does this compare to jupyter (ipython) with the haskell kernel? - Is it on GitHub or somewhere?

Cheers, Moritz

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

------------------------------------------------------------------------

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

3151

Age (days ago)

3156

Last active (days ago)

List overview

Download

20 comments

11 participants

participants (11)

Brandon Allbery
David McBride
Heinrich Apfelmus
Herbert Valerio Riedel
Jerzy Karczmarczuk
Joachim Durchholz
Moritz Angermann
Olaf Klinke
Theodore Lief Gannon
Tillmann Rendel
Tony Day