×
all 5 comments

[–][deleted]  (1 child)

[deleted]

    [–]gwern 0 points1 point  (0 children)

    Yes, I thought much the same thing. (The idea sounds a bit like uzbl.)

    [–]dons 1 point2 points  (1 child)

    I'm not sure what value to the Haskell community this would bring.


    Note: we have a webkit binding now: http://hackage.haskell.org/package/webkit-0.12.2

    and Andy Stewart has written a browser, http://hackage.haskell.org/package/manatee-browser-0.1.0

    so there you go. Done.

    [–]barsoap 0 points1 point  (0 children)

    There'd be true value in a render/layout/event engine that incidentally supports HTML, of course. It could be used to do silly things like GUIs.

    And no, I'm still not much closer to any of that since I last went ranting on the cafe, in perfect adherence to Haskell tradition.

    [–]jfredett 0 points1 point  (1 child)

    I had thought of something like this a while ago, with the idea of starting at a much lower level and designing the thing to be parallel from the ground up. So that the browser would be stitched together as a bunch of independent units which could run in isolation. Kind of a modular browser, the goal being crashproofing -- eg, one thing failing does not imply everything failing (a la Chrome, which didn't exist when I first thought of this, but is a good enough analogy now). And able to take full advantage of multicores machines -- even as plugins pile in.

    I had named the thing "Horizon", but just found it very difficult to get started writing the low-level (eg, what webkit does) stuff. I wanted the thing to be pure haskell principally for the learning experience, but I ended up going another direction instead.

    [–]barsoap 0 points1 point  (0 children)

    What about doing an ECMAscript implementation (or, well, start one, the language is a bitch)? Compiling the AST together with an interpreter could quickly yield some decent performance.