Re: [Haskell-cafe] Poll & plea: State of GUI & graphics libraries in Haskell
I only managed to find some screenshots from Harley Trung's class
projects a few years ago:
https://github.com/harleyttd/keyboard-fretboard/blob/master/demo2.png
https://github.com/harleyttd/InstrVislizr/blob/master/stereo.png
It was nothing fancy, only basic widgets, single font, not skinnable.
The design was based on your Phooey work, monadic composition of UI
elements wired by signals. I deliberately made the layout not reactive
in order to simplify implementation.
Regards,
Paul Liu
On Wed, Oct 2, 2013 at 3:28 PM, Conal Elliott wrote:
> Interesting. How are the aesthetics? Can you point me to screen shots?
>
> It'd be a lot of work, but one cool project would be to create *beautiful*
> GUI elements using OpenGL programmable shaders. Given the speed of GPUs, we
> could afford to put a lot into visual details.
>
> A complementary project is designing a semantically precise and elegant
> ("denotative"/"genuinely functional" to use Peter Landin's terms) GUI DSEL
> that would be simpler and more powerful than the conventional OO-inspired
> libraries we have so much trouble getting to work in Haskell. I've thought
> about this sort of thing on and off for a very long time and would be happy
> to be involved if others are interested also.
>
> Together, these two efforts would yield an approach to GUIs that is
> beautiful inside and out.
>
> -- Conal
>
>
>
> On Wed, Oct 2, 2013 at 1:21 PM, Paul Liu wrote:
>>
>> No. GLFW does not give you any UI elements, just basic windowing and
>> input handling.
>>
>> Euterpea has a UI layer on top of GLFW that provides text boxes and
>> sliders, etc, entirely written in Haskell.
>>
>> On Wed, Oct 2, 2013 at 8:40 AM, Conal Elliott wrote:
>> > Hi Paul. Is there a way to use GLFW with GUI elements other than OpenGL
>> > display windows, e.g., text boxes and sliders? -- Conal
>> >
>> >
>> > On Tue, Oct 1, 2013 at 11:23 PM, Paul Liu wrote:
>> >>
>> >> Thanks. I've just built GHC HEAD on Mac OS X Lion, and tested by
>> >> installing libraries with --enable-shared and loading a GLFW program
>> >> into GHCi. Using ghci -fno-ghci-sandbox, everything works great
>> >> including closing and restarting GL window multiple times. Can't wait
>> >> for the official release of GHC 7.8!
>> >>
>> >> On Tue, Oct 1, 2013 at 12:09 PM, Carter Schonwald
>> >> wrote:
>> >> > thats the linker bug.
>> >> >
>> >> > the glfw stuff has been tested on ghc HEAD / 7.7 by folks on
>> >> > #haskell-game
>> >> > in recent memory. GHCI + foreign libs should work fine now (modulo
>> >> > thread
>> >> > local storage related thing).
>> >> >
>> >> > the historical element doesn't matter any more.
>> >> >
>> >> > To the best of my knowledge, all such issues should be gone. Anyone
>> >> > who
>> >> > cares about making sure GHCI+ gui libs play nice, PLEASE test with
>> >> > HEAD.
>> >> >
>> >> > the better this issue is properly tested (which i believe it has
>> >> > been),
>> >> > the
>> >> > more we can actually prevent it from happening. This requires people
>> >> > to
>> >> > test
>> >> > with HEAD GHCi now, rather than doing archaeology.
>> >> >
>> >> > anyone who cares, please play with GHCI in HEAD. If your lib doesn't
>> >> > work
>> >> > with ghci, please report a bug. It would be a new bug because it
>> >> > wont'
>> >> > be
>> >> > the previous reasons it hasnt' worked.
>> >> >
>> >> >
>> >> > tl;dr to the best of my knowledge this issue is resolved in HEAD.
>> >> > Test
>> >> > HEAD.
>> >> > Help us make sure it stays resolved by testing HEAD.
>> >> >
>> >> > thanks
>> >> > -Carter
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On Tue, Oct 1, 2013 at 1:20 PM, Paul Liu wrote:
>> >> >>
>> >> >> I reported a problem with statically linked GLFW library on Mac OS X
>> >> >> Lion in this thread:
>> >> >>
>> >> >>
>> >> >> http://www.haskell.org/pipermail/haskell-cafe/2012-January/097355.html
>> >> >>
>> >
Re: [Haskell-cafe] Poll & plea: State of GUI & graphics libraries in Haskell
No. GLFW does not give you any UI elements, just basic windowing and input handling. Euterpea has a UI layer on top of GLFW that provides text boxes and sliders, etc, entirely written in Haskell. On Wed, Oct 2, 2013 at 8:40 AM, Conal Elliott wrote: > Hi Paul. Is there a way to use GLFW with GUI elements other than OpenGL > display windows, e.g., text boxes and sliders? -- Conal > > > On Tue, Oct 1, 2013 at 11:23 PM, Paul Liu wrote: >> >> Thanks. I've just built GHC HEAD on Mac OS X Lion, and tested by >> installing libraries with --enable-shared and loading a GLFW program >> into GHCi. Using ghci -fno-ghci-sandbox, everything works great >> including closing and restarting GL window multiple times. Can't wait >> for the official release of GHC 7.8! >> >> On Tue, Oct 1, 2013 at 12:09 PM, Carter Schonwald >> wrote: >> > thats the linker bug. >> > >> > the glfw stuff has been tested on ghc HEAD / 7.7 by folks on >> > #haskell-game >> > in recent memory. GHCI + foreign libs should work fine now (modulo >> > thread >> > local storage related thing). >> > >> > the historical element doesn't matter any more. >> > >> > To the best of my knowledge, all such issues should be gone. Anyone who >> > cares about making sure GHCI+ gui libs play nice, PLEASE test with HEAD. >> > >> > the better this issue is properly tested (which i believe it has been), >> > the >> > more we can actually prevent it from happening. This requires people to >> > test >> > with HEAD GHCi now, rather than doing archaeology. >> > >> > anyone who cares, please play with GHCI in HEAD. If your lib doesn't >> > work >> > with ghci, please report a bug. It would be a new bug because it wont' >> > be >> > the previous reasons it hasnt' worked. >> > >> > >> > tl;dr to the best of my knowledge this issue is resolved in HEAD. Test >> > HEAD. >> > Help us make sure it stays resolved by testing HEAD. >> > >> > thanks >> > -Carter >> > >> > >> > >> > >> > On Tue, Oct 1, 2013 at 1:20 PM, Paul Liu wrote: >> >> >> >> I reported a problem with statically linked GLFW library on Mac OS X >> >> Lion in this thread: >> >> >> >> http://www.haskell.org/pipermail/haskell-cafe/2012-January/097355.html >> >> >> >> I do not know why this is broken on Mac OS X Lion, but not on Linux or >> >> Windows. There was an EnableGUI hack for GHC 7.2 (and previous >> >> versions) and OS X version before Lion, but it no longer works. So I'm >> >> not sure if it is OS X Lion, or GLFW, or GHC, or a combination of them >> >> that caused this problem. >> >> >> >> Regards, >> >> Paul Liu >> >> >> >> On Tue, Oct 1, 2013 at 7:04 AM, Carter Schonwald >> >> wrote: >> >> > Hey simon, the two issues that have recurrently bit ghci interaction >> >> > with >> >> > foreign GUI libs are >> >> > 1) the ghci linker. This is fixed in head by now having ghci use the >> >> > system >> >> > linker >> >> > 2) some GUI libs require thread local state, and ghci has a flag for >> >> > that >> >> > 3) I'm not aware of anyone reporting newly broken libs wrt GUI >> >> > bindings >> >> > when 7.6 rolled out. The only fix that's relevant to 7.8 is the >> >> > dylinker >> >> > bit, but that would have been a problem historically too. >> >> > >> >> > I believe a number of folks in #haskell-game have recently tested >> >> > point >> >> > one. >> >> > (Though I should ask to double check) >> >> > >> >> > At the very least, I'm not aware of hearing of such a 7.6 specific >> >> > ghci >> >> > breakage before. >> >> > >> >> > >> >> > On Tuesday, October 1, 2013, Simon Peyton-Jones wrote: >> >> >> >> >> >> Dear GHC devs >> >> >> >> >> >> >> >> >> >> >> >> See below (in red). I do not know the details of this, but it >> >> >> sounds >> >> >> like >> >> >> a pretty serious problem, and it used to work. Is whatever-it-is >> >>
Re: [Haskell-cafe] Poll & plea: State of GUI & graphics libraries in Haskell
Thanks. I've just built GHC HEAD on Mac OS X Lion, and tested by installing libraries with --enable-shared and loading a GLFW program into GHCi. Using ghci -fno-ghci-sandbox, everything works great including closing and restarting GL window multiple times. Can't wait for the official release of GHC 7.8! On Tue, Oct 1, 2013 at 12:09 PM, Carter Schonwald wrote: > thats the linker bug. > > the glfw stuff has been tested on ghc HEAD / 7.7 by folks on #haskell-game > in recent memory. GHCI + foreign libs should work fine now (modulo thread > local storage related thing). > > the historical element doesn't matter any more. > > To the best of my knowledge, all such issues should be gone. Anyone who > cares about making sure GHCI+ gui libs play nice, PLEASE test with HEAD. > > the better this issue is properly tested (which i believe it has been), the > more we can actually prevent it from happening. This requires people to test > with HEAD GHCi now, rather than doing archaeology. > > anyone who cares, please play with GHCI in HEAD. If your lib doesn't work > with ghci, please report a bug. It would be a new bug because it wont' be > the previous reasons it hasnt' worked. > > > tl;dr to the best of my knowledge this issue is resolved in HEAD. Test HEAD. > Help us make sure it stays resolved by testing HEAD. > > thanks > -Carter > > > > > On Tue, Oct 1, 2013 at 1:20 PM, Paul Liu wrote: >> >> I reported a problem with statically linked GLFW library on Mac OS X >> Lion in this thread: >> >> http://www.haskell.org/pipermail/haskell-cafe/2012-January/097355.html >> >> I do not know why this is broken on Mac OS X Lion, but not on Linux or >> Windows. There was an EnableGUI hack for GHC 7.2 (and previous >> versions) and OS X version before Lion, but it no longer works. So I'm >> not sure if it is OS X Lion, or GLFW, or GHC, or a combination of them >> that caused this problem. >> >> Regards, >> Paul Liu >> >> On Tue, Oct 1, 2013 at 7:04 AM, Carter Schonwald >> wrote: >> > Hey simon, the two issues that have recurrently bit ghci interaction >> > with >> > foreign GUI libs are >> > 1) the ghci linker. This is fixed in head by now having ghci use the >> > system >> > linker >> > 2) some GUI libs require thread local state, and ghci has a flag for >> > that >> > 3) I'm not aware of anyone reporting newly broken libs wrt GUI bindings >> > when 7.6 rolled out. The only fix that's relevant to 7.8 is the >> > dylinker >> > bit, but that would have been a problem historically too. >> > >> > I believe a number of folks in #haskell-game have recently tested point >> > one. >> > (Though I should ask to double check) >> > >> > At the very least, I'm not aware of hearing of such a 7.6 specific ghci >> > breakage before. >> > >> > >> > On Tuesday, October 1, 2013, Simon Peyton-Jones wrote: >> >> >> >> Dear GHC devs >> >> >> >> >> >> >> >> See below (in red). I do not know the details of this, but it sounds >> >> like >> >> a pretty serious problem, and it used to work. Is whatever-it-is >> >> confirmed >> >> fixed in 7.8? Do we have a test that’ll trip if it breaks again? (I’m >> >> guessing that the latter might be hard.) >> >> >> >> >> >> >> >> Thanks >> >> >> >> >> >> >> >> Simon >> >> >> >> >> >> >> >> -Original Message- >> >> From: Haskell-Cafe [mailto:haskell-cafe-boun...@haskell.org] On Behalf >> >> Of >> >> Paul Liu >> >> Sent: 30 September 2013 07:18 >> >> To: Conal Elliott >> >> Cc: Haskell Cafe >> >> Subject: Re: [Haskell-cafe] Poll & plea: State of GUI & graphics >> >> libraries >> >> in Haskell >> >> >> >> >> >> >> >> Hi Conal, >> >> >> >> >> >> >> >> I wasn't able to make it to last Saturday's FARM track, but I think >> >> >> >> there was a good chance that Paul would have demonstrated his Euterpea >> >> >> >> music library, which includes a GUI interface (called MUI) written on >> >> >> >> top of GLFW. I wrote its initial implementation (around 2009?) with a >> >> >> >> monadic in
Re: [Haskell-cafe] Poll & plea: State of GUI & graphics libraries in Haskell
Hi Conal, I wasn't able to make it to last Saturday's FARM track, but I think there was a good chance that Paul would have demonstrated his Euterpea music library, which includes a GUI interface (called MUI) written on top of GLFW. I wrote its initial implementation (around 2009?) with a monadic interface that let you wire together UI components with signals (I believe Dan later wrote an arrow interface, but I could be wrong). It was actually inspired by the ideas behind your Phooey UI library. It should be very easy to extract this part out as a standalone package if there is enough interest. The only issue with it (and all other UI libraries) is that it doesn't play nicely in GHCi. It used to work pretty well with GHC 7.2 and 7.4 on almost all platforms (Mac needs an extra hack), but GHC 7.6 broke Mac (and perhaps Windows too). GHC 7.8 supposedly should fix this problem. BTW, as also the author of the GLFW library on HackageDB, I've done barely minimal to keep this Haskell binding afloat. I'm actually leaning towards GLFW-b library, which is better maintained, and provides similar binding for GLFW C library but with a saner interface (no dependency on the OpenGL library, for example). If you don't need the two extra things that GLFW does (choice of either dynamic or static linking to GLFW C, and an embedded bitmap font), I suggest you try out GLFW-b if you are only looking for a think graphics layer with input+window+OpenGL. The only thing keeping GLFW-b from becoming a good foundation for a pure Haskell UI lib is IMHO the lack of a light-weight, cross-platform, and full-featured font rendering solution. I believe many other libraries (including Diagram) are having the same problem. On Thu, Sep 26, 2013 at 8:32 PM, Conal Elliott wrote: > I'm polling to see whether there are will and expertise to reboot graphics > and GUIs work in Haskell. I miss working on functional graphics and GUIs in > Haskell, as I've been blocked for several years (eight?) due to the absence > of low-level foundation libraries having the following properties: > > * cross-platform, > * easily buildable, > * GHCi-friendly, and > * OpenGL-compatible. > > The last several times I tried Gtk2hs, I was unable to compile it on my Mac. > Years ago when I was able to compile, the GUIs looked and interacted like a > Linux app, which made them awkward and upleasant to use. wxHaskell (whose > API and visual appearance I prefered) has for years been incompatible with > GHCi, in that the second time I open a top-level window, the host process > (GHCi) dies abruptly. Since my GUI & graphics programs are often one-liners, > and I tend to experiment a lot, using a full compilation greatly thwarts my > flow. For many years, I've thought that the situation would eventually > improve, since I'm far from the only person who wants GUIs or graphics from > Haskell. > > About three years ago, I built a modern replacement of my old Pan and > Vertigo systems (optimized high-level functional graphics in 2D and 3D), > generating screamingly fast GPU rendering code. I'd love to share it with > the community, but I'm unable to use it even myself. > > Two questions: > > * Am I mistaken about the current status? I.e., is there a solution for > Haskell GUI & graphics programming that satisfies the properties I'm looking > for (cross-platform, easily buildable, GHCi-friendly, and > OpenGL-compatible)? > * Are there people willing and able to fix this situation? My own > contributions would be to test and to share high-level composable and > efficient GUI and graphics libraries on top of a working foundation. > > Looking forward to replies. Thanks, > > -- Conal > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Regards, Paul Liu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] why do I need class context in declaring data constructor?
Thanks, Simon! I'll be looking forward to its resolution.
On Fri, Aug 31, 2012 at 4:37 AM, Simon Peyton-Jones
wrote:
> Aha. See http://hackage.haskell.org/trac/ghc/ticket/7205.
>
> I don't think there's a workaround, I'm afraid
>
> Simon
>
> | -Original Message-
> | From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-
> | boun...@haskell.org] On Behalf Of Paul Liu
> | Sent: 30 August 2012 20:52
> | To: Haskell Cafe
> | Subject: [Haskell-cafe] why do I need class context in declaring data
> | constructor?
> |
> | I had a toy program that encodes simply typed lambda in types. It used
> | to work fine with GHC prior to 7.2. But now it no longer compiles.
> | Here is a minimal fragment that demonstrates this problem.
> |
> | > {-# LANGUAGE GADTs,
> | > MultiParamTypeClasses,
> | > FlexibleInstances,
> | > FlexibleContexts #-}
> | >
> | > data Abs env t v where
> | > Abs :: g (a, env) h v -> Abs env (g (a, env) h v) (a -> v)
> | >
> | > class Eval g env t v where
> | > eval :: env -> g env t v -> v
> | >
> | > instance Eval g (a, env) h v =>
> | > Eval Abs env (g (a, env) h v) (a -> v) where
> | > eval env (Abs e) = \x -> eval (x, env) e
> |
> | The type Abs has 3 parameters: its environment, sub term (encoded in
> | types), and type. The constructor Abs has 1 parameter: its sub term.
> | The code loads fine in GHC 7.0.3.
> |
> | Here is the error reported by GHC 7.2.2 (and later):
> |
> | test.lhs:14:30:
> | Could not deduce (Eval g1 (a1, env) h1 v1)
> | arising from a use of `eval'
> | from the context (Eval g (a, env) h v)
> | bound by the instance declaration at test.lhs:(12,12)-(13,49)
> | or from (g (a, env) h v ~ g1 (a1, env) h1 v1,
> | (a -> v) ~ (a1 -> v1))
> | bound by a pattern with constructor
> | Abs :: forall env (g :: * -> * -> * -> *) a h v.
> | g (a, env) h v -> Abs env (g (a, env) h v) (a ->
> | v),
> |in an equation for `eval'
> | at test.lhs:14:15-19
> | Possible fix:
> | add (Eval g1 (a1, env) h1 v1) to the context of
> | the data constructor `Abs'
> | or the instance declaration
> | or add an instance declaration for (Eval g1 (a1, env) h1 v1)
> | In the expression: eval (x, env) e
> | In the expression: \ x -> eval (x, env) e
> | In an equation for `eval':
> | eval env (Abs e) = \ x -> eval (x, env) e
> |
> | However, if I move the class context to the data constructor of
> | definition, then it compiles fine in GHC 7.2.2 (and later):
> |
> | > data Abs env t v where
> | > Abs :: Eval g (a, env) h v => g (a, env) h v -> Abs env (g (a, env)
> | > h v) (a -> v)
> |
> | But this is very troublesome because for every new class instance I want
> | to make Abs of, I have to make a new class context to the data
> | constructor. It totally defeats the purpose of making class instances to
> | extend usage of data types.
> |
> | Did I missed a language extension when moving code from GHC 7.0.3 to GHC
> | 7.2.2? What can I do to fix it for newer GHCs?
> |
> | --
> | Regards,
> | Paul Liu
> |
> | ___
> | Haskell-Cafe mailing list
> | Haskell-Cafe@haskell.org
> | http://www.haskell.org/mailman/listinfo/haskell-cafe
--
Regards,
Paul Liu
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUCE: monad-task-0.1.0, GLFW-task-0.1.0 and a tutorial on invert the inversion of control
Graphics program often relies on system frameworks such as GLUT or GLFW to handle window and user input. But such frameworks often impose a rigid style of callback programming, or inversion of control. It is no secret that continuation monad can deal with this issue [1]. It is also known that concurrency can be naturally expressed as continuation monads [2], and a hybrid model of event and threads [3] brings the best of both worlds. But then I'm a bit surprised to find no single library on HackageDB that can deal with this issue. Further more, I wanted something that can escape the IO monad imposed by callbacks (and FFI) and be flexible. (no, monad-control is not a solution here). So I wrote a monad-task library to handle both co-operative threads (or co-routines) and event processing in a TaskT transformer. To demonstrate its usage, I also uploaded a GLFW-task library that helps to program task monad with GLFW, which contains a sample application if you unpack its source. I documented the rationales behind this work in a (rather length but runnable literal Haskell) tutorial "Invert the Inversion of Control", and welcome any suggestions and feedbacks. monad-task:http://hackage.haskell.org/package/monad-task GLFW-task:http://hackage.haskell.org/package/GLFW-task tutorial: http://www.thev.net/PaulLiu/invert-inversion.html [1]: Quick and dirty reinversion of control, Dan Piponi. http://blog.sigfpe.com/2011/10/quick-and-dirty-reinversion-of-control.html [2]: Functional Pearls: A Poor Man's Concurrency Monad, Koen Claessen, 1999 [3]: Combining Events And Threads For Scalable Network Services. Peng Li and Steve Zdancewic. PLDI, 2007. -- Regards, Paul Liu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] why do I need class context in declaring data constructor?
I had a toy program that encodes simply typed lambda in types. It used
to work fine with GHC prior to 7.2. But now it no longer compiles.
Here is a minimal fragment that demonstrates this problem.
> {-# LANGUAGE GADTs,
> MultiParamTypeClasses,
> FlexibleInstances,
> FlexibleContexts #-}
>
> data Abs env t v where
> Abs :: g (a, env) h v -> Abs env (g (a, env) h v) (a -> v)
>
> class Eval g env t v where
> eval :: env -> g env t v -> v
>
> instance Eval g (a, env) h v =>
> Eval Abs env (g (a, env) h v) (a -> v) where
> eval env (Abs e) = \x -> eval (x, env) e
The type Abs has 3 parameters: its environment, sub term (encoded in
types), and type. The constructor Abs has 1 parameter: its sub term.
The code loads fine in GHC 7.0.3.
Here is the error reported by GHC 7.2.2 (and later):
test.lhs:14:30:
Could not deduce (Eval g1 (a1, env) h1 v1)
arising from a use of `eval'
from the context (Eval g (a, env) h v)
bound by the instance declaration at test.lhs:(12,12)-(13,49)
or from (g (a, env) h v ~ g1 (a1, env) h1 v1,
(a -> v) ~ (a1 -> v1))
bound by a pattern with constructor
Abs :: forall env (g :: * -> * -> * -> *) a h v.
g (a, env) h v -> Abs env (g (a, env) h v) (a -> v),
in an equation for `eval'
at test.lhs:14:15-19
Possible fix:
add (Eval g1 (a1, env) h1 v1) to the context of
the data constructor `Abs'
or the instance declaration
or add an instance declaration for (Eval g1 (a1, env) h1 v1)
In the expression: eval (x, env) e
In the expression: \ x -> eval (x, env) e
In an equation for `eval':
eval env (Abs e) = \ x -> eval (x, env) e
However, if I move the class context to the data constructor of
definition, then it compiles fine in GHC 7.2.2 (and later):
> data Abs env t v where
> Abs :: Eval g (a, env) h v => g (a, env) h v -> Abs env (g (a, env) h v) (a
> -> v)
But this is very troublesome because for every new class instance I
want to make Abs of, I have to make a new class context to the data
constructor. It totally defeats the purpose of making class instances
to extend usage of data types.
Did I missed a language extension when moving code from GHC 7.0.3 to
GHC 7.2.2? What can I do to fix it for newer GHCs?
--
Regards,
Paul Liu
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is this a correct explanation of FRP?
On Thu, Apr 5, 2012 at 4:30 AM, Ertugrul Söylemez wrote: > Paul Liu wrote: > >> > This isn't switching. It's selection. If fullTime decides to be >> > productive, then alterTime acts like fullTime. Otherwise it acts >> > like halfTime. If both inhibit, then alterTime inhibits. This >> > allows for a much more algebraic description of reactive systems. >> >> AFRP can do this through ArrowChoice. Maybe you can explain the >> concept of "inhibition" in more detail? >> >> I fail to grasp why this is making switches obsolete. The idea of >> switch is to completely abandoning the old state. See the broken >> pendulum example. > > Some of this can be done through ArrowChoice. The difference is > comparable to why server parts form a monoid in Happstack. You don't > have to decide when a server part reaches a request. You let the server > part decide itself. In other words ArrowChoice forces you to deal with > events in the application itself: > > -- Library code: > x = x' > y = y' > > -- Application code: > proc inp -> do > r <- request -< () > if p r > then x -< inp > else y -< inp > > Signal inhibition allows the component wires themselves to deal with the > events and you as the higher level programmer to just stick the wires > together: > > -- Library code: > x = proc inp -> do requireReq -< (); x' -< inp > y = y' > > -- Application code: > x <|> y I'm curious as to how this plays out with the usual arrow compositions. How does x *** y behave when x inhibits? what about z >>> x? This cannot replace switching though, since the structure of your arrows cannot change dynamically, while with switches it can. -- Regards, Paul Liu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is this a correct explanation of FRP?
On Sun, Apr 1, 2012 at 7:03 PM, Ertugrul Söylemez wrote: > No, Netwire does things very differently. Note the total absence of > switching combinators. Where in traditional FRP and regular AFRP you > have events and switching in Netwire you have signal inhibition and > selection. AFRP is really just changes the theory to establish some > invariants. Netwire changes the whole paradigm. Review alterTime as > expressed in the Netwire framework: > > alterTime = fullTime <|> halfTime > > This isn't switching. It's selection. If fullTime decides to be > productive, then alterTime acts like fullTime. Otherwise it acts like > halfTime. If both inhibit, then alterTime inhibits. This allows for a > much more algebraic description of reactive systems. AFRP can do this through ArrowChoice. Maybe you can explain the concept of "inhibition" in more detail? I fail to grasp why this is making switches obsolete. The idea of switch is to completely abandoning the old state. See the broken pendulum example. -- Regards, Paul Liu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Conduits: Is Source a valid instance of Monad?
Thanks! I failed to notice this instance declaration in the document.
But I'm still curious as to whether a Monad instance for Source makes
any sense, since in 4.0 all of Source/Conduit/Sink would share the
same implementation.
Regards,
Paul Liu
On Tue, Apr 3, 2012 at 6:25 PM, yi huang wrote:
> On Wed, Apr 4, 2012 at 4:48 AM, Paul Liu wrote:
>>
>> Is there any follow up on this?
>>
>> I was wondering what is the best way to sequence a number of sources
>> together. Anybody gave a further thought on this?
>
>
> I believe sequence sources together can already be done by `Monoid`
> instance.
>
>>
>>
>> Regards,
>> Paul Liu
>>
>> On Tue, Dec 27, 2011 at 3:45 PM, Aristid Breitkreuz
>> wrote:
>> > Hi all,
>> >
>> > As you may have noticed, Michael Snoyman has been working on an
>> > alternative approach to I/O, called conduits. You can find it here:
>> >
>> > https://github.com/snoyberg/conduit
>> >
>> > When looking at the Source type (explained here:
>> > http://www.yesodweb.com/blog/2011/12/conduits), I noticed that they
>> > seem to behave "like lists", and naturally wondered if I could write a
>> > Monad instance for them. But first, let's have a brief look at the
>> > definition of Source:
>> >
>> > data SourceResult a = Open a | Closed
>> >
>> > data PreparedSource m a = PreparedSource
>> > { sourcePull :: ResourceT m (SourceResult a)
>> > , sourceClose :: ResourceT m ()
>> > }
>> >
>> > newtype Source m a = Source { prepareSource :: ResourceT m
>> > (PreparedSource m a) }
>> >
>> > ResourceT deals with resource acquisition and releasing (making sure
>> > that all resources are released), and provides a an abstraction over
>> > IORef/STRef. For our purposes here, ResourceT is probably close enough
>> > to IO.
>> >
>> >
>> > So now the question again is, can we write a Monad instance for this?
>> > I have been able to write join (concatenate) and return (a source with
>> > a single non-repeated) element.
>> >
>> > https://gist.github.com/1525471
>> >
>> > I _think_ it behaves properly like a Monad, but I'm not quite sure,
>> > and neither was Michael. Greg Weber then suggested bringing the
>> > question to this forum. What made the question difficult for me is
>> > that this would be a stateful Monad transformer, so I'm not quite sure
>> > how to test the Monad laws properly.
>> >
>> >
>> > There's a second part to this question: If Source turns out not to be
>> > a Monad, is it possibly a ZipList-like Applicative? And either way,
>> > which is more useful: The list-like or the ziplist-like instances (of
>> > Applicative/Monad)?
>> >
>> >
>> >
>> > Thank you,
>> >
>> > Aristid
>> >
>> > ___
>> > Haskell-Cafe mailing list
>> > Haskell-Cafe@haskell.org
>> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>>
>> --
>> Regards,
>> Paul Liu
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
>
>
> --
> http://yi-programmer.com/
--
Regards,
Paul Liu
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Conduits: Is Source a valid instance of Monad?
Is there any follow up on this?
I was wondering what is the best way to sequence a number of sources
together. Anybody gave a further thought on this?
Regards,
Paul Liu
On Tue, Dec 27, 2011 at 3:45 PM, Aristid Breitkreuz
wrote:
> Hi all,
>
> As you may have noticed, Michael Snoyman has been working on an
> alternative approach to I/O, called conduits. You can find it here:
>
> https://github.com/snoyberg/conduit
>
> When looking at the Source type (explained here:
> http://www.yesodweb.com/blog/2011/12/conduits), I noticed that they
> seem to behave "like lists", and naturally wondered if I could write a
> Monad instance for them. But first, let's have a brief look at the
> definition of Source:
>
> data SourceResult a = Open a | Closed
>
> data PreparedSource m a = PreparedSource
> { sourcePull :: ResourceT m (SourceResult a)
> , sourceClose :: ResourceT m ()
> }
>
> newtype Source m a = Source { prepareSource :: ResourceT m
> (PreparedSource m a) }
>
> ResourceT deals with resource acquisition and releasing (making sure
> that all resources are released), and provides a an abstraction over
> IORef/STRef. For our purposes here, ResourceT is probably close enough
> to IO.
>
>
> So now the question again is, can we write a Monad instance for this?
> I have been able to write join (concatenate) and return (a source with
> a single non-repeated) element.
>
> https://gist.github.com/1525471
>
> I _think_ it behaves properly like a Monad, but I'm not quite sure,
> and neither was Michael. Greg Weber then suggested bringing the
> question to this forum. What made the question difficult for me is
> that this would be a stateful Monad transformer, so I'm not quite sure
> how to test the Monad laws properly.
>
>
> There's a second part to this question: If Source turns out not to be
> a Monad, is it possibly a ZipList-like Applicative? And either way,
> which is more useful: The list-like or the ziplist-like instances (of
> Applicative/Monad)?
>
>
>
> Thank you,
>
> Aristid
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
--
Regards,
Paul Liu
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GLFW-0.5.0.0 is released
On Sat, Jan 21, 2012 at 2:05 PM, Jason Dagit wrote: >> 4. There is an outstanding bug preventing GLFW programs to be invoked >> from GHCi on OS X. One has to compile before running GLFW programs. > > Does it still happen with -fno-ghci-sandbox? That fixes these sort of > bugs with GLFW-b (and other libraries). If so, then the cause of the > problem is the use of thread local storage in the vendor APIs (OpenGL > on OSX is an example). Thanks for the tips! As I'm testing now, ghci -fno-ghci-sandbox only seems to work with dynamically linked libraries, i.e., with GLFW-b, or GLFW installed with "--flags dynamic". Statically compiled GLFW C library would still give the "__NSCFString autoreleased with no pool in place" error. -- Regards, Paul Liu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GLFW-0.5.0.0 is released
There is now a new GLFW package on hackage with version number 0.5.0.0. Maintainers of packages that depend on GLFW may want to update your packages since (1) GLFW-0.4.2 is mostly broken on OS X Lion (10.7); (2) there are incompatible API changes. Notable changes include (but not limited to): 1. It now uses GLFW C library version 2.7.2 on all platforms. 2. It still tries to compile and build a static version of the C library on all platforms. If this is not what you want, use '--flags dynamic' to dynamically link to pre-installed glfw C library on your system. 3. It nows does a much better job at configuring itself on Linux and FreeBSD. 4. There is an outstanding bug preventing GLFW programs to be invoked from GHCi on OS X. One has to compile before running GLFW programs. 5. Documentation has been improved, and there are also API changes affecting window params and hints. See the hackage documentation for details. 6. An example program and detail change log are included if you unpack the source. Many thanks to Marc Sunet and a lot of other people for sending in bug reports and helping out with this upgrade. Marc is now also a maintainer of this package. Please send your bug report to either of us or to the GLFW mailing list . For new users to GLFW or GLFW-b, there are some style and API differences between these two packages (see https://github.com/bsl/GLFW-b/blob/master/README.md), and in particular, GLFW includes some basic texture support and a "quick-and-dirty" font rendering hack (not found in GLFW C library). Now, more on the outstanding bug with GHCi on OS X. Here is what happens when invoking initialize from GHCi on OS X: Prelude> import Graphics.UI.GLFW Prelude Graphics.UI.GLFW> initialize Loading package OpenGLRaw-1.1.0.1 ... linking ... done. Loading package GLURaw-1.1.0.0 ... linking ... done. Loading package ObjectName-1.0.0.0 ... linking ... done. Loading package StateVar-1.0.0.0 ... linking ... done. Loading package Tensor-1.0.0.1 ... linking ... done. Loading package OpenGL-2.4.0.1 ... linking ... done. Loading package GLFW-0.5.0.0 ... linking ... done. objc[18039]: Object 0x105e00a70 of class __NSCFString autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug 2012-01-21 03:23:58.574 ghc[18039:1303] -[NSAutoreleasePool init]: unrecognized selector sent to instance 0x105e00740 2012-01-21 03:23:58.577 ghc[18039:1303] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NSAutoreleasePool init]: unrecognized selector sent to instance 0x105e00740' On the other hand, if GLFW is installed with the dynamic flag to link to a pre-installed system libglfw.dylib, then initialize would work fine but again GLFW applications still fail to run properly as the window fails to receive user input and seems to hang. The enableGUI hack wouldn't help either (and is broken on 10.7). I believe this situation is the same when running GLFW-b applications from GHCi on OS X, since it builds and installs dynamic library on OS X too. Compiled applications are not affected by this bug. Any help is greatly appreciated! Thanks! -- Regards, Paul Liu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] Call for GUI examples - Functional Reactive Programming
Hi James, I think you meant to reply to the list. For one, I wouldn't consider GUI programming based on HTML as declarative, since more often than not, the format says nothing about its behavior, and when it does, it's through javascript, which is hardly declarative. Regards, Paul Liu On Tue, Jul 12, 2011 at 5:17 AM, James Deng wrote: > These days, more and more GUI programming are done in declarative, such as > HTML(jQuery), Mozilla XUL, android UI XML. > > Haskell is an excellent declarative language, so should have the advantages > of constructing GUI in declarative, intuitive and powerful way. But so far, > there is not such a GUI library intuitive like Html, powerful like XUL. > > I expect something like html to layout GUI, and a haskell GUI engine would > render the user interfaces files. > Where is the gap lying? > > On 07/12/2011 05:51 AM, Paul Liu wrote: > > You guys might want to checkout the recent work on Euterpea at Yale > CS. In particular: > > 1. Paul Hudak is writing a new book. > http://plucky.cs.yale.edu/cs431/reading.htm > 2. It uses FRP and arrows for sound synthesis. > 3. It combines FRP signals with monadic (which recently gets > re-written in arrows) GUI composition. > 4. New novel techniques is being developed to handle I/O within arrows > framework. > > The code can be obtained through darcs, details at > http://plucky.cs.yale.edu/cs431/software_resources.htm > > Notably, the way it handles GUI is that the composition of widgets are > static, but the signals flowing between them are dynamic. This closely > follows Conal Elliott's Phooey approach, and greatly reduces the > complexity of GUI programming. > > Disclaimer: I was an ex-student who worked on this project. > > Regards, > Paul Liu > > On Thu, Jul 7, 2011 at 11:08 PM, Heinrich Apfelmus > wrote: > > Dear Haskellers, > > Can GUI programming be liberated from the IO monad? > > > Regards, > -- > James Deng > http://cnjdeng.appspot.com -- Regards, Paul Liu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Call for GUI examples - Functional Reactive Programming
The original SOE had some FAL (functional animation) stuff, but I don't think it used specifically the word FRP. Certainly the concept of a first-class signal (behavior and event) was present. Regards, Paul Liu On Mon, Jul 11, 2011 at 3:22 PM, Yves Parès wrote: >> 1. Paul Hudak is writing a new book. >> http://plucky.cs.yale.edu/cs431/reading.htm > > Wow... this is going to be my bedside reading. > > I haven't read the original Haskell School of Expression, did it use FRP > back then? > > 2011/7/11 Paul Liu >> >> You guys might want to checkout the recent work on Euterpea at Yale >> CS. In particular: >> >> 1. Paul Hudak is writing a new book. >> http://plucky.cs.yale.edu/cs431/reading.htm >> 2. It uses FRP and arrows for sound synthesis. >> 3. It combines FRP signals with monadic (which recently gets >> re-written in arrows) GUI composition. >> 4. New novel techniques is being developed to handle I/O within arrows >> framework. >> >> The code can be obtained through darcs, details at >> http://plucky.cs.yale.edu/cs431/software_resources.htm >> >> Notably, the way it handles GUI is that the composition of widgets are >> static, but the signals flowing between them are dynamic. This closely >> follows Conal Elliott's Phooey approach, and greatly reduces the >> complexity of GUI programming. >> >> Disclaimer: I was an ex-student who worked on this project. >> >> Regards, >> Paul Liu >> >> On Thu, Jul 7, 2011 at 11:08 PM, Heinrich Apfelmus >> wrote: >> > Dear Haskellers, >> > >> > Can GUI programming be liberated from the IO monad? >> >> >> -- >> Regards, >> Paul Liu >> >> ___ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- Regards, Paul Liu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Call for GUI examples - Functional Reactive Programming
You guys might want to checkout the recent work on Euterpea at Yale CS. In particular: 1. Paul Hudak is writing a new book. http://plucky.cs.yale.edu/cs431/reading.htm 2. It uses FRP and arrows for sound synthesis. 3. It combines FRP signals with monadic (which recently gets re-written in arrows) GUI composition. 4. New novel techniques is being developed to handle I/O within arrows framework. The code can be obtained through darcs, details at http://plucky.cs.yale.edu/cs431/software_resources.htm Notably, the way it handles GUI is that the composition of widgets are static, but the signals flowing between them are dynamic. This closely follows Conal Elliott's Phooey approach, and greatly reduces the complexity of GUI programming. Disclaimer: I was an ex-student who worked on this project. Regards, Paul Liu On Thu, Jul 7, 2011 at 11:08 PM, Heinrich Apfelmus wrote: > Dear Haskellers, > > Can GUI programming be liberated from the IO monad? -- Regards, Paul Liu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
