Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
Hi Atze. I'm glad to hear that some work is going into wxHaskell. Do you know about the issue that arose roughly 7-8 years ago that prevented opening more than one top-level window per process? It had to do with a change to initialization techniques, and made wxHaskell no longer useful with GHCi. -- Conal On Wed, Oct 2, 2013 at 3:24 AM, Atze Dijkstra a...@uu.nl wrote: Hi, as for wxHaskell, it is currently maintained at https://github.com/wxHaskell/wxHaskell, compilable with wxWidgets 2.9.5 and GHC 7.6. Work is underway to fix various bugs introduced over time by changes in wxWidgets, but we (i.e. https://github.com/wxHaskell?tab=members) hope to release announce in not too much time. cheers, Atze On 30 Sep, 2013, at 20:32 , Conal Elliott co...@conal.net wrote: Hi Conrad, Great. The challenge is not specific to Pan, Vertigo, etc. If we can get some low-level GUI platform working with the characteristics I listed, I can resurrect and my high-level libraries accordingly. Any GUI program containing at least one OpenGL window would probably get us most of the way there (again, noting the properties I listed). -- Conal On Fri, Sep 27, 2013 at 1:40 AM, Conrad Parker con...@metadecks.org wrote: Hi Conal! Yes. I'd be very interested to help get Pan and Vertigo working. Do you have a repo somewhere? Conrad. On 27 September 2013 13:32, Conal Elliott co...@conal.net 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe - Atze - Atze Dijkstra, Department of Information and Computing Sciences. /|\ Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands. / | \ Tel.: +31-30-2534118/1454 | WWW : http://www.cs.uu.nl/~atze . /--| \ Fax : +31-30-2513971 | Email: a...@uu.nl ... / |___\ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
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 nine...@gmail.com 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 carter.schonw...@gmail.com 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 nine...@gmail.com 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 carter.schonw...@gmail.com 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 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
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
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 nine...@gmail.com 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 co...@conal.net 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 nine...@gmail.com 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 carter.schonw...@gmail.com 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 nine...@gmail.com 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 carter.schonw...@gmail.com 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
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
Hi Conrad, Great. The challenge is not specific to Pan, Vertigo, etc. If we can get some low-level GUI platform working with the characteristics I listed, I can resurrect and my high-level libraries accordingly. Any GUI program containing at least one OpenGL window would probably get us most of the way there (again, noting the properties I listed). -- Conal On Fri, Sep 27, 2013 at 1:40 AM, Conrad Parker con...@metadecks.org wrote: Hi Conal! Yes. I'd be very interested to help get Pan and Vertigo working. Do you have a repo somewhere? Conrad. On 27 September 2013 13:32, Conal Elliott co...@conal.net 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
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
[Haskell-cafe] Looking for ICFP roommate
I'm looking for an ICFP roommate. I plan to attend Sunday through Saturday and stay the nights of Saturday the 21st through Saturday the 28th. I missed the discounted price of $225 (yipes) at the Airport Hilton (sold out). Perhaps someone already has a room reserved with two beds or could switch to one with two beds and would like to reduce their cost by room-sharing for part or all of their stay. If so, please let me know. Thanks, - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Categories with associated constraints?
Has anyone given a go at a Category class and friends (including cartesian and closed) with associated constraints (presumably using the ConstraintKinds language extension)? I gave it a try a while back and wasn't able to keep the signatures from getting very complicated. Thanks, -- Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Module import and use in GHC plugin?
In writing GHC plugins, how can I (a) add a module import (preferably qualified) and (b) make vars/ids for names imported from the newly imported module (to insert in the transformed Core code)? Thanks, - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Lambda expressions (core) to categorical form
I want to convert lambda expressions into a vocabulary of monoidal categories, so that they can be given multiple interpretations, including circuit generation and timing analysis, and hopefully some other far-out alternatives (3D visualization, animated evaluation, etc). More specifically, I want a GHC plugin that makes this transformation on GHC's Core language. If you know of related work, have suggestions, and/or are interested in collaborating/consulting, I'd love to hear. Thanks, - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Constrained Category, Arrow, ArrowChoice, etc?
: the identity arrow for that object. But this then turns id into cat a a - cat a a, which is quite useless. So I had to borrow from the arrows-only description of categories, which has source and target operations that give the source and target identity arrows for each arrow. Because of the requirement that every value is a valid arrow, there's no need to change the definition of composition. In the code you can see that I have to do a lot of pattern matching. This is to make the constraints inside the arrows available. Admittedly passing around proof values instead of relying on constraints gives the whole library quite a unhaskelly feel, but it's the only way I could find that really works well. And often it is possible to provide a public API for a specific category that constructs the proof values from the constraints, like I have done with fstL and sndL in the gist. I hope this helps you implement your ideas further. Your reimagining matrices post was really superb and I'd love to learn more! greetings, Sjoerd On May 8, 2013, at 12:09 AM, Conal Elliott co...@conal.net wrote: I'm using a collection of classes similar to Category, Arrow, ArrowChoice, etc (though without arr and with methods like fst, snd, dup, etc). I think I need some associated constraints (via ConstraintKinds), so I've tried adding them. However, I'm getting terribly complex multiplication of these constraints in the signatures of method defaults and utility functions, and I don't know how to tame them. Has anyone tried adding associated constraints to Category etc? Thanks, -- Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Categories (cont.)
Hi Wren,
Have you taken this constrained categories experiment further,
particularly for adding products? As I mentioned in a haskell-cafe note
yesterday, I tried and got a frightening proliferation of constraints when
defining method defaults and utility functions (e.g., left- or
right-associating).
-- Conal
On Fri, Dec 21, 2012 at 8:59 PM, wren ng thornton w...@freegeek.org wrote:
On 12/21/12 2:35 PM, Chris Smith wrote:
It would definitely be nice to be able to work with a partial Category
class, where for example the objects could be constrained to belong to a
class. One could then restrict a Category to a type level representation
of the natural numbers or any other desired set. Kind polymorphism should
make this easy to define, but I still don't have a good feel for whether
it
is worth the complexity.
Actually, what you really want is ConstraintKinds. The following works
just fine in GHC 7.6.1:
{-# LANGUAGE KindSignatures
, ConstraintKinds
, PolyKinds
, TypeFamilies
, MultiParamTypeClasses
, FunctionalDependencies
, FlexibleInstances
, FlexibleContexts
#-}
class Category (c :: k - k - *) where
-- | The kind of domain objects.
type DomC c x :: Constraint
-- | The kind of codomain objects.
type CodC c x :: Constraint
-- | The identity morphisms.
id :: (ObjC c x) = c x x
-- | Composition of morphisms.
(.) :: (DomC c x, ObjC c y, CodC c z) = c y z - c x y - c x z
-- | An alias for objects in the centre of a category.
type ObjC c x = (Category c, DomC c x, CodC c x)
-- | An alias for a pair of objects which could be connected by a
-- @c@-morphism.
type HomC c x y = (Category c, DomC c x, CodC c y)
Notably, we distinguish domain objects from codomain objects in order to
allow morphisms into or out of the category, which is indeed helpful in
practice.
Whether there's actually any good reason for distinguishing DomC and CodC,
per se, remains to be seen. In Conal Elliott's variation[1] he moves HomC
into the class and gets rid of DomC and CodC. Which allows constraints that
operate jointly on both the domain and codomain, whereas the above version
does not. I haven't run into the need for that yet, but I could easily
imagine it. It does add a bit of complication though since we can no longer
have ObjC be a derived thing; it'd have to move into the class as well, and
we'd have to somehow ensure that it's coherent with HomC.
The above version uses PolyKinds as well as ConstraintKinds. I haven't
needed this myself, since the constraints act as a sort of kind for the
types I'm interested in, but it'll definitely be useful if you get into
data kinds, or want an instance of functor categories, etc.
[1] https://github.com/conal/**linear-map-gadt/blob/master/**
src/Control/ConstraintKinds/**Category.hshttps://github.com/conal/linear-map-gadt/blob/master/src/Control/ConstraintKinds/Category.hs
--
Live well,
~wren
__**_
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Constrained Category, Arrow, ArrowChoice, etc?
I'm using a collection of classes similar to Category, Arrow, ArrowChoice, etc (though without arr and with methods like fst, snd, dup, etc). I think I need some associated constraints (via ConstraintKinds), so I've tried adding them. However, I'm getting terribly complex multiplication of these constraints in the signatures of method defaults and utility functions, and I don't know how to tame them. Has anyone tried adding associated constraints to Category etc? Thanks, -- Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Instances for continuation-based FRP
Hi Hans.
I'm delighted to hear that you have a precise denotation to define
correctness of your implementation. So much of what gets called FRP these
days abandons any denotational foundation, as well as continuous time,
which have always been the two key properties of
FRPhttp://stackoverflow.com/a/5878525/127335for me.
I like your goal of finding a provably correct (perhaps correct by
construction/derivation) implementation of the simple denotational
semantics. I'm happy to give feedback and pointers if you continue with
this goal.
While I like the idea of TCMs very much, they do not seem to be applicable
for things that lack a denotation, such as IO
I suppose so, although I'd say it the other way around: things that lack
denotation are not applicable for fulfilling denotational principles. Which
suggests to me that IO will not get you to your goal. Instead, I recommend
instead looking for a subset of imperative computation that suffices to
implement the denotation you want, but is well-defined denotationally and
tractable for reasoning. IO (general imperative computation) is neither,
which is why we have denotative/functional programming in the first place.
Regards, - Conal
On Wed, Apr 24, 2013 at 8:31 AM, Hans Höglund h...@hanshoglund.se wrote:
Hi Conal,
Thank you for replying.
My aim is to find the simplest possible implementation of the semantics
you describe in Push-pull FRP http://conal.net/papers/push-pull-frp/,
so the denotational semantics are already in place. I guess what I am
looking for is a simple translation of a denotational program into an
imperative one. My intuition tells me that such a translation is possible,
maybe even trivial, but I am not sure how to reason about correctness.
While I like the idea of TCMs very much, they do not seem to be applicable
for things that lack a denotation, such as IO. Maybe it is a question of
how to relate denotational semantics to operational ones?
Hans
On 24 apr 2013, at 02:18, Conal Elliott wrote:
Hi Hans,
Do you have a denotation for your representation (a specification for your
implementation)? If so, it will likely guide you to exactly the right type
class instances, via the principle of type class
morphismshttp://conal.net/papers/type-class-morphisms/(TCMs). If you don't
have a denotation, I wonder how you could decide what
correctness means for any aspect of your implementation.
Good luck, and let me know if you want some help exploring the TCM process,
-- Conal
On Tue, Apr 23, 2013 at 6:22 AM, Hans Höglund h...@hanshoglund.se wrote:
Hi everyone,
I am experimenting with various implementation styles for classical FRP.
My current thoughts are on a continuation-style push implementation, which
can be summarized as follows.
newtype EventT m r a= E { runE :: (a - m r) - m r - m r }
newtype ReactiveT m r a = R { runR :: (m a - m r) - m r }
type Event= EventT IO ()
type Reactive = ReactiveT IO ()
The idea is that events allow subscription of handlers, which are
automatically unsubscribed after the continuation has finished, while
reactives allow observation of a shared state until the continuation has
finished.
I managed to write the following Applicative instance
instance Applicative (ReactiveT m r) where
pure a = R $ \k - k (pure a)
R f * R a = R $ \k - f (\f' - a (\a' - k $ f' * a'))
But I am stuck on finding a suitable Monad instance. I notice the
similarity between my types and the ContT monad and have a feeling this
similarity could be used to clean up my instance code, but am not sure how
to proceed. Does anyone have an idea, or a pointer to suitable literature.
Best regards,
Hans
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Instances for continuation-based FRP
Hi Jared, Oh -- does Elm have a denotational semantics? I haven't heard of one. I just now skimmed the informal description of the Signal typehttp://elm-lang.org/docs/Signal/Signal.elm, and from the reference to updates in the description of merge, it sound like whatever semantics it might have, it couldn't be function-of-time. I'm intrigued with your interpretation. I wonder what it could mean for an event to be a derivative, especially partial one, and for arbitrary types. -- Conal On Wed, Apr 24, 2013 at 1:48 PM, earl obscure theanswertoprobl...@gmail.com wrote: Hi Conal, Caveat pre-emptor I'm new to haskell, frp, etc .. anyway how I was interpreting Elm's Eventbased strict FRP, was that each event was the partial derivative of the continuous time variable, and then since it was being strict, it would evaluate the tangent line or state of the system at that point, only update when necessary. Now related to Continuations, this is something I've been thinking about as well,but haven't gotten very far; apparently cont monad, and comonad are closely related. I was hoping to use the comonad rules, extend/duplicate to encode different continuations paths, and then extract when, a continuation path is chosen. Was hoping maybe the analog would be PDE's, or something more general than my interpretation of Elm's FRP. These are just random thoughts that I wanted to get out. Thanks. Jared Nicholson. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Instances for continuation-based FRP
The intuition intrigues me. If, upon inspection, it survives morphs into something else, I'd like to hear about it. Good luck! -- Conal The object of mathematical rigor is to sanction and legitimize the conquests of intuition, and there was never any other object for it. - Jacques Hadamard I call intuition cosmic fishing. You feel a nibble, then you've got to hook the fish. -- Buckminster Fullero On Wed, Apr 24, 2013 at 7:26 PM, earl obscure theanswertoprobl...@gmail.com wrote: His description of the different frp approaches starts at section 2.1 of the thesis. http://www.testblogpleaseignore.com/wp-content/uploads/2012/04/thesis.pdfThen in 3.1 describes implementation of discrete signals. I don't think he gives a denotational semantics. I was thinking, the event, is the derivative of the specific continuous signal it corresponds to, all other continuous signals of the system held equal. Applying the partial derivative, is like sampling, or discrete time stepping. But it is samplying the entire state, or multivariate structure not just the specific symbol. This made more sense unarticulated. I'll need to think a bit. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Instances for continuation-based FRP
Hi Hans,
Do you have a denotation for your representation (a specification for your
implementation)? If so, it will likely guide you to exactly the right type
class instances, via the principle of type class
morphismshttp://conal.net/papers/type-class-morphisms/(TCMs). If you
don't have a denotation, I wonder how you could decide what
correctness means for any aspect of your implementation.
Good luck, and let me know if you want some help exploring the TCM process,
-- Conal
On Tue, Apr 23, 2013 at 6:22 AM, Hans Höglund h...@hanshoglund.se wrote:
Hi everyone,
I am experimenting with various implementation styles for classical FRP.
My current thoughts are on a continuation-style push implementation, which
can be summarized as follows.
newtype EventT m r a= E { runE :: (a - m r) - m r - m r }
newtype ReactiveT m r a = R { runR :: (m a - m r) - m r }
type Event= EventT IO ()
type Reactive = ReactiveT IO ()
The idea is that events allow subscription of handlers, which are
automatically unsubscribed after the continuation has finished, while
reactives allow observation of a shared state until the continuation has
finished.
I managed to write the following Applicative instance
instance Applicative (ReactiveT m r) where
pure a = R $ \k - k (pure a)
R f * R a = R $ \k - f (\f' - a (\a' - k $ f' * a'))
But I am stuck on finding a suitable Monad instance. I notice the
similarity between my types and the ContT monad and have a feeling this
similarity could be used to clean up my instance code, but am not sure how
to proceed. Does anyone have an idea, or a pointer to suitable literature.
Best regards,
Hans
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Prolog-style patterns
Hi Jan, What you're suggesting is called non-linear patterns, and it's a perfectly sensible, well-defined feature in a language with pattern-matching. As you point out, non-linearity allows for more direct succinct programming. I've often wished for this feature when writing optimizations on data types, especially for syntactic types (languages). As Ivan mentioned, there is some danger that people may accidentally a non-linear pattern accidentally, and perhaps the early Haskell designers chose the linearity restriction out of this worry. The importance of such dangers is a subjective call, and certainly not one carried out consistently in Haskell. Consider, for instance, the choice that let where bindings are recursive by default in Haskell, unlike ML and Lisp. I like this choice, but I can understand objections that it leads to accidental recursions, especially for non-functions. -- Conal On Mon, Apr 8, 2013 at 6:11 AM, Jan Stolarek jan.stola...@p.lodz.pl wrote: You can achieve something similar with the ViewPatterns language extension. member _ [] = False member x (((x ==) - True) : _) = True member x (_ : xs) = member x xs Hi Tillmann, there are a couple of ways to achieve this in Haskell, for example using guards: member :: Eq a = a - [a] - Bool member _ [] = False member y (x:_) | x == y = True member y (_:xs) = member y xs The goal of my proposal is to provide a concise syntax, whereas ViewPatterns are very verbose and guards are slightly verbose. I want something simple and something that is very intuitive if you've programmed in Prolog :) Janek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimizing Fold Expressions
You can use a general fold and unfold, without any type-specific
programming if you re-express Expr as the least fixed point of its
underlying base functor:
data ExprF a = Add a a | Sub a a | Mul a a | Eq a a | B Bool | I Int
deriving (Show,Functor)
data Expr = Fix ExprF
Then use the standard definitions:
newtype Fix f = Roll { unRoll :: f (Fix f) }
fold :: Functor f = (f b - b) - (Fix f - b)
fold h = h . fmap (fold h) . unRoll
unfold :: Functor f = (a - f a) - (a - Fix f)
unfold g = Roll . fmap (unfold g) . g
Also handy:
hylo :: Functor f = (f b - b) - (a - f a) - (a - b)
hylo h g = fold h . unfold g
For details, see Jeremy Gibbons's paper Calculating functional programs.
There are probably easier sources as well.
-- Conal
On Sat, Mar 30, 2013 at 11:45 AM, J. J. W. bsc.j@gmail.com wrote:
Dear all,
I was wondering whether it was possible to write fold expressions more
elegantly. Suppose I have the following
datastructure:
data Expr = Add Expr Expr
| Sub Expr Expr
| Mul Expr Expr
| Eq Expr Expr
| B Bool
| I Int
deriving Show
type ExprAlgebra r = (r - r - r, -- Add
r - r - r, -- Sub
r - r - r, -- Mul
r - r - r, -- Eq
Bool - r, -- Bool
Int - r -- Int
)
foldAlgebra :: ExprAlgebra r - Expr - r
foldAlgebra alg@(a, b, c ,d, e, f) (Add x y) = a (foldAlgebra alg x)
(foldAlgebra alg y)
foldAlgebra alg@(a, b, c ,d, e, f) (Sub x y) = b (foldAlgebra alg x)
(foldAlgebra alg y)
foldAlgebra alg@(a, b, c ,d, e, f) (Mul x y) = c (foldAlgebra alg x)
(foldAlgebra alg y)
foldAlgebra alg@(a, b, c ,d, e, f) (Eq x y) = d (foldAlgebra alg x)
(foldAlgebra alg y)
foldAlgebra alg@(a, b, c ,d, e, f) (B b')= e b'
foldAlgebra alg@(a, b, c ,d, e, f) (I i) = f i
If I am correct, this works, however if we for example would like to
replace all Int's by booleans (note: this is to illustrate my problem):
replaceIntByBool = foldAlgebra (Add, Sub, Mul, Eq, B, \x - if x == 0 then
B False else B True)
As you can see, a lot of useless identity code. Can I somehow optimize
this? Can someone give me some pointers how I can write this more clearly
(or with less code?) So I constantly don't have to write Add, Sub, Mul, for
those things that I just want an identity function?
Thanks in advance!
Jun Jie
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: data-fix-cse -- Common subexpression elimination for EDSLs
On Tue, Feb 19, 2013 at 9:28 PM, Anton Kholomiov anton.kholom...@gmail.comwrote: Do you think the approach can be extended for non-regular (nested) algebraic types (where the recursive data type is sometimes at a different type instance)? For instance, it's very handy to use GADTs to capture embedded language types in host language (Haskell) types, which leads to non-regularity. I'm not sure I understand the case you are talking about. Can you write a simple example of the types like this? Here's an example of a type-embedded DSEL, represented as a GADT: data E :: * - * where Lit :: Show a = a - E a Op :: Op a - E a App :: E (a - b) - E a - E b ... data Op :: * - * where Add :: Num a = E (a - a - a) Mul :: Num a = E (a - a - a) Neg :: Num a = E (a - a) ... -- Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: data-fix-cse -- Common subexpression elimination for EDSLs
What a delightfully elegant approach to CSE! I've been thinking about CSE
for DSELs and about functor fixpoints, but it never occurred to me to put
the two together.
Do you think the approach can be extended for non-regular (nested)
algebraic types (where the recursive data type is sometimes at a different
type instance)? For instance, it's very handy to use GADTs to capture
embedded language types in host language (Haskell) types, which leads to
non-regularity.
- Conal
On Tue, Feb 19, 2013 at 3:10 AM, Anton Kholomiov
anton.kholom...@gmail.comwrote:
I'm glad to announce the package for Common subexpression elimination [1].
It's an implementation of the hashconsig algorithm as described in the
paper
'Implementing Explicit and Finding Implicit Sharing in EDSLs' by Oleg
Kiselyov.
Main point of the library is to define this algorithm in the most generic
way.
You can define the AST for your DSL as fixpoint type[2]. And then all you
need
to use the library is to define the instance for type class `Traversable`.
This idea is inspired by `data-reify` [3] package which you can use to
transform
your ASTs to DAGs too. But it relies on inspection of the references for
values
when `data-fix-cse` doesn't sacrifices the purity.
A short example:
Let's define a tiny DSL for signals
import Data.Fix
type Name = String
type E = Fix Exp
data Exp a = Const Double | ReadPort Name | Tfm Name [a] | Mix a a
deriving (Show, Eq, Ord)
We can make constant signals, read them from some ports and transform them
(apply some named function to the list of signals) and mix two signals.
Let's define an instance of the Traversable (hence for the Functor and
Foldable)
import Control.Applicative
import Data.Monoid
import Data.Traversable
import Data.Foldable
instance Functor Exp where
fmap f x = case x of
Const d - Const d
ReadPort n - ReadPort n
Mix a b - Mix (f a) (f b)
Tfm n as - Tfm n $ fmap f as
instance Foldable Exp where
foldMap f x = case x of
Mix a b - f a f b
Tfm n as - mconcat $ fmap f as
_ - mempty
instance Traversable Exp where
traverse f x = case x of
Mix a b - Mix $ f a * f b
Tfm n as - Tfm n $ traverse f as
a - pure a
Now we can use the functio `cse`
cse ::
(Eqhttp://hackage.haskell.org/packages/archive/base/4.6.0.1/doc/html/Data-Eq.html#t:Eq(f
Inthttp://hackage.haskell.org/packages/archive/base/4.6.0.1/doc/html/Data-Int.html#t:Int),
Ordhttp://hackage.haskell.org/packages/archive/base/4.6.0.1/doc/html/Data-Ord.html#t:Ord(f
Inthttp://hackage.haskell.org/packages/archive/base/4.6.0.1/doc/html/Data-Int.html#t:Int),
Traversablehttp://hackage.haskell.org/packages/archive/base/4.6.0.1/doc/html/Data-Traversable.html#t:Traversablef)
=
Fixhttp://hackage.haskell.org/packages/archive/data-fix/0.0.1/doc/html/Data-Fix.html#t:Fixf
-
Daghttp://hackage.haskell.org/packages/archive/data-fix-cse/0.0.1/doc/html/Data-Fix-Cse.html#t:Dagf
to transform our AST to DAG. DAG is already sorted.
Later we can define a handy wrapper to hide the details from the client
newtype Sig = Sig { unSig :: E }
You can find examples in the package archive
Extra-Source-Files:
test/Exp.hs
test/Impl.hs
test/Expl.hs
If you want to see a real world example of usage you can find it
in the csound-expression[4]. An edsl for the Csound language.
One side-note form my experience: Fixpoint types can be very flexible.
It's easy to compose them. If suddenly we need to add some extra data
to all cases from the example above we can easily do it with just another
Functor:
Imagine that we want to use a SampleRate value with all signals.
Then we can do it like this:
type E = Fix SampledExp
data SampledExp a = SampledExp SampleRate (Exp a)
then we should define an instance of the type class Traversable
for our new type SampleRate. The Exp doesn't change.
[1] http://hackage.haskell.org/package/data-fix-cse-0.0.1
[2] http://hackage.haskell.org/package/data-fix-0.0.1
[3] http://hackage.haskell.org/package/data-reify
[4] http://hackage.haskell.org/package/csound-expression
Anton
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] arrow notation
On Thu, Feb 7, 2013 at 5:41 PM, Ross Paterson r...@soi.city.ac.uk wrote: On Thu, Feb 07, 2013 at 02:49:40PM -0800, Conal Elliott wrote: I make some use of arrow notation, though sadly I often have to avoid it because my (pseudo-)arrows don't have arr. I'd love to see a variant that has restricted expressiveness in exchange for arr-freeness. It's hard to imagine arrow notation without arr (or at least contravariance in the first argument of the arrow) because forming expressions using the local environment is so central to it. That is, I can't imagine what things you are trying to write in that situation. What I have in mind is a small collection of methods including fst snd (and similarly for sums) that could be defined via arr but could instead form the basis of translating restricted arrow notation for (pseudo-)arrows that don't support arr. I keep running into these pseudo-arrows in practical work. The reliance of arrow notation on arr means that I can't use arrow notation, and my code is terribly difficult to read. -- Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] arrow notation
Hi Ross, I make some use of arrow notation, though sadly I often have to avoid it because my (pseudo-)arrows don't have arr. I'd love to see a variant that has restricted expressiveness in exchange for arr-freeness. -- Conal On Thu, Feb 7, 2013 at 6:08 AM, Ross Paterson r...@soi.city.ac.uk wrote: I'd like to hear from anyone who's using arrow notation as supported by GHC, because I'm planning a couple of changes to parts of it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Advice on type families and non-injectivity?
There is a real difficulty here with type-checking 'bar'. (And that
difficulty is why 'foo' is also rejected.)
Oh! Is the definition of 'foo' rejected in recent versions of GHC? My 7.4.1
installation doesn't complain. -- Conal
On Mon, Jan 14, 2013 at 3:39 AM, Simon Peyton-Jones
simo...@microsoft.comwrote:
| {-# LANGUAGE TypeFamilies #-}
|
| type family F a
|
| foo :: F a
| foo = undefined
|
| bar :: F a
| bar = foo
There is a real difficulty here with type-checking 'bar'. (And that
difficulty is why 'foo' is also rejected.)
Namely, when typechecking 'bar', we must instantiate foo with an unknown
type, say alpha. So now we must find a type 'alpha' such that
F a ~ F alpha
Certainly alpha=1 is one solution, but there might be others. For
example, suppose
type instance F [b] = F b
Then alpha=[a] would also be a solution.
In this particular case any solution will do, but suppose there was an
addition constraint (C alpha) arising from the right hand side, where C is
a class. Then if we had
instance C [b] where ...
then the second solution (alpha=[a]) would work, but not the first. This
can get arbitrarily complicated, and GHC's type inference does not search
various solutions; it follows one path.
The solution is to provide a way to fix alpha. For example,
foo :: a - F a
is fine.
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-
| users-boun...@haskell.org] On Behalf Of Richard Eisenberg
| Sent: 14 January 2013 03:47
| To: Conal Elliott
| Cc: glasgow-haskell-us...@haskell.org; Haskell Cafe
| Subject: Re: Advice on type families and non-injectivity?
|
| Hi Conal,
|
| I agree that your initial example is a little puzzling, and I'm glad
| that the new ambiguity checker prevents both definitions, not just one.
|
| However, your initial question seems broader than just this example. I
| have run into this problem (wanting injective type functions) several
| times myself, and have been successful at finding workarounds. But, I
| can't think of any unifying principle or solid advice. If you can post
| more information about your problem, perhaps I or others can contribute.
|
| For what it's worth, the desire for injective type functions has been
| entered as ticket #6018 in the GHC Trac, but I see you're already on the
| cc: list. I believe Simon PJ has given serious thought to implementing
| this feature and may have even put in some very basic code toward this
| end.
|
| Richard
|
| On Jan 13, 2013, at 2:10 PM, Conal Elliott co...@conal.net wrote:
|
| I sometimes run into trouble with lack of injectivity for type
| families. I'm trying to understand what's at the heart of these
| difficulties and whether I can avoid them. Also, whether some of the
| obstacles could be overcome with simple improvements to GHC.
|
| Here's a simple example:
|
| {-# LANGUAGE TypeFamilies #-}
|
| type family F a
|
| foo :: F a
| foo = undefined
|
| bar :: F a
| bar = foo
|
| The error message:
|
| Couldn't match type `F a' with `F a1'
| NB: `F' is a type function, and may not be injective
| In the expression: foo
| In an equation for `bar': bar = foo
|
| A terser (but perhaps subtler) example producing the same error:
|
| baz :: F a
| baz = baz
|
| Replacing `a` with a monotype (e.g., `Bool`) eliminates the error.
|
| Does the difficulty here have to do with trying to *infer* the type
| and then compare with the given one? Or is there an issue even with type
| *checking* in such cases?
|
| Other insights welcome, as well as suggested work-arounds.
|
| I know about (injective) data families but don't want to lose the
| convenience of type synonym families.
|
| Thanks, -- Conal
|
| ___
| Glasgow-haskell-users mailing list
| glasgow-haskell-us...@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|
|
| ___
| Glasgow-haskell-users mailing list
| glasgow-haskell-us...@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Advice on type families and non-injectivity?
Thanks, Jake! This suggestion helped a lot. -- Conal
On Sun, Jan 13, 2013 at 1:59 PM, Jake McArthur jake.mcart...@gmail.comwrote:
I have a trick that loses a little convenience, but may still be more
convenient than data families.
{-# LANGUAGE TypeFamilies #-}
import Data.Tagged
type family F a
foo :: Tagged a (F a)
foo = Tagged undefined
bar :: Tagged a (F a)
bar = foo
This allows you to use the same newtype wrapper consistently, regardless
of what the type instance actually is; one of the inconveniences of data
families is the need to use different constructors for different types.
On Sun, Jan 13, 2013 at 2:10 PM, Conal Elliott co...@conal.net wrote:
I sometimes run into trouble with lack of injectivity for type families.
I'm trying to understand what's at the heart of these difficulties and
whether I can avoid them. Also, whether some of the obstacles could be
overcome with simple improvements to GHC.
Here's a simple example:
{-# LANGUAGE TypeFamilies #-}
type family F a
foo :: F a
foo = undefined
bar :: F a
bar = foo
The error message:
Couldn't match type `F a' with `F a1'
NB: `F' is a type function, and may not be injective
In the expression: foo
In an equation for `bar': bar = foo
A terser (but perhaps subtler) example producing the same error:
baz :: F a
baz = baz
Replacing `a` with a monotype (e.g., `Bool`) eliminates the error.
Does the difficulty here have to do with trying to *infer* the type and
then compare with the given one? Or is there an issue even with type
*checking* in such cases?
Other insights welcome, as well as suggested work-arounds.
I know about (injective) data families but don't want to lose the
convenience of type synonym families.
Thanks, -- Conal
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Advice on type families and non-injectivity?
I sometimes run into trouble with lack of injectivity for type families.
I'm trying to understand what's at the heart of these difficulties and
whether I can avoid them. Also, whether some of the obstacles could be
overcome with simple improvements to GHC.
Here's a simple example:
{-# LANGUAGE TypeFamilies #-}
type family F a
foo :: F a
foo = undefined
bar :: F a
bar = foo
The error message:
Couldn't match type `F a' with `F a1'
NB: `F' is a type function, and may not be injective
In the expression: foo
In an equation for `bar': bar = foo
A terser (but perhaps subtler) example producing the same error:
baz :: F a
baz = baz
Replacing `a` with a monotype (e.g., `Bool`) eliminates the error.
Does the difficulty here have to do with trying to *infer* the type and
then compare with the given one? Or is there an issue even with type
*checking* in such cases?
Other insights welcome, as well as suggested work-arounds.
I know about (injective) data families but don't want to lose the
convenience of type synonym families.
Thanks, -- Conal
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Advice on type families and non-injectivity?
Hi Iavor,
Thanks for the remarks.
so there is really no way for GHC to figure out what is the intended value
for `a`.
Indeed. Though I wonder: does the type-checker really need to find a
binding for `a` in this case, i.e., given the equation `(forall a. F a) ==
(forall a'. F a')`?
-- Conal
On Sun, Jan 13, 2013 at 11:39 AM, Iavor Diatchki
iavor.diatc...@gmail.comwrote:
Hello Conal,
The issue with your example is that it is ambiguous, so GHC can't figure
out how to instantiate the use of `foo`. It might be easier to see why
this is if you write it in this form:
foo :: (F a ~ b) = b
foo = ...
Now, we can see that only `b` appears on the RHS of the `=`, so there is
really no way for GHC to figure out what is the intended value for `a`.
Replacing `a` with a concrete type (such as `Bool`) eliminates the
problem, because now GHC does not need to come up with a value for `a`.
Another way to eliminate the ambiguity would be if `F` was injective---then
we'd know that `b` uniquely determines `a` so again there would be no
ambiguity.
If `F` is not injective, however, the only workaround would be to write
the type in such a way that the function arguments appear in the signature
directly (e.g., something like 'a - F a' would be ok).
-Iavor
On Sun, Jan 13, 2013 at 11:10 AM, Conal Elliott co...@conal.net wrote:
I sometimes run into trouble with lack of injectivity for type
families. I'm trying to understand what's at the heart of these
difficulties and whether I can avoid them. Also, whether some of the
obstacles could be overcome with simple improvements to GHC.
Here's a simple example:
{-# LANGUAGE TypeFamilies #-}
type family F a
foo :: F a
foo = undefined
bar :: F a
bar = foo
The error message:
Couldn't match type `F a' with `F a1'
NB: `F' is a type function, and may not be injective
In the expression: foo
In an equation for `bar': bar = foo
A terser (but perhaps subtler) example producing the same error:
baz :: F a
baz = baz
Replacing `a` with a monotype (e.g., `Bool`) eliminates the error.
Does the difficulty here have to do with trying to *infer* the type and
then compare with the given one? Or is there an issue even with type
*checking* in such cases?
Other insights welcome, as well as suggested work-arounds.
I know about (injective) data families but don't want to lose the
convenience of type synonym families.
Thanks, -- Conal
___
Glasgow-haskell-users mailing list
glasgow-haskell-us...@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Advice on type families and non-injectivity?
Hi Christian,
Given bar :: Bool, I can't see how one could go from Bool to F a =
Bool and determine a uniquely.
The same question applies to foo :: Bool, right? Yet no error message
there.
Regards, - Conal
On Sun, Jan 13, 2013 at 11:36 AM, Christian Höner zu Siederdissen
choe...@tbi.univie.ac.at wrote:
Hi,
How would you infer a from F a? Given bar :: Bool, I can't see how
one could go from Bool to F a = Bool and determine a uniquely.
My question is not completely retorical, if there is an answer I would
like to know it :-)
Gruss,
Christian
* Conal Elliott co...@conal.net [13.01.2013 20:13]:
I sometimes run into trouble with lack of injectivity for type
families.
I'm trying to understand what's at the heart of these difficulties and
whether I can avoid them. Also, whether some of the obstacles could be
overcome with simple improvements to GHC.
Here's a simple example:
{-# LANGUAGE TypeFamilies #-}
type family F a
foo :: F a
foo = undefined
bar :: F a
bar = foo
The error message:
Couldn't match type `F a' with `F a1'
NB: `F' is a type function, and may not be injective
In the expression: foo
In an equation for `bar': bar = foo
A terser (but perhaps subtler) example producing the same error:
baz :: F a
baz = baz
Replacing `a` with a monotype (e.g., `Bool`) eliminates the error.
Does the difficulty here have to do with trying to *infer* the type
and
then compare with the given one? Or is there an issue even with type
*checking* in such cases?
Other insights welcome, as well as suggested work-arounds.
I know about (injective) data families but don't want to lose the
convenience of type synonym families.
Thanks, -- Conal
___
Glasgow-haskell-users mailing list
glasgow-haskell-us...@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] arr considered harmful
Oh, I see Ross's trick. By quantifying over the domain range types, they can later be specialized to analysis-time types (like circuit labels) or to run-time types (like Boolean or Integer). On Thu, Dec 20, 2012 at 4:55 PM, Conal Elliott co...@conal.net wrote: If you require the circuit to be parametric in the value types, you can limit the types of function you can pass to arr to simple plumbing. See the netlist example at the end of my Fun of Programming slides ( http://www.soi.city.ac.uk/~ross/papers/fop.html). I'm running into this same issue: I have something (another circuits formulation) that's almost an arrow but doesn't support arr. I'd like to use arrow notation, but then I run afoul of my missing arr. I'd like to understand Ross's suggestion and how to apply it. (I've read the FoP slides.) Ross: do you mean to say that you were able to implement arr and thus run your circuit examples via the standard arrow desugarer? Ryan: did you get a working solution to the problem you described for your Circuit arrow? Thanks. -- Conal On Mon, Oct 31, 2011 at 6:52 PM, Paterson, Ross r.pater...@city.ac.ukwrote: Ryan Ingram writes: Most of the conversion from arrow syntax into arrows uses 'arr' to move components around. However, arr is totally opaque to the arrow itself, and prevents describing some very useful objects as arrows. For example, I would love to be able to use the arrow syntax to define objects of this type: data Circuit a b where Const :: Bool - Circuit () Bool Wire :: Circuit a a Delay :: Circuit a a And :: Circuit (Bool,Bool) Bool Or :: Circuit (Bool,Bool) Bool Not :: Circuit Bool Bool Then :: Circuit a b - Circuit b c - Circuit a c Pair :: Circuit a c - Circuit b d - Circuit (a,b) (c,d) First :: Circuit a b - Circuit (a,c) (b,c) Swap :: Circuit (a,b) (b,a) AssocL :: Circuit ((a,b),c) (a,(b,c)) AssocR :: Circuit (a,(b,c)) ((a,b),c) Loop :: Circuit (a,b) (a,c) - Circuit b c etc. Then we can have code that examines this concrete data representation, converts it to VHDL, optimizes it, etc. However, due to the presence of the opaque 'arr', there's no way to make this type an arrow without adding an 'escape hatch' Arr :: (a - b) - Circuit a b which breaks the abstraction: circuit is supposed to represent an actual boolean circuit; (Arr not) is not a valid circuit because we've lost the information about the existence of a 'Not' gate. If you require the circuit to be parametric in the value types, you can limit the types of function you can pass to arr to simple plumbing. See the netlist example at the end of my Fun of Programming slides ( http://www.soi.city.ac.uk/~ross/papers/fop.html). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] arr considered harmful
Thanks, Kim-Ee. Adam M's garrows look very useful for what I'm doing. -- Conal On Fri, Dec 21, 2012 at 5:14 AM, Kim-Ee Yeoh k...@atamo.com wrote: Hey Conal, I have something (another circuits formulation) that's almost an arrow but doesn't support arr. Have you seen Adam Megacz's generalized arrows? http://www.cs.berkeley.edu/~megacz/garrows/ -- Kim-Ee On Fri, Dec 21, 2012 at 7:55 AM, Conal Elliott co...@conal.net wrote: If you require the circuit to be parametric in the value types, you can limit the types of function you can pass to arr to simple plumbing. See the netlist example at the end of my Fun of Programming slides ( http://www.soi.city.ac.uk/~ross/papers/fop.html). I'm running into this same issue: I have something (another circuits formulation) that's almost an arrow but doesn't support arr. I'd like to use arrow notation, but then I run afoul of my missing arr. I'd like to understand Ross's suggestion and how to apply it. (I've read the FoP slides.) Ross: do you mean to say that you were able to implement arr and thus run your circuit examples via the standard arrow desugarer? Ryan: did you get a working solution to the problem you described for your Circuit arrow? Thanks. -- Conal On Mon, Oct 31, 2011 at 6:52 PM, Paterson, Ross r.pater...@city.ac.ukwrote: Ryan Ingram writes: Most of the conversion from arrow syntax into arrows uses 'arr' to move components around. However, arr is totally opaque to the arrow itself, and prevents describing some very useful objects as arrows. For example, I would love to be able to use the arrow syntax to define objects of this type: data Circuit a b where Const :: Bool - Circuit () Bool Wire :: Circuit a a Delay :: Circuit a a And :: Circuit (Bool,Bool) Bool Or :: Circuit (Bool,Bool) Bool Not :: Circuit Bool Bool Then :: Circuit a b - Circuit b c - Circuit a c Pair :: Circuit a c - Circuit b d - Circuit (a,b) (c,d) First :: Circuit a b - Circuit (a,c) (b,c) Swap :: Circuit (a,b) (b,a) AssocL :: Circuit ((a,b),c) (a,(b,c)) AssocR :: Circuit (a,(b,c)) ((a,b),c) Loop :: Circuit (a,b) (a,c) - Circuit b c etc. Then we can have code that examines this concrete data representation, converts it to VHDL, optimizes it, etc. However, due to the presence of the opaque 'arr', there's no way to make this type an arrow without adding an 'escape hatch' Arr :: (a - b) - Circuit a b which breaks the abstraction: circuit is supposed to represent an actual boolean circuit; (Arr not) is not a valid circuit because we've lost the information about the existence of a 'Not' gate. If you require the circuit to be parametric in the value types, you can limit the types of function you can pass to arr to simple plumbing. See the netlist example at the end of my Fun of Programming slides ( http://www.soi.city.ac.uk/~ross/papers/fop.html). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] arr considered harmful
If you require the circuit to be parametric in the value types, you can limit the types of function you can pass to arr to simple plumbing. See the netlist example at the end of my Fun of Programming slides ( http://www.soi.city.ac.uk/~ross/papers/fop.html). I'm running into this same issue: I have something (another circuits formulation) that's almost an arrow but doesn't support arr. I'd like to use arrow notation, but then I run afoul of my missing arr. I'd like to understand Ross's suggestion and how to apply it. (I've read the FoP slides.) Ross: do you mean to say that you were able to implement arr and thus run your circuit examples via the standard arrow desugarer? Ryan: did you get a working solution to the problem you described for your Circuit arrow? Thanks. -- Conal On Mon, Oct 31, 2011 at 6:52 PM, Paterson, Ross r.pater...@city.ac.ukwrote: Ryan Ingram writes: Most of the conversion from arrow syntax into arrows uses 'arr' to move components around. However, arr is totally opaque to the arrow itself, and prevents describing some very useful objects as arrows. For example, I would love to be able to use the arrow syntax to define objects of this type: data Circuit a b where Const :: Bool - Circuit () Bool Wire :: Circuit a a Delay :: Circuit a a And :: Circuit (Bool,Bool) Bool Or :: Circuit (Bool,Bool) Bool Not :: Circuit Bool Bool Then :: Circuit a b - Circuit b c - Circuit a c Pair :: Circuit a c - Circuit b d - Circuit (a,b) (c,d) First :: Circuit a b - Circuit (a,c) (b,c) Swap :: Circuit (a,b) (b,a) AssocL :: Circuit ((a,b),c) (a,(b,c)) AssocR :: Circuit (a,(b,c)) ((a,b),c) Loop :: Circuit (a,b) (a,c) - Circuit b c etc. Then we can have code that examines this concrete data representation, converts it to VHDL, optimizes it, etc. However, due to the presence of the opaque 'arr', there's no way to make this type an arrow without adding an 'escape hatch' Arr :: (a - b) - Circuit a b which breaks the abstraction: circuit is supposed to represent an actual boolean circuit; (Arr not) is not a valid circuit because we've lost the information about the existence of a 'Not' gate. If you require the circuit to be parametric in the value types, you can limit the types of function you can pass to arr to simple plumbing. See the netlist example at the end of my Fun of Programming slides ( http://www.soi.city.ac.uk/~ross/papers/fop.html). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial: Haskell for the Evil Genius
Hi Tillmann. Wow. Lovely and spot on! And I almost never hear monad explanations without wincing. Thanks for sharing. -- Conal On Sun, Sep 16, 2012 at 7:48 AM, Tillmann Rendel ren...@informatik.uni-marburg.de wrote: Hi, Kristopher Micinski wrote: Everyone in the Haskell cafe probably has a secret dream to give the best five minute monad talk. (1) Most programming languages support side effects. There are different kinds of side effects such as accessing mutable variables, reading files, running in parallel, raising exceptions, nondeterministically returning more than one answer, and many more. Most languages have some of these effects built into their semantics, and do not support the others at all. (2) Haskell is pure, so it doesn't support any side effects. Instead, when Haskell programmers want to perform a side effect, they explicitly construct a description of the side effecting computation as a value. For every group of related side effects, there is a Haskell type that describes computations that can have that group of side effects. (3) Some of these types are built in, such as IO for accessing the world outside the processor and ST for accessing local mutable variables. Other such types are defined in Haskell libraries, such as for computations that can fail and for computations that can return multiple answers. Application programmers often define their own types for the side effects they need to describe, tailoring the language to their needs. (4) All computation types have a common interface for operations that are independent of the exact side effects performed. Some functions work with arbitrary computations, just using this interface. For example, we can compose a computation with itself in order to run it twice. Such generic operations are highly reusable. (5) The common interface for constructing computations is called Monad. It is inspired by the mathematical theory that some computer scientists use when they describe what exactly the semantics of a programming language with side effects is. So most other languages support some monad natively without the programmer ever noticing, whereas Haskell programmers can choose (and even implement) exactly the monads they want. This makes Haskell a very good language for side effecting computation. Tillmann __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial: Haskell for the Evil Genius
On Fri, Sep 14, 2012 at 2:18 PM, Andrew Pennebaker wrote: A summary of the changes I've included so far: [...] Another comment: As a declarative language, Haskell manipulates expressions, eventually reducing expressions to values. Huh? In what sense do declarative languages manipulate expressions? Sounds like a classic syntax/semantics confusion, especially when interpreters and/or lazy evaluation (implementation issues, not language properties) are in the mix. Noted and reflected in the new version. I'm trying to introduce the concept of declarative programming as opposed to imperative programming. Declarative programming according to Wikipediahttp://en.wikipedia.org/wiki/Declarative_programming : is a programming paradigm that expresses the logic of a computation without describing its control flow. I believe this is done in Haskell and other declarative languages by treating code as manipulable, reducible expressions, where imperative languages would use machine instructions. I'm struggling to find anything in this belief/opinion that I can relate to. How did you come by it? What experiments can you perform to check whether it's true or false? I second Albert Lai's recommendation to use the scientific method. Along these lines, I still see Haskell manipulates reducible expressions, eventually reducing them to values in your tutorial, which again I suspect comes from confusion between syntax semantics and/or between meaning and possible execution strategy. Regards, - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial: Haskell for the Evil Genius
Hi Andrew, To save others the search, here's the/a reddit URL: http://www.reddit.com/r/programming/related/nhnyd/nfa_in_a_single_line_of_haskell/. The terribly misleading/mistaken remarks on fib memoization are still in your post. As hammar commented on reddit commenter, you're not memoizing in that example; just shadowing one fib definition with another (very partial) one. (BTW, I highly recommend compiling with -Wall in all cases and then addressing all reported issues. Doing so would have issued a shadowing warning.) Another comment: As a declarative language, Haskell manipulates expressions, eventually reducing expressions to values. Huh? In what sense do declarative languages manipulate expressions? Sounds like a classic syntax/semantics confusion, especially when interpreters and/or lazy evaluation (implementation issues, not language properties) are in the mix. Regards, - Conal On Fri, Sep 14, 2012 at 9:13 AM, Andrew Pennebaker andrew.penneba...@gmail.com wrote: I've gotten mixed feedback from Reddit for my tutorial. It provides an overview of how functional and declarative programming in Haskell empower baddies, increasing the accuracy and efficiency of their atomic superweapons. What do you guys think of my tutorial, Haskell for the Evil Genius http://www.yellosoft.us/evilgenius/? Cheers, Andrew Pennebaker www.yellosoft.us ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Derived Read for records
Someone at work just asked me about the inflexibility of the derived Read instances for records -- specifically that they require fields to be given in the same order as in the type definition and that fields cannot be omitted. I hadn't been aware of these restrictions. A few questions: * Are there known work-arounds? * Is it particularly difficult to synthesize more flexible Read instances? * Do people just not mind the restrictions? Thanks, -- Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Have you seen this functor/contrafunctor combo?
Oh, yeah. Thanks, Sjoerd. I wonder if there's some way not to require Monad. Some sort of ApplicativeFix instead. Hm. -- Conal On Wed, Jun 6, 2012 at 2:43 PM, Sjoerd Visscher sjo...@w3future.com wrote: If there would be a package where this could be in it would be contravariant[1], but it isn't. newtype Q' p f a = Q' (p a - f a) This compiles: instance (Contravariant p, Functor m, MonadFix m) = Applicative (Q' p m) where pure a = Q' (pure (return a)) Q' fs * Q' as = Q' $ \r - do rec f - fs (contramap ($ a) r) a - as (contramap (f $) r) return $ f a [1] http://hackage.haskell.org/package/contravariant -- Sjoerd Visscher https://github.com/sjoerdvisscher/blog ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Have you seen this functor/contrafunctor combo?
newtype Q p a = Q (p a - a) instance ContraFunctor p = Functor (Q p) where fmap h (Q w) = Q (h . w . cmap h) using cmap for contravariant map. For instance, p a = u - a. instance ContraFunctor p = Applicative (Q p) where pure a = Q (pure a) Q fs * Q as = Q (\ r - let f = fs (cmap ($ a) r) a = as (cmap (f $) r) in f a) I've checked the functor laws but not the applicative laws, and I haven't looked for a Monad instance. Or extend to a more symmetric definition adding a (covariant) functor f to the contravariant functor p. newtype Q' p f a = Q' (p a - f a) A (law-abiding) Functor instance is easy, but I don't know about an Applicative instance. Have you seen Q or Q' before? They look like they ought to be something familiar useful. -- Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I Need a Better Functional Language!
Agreed. The original note confuses programs (syntax) with functions (semantics). -- Conal On Thu, Apr 5, 2012 at 8:52 AM, Dan Doel dan.d...@gmail.com wrote: On Thu, Apr 5, 2012 at 10:14 AM, Grigory Sarnitskiy sargrig...@ya.ru wrote: First, what are 'functions' we are interested at? It can't be the usual set-theoretic definition, since it is not constructive. The constructive definition should imply functions that can be constructed, computed. Thus these are computable functions that should be of our concern. But computable functions in essence are just a synonym for programs. This is a flawed premise. The point of working with functions is abstraction, and that abstraction is given by extensional equality of functions: f = g iff forall x. f x = g x So functions are not synonymous with programs or algorithms, they correspond to an equivalence class of algorithms that produce the same results from the same starting points. If you can access the source of functions within the language, this abstraction has been broken. And this abstraction is useful, because it allows you to switch freely between programs that do the same thing without having to worry that someone somewhere is relying on the particular algorithm or source. This is the heart of optimization and refactoring and the like. There are places for metaprogramming, or perhaps even a type of algorithms that can be distinguished by means other than the functions they compute. But to say that functions are that type is false, and that functions should mean that is, I think, wrong headed. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Are there arithmetic composition of functions?
This general applicative pattern for numbers is packed up in the applicative-numbers package [1]. In addition to Ralf's paper, there's a discussion in section 10 of *Denotational design with type class morphisms* [2] and an application in sections 2 4 of *Beautiful differentiation* [3]. [1]: http://hackage.haskell.org/package/applicative-numbers [2]: http://conal.net/papers/type-class-morphisms/ [3]: http://conal.net/papers/beautiful-differentiation/ -- Conal On Mon, Mar 19, 2012 at 9:58 PM, wren ng thornton w...@freegeek.org wrote: On 3/19/12 12:57 PM, sdiy...@sjtu.edu.cn wrote: By arithmetic I mean the everyday arithmetic operations used in engineering. In signal processing for example, we write a lot of expressions like f(t)=g(t)+h(t)+g'(t) or f(t)=g(t)*h(t). I feel it would be very natural to have in haskell something like You should take a look at Ralf Hinze's _The Lifting Lemma_: http://www.cs.ox.ac.uk/ralf.**hinze/WG2.8/26/slides/ralf.pdfhttp://www.cs.ox.ac.uk/ralf.hinze/WG2.8/26/slides/ralf.pdf The fact that you can lift arithmetic to work on functions comes from the fact that for every type T, the type (T-) is a monad and therefore is an applicative functor. The output type of the function doesn't matter, except inasmuch as the arithmetic operations themselves care. This pattern has been observed repeatedly, even long before Haskell was around. But one reason it's not too common in production Haskell code is that it's all too easy to make a mistake when programming (e.g., you don't mean to be adding functions but you accidentally forget some argument), and if you're using this trick implicitly by providing a Num instance, then you can get arcane/unexpected/unhelpful error messages during type checking. But then you do get some fun line noise :) twiceTheSumOf = (+) + (+) squareTheSumOf = (+) * (+) cubeTheSumOf = (+) * (+) * (+) -- N.B., the names only make sense if all arguments -- are numeric literals. Don't look at the types. addThreeThings = (+) . (+) addFourThings = (+) . (+) . (+) addFiveThings = (+) . (+) . (+) . (+) -- Live well, ~wren __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Pattern-matching substitution for haskell-src-exts?
Has anyone implemented pattern-matching substitution for haskell-src-exts? - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] generating parens for pretty-printing code in haskell-src-exts
I'm using haskell-src-exts together with SYB for a code-rewriting project, and I'm having difficulty with parenthesization. I naïvely expected that parentheses would be absent from the abstract syntax, being removed during parsing and inserted during pretty-printing. It's easy for me to remove them myself, but harder to add them (minimally) after transformation. Rather than re-inventing the wheel, I thought I'd ask for help. Has anyone written automatic minimal parens insertion for haskell-src-exts? -- Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Where is the pairing-with-monoid monad instance?
Is the standard pair-with-monoid monad instance in some standard place? I see the Applicative instance in Control.Applicative, and the pair-with-monoid Functor instance in Control.Monad.Instances, and the (-) e and Either e monad instances also in Control.Monad.Instances. I'm looking for something like instance Monoid o = Monad ((,) o) where return a= (mempty,a) (o,a) = f = (o `mappend` o', b) where (o',b) = f a Where is it hiding from me? Thanks, - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On 2012/1/1 Ertugrul Söylemez e...@ertes.de wrote: Steve Horne sh006d3...@blueyonder.co.uk wrote: Of course even the bind operator arguably isn't primitive. We could translate to get rid of those too, and see what lies underneath. This is where we start seeing functions of type... World - (x, World) Problem - this level of abstraction is hypothetical. It is not part of the Haskell language. Haskell specifically defines the IO monad to be a black box. And that's fine, because IO is an embedded DSL. A better view of IO is a GADT like: data IO :: * - * where GetLine :: IO String PutStrLn :: String - IO () ... This is still hypothetical, but it shows how even IO is easily referentially transparent (as long as you don't use unsafe* cheats). What?? I see how a definition like this one shows how something else that you call IO can be denotative RT. I don't see how what that conclusion has to do with Haskell's IO. I also wonder whether you're assuming that all of the IO primitives we have in Haskell treat their non-IO arguments denotationally/extensionally, so that there cannot be operations like isWHNF :: a - IO Bool. - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
... World - (x, World) ... I look at this World parameter as purely hypothetical, a trick used to gain an intuition. Whereas Jerzy (I think) uses it to claim Haskell is referentially transparent - those differing x and y values come from different worlds, or different world-states. I don't see this interpretation in Jerzy's words, and I'd be very surprised if he had that sort of argument in mind. If main returns a function of type World - (x, World) wrapped in ... Main does not return or denote such a thing. The idea that Haskell IO can be accurately explained as (i.e., denotes) World - (x,World) is a persistent myth. That model cannot explain concurrency (even with the outside world) or nondeterminism, both of which are part of Haskell IO. We don't have an precise accurate denotational model for IO, in contrast to most other types in Haskell. Which is to say that while much of Haskell programming is denotative, IO programming is not. Peter Landin, an important figure in functional programming, proposed and defined this term denotative as a substantive precise replacement for the fuzzier notions of functional and declarative. He offered his definition and suggested that When faced with a new notation that borrows the functional appearance of everyday algebra, it is (c) that gives us a test for whether the notation is genuinely functional or merely masquerading. Of course, various subsets of IO can be precisely and accurately modeled, but so far not IO as we use it. It's very unlikely that we ever will have such a (precise accurate) model, and by design, as explained at http://conal.net/blog/posts/notions-of-purity-in-haskell/#comment-22829 . - Conal On Sun, Jan 1, 2012 at 7:43 PM, Steve Horne sh006d3...@blueyonder.co.ukwrote: On 01/01/2012 22:57, Jerzy Karczmarczuk wrote: Dan Doel : ... Also, the embedded IO language does not have this property. do x- m ; f x x is different from do x- m ; y- m ; f x y and so on. This is why you shouldn't write your whole program with IO functions; it lacks nice properties for working with your code. Sorry, what are you trying to suggest? You show two OBVIOUSLY different pieces of code, and you say that they are different. If, by chance, some newbie reads that and gets the impression that (-) is something equivalent to (=), you are serving the devil. Speaking as the devil... The do-notation sugar may confuse the issue - the - looks like an operator, but translating to binds-and-lambdas form suggests otherwise. Quick translations (I hope no mistakes) with lots of parens... m = (\x - (f x x)) m = (\x - (m = (\y - (f x y At first sight, these two expressions can give different results for reasons other than evaluation order. In particular, there are two bind operators, not just one. That is, x and y could get different values for reasons other than the two m references referring to different things. So... is that true? Of course even the bind operator arguably isn't primitive. We could translate to get rid of those too, and see what lies underneath. This is where we start seeing functions of type... World - (x, World) Problem - this level of abstraction is hypothetical. It is not part of the Haskell language. Haskell specifically defines the IO monad to be a black box. I look at this World parameter as purely hypothetical, a trick used to gain an intuition. Whereas Jerzy (I think) uses it to claim Haskell is referentially transparent - those differing x and y values come from different worlds, or different world-states. I'm not entirely sure, though, as we got sidetracked. If main returns a function of type World - (x, World) wrapped in a monad context, then there is referential transparency as defined in computer science. But is that a fair claim? In this model, Haskell is an interpreted language for compositing functions. We can call those functions programs. The executable is a translation of the function returned by main, but *not* a translation of the source code. But GHC is called a compiler, and compilation is usually considered a kind of translation - the executable is a translation of the source code. GHCi is an interpreter, but it doesn't stop at returning a function of type World - (x, World) - it does the I/O. And the reason we use these terms is because, as programmers, we think of the executable as the program - as a translation of the source code. So what main returns - that hypothetical function World - (x, World) - isn't just a product of the program, it's also a representation of the program. I've made similar points before, but how do they work out this time... So... when evaluate what effects referentially transparent - --- - compile-time main no yes run-time main someParticularWorld yes yes(?) I've
Re: [Haskell-cafe] Are all monads functions?
In that sense every value in maths is a function. In other words: Your extension of everything (!) to functions is redundant. And function is not unique in this way. All types can be embedded into pairs also, e.g., newtype MyInt = MyInt ((),Int), or newtype MyInt = MyInt (((),Int),()), etc. - Conal 2011/12/31 Ertugrul Söylemez e...@ertes.de Yves Parès limestrael+hask...@gmail.com wrote: But still, I maintain my previous view. I could clarify that by saying that (e.g. for Maybe) we could separate it in two types, Maybe itself and its monad: -- The plain Maybe type data Maybe a = Just a | Nothing -- The MaybeMonad newtype MaybeMonad a = MM ( () - Maybe a ) That's what using Maybe as a monad semantically means, doesn't it? That's a statement like the sky is blue. You can represent any value as a function of (). You are saying that every integer is a function. newtype MyInt = MyInt (() - Int) newtype My a = My (() - a) Think of it this way: There is something like a canonical representation of every monad. If you let that one be the one with the least order (which is reasonable), then no, not every monad's canonical representation is a function, because the base library definition of Maybe is the canonical one (order zero). In that sense every value in maths is a function. In other words: Your extension of everything (!) to functions is redundant. You get the idea. Greets, Ertugrul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On Fri, Dec 30, 2011 at 12:52 AM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: Conal Elliott wrote: I wrote that post to point out the fuzziness that fuels many discussion threads like this one. See also http://conal.net/blog/posts/** notions-of-purity-in-haskell/http://conal.net/blog/posts/notions-of-purity-in-haskell/and the comments. I almost never find value in discussion about whether language X is functional, pure, or even referentially transparent, mainly because those terms are used so imprecisely. In the notions-of-purity post, I suggest another framing, as whether or not a language and/or collection of data types is/are denotative, to use Peter Landin's recommended replacement for functional, declarative, etc. I included some quotes and a link in that post. so people can track down what denotative means. In my understanding, Haskell-with-IO is not denotative, simply because we do not have a (precise/mathematical) model for IO. And this lack is by design, as explained in the toxic avenger remarks in a comment on that post. I often hear explanations of what IO means (world-passing etc), but I don't hear any consistent with Haskell's actual IO, which includes nondeterministic concurrency. Perhaps the difficulties could be addressed, but I doubt it, and I haven't seen claims pursued far enough to find out. Personally, the operational semantics given in SPJ's Tackling the Awkward Squad always struck me as an accurate model of how GHC performs IO. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com It might be accurate, but it's not denotational. - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On Fri, Dec 30, 2011 at 8:12 AM, Conal Elliott co...@conal.net wrote: On Fri, Dec 30, 2011 at 12:52 AM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: Conal Elliott wrote: I wrote that post to point out the fuzziness that fuels many discussion threads like this one. See also http://conal.net/blog/posts/* *notions-of-purity-in-haskell/http://conal.net/blog/posts/notions-of-purity-in-haskell/and the comments. I almost never find value in discussion about whether language X is functional, pure, or even referentially transparent, mainly because those terms are used so imprecisely. In the notions-of-purity post, I suggest another framing, as whether or not a language and/or collection of data types is/are denotative, to use Peter Landin's recommended replacement for functional, declarative, etc. I included some quotes and a link in that post. so people can track down what denotative means. In my understanding, Haskell-with-IO is not denotative, simply because we do not have a (precise/mathematical) model for IO. And this lack is by design, as explained in the toxic avenger remarks in a comment on that post. I often hear explanations of what IO means (world-passing etc), but I don't hear any consistent with Haskell's actual IO, which includes nondeterministic concurrency. Perhaps the difficulties could be addressed, but I doubt it, and I haven't seen claims pursued far enough to find out. Personally, the operational semantics given in SPJ's Tackling the Awkward Squad always struck me as an accurate model of how GHC performs IO. It might be accurate, but it's not denotational. - Conal Moreover, afaict, the Awkward Squad operational semantics tackles only a tiny fraction of the IO type. One of the strengths of Haskell IO is that it can be extended easily via the FFI. And I guess that strength is also a theoretical weakness in the sense that only a tiny fraction of the IO interface has even an operational semantics. - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On Fri, Dec 30, 2011 at 9:11 AM, Chris Smith cdsm...@gmail.com wrote: time t: f 42 (computational process implementing func application begins…) t+1: keystroke = 1 t+2: 43 (… and ends) time t+3: f 42 t+4: keystroke = 2 t+5: 44 Conclusion: f 42 != f 42 That conclusion would only follow if the same IO action always produced the same result when performed twice in a row. That's obviously untrue, so the conclusion doesn't follow. What you've done is entirely consistent with the fact that f 42 = f 42... it just demonstrates that whatever f 42 is, it doesn't always produce the same result when you o it twice. Exactly. Gregg threw in two different executions, which of course can produce two different values, whether or not the IOs are equal. What Conal is getting at is that we don't have a formal model of what an IO action means. Nevertheless, we know because f is a function, that when it is applied twice to the same argument, the values we get back (which are IO actions, NOT integers) are the same. And I also raised a more fundamental question than whether this claim of sameness is true, namely what is equality on IO? Without a precise consistent definition of equality, the claims like f 42 == f (43 - 1) are even defined, let alone true. And since the conversation is about Haskell IO, I'm looking for a definition that applies to all of IO, not just some relatively well-behaved subset like putchar/getchar+IORefs+threads. - Conal - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On Fri, Dec 30, 2011 at 9:20 AM, Colin Adams colinpaulad...@gmail.comwrote: On 30 December 2011 17:17, Gregg Reynolds d...@mobileink.com wrote: On Dec 30, 2011, at 11:04 AM, Colin Adams wrote: On 30 December 2011 16:59, Gregg Reynolds d...@mobileink.com wrote: On Fri, Dec 30, 2011 at 12:49 AM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: The function f :: Int - IO Int f x = getAnIntFromTheUser = \i - return (i+x) is pure according to the common definition of pure in the context of purely functional programming. That's because f 42 = f (43-1) = etc. Put differently, the function always returns the same IO action, i.e. the same value (of type IO Int) when given the same parameter. time t: f 42 (computational process implementing func application begins…) t+1: keystroke = 1 t+2: 43 (… and ends) time t+3: f 42 t+4: keystroke = 2 t+5: 44 Conclusion: f 42 != f 42 (This seems so extraordinarily obvious that maybe Heinrich has something else in mind.) This seems such an obviously incorrect conclusion. f42 is a funtion for returning a program for returning an int, not a function for returning an int. My conclusion holds: f 42 != f 42. Obviously, so I won't burden you with an explanation. ;) -Gregg Your conclusion is clearly erroneous. proof: f is a function, and it is taking the same argument each time. Therefore the result is the same each time. Careful of circular reasoning here. Is f actually a function in the mathematical sense? It's that math sense that you need to reach your conclusion. BTW, the more I hear words like clearly and obvious, the more I suspect that fuzziness is being swept under the carpet. - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On Fri, Dec 30, 2011 at 9:19 AM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: Conal Elliott wrote: Heinrich Apfelmus wrote: The function f :: Int - IO Int f x = getAnIntFromTheUser = \i - return (i+x) is pure according to the common definition of pure in the context of purely functional programming. That's because f 42 = f (43-1) = etc. Put differently, the function always returns the same IO action, i.e. the same value (of type IO Int) when given the same parameter. Two questions trouble me: How can we know whether this claim is true or not? What does the claim even mean, i.e., what does the same IO action mean, considering that we lack a denotational model of IO? I think you can put at least these troubles to rest by noting that f 42 and f (43-1) are intentionally equal, even though you're not confident on their extensional meaning. The idea is to represent IO as an abstract data type type IO' a = Program IOInstr a data Program instr a where Return :: a - Program instr a Then :: instr a - (a - Program instr b) - Program instr b instance Monad (Program instr) where return = Return (Return a) = g = g a (i `Then` f) = g = i `Then` (\x - f x = g) date IOInstr a where PutChar :: Char - IOInstr () GetChar :: IOInstr Char etc... So, two values of type IO' a are equal iff their program codes are equal (= intensional equality), and this is indeed the case for f 42 and f (43-1) . Therefore, the (extensional) interpretations of these values by GHC are equal, too, even though you don't think we know what these interpretations are. (Of course, programs with different source code may be extensionally equal, i.e. have the same effects. That's something we would need a semantics of IO for.) How do you know that GHC's (or YHC's, etc) interpretation of IO is a composition of this program code interpretation with some other (more extensional) interpretation? In particular, how do you know that no IO primitive can ever distinguish between 42 and 43-1. - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On Fri, Dec 30, 2011 at 9:30 AM, Colin Adams colinpaulad...@gmail.comwrote: On 30 December 2011 17:27, Conal Elliott co...@conal.net wrote: On Fri, Dec 30, 2011 at 9:20 AM, Colin Adams colinpaulad...@gmail.comwrote: proof: f is a function, and it is taking the same argument each time. Therefore the result is the same each time. Careful of circular reasoning here. Is f actually a function in the mathematical sense? It's that math sense that you need to reach your conclusion. Yes. Because Haskell is a functional programming language. And how do you know that claim to be true? And do you mean a *purely* functional language? Otherwise f might be in the impure part. If you do mean *purely* functional, aren't you arguing for purity by assuming purity? Moreover, do you have a precise definition for functional? I've witnessed a lot of these arguments and have seen a diversity of interpretations. Which is why I recommend shifting away from such fuzzy terms and following Peter Landin's recommended more precise substantive replacement, namely denotative. (See http://conal.net/blog/posts/is-haskell-a-purely-functional-language/#comment-35882for a quote and reference.) - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On Fri, Dec 30, 2011 at 9:43 AM, Gregg Reynolds d...@mobileink.com wrote: On Dec 30, 2011, at 11:20 AM, Colin Adams wrote: On 30 December 2011 17:17, Gregg Reynolds d...@mobileink.com wrote: On Dec 30, 2011, at 11:04 AM, Colin Adams wrote: On 30 December 2011 16:59, Gregg Reynolds d...@mobileink.com wrote: On Fri, Dec 30, 2011 at 12:49 AM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: The function f :: Int - IO Int f x = getAnIntFromTheUser = \i - return (i+x) is pure according to the common definition of pure in the context of purely functional programming. That's because f 42 = f (43-1) = etc. Conclusion: f 42 != f 42 (This seems so extraordinarily obvious that maybe Heinrich has something else in mind.) This seems such an obviously incorrect conclusion. f42 is a funtion for returning a program for returning an int, not a function for returning an int. My conclusion holds: f 42 != f 42. Obviously, so I won't burden you with an explanation. ;) -Gregg Your conclusion is clearly erroneous. proof: f is a function, and it is taking the same argument each time. Therefore the result is the same each time. That's called begging the question. f is not a function, so I guess your proof is flawed. It seems pretty clear that we're working with different ideas of what constitutes a function. When I use the term, I intend what I take to be the standard notion of a function in computation: not just a unique mapping from one input to one output, but one where the output is computable from the input. Any function that depends on a non-computable component is by that definition not a true function. For clarity let's call such critters quasi-functions, so we can retain the notion of application. Equality cannot be defined for quasi-functions, for obvious reasons. f is a quasi-function because it depends on getAnIntFromUser, which is not definable and is obviously not a function. When applied to an argument like 42, it yields another quasi-function, and therefore f 42 = f 42 is false, or at least unknown, and the same goes for f 42 != f 42 I suppose. -Gregg Please don't redefine function to mean computable function. Besides distancing yourself from math, I don't think doing so really helps your case. And on what do you base your claim that getAnIntFromUser is not definable? Or that applying it (what?) to 42 gives a quasi-function? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On Fri, Dec 30, 2011 at 9:43 AM, Conal Elliott co...@conal.net wrote: On Fri, Dec 30, 2011 at 9:43 AM, Gregg Reynolds d...@mobileink.com wrote: On Dec 30, 2011, at 11:20 AM, Colin Adams wrote: On 30 December 2011 17:17, Gregg Reynolds d...@mobileink.com wrote: On Dec 30, 2011, at 11:04 AM, Colin Adams wrote: On 30 December 2011 16:59, Gregg Reynolds d...@mobileink.com wrote: On Fri, Dec 30, 2011 at 12:49 AM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: The function f :: Int - IO Int f x = getAnIntFromTheUser = \i - return (i+x) is pure according to the common definition of pure in the context of purely functional programming. That's because f 42 = f (43-1) = etc. Conclusion: f 42 != f 42 (This seems so extraordinarily obvious that maybe Heinrich has something else in mind.) This seems such an obviously incorrect conclusion. f42 is a funtion for returning a program for returning an int, not a function for returning an int. My conclusion holds: f 42 != f 42. Obviously, so I won't burden you with an explanation. ;) -Gregg Your conclusion is clearly erroneous. proof: f is a function, and it is taking the same argument each time. Therefore the result is the same each time. That's called begging the question. f is not a function, so I guess your proof is flawed. It seems pretty clear that we're working with different ideas of what constitutes a function. When I use the term, I intend what I take to be the standard notion of a function in computation: not just a unique mapping from one input to one output, but one where the output is computable from the input. Any function that depends on a non-computable component is by that definition not a true function. For clarity let's call such critters quasi-functions, so we can retain the notion of application. Equality cannot be defined for quasi-functions, for obvious reasons. f is a quasi-function because it depends on getAnIntFromUser, which is not definable and is obviously not a function. When applied to an argument like 42, it yields another quasi-function, and therefore f 42 = f 42 is false, or at least unknown, and the same goes for f 42 != f 42 I suppose. -Gregg Please don't redefine function to mean computable function. Besides distancing yourself from math, I don't think doing so really helps your case. And on what do you base your claim that getAnIntFromUser is not definable? Or that applying it (what?) to 42 gives a quasi-function? Also: f is not a function, so I guess your proof is flawed. Can you support the claim that f is not a function? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On Fri, Dec 30, 2011 at 10:24 AM, Gregg Reynolds d...@mobileink.com wrote: On Dec 30, 2011, at 11:43 AM, Conal Elliott wrote: roof: f is a function, and it is taking the same argument each time. Therefore the result is the same each time. That's called begging the question. f is not a function, so I guess your proof is flawed. It seems pretty clear that we're working with different ideas of what constitutes a function. When I use the term, I intend what I take to be the standard notion of a function in computation: not just a unique mapping from one input to one output, but one where the output is computable from the input. Any function that depends on a non-computable component is by that definition not a true function. For clarity let's call such critters quasi-functions, so we can retain the notion of application. Equality cannot be defined for quasi-functions, for obvious reasons. f is a quasi-function because it depends on getAnIntFromUser, which is not definable and is obviously not a function. When applied to an argument like 42, it yields another quasi-function, and therefore f 42 = f 42 is false, or at least unknown, and the same goes for f 42 != f 42 I suppose. -Gregg Please don't redefine function to mean computable function. Besides distancing yourself from math, I don't think doing so really helps your case. No redefinition involved, just a narrowing of scope. I assume that, since we are talking about computation, it is reasonable to limit the discussion to the class of computable functions - which, by the way, are about as deeply embedded in orthodox mathematics as you can get, by way of recursion theory. What would be the point of talking about non-computable functions for the semantics of a programming language? And on what do you base your claim that getAnIntFromUser is not definable? Sorry, not definable might a little strong. Not definable in the way we can define computable functions work better? In any case I think you probably see what I'm getting at. Or that applying it (what?) to 42 gives a quasi-function? I can't think of a way to improve on what I've already written at the moment - it too would depend on IO - so if my meaning is not clear, so be it. Wait, here's another way of looking at it. Think of IO actions as random variables. So instead of getAnIntFromUser, use X as an integer random variable yielding something like: f :: Int - IO Int f x = X = \i - return (i+x) I would not call this f a function because I don't think it answers to the commonly accepted definition of a function. Ditto for the result of applying it to 42. Others obviously might consider it a function. De gustibus non set disputandem. -Gregg I'm recommending a shift to more well-defined terms in hopes to move this discussion away from tastes opinions and from what's obvious (even if untrue or ill-defined). If you look at the signature of 'f', you can see that it's declared to be a function (and a computable one at that). To demonstrate that it's not actually a function, I'd expect you to show that it's one-to-many, which then raises the question of equality, as needed to distinguish one from many. - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On Fri, Dec 30, 2011 at 10:45 AM, Gregg Reynolds d...@mobileink.com wrote: On Dec 30, 2011, at 11:21 AM, Conal Elliott wrote: And I also raised a more fundamental question than whether this claim of sameness is true, namely what is equality on IO? Without a precise consistent definition of equality, the claims like f 42 == f (43 - 1) are even defined, let alone true. And since the conversation is about Haskell IO, I'm looking for a definition that applies to all of IO, not just some relatively well-behaved subset like putchar/getchar+IORefs+threads. Well, you'll no doubt be glad to know I think I've said about all I need to say on this topic, [...] Honestly, I'm not trying to get you to speak less, but rather to share your perspective more clearly. I've have more than my fill of circular arguments and ill-defined claims. I'm reminded of a quote from David R. MacIver in “A problem of languagehttp://www.drmaciver.com/2009/05/a-problem-of-language/, Of course, once you start defining the term people will start arguing about the definitions. This is pretty tedious, I know. But as tedious as arguing about definitions is, it can’t hold a candle to arguing without definitions. - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
I wrote that post to point out the fuzziness that fuels many discussion threads like this one. See also http://conal.net/blog/posts/notions-of-purity-in-haskell/ and the comments. I almost never find value in discussion about whether language X is functional, pure, or even referentially transparent, mainly because those terms are used so imprecisely. In the notions-of-purity post, I suggest another framing, as whether or not a language and/or collection of data types is/are denotative, to use Peter Landin's recommended replacement for functional, declarative, etc. I included some quotes and a link in that post. so people can track down what denotative means. In my understanding, Haskell-with-IO is not denotative, simply because we do not have a (precise/mathematical) model for IO. And this lack is by design, as explained in the toxic avenger remarks in a comment on that post. I often hear explanations of what IO means (world-passing etc), but I don't hear any consistent with Haskell's actual IO, which includes nondeterministic concurrency. Perhaps the difficulties could be addressed, but I doubt it, and I haven't seen claims pursued far enough to find out. - Conal On Thu, Dec 29, 2011 at 4:42 PM, Steve Horne sh006d3...@blueyonder.co.ukwrote: On 30/12/2011 00:16, Sebastien Zany wrote: Steve Horne wrote: I haven't seen this view explicitly articulated anywhere before See Conal Elliott's blog post The C language is purely functionalhttp://conal.net/blog/posts/the-c-language-is-purely-functional . Thanks - yes, that's basically the same point. More concise - so clearer, but not going into all the same issues - but still the same theme. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pointed, but not Applicative
I suspect this definition is what Sebastian meant by converting back and forth to ordinary lists. 2011/8/29 Ryan Ingram ryani.s...@gmail.com On Sun, Aug 28, 2011 at 8:24 PM, Maciej Marcin Piechotka uzytkown...@gmail.com wrote: f `fmap` FList g = _|_ f `fmap` FList g = map id f `fmap` FList g = map _|_ (+ variation of _|_*) f `fmap` FList g = \bs - map f (g []) ++ bs ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] library on common sub-expression elimination?
Note that data-reify will only find *some* common/equal sub-expressions, namely the pointer-equal ones. In all of my code-generating (deep) DSLs, it's been very important for efficiency to also pull out equal-but-pointer-unequal expressions. - Conal On Thu, Aug 11, 2011 at 4:41 AM, Vo Minh Thu not...@gmail.com wrote: I guess you refer to data-reify: http://hackage.haskell.org/package/data-reify 2011/8/11 Stephen Tetley stephen.tet...@gmail.com: Strafunski and its successors (Uniplate, SYB, KURE) are really for working on trees. If you want to work on graphs you would probably be better of with something else. I think I overlooked that you want common sub-expression _elimination_, rather than expression simplification. There are libraries for observable sharing (Andy Gill's recent one is the state-of-the-art, its on Hackage but I've forgotten its name) - that are pertinent where you have built the expressions as an embedded DSL in Haskell and you want sharing in code you generate from the Haskell DSL. On 11 August 2011 08:57, Anton Kholomiov anton.kholom...@gmail.com wrote: Thank you for the reference to Strafunski libraries, I read HaskellWiki, but I don't have a permission to visit their site. All links are forbidden. Can it be a function: fun :: Eq a = Tree a - [(Int, (a, [Int]))] where tuple codes nodes, and Int's code edges. 2011/8/11 Stephen Tetley stephen.tet...@gmail.com Wouldn't this be dependent upon your AST and thus not readily package-able as a library? Expression simplification has been a prime example for Strafunski style traversal libraries. You might be able to find examples that you can adapt to your own AST written with Uniplate or similar library. On 11 August 2011 05:00, Anton Kholomiov anton.kholom...@gmail.com wrote: Is there a library on common sub-expression elimination? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] library on common sub-expression elimination?
yes. On Fri, Aug 12, 2011 at 11:02 AM, Anton Kholomiov anton.kholom...@gmail.com wrote: Do you mean that x and y in x = a + 1 y = a + 1 are different from data-reify point of view? 2011/8/12 Conal Elliott co...@conal.net Note that data-reify will only find *some* common/equal sub-expressions, namely the pointer-equal ones. In all of my code-generating (deep) DSLs, it's been very important for efficiency to also pull out equal-but-pointer-unequal expressions. - Conal On Thu, Aug 11, 2011 at 4:41 AM, Vo Minh Thu not...@gmail.com wrote: I guess you refer to data-reify: http://hackage.haskell.org/package/data-reify 2011/8/11 Stephen Tetley stephen.tet...@gmail.com: Strafunski and its successors (Uniplate, SYB, KURE) are really for working on trees. If you want to work on graphs you would probably be better of with something else. I think I overlooked that you want common sub-expression _elimination_, rather than expression simplification. There are libraries for observable sharing (Andy Gill's recent one is the state-of-the-art, its on Hackage but I've forgotten its name) - that are pertinent where you have built the expressions as an embedded DSL in Haskell and you want sharing in code you generate from the Haskell DSL. On 11 August 2011 08:57, Anton Kholomiov anton.kholom...@gmail.com wrote: Thank you for the reference to Strafunski libraries, I read HaskellWiki, but I don't have a permission to visit their site. All links are forbidden. Can it be a function: fun :: Eq a = Tree a - [(Int, (a, [Int]))] where tuple codes nodes, and Int's code edges. 2011/8/11 Stephen Tetley stephen.tet...@gmail.com Wouldn't this be dependent upon your AST and thus not readily package-able as a library? Expression simplification has been a prime example for Strafunski style traversal libraries. You might be able to find examples that you can adapt to your own AST written with Uniplate or similar library. On 11 August 2011 05:00, Anton Kholomiov anton.kholom...@gmail.com wrote: Is there a library on common sub-expression elimination? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Properties for Foldable
Is there a collection of laws associated with the Foldable class? Or for Traversable? - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
Thanks for these instructions, John. I had to adapt to my 32-bit ghc by adding +universal to the 'port install' lines. I did not find a gtkglext.dpatch. Has it been roled into the gtkglext darcs repo? I guess not, since the last update was Nov 7 (Tag 0.12.0), according to 'darcs changes'. Eventually everything compiled, but I get a linking error. When building an executable, I get Linking dist/build/TestImage/TestImage ... Undefined symbols: _gdk_gl_config_get_screen, referenced from: _s8kj_info in libHSgtkglext-0.12.0.a(Config.o) _gdk_gl_context_is_direct, referenced from: _s73Y_info in libHSgtkglext-0.12.0.a(Context.o) _gdk_gl_context_get_gl_config, referenced from: _s777_info in libHSgtkglext-0.12.0.a(Context.o) _gdk_gl_context_get_render_type, referenced from: _s7lg_info in libHSgtkglext-0.12.0.a(Context.o) _gdk_gl_context_get_share_list, referenced from: _s75v_info in libHSgtkglext-0.12.0.a(Context.o) _gdk_gl_config_get_depth, referenced from: _s8r6_info in libHSgtkglext-0.12.0.a(Config.o) In ghci: *Main main Loading package array-0.3.0.2 ... linking ... done. Loading package bytestring-0.9.1.10 ... linking ... done. ... Loading package cairo-0.12.0 ... linking ... done. Loading package glib-0.12.0 ... linking ... done. Loading package gio-0.12.0 ... linking ... done. Loading package pango-0.12.0 ... linking ... done. Loading package gtk-0.12.0 ... linking ... done. Loading package gtkglext-0.12.0 ... linking ... interactive: unknown symbol `_gdk_gl_context_get_render_type' ghc: unable to load package `gtkglext-0.12.0' *Main Are these failures about the missing patch? - Conal On Thu, May 26, 2011 at 3:03 AM, John Lato jwl...@gmail.com wrote: fltk definitely has some good points, but I've always found it hideously ugly. Of course the default gtk on osx is ugly too, but some of the available themes are nice. However, getting gtk with OpenGL on osx was fairly easy. Everything worked out of the box except gtkglext (Haskell package). I've submitted some patches for that which hopefully will be applied to the repo soon. This is what I used: git darcs ghc-7.0.3 (self-compiled) cabal-install macports gtk2 +no_x11 +quartz macports gtkglext +no_x11 +quartz gtk2hs from source gtkglext (Haskell) from source I use a self-compiled ghc, but this should work with any ghc. Mixing ghc and macports can cause problems with libiconv, but the solutions are pretty well-known. Since I compile ghc, I configure it to use macports's libiconv so there aren't any conflicts. sudo port install gtkglext +no_x11 +quartz (wait a while...) darcs get --lazy http://code.haskell.org/gtk2hs cd gtk cabal install gtk2hs-buildtools chmod +x bootstrap.sh ./bootstrap.sh -fhave-quartz-gtk (wait a while...) cd .. darcs get --lazy http://code.haskell.org/gtkglext cd gtkglext darcs apply gtkglext.dpatch cabal install Until the source tree gets patched, you'll have to manually apply the patch bundle. If you want to avoid macports, it should be possible to use gtk-osx and gtkglext from source instead. However, I've found gtk-osx to be unstable and quite difficult to build in the past, so I'd strongly recommend macports, at least for now. The source install of gtkglext works just fine and can be used with macports gtk2 (I tested this). Since this path already uses macports there's not much benefit though. Cheers, John L On Wed, May 25, 2011 at 9:07 PM, Evan Laforge qdun...@gmail.com wrote: fltk supports OpenGL on windows, X11, and OS X, though I've never used it. The thing it doesn't have is a haskell binding, but as I mentioned I just bind whatever I need when I need it and since I don't need much it's easy. Dunno if this applies in your case though. Maybe it's my NIH, but I like to start with something too simple and add what I need rather than start with something that has more than I need and try to get it working. On Wed, May 25, 2011 at 11:58 AM, Conal Elliott co...@conal.net wrote: Thanks, John. Encouraging bit of news. Please do let us know what you learn when you try. - Conal On Tue, May 24, 2011 at 1:28 AM, John Lato jwl...@gmail.com wrote: You can use gtkglext to get OpenGL support. With the official release of gtkglext-1.2.0 there's a bit of hacking involved (that was probably me you're referring to), but it looks like the repo head has native Quartz. With any luck, you just need to build gtkglext from the repo, then the gtkglext package. I might have some time to try this later today; I'll report back if I get results. John Lato On Tue, May 24, 2011 at 6:01 AM, Conal Elliott co...@conal.net wrote: Last I tried, there wasn't native support for OpenGL with gtk, and I need OpenGL. Then more recently, I heard of some progress in that area
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
Thanks, John. Encouraging bit of news. Please do let us know what you learn when you try. - Conal On Tue, May 24, 2011 at 1:28 AM, John Lato jwl...@gmail.com wrote: You can use gtkglext to get OpenGL support. With the official release of gtkglext-1.2.0 there's a bit of hacking involved (that was probably me you're referring to), but it looks like the repo head has native Quartz. With any luck, you just need to build gtkglext from the repo, then the gtkglext package. I might have some time to try this later today; I'll report back if I get results. John Lato On Tue, May 24, 2011 at 6:01 AM, Conal Elliott co...@conal.net wrote: Last I tried, there wasn't native support for OpenGL with gtk, and I need OpenGL. Then more recently, I heard of some progress in that area, but requiring lots of hacking to get it all compiling. Any recent news? - Conal On Mon, May 23, 2011 at 2:33 AM, John Lato jwl...@gmail.com wrote: Message: 17 Date: Fri, 20 May 2011 15:59:51 -0700 From: Evan Laforge qdun...@gmail.com Subject: Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics To: Erik Hesselink hessel...@gmail.com Cc: haskell-cafe@haskell.org Message-ID: BANLkTi=74mm6ortu2e192jtoot9g49f...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Note that it is supposed to be possible to build gtk2hs with gtk+osx, which will not use X11 but use the native OS X GUI. I've not been able to get this to work, but it's been a while since I tried. The Haskell wiki mentions it doesn't support Glade, but does support Cairo. If this were to work, gtk2hs would be a serious option as well. I've tried this 3 or 4 times, and failed every time. It's crazy complicated. I used to use this combination regularly. IME the difficulties are primarily with getting a working gtk+osx build. Once that was accomplished, gtk2hs was a straightforward install, provided you build from the src repo with the -quartz flag. Recently I've switched to using macports gtk2 with the quartz, no-x11 variant, which also uses native cocoa. This is much more reliable than gtk+osx. I don't know if it supports Glade though. My biggest problem with wx is that there's no support for building 64-bit wx applications on OS X. If that were fixed I might prefer it. John Lato ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
Last I tried, there wasn't native support for OpenGL with gtk, and I need OpenGL. Then more recently, I heard of some progress in that area, but requiring lots of hacking to get it all compiling. Any recent news? - Conal On Mon, May 23, 2011 at 2:33 AM, John Lato jwl...@gmail.com wrote: Message: 17 Date: Fri, 20 May 2011 15:59:51 -0700 From: Evan Laforge qdun...@gmail.com Subject: Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics To: Erik Hesselink hessel...@gmail.com Cc: haskell-cafe@haskell.org Message-ID: BANLkTi=74mm6ortu2e192jtoot9g49f...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Note that it is supposed to be possible to build gtk2hs with gtk+osx, which will not use X11 but use the native OS X GUI. I've not been able to get this to work, but it's been a while since I tried. The Haskell wiki mentions it doesn't support Glade, but does support Cairo. If this were to work, gtk2hs would be a serious option as well. I've tried this 3 or 4 times, and failed every time. It's crazy complicated. I used to use this combination regularly. IME the difficulties are primarily with getting a working gtk+osx build. Once that was accomplished, gtk2hs was a straightforward install, provided you build from the src repo with the -quartz flag. Recently I've switched to using macports gtk2 with the quartz, no-x11 variant, which also uses native cocoa. This is much more reliable than gtk+osx. I don't know if it supports Glade though. My biggest problem with wx is that there's no support for building 64-bit wx applications on OS X. If that were fixed I might prefer it. John Lato ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
Thanks, Heinrich! I tried your sample code (having grabbed compiled EnableGUI.hs). Works okay, including multiple calls to 'main'. There are a few subtle quirks. I don't see the usual bottom-right resize icon (three parallel lines at 45 degrees), and the Zooom/2 program for convenient window moving resizing isn't able to move resize this one window. Have you noticed something similar? - Conal On Wed, May 18, 2011 at 12:33 AM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: Conal Elliott wrote: I still haven't found any way to do GUIs or interactive graphics in Haskell on a Mac that isn't plagued one or more of the following serious problems: * Incompatible with ghci, e.g., fails to make a window frame or kills the process the second time one opens a top-level window, * Goes through the X server, and so doesn't look or act like a Mac app, * Doesn't support OpenGL. A year or two ago, I put my Haskell GUI graphics work on hold while waiting hoping for a functioning pathway to open. So far I haven't heard of one. If anyone has found a solution, I'd love to hear! I've asked a similar question on stackoverflow http://stackoverflow.com/questions/5868916/ and answered it myself. Basically, GLFW works (on my machine) as long as you don't call the GLFW.terminate function. The answer includes an example program that you can try out. It might be worth to include the extra hoops (EnableGUI) in the GLFW package. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
Last I heard, wx still had the problem of crashing its host the second time one opens a window (which is typical in ghci). And last I heard, Jeremy O'Donoghue (cc'd) was exploring solutions but had very little time to pursue them. - Conal On Wed, May 18, 2011 at 11:42 AM, Tom Murphy amin...@gmail.com wrote: My conclusion was that GLFW-b (on hackage) is the best we have right now. I think we could do even better than the C libraries out there by writing the GLUT/GLFW/etc implementation purely in Haskell. We already have x11 and gtk bindings for the linux support. We have win32 api bindings for windows support. What we are lacking is good low level support for OSX GUI programming. Once we have that it's not too much of a stretch to use cabal to glue it together into a cross platform library. I believe that's the right way to go for the long term. Improving GLFW-b is a good short-term route. Would it be possible to do it with wx? There would be a much larger potential developer pool, since it's cross-platform. (Not getting away from C libraries, but they're stable). And just to say it one more time, I can use all the help I can get. There are a lot of yaks to be shaved. My hope is that if we all shave one yak then we'll quickly have the libraries we need to do some serious graphics hacking in Haskell. We already have many good libraries for it, we just need to improve and polish a few key libraries. The momentum is here and a few people have already jumped in. Time to get on board! Count me as onboard; I'm just not sure which ship I'm on yet. Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] opening windows on a mac via ghci?
Has anyone figured out a way to get libraries that open windows to work with ghci? With libraries like glut I get the body of a window, but no frame, and the process wedges. I guess the problem has to do with lack of .app bundle. If so, perhaps a work-around might involve running ghci in an app bundle--though I'm just speculating from vast ignorance. - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Status of Haskell + Mac + GUIs graphics
I still haven't found any way to do GUIs or interactive graphics in Haskell on a Mac that isn't plagued one or more of the following serious problems: * Incompatible with ghci, e.g., fails to make a window frame or kills the process the second time one opens a top-level window, * Goes through the X server, and so doesn't look or act like a Mac app, * Doesn't support OpenGL. A year or two ago, I put my Haskell GUI graphics work on hold while waiting hoping for a functioning pathway to open. So far I haven't heard of one. If anyone has found a solution, I'd love to hear! - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Platform 2011.2.0.1 now available
This release adds support for GHC 7.0.3, and significant improvements for Mac OS X users. Enticing! What are these significant improvements for Mac OS X users? - Conal On Fri, Apr 15, 2011 at 3:44 PM, Don Stewart don...@gmail.com wrote: We're pleased to announce the 2011.2.0.1 release of the Haskell Platform: a single, standard Haskell distribution for everyone. Download the Haskell Platform 2011.2.0.1: http://haskell.org/platform/ This release adds support for GHC 7.0.3, and significant improvements for Mac OS X users. The specification, along with installers (including Windows, Mac and Unix installers for a full Haskell environment) are available. The Haskell Platform is a single, standard Haskell distribution for every system, in the form of a blessed library and tool suite for Haskell distilled from the thousands of libraries on Hackage, along with installers for a wide variety of systems. It saves developers work picking and choosing the best Haskell libraries and tools to use for a task. When you install the Haskell Platform, you get the latest stable compiler, an expanded set of core libraries, additional development tools, and cabal-install – so you can download anything else you need from Hackage. This release ships with GHC 7.0.3. What you get is specified here: http://hackage.haskell.org/platform/contents.html Thanks! -- The Platform Infrastructure Team P.S. a big thanks to Mark Lentczner and Mikhail Glushenkov who built the Mac and Windows installers! ___ Libraries mailing list librar...@haskell.org http://www.haskell.org/mailman/listinfo/libraries ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] DSL for task dependencies
Speaking of which, for a while now I've been interested in designs of make-like systems that have precise simple (denotational) semantics with pleasant properties. What Peter Landin called denotative (as opposed to functional-looking but semantically ill-defined or intractable). Norman Ramsey (cc'd) pointed me to the Vestahttp://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.19.8468system from DEC SRC. If anyone knows of other related experiments, I'd appreciate hearing. - Conal On Thu, Mar 17, 2011 at 1:31 PM, David Peixotto d...@rice.edu wrote: Hi Serge, You may be thinking of the Shake DSL presented by Neil Mitchell at last years Haskell Implementers Workshop. Slides and video are available from: http://haskell.org/haskellwiki/HaskellImplementorsWorkshop/2010 Max Bolingbroke has an open source implementation available here: https://github.com/batterseapower/openshake Hope that helps. -David On Mar 17, 2011, at 3:00 PM, Serge Le Huitouze wrote: Hi Haskellers! I think I remember reading a blog post or web page describing a EDSL to describe tasks and their dependencies a la make. Can anyone point me to such published material? Thanks in advance. --serge ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] semantics
On Tue, Feb 8, 2011 at 7:04 AM, Patrick Browne patrick.bro...@dit.iewrote: Consider the following definitions: 1. Denotational semantics can be considered as relation between syntax and mathematical objects (the meaning of the syntax). 2. Operational semantics can be considered as set of rules for performing computation. Question 1 Applying these definitions in a Haskell context can I say that the lambda calculus provides both the operational and denotational semantics for Haskell programs at value level for definition and evaluations. Question 2 Does it make sense to use these definitions at type level? If so, what exactly do they represent? Thanks, Pat Here's my personal denotational answer to question 2: I think of a type as denoting a collection of (mathematical) values. If an expression e has type T, then the meaning (value) of e is a member of the collection denoted by T. This simple principle, which is fundamental to how I think of functional programming, has consequences in library design, which I've discussed at http://conal.net/blog/posts/notions-of-purity-in-haskell/ . Regards, - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] semantics
On Tue, Feb 8, 2011 at 9:02 PM, ke...@froglingo.com wrote:
On Tue, Feb 8, 2011 at 07:55 pm, Conal Elliott co...@conal.net wrote:
Here's my personal denotational answer to question 2: I think of a type as
denoting a collection of (mathematical) values. If an expression e has type
T, then the meaning (value) of e is a member of the collection denoted by T.
This simple principle, which is fundamental to how I think of functional
programming, has consequences in library design, which I've discussed at
http://conal.net/blog/posts/notions-of-purity-in-haskell/ .
When we consider a class of partial recursive functions as the type T, then
what are the expressions (such as e in your statement above) for T?
There are many, including application of those functions and to those
functions (in a language with higher-order functions), as well as variables
primitive constants. The grammar and type system mediates the legal
expressions.
It seems that the type definition missed operations. For example, if a and
b are two variables declared as integers, then we would not know how to
calculate a + b if the type integers didn't include the plus operator.
The original note didn't ask how to assign meanings to expressions, but
denotational semantics (DS) is a clear simple methodology. Meanings are
defined compositionally. For instance, the meaning of A + B is a function
of the meanings of the expressions A and B. Typically, DS is described as
being functions on syntax, but syntax is just one data type, and I find it
very useful for giving semantics to data types, in the same compositional
style. For several examples, see
http://conal.net/papers/type-class-morphisms .
- Conal
Defining a type as a set of values and a set of operations on the values is
perfectly fine mathematically. But in the context of programming languages,
a type seems to need its syntax anyhow in addition to be a set of values and
a set of operations on the values. For example the type definition in C:
typedef mydata {
int a;
char c;
}
The definition itself is the syntax while we may view the infinite many
records {0, 'a', 2, 'a', ..., 0, 'b, } as its semantics (or the
semantics was called a type earlier).
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] How to #include into .lhs files?
Does anyone have a working example of #include'ing Haskell code into a bird-tracks-style .lhs file with GHC? Every way I try leads to parsing errors. Is there documentation about how it's supposed to work? Help much appreciated. - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to #include into .lhs files?
Thanks, Daniel. I'm still stumped. When I say
#include B.hs
in a .hs file, all works fine, but when in a .lhs file I get error: B.hs:
No such file or directory. The file B.hs is in the same directory as the
including file, which is the current directory for ghci. Same situation with
ghc.
If I change B.hs to ./B.hs, I get the same behavior. Only if I use a
fully qualified path name for B.hs does it get found from the .lhs file.
I'm using GHC 6.12.3 on Mac OS 10.6.6.
Any ideas? (Anyone, not just Daniel.)
Thanks, - Conal
On Thu, Feb 3, 2011 at 2:51 AM, Daniel Fischer
daniel.is.fisc...@googlemail.com wrote:
On Thursday 03 February 2011 10:33:23, Conal Elliott wrote:
Does anyone have a working example of #include'ing Haskell code into a
bird-tracks-style .lhs file with GHC? Every way I try leads to parsing
errors. Is there documentation about how it's supposed to work?
Help much appreciated. - Conal
Stupid example:
-- Main:
{-# LANGUAGE CPP #-}
module Main (main) where
#include MachDeps.h
main :: IO ()
main = do
#if WORD_SIZE_IN_BITS == 32
putStrLn 32 bits
#include Stuff32
# else
putStrLn 64 bits
#include Stuff64
#endif
-- Stuff32:
putStrLn Included from Stuff32
-- Stuff64:
putStrLn Included from Stuff64
It's a bit tricky. Since the C preprocessor is run after the unlit, the
included code should not have bird-tracks, also you have to get the
indentation right. There's probably a way to run cpp before unlit, which
would allow you to have bird-tracks in the #include'd code.
Much easier with LaTeX-style literate code.
Cheers,
Daniel
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Interactive OpenGL-based graphics and ghci?
I'm trying to find some way to do interactive, OpenGL-based graphics in Haskell on Mac OS X. Does anyone here use GLUT or SDL on Mac OS X with ghci, or maybe an alternative library? Using ghci is very important to me, as my programs are pretty high-level and are often half-liners. I'm using gtk2hs for now, but I want something that works more natively, i.e., without the awkwardness of going through the X server. Thanks, - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What do you call Applicative Functor Morphism?
I like C morphism in general, where C is the class name, so I use Applicative morphism or applicative functor morphism (as in http://conal.net/papers/type-class-morphisms/). - Conal On Fri, Nov 5, 2010 at 8:49 PM, rocon...@theorem.ca wrote: An applicative functor morphism is a polymorphic function, eta : forall a. A1 a - A2 a between two applicative functors A1 and A2 that preserve pure and *: eta (pure c) = pure c eta (f * x) = eta f * eta x What do you guys call such a thing? My leading candidate is idomatic transformation. -- Russell O'Connor http://r6.ca/ ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] vector-space and standard API for vectors
Vector (Complex a) is a vector with respect to both 'a' and 'Complex a'. Even worse, () is a vector w.r.t. *every* scalar type. On Sat, Oct 30, 2010 at 3:07 AM, Henning Thielemann schlepp...@henning-thielemann.de wrote: wren ng thornton schrieb: On 10/22/10 8:46 AM, Alexey Khudyakov wrote: Hello everyone! It's well known that Num Co type classes are not adequate for vectors (I don't mean arrays). I have an idea how to address this problem. Conal Elliott wrote very nice set of type classes for vectors. (Definition below). I used them for some time and quite pleased. Code is concise and readable. class AdditiveGroup v where zeroV :: v (^+^) :: v - v - v negateV :: v - v [...] I'd like to know opinion of haskellers on this and specifically opinion of Conal Eliott as author and maintainer (I CC'ed him) Looks like you are about to re-implement numeric-prelude. :-) Just my standard complaint: lack of support for semirings, modules, and other simple/general structures. How come everyone's in such a hurry to run off towards Euclidean spaces et al.? I'd rather see, class Additive v where -- or AdditiveMonoid, if preferred zeroV :: v (^+^) :: v - v - v class Additive v = AdditiveGroup v where negateV :: v - v type family Scalar :: * - * Vector (Complex a) is a vector with respect to both 'a' and 'Complex a'. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lambda-case / lambda-if
I like it! Are the other sections available as well, e.g., (if False then else Cafe) Haskell -- Cafe - Conal On Sat, Oct 2, 2010 at 11:23 AM, Max Bolingbroke batterseapo...@hotmail.com wrote: Hi Cafe, I implemented the proposed Haskell' feature lambda-case/lambda-if [1] during the Haskell Implementors Workshop yesterday for a bit of fun. The patches are online [2, 3]. The feature is demonstrated in this GHCi session: $ inplace/bin/ghc-stage2 --interactive -XLambdaCase GHCi, version 7.1.20101002: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. Prelude (if then Haskell else Cafe) False Cafe Prelude (case of 1 - One; _ - Not-one) 1 One Prelude :q Do you like this feature and think it would be worth incorporating this into GHC? Or is it too specialised to be of use? If there is enough support, I'll create a ticket and see what GHC HQ make of it. Max [1] http://hackage.haskell.org/trac/haskell-prime/ticket/41 [2] http://www.omega-prime.co.uk/files/LambdaCase-Testsuite.patch [3] http://www.omega-prime.co.uk/files/LambdaCase-Compiler.patch ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: I still cannot seem to get a GUI working under Windows.
For another model of GUIs, see Tangible Values ( http://www.haskell.org/haskellwiki/TV), which is composable MVC. And amen to targeting GPUs. In addition to getting clunky, imperative GUI frameworks like wx gtk working robustly and easily in Haskell across platforms, I'd love to see more powerful, functional-friendly re-thinking of UIs. And if a new generation of GUIs comes out scrapping legacy toolkits, and the look is not what people are used to, then exploiting GPUs and good visual design could lead to something that looks better and is more fun to use. I imagine someone looking at a lovely app and saying, Wow -- great interface! I bet it was programmed in Haskell. - Conal On Sat, Oct 2, 2010 at 6:30 AM, Peter Verswyvelen bugf...@gmail.com wrote: Regarding GUIs, I really miss a pure functional framework for doing so. Currently I'm using Microsoft's WPF, and that is more or less declarative, a bit like BOOPSI or MUI on the good old Amiga days. But WPF has so many little quirks, not to mentioned a weakly typed XML-like language called XAML. Still it offers the best experiences I had so far, because it is very composable. What I would love is to build GUIs the Fruit/Yampa or maybe Reactive/Elerea way, using a graphical editor if possible. And allow separation of data (model and view-model) and looks (styling, CSS, themes...) Oh and it should preferably make use of the GPU as much as possible, where it makes sense at least. Anyway knows about such a framework in Haskell? It's a gigantic undertaking, but maybe if someone can make the basic framework, others in the community will develop controls for it? Cheers, Peter Verswyvelen On Sat, Oct 2, 2010 at 1:20 PM, Vo Minh Thu not...@gmail.com wrote: 2010/10/2 Luke Palmer lrpal...@gmail.com: On Sat, Oct 2, 2010 at 4:32 AM, Bulat Ziganshin bulat.zigans...@gmail.com wrote: Hello Heinrich, Saturday, October 2, 2010, 1:36:48 PM, you wrote: Would you put a flattr button [1] on the wxHaskell page? This way, people like me would be able to show their appreciation by donating a this page doesn't describe how to pay and how to got the money received. if Jeremy lives in right country, i suggest to use PayPal donations system. it allows to pay by credit card and then receive money to author's credit card Because of the way flattr distributes my money (i.e. donating has 0 marginal cost to me), I am much more likely to donate using flattr than paypal. Is it right that by using flattr, you end up donating the same amount of money to every flattred person in a month? So you can donate more the previous month to some project you value less than another project the next month. This seems weird to me. Cheers, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Memoization/call-by-need
Hi Alex, In Haskell, data structures cache, while functions do not. Memoization is conversion of functions into data structures (and then trivially re-wrapping as functions) so as to exploit the caching property of data structures to get caching functions. - Conal On Wed, Sep 15, 2010 at 11:03 AM, Alex Rozenshteyn rpglove...@gmail.comwrote: I feel that there is something that I don't understand completely: I have been told that Haskell does not memoize function call, e.g. slowFib 50 will run just as slowly each time it is called. However, I have read that Haskell has call-by-need semantics, which were described as lazy evaluation with memoization I understand that fib50 = slowFib 50 will take a while to run the first time but be instant each subsequent call; does this count as memoization? (I'm trying to understand Purely Functional Data Structures, hence this question) -- Alex R ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haddock comments for GADT constructors?
I'm updating a library (TV) and getting haddock parse errors for the doc strings attached to GADT constructors. Is there a way to haddock-document GADT constructors? I've tried both -- | ... before and -- ^ ... after. Both give parse errors. Thanks, - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haddock comments for GADT constructors?
Thanks David. Glad to know. I'll kludge around the missing feature for now. I've added myself to the CC list for the ticket. Regards, - Conal On Fri, Sep 10, 2010 at 10:47 AM, David Waern david.wa...@gmail.com wrote: 2010/9/10 Conal Elliott co...@conal.net: I'm updating a library (TV) and getting haddock parse errors for the doc strings attached to GADT constructors. Is there a way to haddock-document GADT constructors? I've tried both -- | ... before and -- ^ ... after. Both give parse errors. Thanks, - Conal Nope. It's not yet supported. We should really get this one done. http://trac.haskell.org/haddock/ticket/43 David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Fwd: Semantics of iteratees, enumerators, enumeratees?
Here's a way I've been tinkering with to think about iteratees clearly. For simplicity, I'll stick with pure, error-free iteratees for now, and take chunks to be strings. Define a function that runs the iteratee: runIter :: Iteratee a - [String] - (a, [String]) Note that chunking is explicit here. Next, a relation that an iteratee implements a given specification, defined by a state transformer: sat :: Iteratee a - State String a - Bool Define sat in terms of concatenating chunks: sat it st = second concat . runIter it == runState st . second concat where the RHS equality is between functions (pointwise/extensionally), and runState uses the representation of State directly runState :: State s a - s - (a,s) (I think this sat definition is what Conrad was alluding to.) Now use sat to specify and verify operations on iteratees and to *synthesize* those operations from their specifications. Some iteratees might not satisfy *any* (State-based) specification. For instance, an iteratee could look at the lengths or number of its chunks and produce results accordingly. I think of such iteratees as abstraction leaks. Can the iteratee vocabulary be honed to make only well-behaved (specifiable) iteratees possible to express? If so, can we preserve performance benefits? If indeed the abstraction leaks can be fixed, I expect there will be a simpler more conventional semantics than sat above. - Conal On Tue, Aug 24, 2010 at 2:55 PM, Conrad Parker con...@metadecks.org wrote: On 24 August 2010 14:47, Jason Dagit da...@codersbase.com wrote: On Mon, Aug 23, 2010 at 10:37 PM, Conrad Parker con...@metadecks.org wrote: On 24 August 2010 14:14, Jason Dagit da...@codersbase.com wrote: I'm not a semanticist, so I apologize right now if I say something stupid or incorrect. On Mon, Aug 23, 2010 at 9:57 PM, Conal Elliott co...@conal.net wrote: So perhaps this could be a reasonable semantics? Iteratee a = [Char] - Maybe (a, [Char]) I've been tinkering with this model as well. However, it doesn't really correspond to the iteratee interfaces I've seen, since those interfaces allow an iteratee to notice size and number of chunks. I suspect this ability is an accidental abstraction leak, which raises the question of how to patch the leak. From a purely practical viewpoint I feel that treating the chunking as an abstraction leak might be missing the point. If you said, you wanted the semantics to acknowledge the chunking but be invariant under the size or number of the chunks then I would be happier. I think that's the point, ie. to specify what the invariants should be. For example (to paraphrase, very poorly, something Conal wrote on the whiteboard behind me): run [concat [chunk]] == run [chunk] ie. the (a, [Char]) you maybe get from running an iteratee over any partitioning of chunks should be the same, ie. the same as from running it over the concatenation of all chunks, which is the whole input [Char]. I find this notation foreign. I get [Char], that's the Haskell String type, but what is [chunk]? I doubt you mean a list of one element. sorry, that was just my way of writing the list of chunks or perhaps the stream of chunks that represents the input. Conrad. I use iteratees when I need to be explicit about chunking and when I don't want the resources to leak outside of the stream processing. If you took those properties away, I wouldn't want to use it anymore because then it would just be an inelegant way to do things. Then I suppose the model for Enumerators is different than that for Iteratees; part of the point of an Enumerator is to control the size of the chunks, so that needs to be part of the model. An Iteratee, on the other hand, should not have to know the size of its chunks. So you don't want to be able to know the length of a chunk (ie. a part of the stream), but you do want to be able to, say, fold over it, and to be able to stop the computation at any time (these being the main point of iteratees ...). I think I agree with that. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Fwd: Semantics of iteratees, enumerators, enumeratees?
Hi John, Please note that I'm suggesting eliminating chunks from the semantics only -- not from the implementation. For precise simple chunk-less semantics, it's only important that the iteratees map equivalent input streams to equivalent output streams, where equivalent means equal after concatenating all of the chunks. In other words, the chunk lists denote their concatenations, so semantically equal inputs must lead to semantically equal outputs. (Assuming I understand the intention of chunking as being an implementation issue only, i.e., present only for optimization.) We could call this property semantic referential transparency. IIUC, 'drop' is semantically RT, since it's *specified* in terms of elements (and only *implemented* in terms of chunks). Do you know of any iteratees in use that map (semantically) equal inputs to (semantically) unequal outputs, i.e.,that violate semantic RT as I've defined it? In the current APIs, one can easily define such iteratees, but I'm hoping that the programming interfaces can be repaired to eliminate that problem (the abstraction leaks I've been mentioning). - Conal On Tue, Aug 24, 2010 at 9:32 PM, John Lato jwl...@gmail.com wrote: I think the big problem with chunking is that many useful iteratees need to be able to inspect the length of the chunk. The most obvious is drop, but there are many others. Or if not inspect the length, have a new function on the stream dropReport :: Int - s - (s, Int) which reports how much was dropped. Either way, chunking adds a deal of implementation burden. I suspect that the proper vocabulary for iteratees wouldn't include chunks at all, only single elements. This discussion has prompted me to consider the implications of such an implementation, as it would be much simpler. I have one idea that I think will at least maintain performance for many operations, although there will be performance hits too. If the drawbacks are in areas that aren't particularly useful, though, it may be acceptable. John From: Conal Elliott co...@conal.net Here's a way I've been tinkering with to think about iteratees clearly. For simplicity, I'll stick with pure, error-free iteratees for now, and take chunks to be strings. Define a function that runs the iteratee: runIter :: Iteratee a - [String] - (a, [String]) Note that chunking is explicit here. Next, a relation that an iteratee implements a given specification, defined by a state transformer: sat :: Iteratee a - State String a - Bool Define sat in terms of concatenating chunks: sat it st = second concat . runIter it == runState st . second concat where the RHS equality is between functions (pointwise/extensionally), and runState uses the representation of State directly runState :: State s a - s - (a,s) (I think this sat definition is what Conrad was alluding to.) Now use sat to specify and verify operations on iteratees and to *synthesize* those operations from their specifications. Some iteratees might not satisfy *any* (State-based) specification. For instance, an iteratee could look at the lengths or number of its chunks and produce results accordingly. I think of such iteratees as abstraction leaks. Can the iteratee vocabulary be honed to make only well-behaved (specifiable) iteratees possible to express? If so, can we preserve performance benefits? If indeed the abstraction leaks can be fixed, I expect there will be a simpler more conventional semantics than sat above. - Conal On Tue, Aug 24, 2010 at 2:55 PM, Conrad Parker con...@metadecks.org wrote: On 24 August 2010 14:47, Jason Dagit da...@codersbase.com wrote: On Mon, Aug 23, 2010 at 10:37 PM, Conrad Parker con...@metadecks.org wrote: On 24 August 2010 14:14, Jason Dagit da...@codersbase.com wrote: I'm not a semanticist, so I apologize right now if I say something stupid or incorrect. On Mon, Aug 23, 2010 at 9:57 PM, Conal Elliott co...@conal.net wrote: So perhaps this could be a reasonable semantics? Iteratee a = [Char] - Maybe (a, [Char]) I've been tinkering with this model as well. However, it doesn't really correspond to the iteratee interfaces I've seen, since those interfaces allow an iteratee to notice size and number of chunks. I suspect this ability is an accidental abstraction leak, which raises the question of how to patch the leak. From a purely practical viewpoint I feel that treating the chunking as an abstraction leak might be missing the point. If you said, you wanted the semantics to acknowledge the chunking but be invariant under the size or number of the chunks then I would be happier. I think that's the point, ie. to specify what the invariants should be. For example (to paraphrase, very poorly, something Conal wrote on the whiteboard behind me): run [concat [chunk
Re: [Haskell-cafe] Re: Fwd: Semantics of iteratees, enumerators, enumeratees?
I have omitted the chunking [Char] because I don't like it; invariance with respect to the chunk sizes is something that should be left to the iteratee abstraction. I have this same reservation about iteratees. And related one for enumerators and enumeratees. Assuming my sense of their intended meanings is on track, they allow lots of well-typed but bogus values. Defining and adhering to a precise denotational model would eliminate all of these abstraction leaks, as Luke Palmer alludes to in http://lukepalmer.wordpress.com/2008/07/18/semantic-design/ . - Conal On Mon, Aug 23, 2010 at 4:06 PM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: Conal Elliott wrote: For anyone interested in iteratees (etc) and not yet on the iteratees mailing list. I'm asking about what iteratees *mean* (denote), independent of the various implementations. My original note (also at the end below): In my world view, iteratees are just a monad M with a single operation symbol :: M Char that reads the next symbol from an input stream. In other words, they're a very simple parser monad. The emphasis is not on parsing, but on the fact that one and the same monadic value can be run on different streams runHandle :: M a - Handle - IO a runString :: M a - String - a runByteString :: M a - ByteString - a The monad M may also include convenience like exceptions and liftIO . I have omitted the chunking [Char] because I don't like it; invariance with respect to the chunk sizes is something that should be left to the iteratee abstraction. Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Fwd: Semantics of iteratees, enumerators, enumeratees?
So perhaps this could be a reasonable semantics? Iteratee a = [Char] - Maybe (a, [Char]) I've been tinkering with this model as well. However, it doesn't really correspond to the iteratee interfaces I've seen, since those interfaces allow an iteratee to notice size and number of chunks. I suspect this ability is an accidental abstraction leak, which raises the question of how to patch the leak. What about enumerators? The definition given in Oleg's presentation ( http://okmij.org/ftp/Streams.html#iteratee, slide 21) is type Enumerator a = Iteratee a - Iteratee a Since we have a semantics for Iteratee, we could take this Enumerator definition as is, and we'd have a semantics, i.e., [[Enumerator a]] = [[Iteratee a]] - [[Iteratee a]] I don't trust this choice, however. It could be that, like the Iteratee representation, the Enumerator representation (as a function) is more an *implementation* than a semantics. That is, like Iteratee, * there might be a simpler and more natural semantic model; and * the representation may be junky, i.e., having many representations that we wouldn't want to be denotable. Is there a simpler model of Enumerator? My intuition is that it's simply a stream: [[Enumerator a]] = String Oddly, 'a' doesn't show up on the RHS. Maybe the representation ought to be type Enumerator = forall a. Iteratee a - Iteratee a so [[Enumerator]] = String Are there any enumerator definitions that couldn't use this more restrictive representation type? Glancing through the slides, the only Enumerator types I see are indeed polymorphic over a (the iteratee's result type.) Again, there's a terrible abstraction leak here, i.e., many ways to write down enumerators that type-check but are not meaningful within the model. Can this leak be fixed? Comments? - Conal On Mon, Aug 23, 2010 at 8:13 PM, Luke Palmer lrpal...@gmail.com wrote: On Mon, Aug 23, 2010 at 1:06 AM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: Conal Elliott wrote: For anyone interested in iteratees (etc) and not yet on the iteratees mailing list. I'm asking about what iteratees *mean* (denote), independent of the various implementations. My original note (also at the end below): In my world view, iteratees are just a monad M with a single operation symbol :: M Char that reads the next symbol from an input stream. So perhaps this could be a reasonable semantics? Iteratee a = [Char] - Maybe (a, [Char]) = MaybeT (State [Char]) a symbol [] = Nothing symbol (c:cs) = Just (c, cs) I'm not experienced with iteratees. Does this miss something? Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Fwd: Semantics of iteratees, enumerators, enumeratees?
For anyone interested in iteratees (etc) and not yet on the iteratees mailing list. I'm asking about what iteratees *mean* (denote), independent of the various implementations. My original note (also at the end below): With the encouragement help of Conrad Parker, I've been looking at iteratees, enumerators, enumeratees. I can find plenty written about them, but only about benefits and implementation. In sifting through chunks, error/control messages, and continuations, I find myself longing for a precise semantic basis. I keep wondering: what simpler precise semantic notions do these mechanisms implement? Has anyone worked out a denotational semantics for iteratees, enumerators, enumeratees -- something that simplifies away the performance advantages complexities? I've worked out something tentative, but perhaps I'm covering old ground. - Conal -- Forwarded message -- From: Conal Elliott co...@conal.net Date: Sun, Aug 22, 2010 at 11:02 PM Subject: Re: Semantics of iteratees, enumerators, enumeratees? To: John Lato jwl...@gmail.com Hi John, I just remembered: Luke Palmer wrote an accessible helpful description of this approach to library design. See his post *Semantic Designhttp://lukepalmer.wordpress.com/2008/07/18/semantic-design/ *. (I've switched to using the more specific term denotational design, since I specifically intend denotational semantics, not operational.) Denotational design is at the heart of most of what I do, particularly including the three pieces of work you mentioned: functional images (Pan), FRP, and automatic differentiation. My main goal is simplicity with precision. Without the precision, I can't tell whether the simplicity is real or illusory. We functional programmers have a strong advantage over imperative programming (including OO) in that we can achieve semantic precision. I want to see us exploit this advantage! And not settle for being a power tool for generating semantically inscrutable imperative computations. Regards, - Conal On Sun, Aug 22, 2010 at 10:43 PM, John Lato jwl...@gmail.com wrote: Hi Conal, I've always regarded your work in essentially the same category as Edward Kmett's (and most of Oleg's): stuff that's incredible powerful and concise, but I can't understand at all what it means. I've admired a lot of your work, particularly on Pan, FRP, and automatic differentiation, but most of the rest I couldn't understand at all. I'll take a look at your *Denotational Design* paper again; maybe now that I have a lot more experience I'll be able to make sense of it. John On Sun, Aug 22, 2010 at 8:18 AM, Conal Elliott co...@conal.net wrote: Hi John, Thanks for the reply. A denotational semantics would be independent of any implementation, so it would apply to any of them, as long as they have the same programming interface. The purpose is to simply precisely say what the types and their building blocks (API) mean by providing a precise, implementation-independent, and simple-as-possible math model. Such a semantics can be used to prove properties and to define correctness of any implementation. It also gives clear feedback on how elegant or inelegant a library design is. For instance, given a type, Map k v, of finite maps, we might say the meaning is the type of partial functions from k to v, either k - v (where absent is _|_) or k - Maybe v (where absent is Nothing). Then we'd give the meaning of each Map operation as a function of the meanings of its arguments. This example and several others are given in the paper *Denotational design with type class morphismshttp://conal.net/papers/type-class-morphisms/ *. Regards, - Conal On Sun, Aug 22, 2010 at 8:31 PM, John Lato jwl...@gmail.com wrote: Hi Conal, To my knowledge, nobody has attempted this. Oleg may have some ideas, but I don't think he's written about it. I really don't know anything about denotational semantics, so I couldn't do this myself. For some time I've thought it would be good if somebody were able to put together a formal semantics for iteratees, so I'd be very interested if you'd share what you have so far. Would a denotational semantics apply equally to multiple implementations, or would it be tied to a specific implementation? John On Sun, Aug 22, 2010 at 3:47 AM, Conal Elliott co...@conal.net wrote: With the encouragement help of Conrad Parker, I've been looking at iteratees, enumerators, enumeratees. I can find plenty written about them, but only about benefits and implementation. In sifting through chunks, error/control messages, and continuations, I find myself longing for a precise semantic basis. I keep wondering: what simpler precise semantic notions do these mechanisms implement? Has anyone worked out a denotational semantics for iteratees, enumerators, enumeratees -- something that simplifies away the performance advantages complexities? I've
Re: [Haskell-cafe] Re: philosophy of Haskell
On Sat, Aug 14, 2010 at 10:11 PM, Bill Atkins watk...@alum.rpi.edu wrote: On Saturday Aug 14, 2010, at 12:50 AM, Conal Elliott wrote: And the IO monad is what Jerzy asked about. I'm pointing out that the state monad does not capture concurrency, and the EDSL model does not capture FFI. (Really, it depends which EDSL model. I haven't seen one that can capture FFI. And maybe not concurrency either.) So which model captures the way the IO monad works? I don't think anyone has given a denotational (functional-style) model for the meaning of IO. As I wrote elsewherehttp://conal.net/blog/posts/notions-of-purity-in-haskell/#comment-22829 : IO carries the collective sins of our tribe, as the scapegoat did among the ancient Hebrews. Or, as Simon Peyton Jones expressed it, “The IO monad has become Haskell’s sin-bin. Whenever we don’t understand something, we toss it in the IO monad.” (From Wearing the hair shirt – A retrospective on Haskellhttp://research.microsoft.com/en-us/um/people/simonpj/papers/haskell-retrospective/.) Is it likely that we can then come along later and give a compelling and mathematically well-behaved notion of equality to our toxic waste pile? Or will it insist on behaving anti-sociably, as our own home-grown Toxic Avenger http://en.wikipedia.org/wiki/Toxic_Avenger? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: philosophy of Haskell
There are various models. One (the state monad model) of them would desugar this to: \world0 - let (x, world1) = getLine world0 world2 = print (x+1) world1 world3 = print (x+2) world2 in world3 Hi Ertugrul, This state monad model does not really work for IO, since it fails to capture IO's concurrency (with non-deterministic interleaving). I don't know whether/how the EDSL model you mention addresses concurrency or FFI. So, maybe these models are models of something other (and much less expressive) than Haskell's IO. Which re-raises Jerzy's question. Regards, - Conal On Mon, Aug 9, 2010 at 10:38 PM, Ertugrul Soeylemez e...@ertes.de wrote: jerzy.karczmarc...@info.unicaen.fr wrote: Alberto G. Corona writes: (...) Desugarize the do notation, after that, desugarize the = and operators down to the function call notation and suddenly everithing lost its magic because it becomes clear that a haskell monad is a sugarization of plain functional tricks. Yep. But, BTW, could you tell me what was the result of the final desugarization and the BASIC sense of the IO monad for you? Example: do x - getLine print (x+1) print (x+2) There are various models. One (the state monad model) of them would desugar this to: \world0 - let (x, world1) = getLine world0 world2 = print (x+1) world1 world3 = print (x+2) world2 in world3 Another one (the EDSL model, which I personally prefer) would desugar it to something as simple as this: GetLine `BindIO` \x - Print (x+1) `BindIO` const (Print (x+2)) I wonder if there are more models for IO. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: philosophy of Haskell
On Sat, Aug 14, 2010 at 9:27 AM, Ertugrul Soeylemez e...@ertes.de wrote: Conal Elliott co...@conal.net wrote: There are various models. One (the state monad model) of them would desugar this to: \world0 - let (x, world1) = getLine world0 world2 = print (x+1) world1 world3 = print (x+2) world2 in world3 Hi Ertugrul, This state monad model does not really work for IO, since it fails to capture IO's concurrency (with non-deterministic interleaving). Well, it does capture concurrency and FFI, but it has no explicit notion for it. In other words, concurrent threads and FFI calls are effects like everything else, so the forkIO function just changes the world state implicitly and that's it. Consider that IO's concurrency means that something else can happen between printing x+1 and printing x+2, so that x+2 is *not* printed in world2, but rather in a world influenced outside of this thread. Similarly, x+1 might not be printed in world1, and the getLine might not be executed in world0. So World - (a, World) is *not* expressive enough to explain Haskell-IO-style concurrency. Do you see what I mean? I don't know whether/how the EDSL model you mention addresses concurrency or FFI. Just like the state monad model. This is not a weakness of the interpretation, but of the IO monad itself, because it is quite a raw and straightforward language for doing I/O. And the IO monad is what Jerzy asked about. I'm pointing out that the state monad does not capture concurrency, and the EDSL model does not capture FFI. (Really, it depends which EDSL model. I haven't seen one that can capture FFI. And maybe not concurrency either.) Other approaches like functional reactive programming may be better at capturing these things, particularly the interactions between concurrent threads, at least for specific applications. So, maybe these models are models of something other (and much less expressive) than Haskell's IO. Which re-raises Jerzy's question. Haskell's IO is flexible at the cost of being quite low level. I think to capture things like concurrency properly and explicitly you need a richer sublanguage, maybe something based on the pi calculus. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strange error with type classes + associated types
On Sun, Apr 18, 2010 at 9:02 PM, Brent Yorgey byor...@seas.upenn.eduwrote: Conal, Thanks for looking into this! Making (:-*) into a proper type seems promising. I did try wrapping (:-*) in a newtype but that didn't help (although I didn't expect it to). What do you mean by a proper type? I didn't know what Roman meant either, though I guessed he meant a newtype or data type. I see you just uploaded a new version of vector-space; what's new in 0.6.2? The dependency on the Boolean package now specifies = 0.0.1. -Brent On Sat, Apr 17, 2010 at 10:28:45AM -0700, Conal Elliott wrote: Oh! I'd completely forgotten about this idea. Looking at Data.LinearMap in vector-space, I see a comment about exactly this ambiguity, as well as the start of a new module that wraps a data type around the linear map representation. I don't recall whether I got stuck or just distracted. On Sat, Apr 17, 2010 at 3:46 AM, Roman Leshchinskiy r...@cse.unsw.edu.au wrote: On 17/04/2010, at 11:00, Conal Elliott wrote: I'm unsure now, but I think I tried making Basis a data type (not syn) and ran into the problem I mentioned above. The Basis *synonyms* also have HasTrie instances, which is crucially important. If we switch to (injective) data types, then we lose the HasTrie instances. I'd be okay with defining HasTrie instances (preferably via deriving) for the associated Basis data types, but I couldn't figure out how to. Maybe it's not possible currently, or maybe I just didn't know how. Could you perhaps make (:-*) a proper type rather than a synonym? That would help with the ambiguity. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strange error with type classes + associated types
Oh! I'd completely forgotten about this idea. Looking at Data.LinearMap in vector-space, I see a comment about exactly this ambiguity, as well as the start of a new module that wraps a data type around the linear map representation. I don't recall whether I got stuck or just distracted. On Sat, Apr 17, 2010 at 3:46 AM, Roman Leshchinskiy r...@cse.unsw.edu.auwrote: On 17/04/2010, at 11:00, Conal Elliott wrote: I'm unsure now, but I think I tried making Basis a data type (not syn) and ran into the problem I mentioned above. The Basis *synonyms* also have HasTrie instances, which is crucially important. If we switch to (injective) data types, then we lose the HasTrie instances. I'd be okay with defining HasTrie instances (preferably via deriving) for the associated Basis data types, but I couldn't figure out how to. Maybe it's not possible currently, or maybe I just didn't know how. Could you perhaps make (:-*) a proper type rather than a synonym? That would help with the ambiguity. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strange error with type classes + associated types
Hi Brent, I'm sorry to hear that the non-injectivity issue bit you. It's bitten me also at times, leading me to choose associated data types (injective) instead of associated synonyms (potentially non-injective). And sometimes, the data types route is problematic, as the new types aren't instances (and I don't know how to declare them to be) of other classes when I need them to be. MemoTrie vector-space seem to trip over these issues, and I thought I'd lucked into a combo that worked, but from your note I guess I just hadn't pushed far enough to uncover difficulties. I'm unsure now, but I think I tried making Basis a data type (not syn) and ran into the problem I mentioned above. The Basis *synonyms* also have HasTrie instances, which is crucially important. If we switch to (injective) data types, then we lose the HasTrie instances. I'd be okay with defining HasTrie instances (preferably via deriving) for the associated Basis data types, but I couldn't figure out how to. Maybe it's not possible currently, or maybe I just didn't know how. I'd love to have help exploring these issues more widely deeply, as they do seem to fatally wound the usefulness of associated data types. - Conal On Wed, Apr 14, 2010 at 8:01 AM, Brent Yorgey byor...@seas.upenn.eduwrote: On Thu, Apr 15, 2010 at 12:48:20AM +1000, Roman Leshchinskiy wrote: Right, this seems weird to me. Why is there still a 'u' mentioned in the constraints? Actually, I don't even see why there ought to be both v and v1. The type of (*.*) mentions three type variables, u, v, and w: (*.*) :: (HasBasis u, HasTrie (Basis u), HasBasis v, HasTrie (Basis v), VectorSpace w, Scalar v ~ Scalar w) = (v :-* w) - (u :-* v) - u :-* w Note that (:-*) is a type synonym: type :-* u v = MSum (Basis u :-: v) Aha! That's what I was missing. Thanks for the insight, Roman. I guess it's time to go bug Conal... =) -Brent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] vector stream fusion, inlining and compilation time
Hi Max. Thanks much for passing on this info. Very encouraging news! - Conal On Wed, Mar 10, 2010 at 8:41 AM, Max Bolingbroke batterseapo...@hotmail.com wrote: This is my understanding: Old story (GHC 6.12.1 (?) and below): 1) Function bodies are only optimised if they are not marked INLINE. The assumption is that INLINE bodies will be inlined and then optimised at the point where they are inlined. 2) Unfoldings are exported in .hi files for functions if they are nonrecursive and small enough or marked INLINE New story (GHC HEAD): 1) Function bodies are optimised regardless of whether they are marked INLINE or not. 2) Unfoldings are exported in .hi files for functions if they are nonrecursive and small enough or marked INLINE, but the unfolding that is exported is the _unoptimised_ version! - It is important to export the unoptimised version because the optimisation may destroy information we would have relied upon in rule matching. E.g. the optimised version of a list producer will not use build, but we need to be able to spot the build in rules to do foldr/build fusion. The new story is much more robust - adding INLINE pragmas should be a much safer thing to do now, because even if the function is not inlined you will still get an optimised definition for that function. Other relevant points: a) There is a new flag, -fexpose-all-unfoldings, in GHC HEAD. This does what you want - compile vector-space with this flag on and unfoldings for everything will show up in the .hi file, with no INLINE annotations necessary. This was intended for supercompilers (such as the one I'm working on :-) but you can probably use for this as well. b) GHC already treats RULES differently for the purposes of inlining. It is very eager to inline into the arguments of a function you have RULES for, because doing so may let it spot extra chances for the rule to fire. Hope that helps, Max On 10 March 2010 16:23, Jake McArthur jake.mcart...@gmail.com wrote: Here's a transcript from a conversation I had with Conal on IRC. tl;dr: conal cross-module inlining is only possible because ghc stashes a definition in a .hi, iuuc. i'm suggesting that the stashed definition either (a) never include further inlinings, or (b) be augmented by such a definition. Full transcript: 11:23:10 conal jmcarthur: i'm wondering what to do about INLINE pragmas for vector-space and other libraries. i love optimizability and clean/elegant/terse code. and i don't know how to resolve that tension. 11:23:21 jmcarthur conal: yeah, me either. it's annoying 11:23:41 jmcarthur conal: a compiler feature to do it more succinctly would be nice, if we can come up with one 11:23:52 conal jmcarthur: i'm thinking exactly the same 11:24:04 conal jmcarthur: a ghc flag that does what you did manually 11:24:41 jmcarthur conal: yeah, but we still need to do better than inlining *all* functions. we need to be able to tell it we want it to inline all functions satisfying some predicate or something 11:25:07 jmcarthur like, there's no point in forcing to inline functions having absolutely nothing to do with vector, for example 11:25:18 conal jmcarthur: i wonder. ghc already has some heuristics. do we really want anything different/unusual? 11:25:26 jmcarthur then again, combinators that don't inline and get used in a vector function later might still be annoying 11:26:08 conal jmcarthur: maybe some kind of demand-driven mechanism 11:26:21 jmcarthur conal: that's what i was thinking would be best 11:26:28 conal jmcarthur: ie pull inlining rather than push them. or some combo. 11:27:21 conal jmcarthur: i don't think this issue is specific to either vector fusion or to the vector-space package. 11:27:28 jmcarthur conal: actually, this is about rewrite rules more than inlining 11:27:40 jmcarthur conal: maybe if we focus on the rewrite rules we can think of something nicer 11:27:46 conal jmcarthur: ah, yeah. 11:28:32 conal jmcarthur: have you talked with they ghc guys about this issue? i wonder what practice they'd advise for use with the current ghc 11:28:54 jmcarthur i have not 11:29:47 conal jmcarthur: how did the inlining/rewriting concern arise for vector fusion and the vector-space package? 11:30:16 jmcarthur conal: i assume you read the email i linked to? 11:30:27 jmcarthur this one: http://www.haskell.org/pipermail/haskell-cafe/2010-March/074153.html 11:30:34 conal jmcarthur: yes. i'l reread now. 11:31:03 jmcarthur conal: in general, you have to add INLINE pragmas in such cases if you want to be sure your code fuses. A general-purpose mechanism for handling situations like this automatically would be great but we haven't found a good one so far. 11:31:14 jmcarthur i think the most relevant line 11:31:49 conal jmcarthur: thx. and the difficulty (with current ghc) is specifically cross-module, right? 11:32:00
Re: [Haskell-cafe] vector stream fusion, inlining and compilation time
I think Jake is referring to my vector-space package. He did the work of writing 171 INLINE pragmas, covering lots of methods and standalone function defs. I'm simultaneously grateful for the effort and repelled by the added syntactic noise. Also concerned about the impact of all these directives on other uses of vector-space. If all this inlining is a uniform win, I'd rather ghc did it for me. If the ghc implementers have reasons not to do so in general, then I'd expect that some of those reasons apply to vector-space (and many other libraries) as well. It's not like I'm applying some kind of domain-specific understanding that ghc doesn't have access to. I'm raising my concerns here in the hopes of stimulating some creative thinking and suggestions about addressing this sort of situation more generally. - Conal On Sun, Mar 7, 2010 at 9:23 PM, Don Stewart d...@galois.com wrote: jake.mcarthur: I've run into an issue with inlining that I'm not sure how to work around. I am instantiating some pre-existing type classes with Vector-based types. There already exist generic functions in modules I do not control that use this type class, and they are not tagged with the INLINE pragma. I am doubtful, but I figure it is worth at least asking: is there some practical workaround for this kind of situation that anybody knows about? I don't know of a way, other than patching the library code. If it makes a difference to you, it probably makes a difference to lots of people. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: A few ideas about FRP and arbitrary access in time
Even if the implementation is discrete (as all digital hardware), it may be more natural to treat things such as a temperature sensor, mouse position, and perhaps even video as functions of continuous time, values that vary continuously. So behaviors are not a workaround at all, in this sense. Just as we program with infinite lists etc even though the implementation is finite. In this way, implementations serve abstractions/semantics/specifications, rather than vice versa. See also http://conal.net/blog/posts/why-program-with-continuous-time/ . - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Linguistic hair-splitting
I call it an m or (more specifically) an Int m or a list of Int. For instance, a list or an Int list or a list of Int. - Conal On Wed, Jan 27, 2010 at 12:14 PM, Luke Palmer lrpal...@gmail.com wrote: On Wed, Jan 27, 2010 at 11:39 AM, Jochem Berndsen joc...@functor.nl wrote: Now, here's the question: Is is correct to say that [3, 5, 8] is a monad? In what sense would this be a monad? I don't quite get your question. I think the question is this: if m is a monad, then what do you call a thing of type m Int, or m Whatever. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Linguistic hair-splitting
I don't like this bias toward singling out Monad among all of the type classes, thereby perpetuating the misleading mystique surrounding Monad. If you're going to call [3,5,8] a monadic value, then please give equal time to other type classes by also calling [3,5,8] a functorial value (functorific?), an applicative value, a monoidal value, a foldable value (foldalicious?), a traversable value, a numeric value (see the applicative-numbers package), etc. Similarly when referring to values of other types that happen to be monads as well as other type classes. - Conal On Wed, Jan 27, 2010 at 12:17 PM, Jochem Berndsen joc...@functor.nl wrote: Luke Palmer wrote: On Wed, Jan 27, 2010 at 11:39 AM, Jochem Berndsen joc...@functor.nl wrote: Now, here's the question: Is is correct to say that [3, 5, 8] is a monad? In what sense would this be a monad? I don't quite get your question. I think the question is this: if m is a monad, then what do you call a thing of type m Int, or m Whatever. Ah yes, I see. It's probably the most common to call this a monadic value or monadic action. As Daniel pointed out, the type constructor itself is called a monad (e.g., Maybe). Jochem -- Jochem Berndsen | joc...@functor.nl ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: where is the eros distribution
Odd. Looks like most of the packages on d.h.o evaporated. I'll push the repo to a new location. - Conal On Sat, Jan 23, 2010 at 10:38 AM, Thomas Hartman tphya...@gmail.com wrote: I was inspired by the google tech talk and would like to install and play with eros, but the http://darcs.haskell.org/packages/Eros/dist/ address pointed to at http://www.haskell.org/haskellwiki/Eros appears to be obsolete. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] inotify-alike for mac os x?
Thanks, Matt. I see libev is available via macports. - Conal On Fri, Dec 4, 2009 at 3:03 PM, Matt Morrow moonpa...@gmail.com wrote: Conal, If I were looking to do this, I'd read the relevant parts of the libev code. Matt On 12/3/09, Conal Elliott co...@conal.net wrote: I'd like to make some FRPish toys that keep files updated to have functional relationships with other files. hinotify looks like just the sort of underlying magic I could use for efficient implementation on linux. Is there any support for mac os x? Could support be either added to hinotify or maybe inotify and a mac-friendly library be abstracted into a common Haskell interface? I'm fine with an imperative interface, since I can abstract into a functional library, which I guess would be a sort of persistent simplified FRP. - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] inotify-alike for mac os x?
Oh -- also libevent, described at http://www.monkey.org/~provos/libevent/ : Currently, *libevent* supports */dev/pollhttp://access1.sun.com/techarticles/devpoll.html *, *kqueue(2)http://www.freebsd.org/cgi/man.cgi?query=kqueueapropos=0sektion=0format=html *, *event portshttp://developers.sun.com/solaris/articles/event_completion.html *, *select(2)*, *poll(2)* and *epoll(4)http://www.xmailserver.org/linux-patches/epoll.txt *. The internal event mechanism is completely independent of the exposed event API, and a simple update of libevent can provide new functionality without having to redesign the applications. As a result, *Libevent*allows for portable application development and provides the most scalable event notification mechanism available on an operating system. Libevent can also be used for multi-threaded applications; see Steven Grimm's explanationhttp://monkeymail.org/archives/libevent-users/2007-January/000450.html. *Libevent* should compile on Linux, *BSD, Mac OS X, Solaris and Windows. On Fri, Dec 4, 2009 at 10:52 PM, Conal Elliott co...@conal.net wrote: Thanks, Matt. I see libev is available via macports. - Conal On Fri, Dec 4, 2009 at 3:03 PM, Matt Morrow moonpa...@gmail.com wrote: Conal, If I were looking to do this, I'd read the relevant parts of the libev code. Matt On 12/3/09, Conal Elliott co...@conal.net wrote: I'd like to make some FRPish toys that keep files updated to have functional relationships with other files. hinotify looks like just the sort of underlying magic I could use for efficient implementation on linux. Is there any support for mac os x? Could support be either added to hinotify or maybe inotify and a mac-friendly library be abstracted into a common Haskell interface? I'm fine with an imperative interface, since I can abstract into a functional library, which I guess would be a sort of persistent simplified FRP. - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] inotify-alike for mac os x?
I'd like to make some FRPish toys that keep files updated to have functional relationships with other files. hinotify looks like just the sort of underlying magic I could use for efficient implementation on linux. Is there any support for mac os x? Could support be either added to hinotify or maybe inotify and a mac-friendly library be abstracted into a common Haskell interface? I'm fine with an imperative interface, since I can abstract into a functional library, which I guess would be a sort of persistent simplified FRP. - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
