[Haskell] Haskell in Leipzig 2017: 2nd call for participation
Event:Haskell in Leipzig 2017 Time: October 26–28, 2017 Place:HTWK Leipzig, Germany Homepage: https://hal2017.softbase.org/ About = Haskell is a modern functional programming language that allows rapid development of robust and correct software. It is renowned for its expressive type system, its unique approaches to concurrency and parallelism, and its excellent refactoring capabilities. Haskell is both the playing field of cutting-edge programming language research and a reliable base for commercial software development. The workshop series Haskell in Leipzig (HaL), now in its 12th year, brings together Haskell developers, Haskell researchers, Haskell enthusiasts, and Haskell beginners to listen to talks, take part in tutorials, join in interesting conversations, and hack together. To support the latter, HaL will include a one-day hackathon this year. The workshop will have a focus on functional reactive programming (FRP) this time, while continuing to be open to all aspects of Haskell. As in the previous year, the workshop will be in English. Invited Speaker === * Ivan Perez, University of Nottingham, UK Invited Performer = * Lennart Melzer, Robert-Schumann-Hochschule Düsseldorf, Germany Registration Registration information is available on the web page of the local organizers at http://nfa.imn.htwk-leipzig.de/HAL2017/. Program Committee = * Edward Amsden, Plow Technologies, USA * Heinrich Apfelmus, Germany * Jurriaan Hage, Utrecht University, The Netherlands * Petra Hofstedt, BTU Cottbus-Senftenberg, Germany * Wolfgang Jeltsch, Tallinn University of Technology, Estonia (chair) * Andres Löh, Well-Typed LLP, Germany * Keiko Nakata, SAP SE, Germany * Henrik Nilsson, University of Nottingham, UK * Ertuğrul Söylemez, Intelego GmbH, Germany * Henning Thielemann, Germany * Niki Vazou, University of Maryland, USA * Johannes Waldmann, HTWK Leipzig, Germany Questions = If you have any questions, please do not hesitate to contact Wolfgang Jeltsch at wolfgang...@jeltsch.info. ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
Re: [Haskell] Haskell in Leipzig 2017: 1st call for participation
Hi! Thank you for the suggestion. I will see what we can do. All the best, Wolfgang Am Mittwoch, den 20.09.2017, 13:38 +0700 schrieb Kim-Ee Yeoh: > Hi Wolfgang, > > May I respectfully suggest that the talks be video recorded and made > viewable on the internet? > > The benefits are too many to name; not least is the fact that they > will popularize your conference and increase the turnout for the next > HaL. > > Best, > Kim Ee > > > On Tuesday, September 19, 2017, Wolfgang Jeltsch > info> wrote: > > Event:Haskell in Leipzig 2017 > > Time: October 26–28, 2017 > > Place:HTWK Leipzig, Germany > > Homepage: https://hal2017.softbase.org/ > > > > > > About > > = > > > > Haskell is a modern functional programming language that allows > > rapid > > development of robust and correct software. It is renowned for its > > expressive type system, its unique approaches to concurrency and > > parallelism, and its excellent refactoring capabilities. Haskell is > > both > > the playing field of cutting-edge programming language research and > > a > > reliable base for commercial software development. > > > > The workshop series Haskell in Leipzig (HaL), now in its 12th year, > > brings together Haskell developers, Haskell researchers, Haskell > > enthusiasts, and Haskell beginners to listen to talks, take part in > > tutorials, join in interesting conversations, and hack together. To > > support the latter, HaL will include a one-day hackathon this year. > > The > > workshop will have a focus on functional reactive programming (FRP) > > this > > time, while continuing to be open to all aspects of Haskell. As in > > the > > previous year, the workshop will be in English. > > > > > > Invited Speaker > > === > > > > * Ivan Perez, University of Nottingham, UK > > > > > > Invited Performer > > = > > > > * Lennart Melzer, Robert-Schumann-Hochschule Düsseldorf, Germany > > > > > > Registration > > > > > > Registration information is available on the web page of the local > > organizers at http://nfa.imn.htwk-leipzig.de/HAL2017/. > > > > > > Program Committee > > = > > > > * Edward Amsden, Plow Technologies, USA > > * Heinrich Apfelmus, Germany > > * Jurriaan Hage, Utrecht University, The Netherlands > > * Petra Hofstedt, BTU Cottbus-Senftenberg, Germany > > * Wolfgang Jeltsch, Tallinn University of Technology, Estonia > > (chair) > > * Andres Löh, Well-Typed LLP, Germany > > * Keiko Nakata, SAP SE, Germany > > * Henrik Nilsson, University of Nottingham, UK > > * Ertuğrul Söylemez, Intelego GmbH, Germany > > * Henning Thielemann, Germany > > * Niki Vazou, University of Maryland, USA > > * Johannes Waldmann, HTWK Leipzig, Germany > > > > > > Questions > > = > > > > If you have any questions, please do not hesitate to contact > > Wolfgang > > Jeltsch at wolfgang...@jeltsch.info. > > ___ > > Haskell mailing list > > Haskell@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell > > > > -- > -- Kim-Ee___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] Haskell in Leipzig 2017: 1st call for participation
Event:Haskell in Leipzig 2017 Time: October 26–28, 2017 Place:HTWK Leipzig, Germany Homepage: https://hal2017.softbase.org/ About = Haskell is a modern functional programming language that allows rapid development of robust and correct software. It is renowned for its expressive type system, its unique approaches to concurrency and parallelism, and its excellent refactoring capabilities. Haskell is both the playing field of cutting-edge programming language research and a reliable base for commercial software development. The workshop series Haskell in Leipzig (HaL), now in its 12th year, brings together Haskell developers, Haskell researchers, Haskell enthusiasts, and Haskell beginners to listen to talks, take part in tutorials, join in interesting conversations, and hack together. To support the latter, HaL will include a one-day hackathon this year. The workshop will have a focus on functional reactive programming (FRP) this time, while continuing to be open to all aspects of Haskell. As in the previous year, the workshop will be in English. Invited Speaker === * Ivan Perez, University of Nottingham, UK Invited Performer = * Lennart Melzer, Robert-Schumann-Hochschule Düsseldorf, Germany Registration Registration information is available on the web page of the local organizers at http://nfa.imn.htwk-leipzig.de/HAL2017/. Program Committee = * Edward Amsden, Plow Technologies, USA * Heinrich Apfelmus, Germany * Jurriaan Hage, Utrecht University, The Netherlands * Petra Hofstedt, BTU Cottbus-Senftenberg, Germany * Wolfgang Jeltsch, Tallinn University of Technology, Estonia (chair) * Andres Löh, Well-Typed LLP, Germany * Keiko Nakata, SAP SE, Germany * Henrik Nilsson, University of Nottingham, UK * Ertuğrul Söylemez, Intelego GmbH, Germany * Henning Thielemann, Germany * Niki Vazou, University of Maryland, USA * Johannes Waldmann, HTWK Leipzig, Germany Questions = If you have any questions, please do not hesitate to contact Wolfgang Jeltsch at wolfgang...@jeltsch.info. ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] Haskell in Leipzig 2017: last call for papers
Hi! I want to kindly remind you that the submission deadline of Haskell in Leipzig 2017 is on Friday this week. Looking forward to your contributions. ☺ Event:Haskell in Leipzig 2017 Time: October 26–28, 2017 Place:HTWK Leipzig, Germany Homepage: https://hal2017.softbase.org/ About = Haskell is a modern functional programming language that allows rapid development of robust and correct software. It is renowned for its expressive type system, its unique approaches to concurrency and parallelism, and its excellent refactoring capabilities. Haskell is both the playing field of cutting-edge programming language research and a reliable base for commercial software development. The workshop series Haskell in Leipzig (HaL), now in its 12th year, brings together Haskell developers, Haskell researchers, Haskell enthusiasts, and Haskell beginners to listen to talks, take part in tutorials, join in interesting conversations, and hack together. To support the latter, HaL will include a one-day hackathon this year. The workshop will have a focus on functional reactive programming (FRP) this time, while continuing to be open to all aspects of Haskell. As in the previous year, the workshop will be in English. Contributions = Everything related to Haskell is on topic, whether it is about current research, practical applications, interesting ideas off the beaten track, education, or art, and topics may extend to functional programming in general and its connections to other programming paradigms. Contributions can take the form of * talks (about 30 minutes), * tutorials (about 90 minutes), * demonstrations, artistic performances, or other extraordinary things. Please submit an abstract that describes the content and form of your presentation, the intended audience, and required previous knowledge. We recommend a length of 2 pages, so that the program committee and the audience get a good idea of your contribution, but this is not a hard requirement. Please submit your abstract as a PDF document at https://easychair.org/conferences/?conf=hal2017 until Friday, August 18, 2017. You will be notified by Friday, September 8, 2017. Hacking Projects Projects for the hackathon can be presented during the workshop. A prior submission is not needed for this. Invited Speaker === * Ivan Perez, University of Nottingham, UK Invited Performer = * Lennart Melzer, Robert-Schumann-Hochschule Düsseldorf, Germany Program Committee = * Edward Amsden, Plow Technologies, USA * Heinrich Apfelmus, Germany * Jurriaan Hage, Utrecht University, The Netherlands * Petra Hofstedt, BTU Cottbus-Senftenberg, Germany * Wolfgang Jeltsch, Tallinn University of Technology, Estonia (chair) * Andres Löh, Well-Typed LLP, Germany * Keiko Nakata, SAP SE, Germany * Henrik Nilsson, University of Nottingham, UK * Ertuğrul Söylemez, Intelego GmbH, Germany * Henning Thielemann, Germany * Niki Vazou, University of Maryland, USA * Johannes Waldmann, HTWK Leipzig, Germany Questions = If you have any questions, please do not hesitate to contact Wolfgang Jeltsch at wolfgang...@jeltsch.info. ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] Haskell in Leipzig 2017: submission deadline shifted by two weeks
Hi! We have shifted the submission deadline for Haskell in Leipzig 2017 by two weeks. The new deadline is at 18 August 2017. Looking forward to your contribution. Event:Haskell in Leipzig 2017 Time: October 26–28, 2017 Place:HTWK Leipzig, Germany Homepage: https://hal2017.softbase.org/ About = Haskell is a modern functional programming language that allows rapid development of robust and correct software. It is renowned for its expressive type system, its unique approaches to concurrency and parallelism, and its excellent refactoring capabilities. Haskell is both the playing field of cutting-edge programming language research and a reliable base for commercial software development. The workshop series Haskell in Leipzig (HaL), now in its 12th year, brings together Haskell developers, Haskell researchers, Haskell enthusiasts, and Haskell beginners to listen to talks, take part in tutorials, join in interesting conversations, and hack together. To support the latter, HaL will include a one-day hackathon this year. The workshop will have a focus on functional reactive programming (FRP) this time, while continuing to be open to all aspects of Haskell. As in the previous year, the workshop will be in English. Contributions = Everything related to Haskell is on topic, whether it is about current research, practical applications, interesting ideas off the beaten track, education, or art, and topics may extend to functional programming in general and its connections to other programming paradigms. Contributions can take the form of * talks (about 30 minutes), * tutorials (about 90 minutes), * demonstrations, artistic performances, or other extraordinary things. Please submit an abstract that describes the content and form of your presentation, the intended audience, and required previous knowledge. We recommend a length of 2 pages, so that the program committee and the audience get a good idea of your contribution, but this is not a hard requirement. Please submit your abstract as a PDF document at https://easychair.org/conferences/?conf=hal2017 until Friday, August 18, 2017. You will be notified by Friday, September 8, 2017. Hacking Projects Projects for the hackathon can be presented during the workshop. A prior submission is not needed for this. Invited Speaker === * Ivan Perez, University of Nottingham, UK Invited Performer = * Lennart Melzer, Robert-Schumann-Hochschule Düsseldorf, Germany Program Committee = * Edward Amsden, Plow Technologies, USA * Heinrich Apfelmus, Germany * Jurriaan Hage, Utrecht University, The Netherlands * Petra Hofstedt, BTU Cottbus-Senftenberg, Germany * Wolfgang Jeltsch, Tallinn University of Technology, Estonia (chair) * Andres Löh, Well-Typed LLP, Germany * Keiko Nakata, SAP SE, Germany * Henrik Nilsson, University of Nottingham, UK * Ertuğrul Söylemez, Intelego GmbH, Germany * Henning Thielemann, Germany * Niki Vazou, University of Maryland, USA * Johannes Waldmann, HTWK Leipzig, Germany Questions = If you have any questions, please do not hesitate to contact Wolfgang Jeltsch at wolfgang...@jeltsch.info. ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
Re: [ANNOUNCE] GHC 8.2.1 available
Hi! I ran into the same problem. Apparently, we need cabal-install 2.0, which has not been released yet. A preliminary solution is to use the development version from the 2.0 branch. Binary packages can be found at http://ppa.launchpad.net/hvr/ghc/ubuntu/pool/main/c/cabal-install-2.0/ , for example. It is possible to extract the cabal-install executable from these packages, so that it can be installed without using some Linux distribution package manager. All the best, Wolfgang Am Mittwoch, den 26.07.2017, 18:45 -0700 schrieb Evan Laforge: > This seems like a silly question, but how can we install cabal-install > now? The latest hackage version 1.24.0.2 has Cabal (>=1.24.2 && > <1.25), but it looks like ghc Cabal is now at 2.*. > > I ran into this because if I get: > > % cabal install --only-dependencies > Resolving dependencies... > cabal: internal error when reading package index: failed to parse > .cabal > fileThe package index or index cache is probably corrupt. Running > cabal update > might fix it. > > It seems to be triggered by having 'ekg' in the deps list, since if I > take it out then I get some other errors about packages not liking the > new base, which is true. 'ekg' also doesn't like the new base, but > "internal error" is not the clearest way to express that :) > > It's frustrating that cabal-install still doesn't report the parse > error, even though the parse function returns one. It just ignores > the ParseFailed case. I was going to try fixing it and send a pull > request when I ran into the Cabal 2.* problem. > > On Wed, Jul 26, 2017 at 7:15 AM, Ben Gamari <b...@smart-cactus.org> > wrote: > > > > Wolfgang Jeltsch <wolfgang...@jeltsch.info> writes: > > > > > > > > Am Samstag, den 22.07.2017, 23:03 -0400 schrieb Ben Gamari: > > > > > > > > In addition, there are a number of new features, > > > > > > > > * A new, more type-safe type reflection mechanism > > > > > > > > * The long-awaited Backpack module system > > > > > > > > * Deriving strategies to disambiguate between GHC's various > > > > instance > > > > deriving mechanisms > > > > > > > > * Unboxed sum types, for efficient unpacked representation of > > > > sum > > > > data types > > > > > > > > * Compact regions, allowing better control over garbage > > > > collection > > > > in the presence of large heaps containing many long-lived > > > > objects. > > > > > > > > * Colorful messages and caret diagnostics for more legible > > > > errors > > > > > > > > A more thorough list of the changes in this release can be found > > > > in > > > > the release notes, > > > > > > > > https://haskell.org/ghc/docs/8.2.1/docs/html/users_guide/8.2.1 > > > > -notes.html > > > It seems that the release notes mention the new type reflection > > > mechanism und colorful messages only in the “Highlights” section, > > > not in > > > the “Full details” section, and that they do not mention the > > > Backpack > > > module system and unboxed sums at all. > > > > > Yes, indeed these were oversights. They are fixed in the ghc-8.2 > > branch > > and I will try to push newly generated documentation shortly. > > > > Cheers, > > > > - Ben > > > > ___ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-use > > rs > > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: [ANNOUNCE] GHC 8.2.1 available
Am Samstag, den 22.07.2017, 23:03 -0400 schrieb Ben Gamari: > In addition, there are a number of new features, > > * A new, more type-safe type reflection mechanism > > * The long-awaited Backpack module system > > * Deriving strategies to disambiguate between GHC's various instance > deriving mechanisms > > * Unboxed sum types, for efficient unpacked representation of sum > data types > > * Compact regions, allowing better control over garbage collection > in the presence of large heaps containing many long-lived objects. > > * Colorful messages and caret diagnostics for more legible errors > > A more thorough list of the changes in this release can be found in > the release notes, > > https://haskell.org/ghc/docs/8.2.1/docs/html/users_guide/8.2.1-notes.html It seems that the release notes mention the new type reflection mechanism und colorful messages only in the “Highlights” section, not in the “Full details” section, and that they do not mention the Backpack module system and unboxed sums at all. All the best, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
[Haskell] Haskell in Leipzig 2017: 2nd call for papers
Event:Haskell in Leipzig 2017 Time: October 26–28, 2017 Place:HTWK Leipzig, Germany Homepage: https://hal2017.softbase.org/ About = Haskell is a modern functional programming language that allows rapid development of robust and correct software. It is renowned for its expressive type system, its unique approaches to concurrency and parallelism, and its excellent refactoring capabilities. Haskell is both the playing field of cutting-edge programming language research and a reliable base for commercial software development. The workshop series Haskell in Leipzig (HaL), now in its 12th year, brings together Haskell developers, Haskell researchers, Haskell enthusiasts, and Haskell beginners to listen to talks, take part in tutorials, join in interesting conversations, and hack together. To support the latter, HaL will include a one-day hackathon this year. The workshop will have a focus on functional reactive programming (FRP) this time, while continuing to be open to all aspects of Haskell. As in the previous year, the workshop will be in English. Contributions = Everything related to Haskell is on topic, whether it is about current research, practical applications, interesting ideas off the beaten track, education, or art, and topics may extend to functional programming in general and its connections to other programming paradigms. Contributions can take the form of * talks (about 30 minutes), * tutorials (about 90 minutes), * demonstrations, artistic performances, or other extraordinary things. Please submit an abstract that describes the content and form of your presentation, the intended audience, and required previous knowledge. We recommend a length of 2 pages, so that the program committee and the audience get a good idea of your contribution, but this is not a hard requirement. Please submit your abstract as a PDF document at https://easychair.org/conferences/?conf=hal2017 until Friday, August 4, 2017. You will be notified by Friday, August 25, 2017. Hacking Projects Projects for the hackathon can be presented during the workshop. A prior submission is not needed for this. Invited Speaker === * Ivan Perez, University of Nottingham, UK Program Committee = * Edward Amsden, Plow Technologies, USA * Heinrich Apfelmus, Germany * Jurriaan Hage, Utrecht University, The Netherlands * Petra Hofstedt, BTU Cottbus-Senftenberg, Germany * Wolfgang Jeltsch, Tallinn University of Technology, Estonia (chair) * Andres Löh, Well-Typed LLP, Germany * Keiko Nakata, SAP SE, Germany * Henrik Nilsson, University of Nottingham, UK * Ertuğrul Söylemez, Intelego GmbH, Germany * Henning Thielemann, Germany * Niki Vazou, University of Maryland, USA * Johannes Waldmann, HTWK Leipzig, Germany Questions = If you have any questions, please do not hesitate to contact Wolfgang Jeltsch at wolfgang...@jeltsch.info. ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
Heterogeneous equality
Hi!
The base package contains the module Data.Type.Equality, which contains
the type (:~:) for homogeneous equality. I was a bit surprised that
there is no type for heterogeneous equality there. Is there such a type
somewhere else in the standard library?
I tried to define a type for heterogeneous equality myself as follows:
> {-# LANGUAGE GADTs, PolyKinds, TypeOperators #-}
>
> data a :~~: b where
>
> HRefl :: a :~~: a
To my surprise, the kind of (:~~:) defined this way is k -> k -> *, not
k -> l -> *. Why is this? Apparently, the latter, more general, kind is
possible, since we can define (:~~:) :: k -> l -> * as follows:
> {-# LANGUAGE GADTs, PolyKinds, TypeOperators #-}
>
> data (a :: k) :~~: (b :: l) where
>
> HRefl :: a :~~: a
All the best,
Wolfgang
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Trouble with injective type families
Dear Simon,
thank you very much for this elaborate explanation.
I stumbled on this issue when using functional dependencies years ago.
The solution at that time was to use type families.
I did not know that injectivity is handled analogously to functional
dependencies. Given that it is, the syntax for injectivity makes a lot
more sense.
All the best,
Wolfgang
Am Mittwoch, den 05.07.2017, 06:45 + schrieb Simon Peyton Jones:
> Functional dependencies and type-family dependencies only induce extra
> "improvement" constraints, not evidence. For example
>
> class C a b | a -> b where foo :: a -> b
> instance C Bool Int where ...
>
> f :: C Bool b => b -> Int
> f x = x -- Rejected
>
> Does the fundep on 'b' allow us to deduce (b ~ Int), GADT-like, in the
> body of 'f', and hence accept the definition. No, it does not. Think
> of the translation into System F. We get
>
> f = /\b \(d :: C Bool b). \(x::b). x |> ???
>
> What evidence can I used to cast 'x' by to get it from type 'b' to
> Int?
>
> Rather, fundeps resolve ambiguity. Consider
>
> g x = foo True + x
>
> The call to 'foo True' gives rise to a "wanted" constraint (C Bool
> beta), where beta is a fresh unification variable. Then by the fundep
> we get an "improvement" constraint (also "wanted") (beta ~ Int). So we
> can infer g :: Int -> Int.
>
>
> In your example we have
>
> x :: forall a b. (T Int ~ b) => a
> x = False
>
> Think of the System F translation:
>
> x = /\a b. \(d :: T Int ~ b). False |> ??
>
> Again, what evidence can we use to cast False to 'a'.
>
>
> In short, fundeps and type family dependencies only add extra
> unification constraints, which may help to resolve ambiguous
> types. They don’t provide evidence. That's not to say that they
> couldn't. But you'd need to extend System FC, GHC's core language, to
> do so.
>
> Simon
>
>
> >
> > -Original Message-
> > From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
> > boun...@haskell.org] On Behalf Of Wolfgang Jeltsch
> > Sent: 05 July 2017 01:21
> > To: glasgow-haskell-users@haskell.org
> > Subject: Trouble with injective type families
> >
> > Hi!
> >
> > Injective type families as supported by GHC 8.0.1 do not behave like
> > I
> > would expect them to behave from my intuitive understanding.
> >
> > Let us consider the following example:
> >
> > >
> > > {-# LANGUAGE RankNTypes, TypeFamilyDependencies #-}
> > >
> > > class C a where
> > >
> > > type T a = b | b -> a
> > >
> > > instance C Bool where
> > >
> > > type T Bool = Int
> > >
> > > type X b = forall a . T a ~ b => a
> > >
> > > x :: X Int
> > > x = False
> > I would expect this code to be accepted. However, I get the
> > following
> > error message:
> >
> > >
> > > A.hs:14:5: error:
> > > • Could not deduce: a ~ Bool
> > > from the context: T a ~ Int
> > > bound by the type signature for:
> > > x :: T a ~ Int => a
> > > at A.hs:13:1-10
> > > ‘a’ is a rigid type variable bound by
> > > the type signature for:
> > > x :: forall a. T a ~ Int => a
> > > at A.hs:11:19
> > > • In the expression: False
> > > In an equation for ‘x’: x = False
> > > • Relevant bindings include x :: a (bound at A.hs:14:1)
> > This is strange, since injectivity should exactly make it possible
> > to
> > deduce a ~ Bool from T a ~ Int.
> >
> > Another example is this:
> >
> > >
> > > {-# LANGUAGE GADTs, TypeFamilyDependencies #-}
> > >
> > > class C a where
> > >
> > > type T a = b | b -> a
> > >
> > > instance C Bool where
> > >
> > > type T Bool = Int
> > >
> > > data G b where
> > >
> > > G :: Eq a => a -> G (T a)
> > >
> > > instance Eq (G b) where
> > >
> > > G a1 == G a2 = a1 == a2a
> > I would also expect this code to be accepted. However, I get the
> > following error message:
> >
> > >
> > > B.hs:17:26: error:
> > > • Could not deduce: a1 ~ a
> > > from the context: (b ~ T a, Eq a)
> > > bound by a pattern with constructor:
>
Trouble with injective type families
Hi!
Injective type families as supported by GHC 8.0.1 do not behave like I
would expect them to behave from my intuitive understanding.
Let us consider the following example:
> {-# LANGUAGE RankNTypes, TypeFamilyDependencies #-}
>
> class C a where
>
> type T a = b | b -> a
>
> instance C Bool where
>
> type T Bool = Int
>
> type X b = forall a . T a ~ b => a
>
> x :: X Int
> x = False
I would expect this code to be accepted. However, I get the following
error message:
> A.hs:14:5: error:
> • Could not deduce: a ~ Bool
> from the context: T a ~ Int
> bound by the type signature for:
> x :: T a ~ Int => a
> at A.hs:13:1-10
> ‘a’ is a rigid type variable bound by
> the type signature for:
> x :: forall a. T a ~ Int => a
> at A.hs:11:19
> • In the expression: False
> In an equation for ‘x’: x = False
> • Relevant bindings include x :: a (bound at A.hs:14:1)
This is strange, since injectivity should exactly make it possible to
deduce a ~ Bool from T a ~ Int.
Another example is this:
> {-# LANGUAGE GADTs, TypeFamilyDependencies #-}
>
> class C a where
>
> type T a = b | b -> a
>
> instance C Bool where
>
> type T Bool = Int
>
> data G b where
>
> G :: Eq a => a -> G (T a)
>
> instance Eq (G b) where
>
> G a1 == G a2 = a1 == a2a
I would also expect this code to be accepted. However, I get the
following error message:
> B.hs:17:26: error:
> • Could not deduce: a1 ~ a
> from the context: (b ~ T a, Eq a)
> bound by a pattern with constructor:
> G :: forall a. Eq a => a -> G (T a),
> in an equation for ‘==’
> at B.hs:17:5-8
> or from: (b ~ T a1, Eq a1)
> bound by a pattern with constructor:
> G :: forall a. Eq a => a -> G (T a),
> in an equation for ‘==’
> at B.hs:17:13-16
> ‘a1’ is a rigid type variable bound by
> a pattern with constructor: G :: forall a. Eq a => a -> G (T a),
> in an equation for ‘==’
> at B.hs:17:13
> ‘a’ is a rigid type variable bound by
> a pattern with constructor: G :: forall a. Eq a => a -> G (T a),
> in an equation for ‘==’
> at B.hs:17:5
> • In the second argument of ‘(==)’, namely ‘a2’
> In the expression: a1 == a2
> In an equation for ‘==’: (G a1) == (G a2) = a1 == a2
> • Relevant bindings include
> a2 :: a1 (bound at B.hs:17:15)
> a1 :: a (bound at B.hs:17:7)
If b ~ T a and b ~ T a1, then T a ~ T a1 and subsequently a ~ a1,
because of injectivity. Unfortunately, GHC does not join the two
contexts (b ~ T a, Eq a) and (b ~ T a1, Eq a1).
Are these behaviors really intended, or are these bugs showing up?
All the best,
Wolfgang
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Untouchable type variables
Am Sonntag, den 18.06.2017, 12:02 -0700 schrieb wren romano:
> > > {-# LANGUAGE Rank2Types, TypeFamilies #-}
> > >
> > > import GHC.Exts (Constraint)
> > >
> > > type family F a b :: Constraint
> > >
> > > data T b c = T
> > >
> > > f :: (forall b . F a b => T b c) -> a
> > > f _ = undefined
>
> FWIW, the error comes specifically from the fact that @F@ is a family.
> If you use a plain old type class, or if you use a type alias (via
> -XConstraintKinds) then it typechecks just fine. So it's something
> about how the arguments to @F@ are indices rather than parameters.
>
> I have a few guesses about why the families don't work here, but I'm
> not finding any of them particularly convincing. Really, imo, @c@
> should be held abstract within the type of the argument, since it's
> universally quantified from outside. Whatever @F a b@ evaluates to
> can't possibly have an impact on @c@. I'd file a bug report. If
> it's just an implementation defect, then the GHC devs will want to
> know. And if there's actually a type theoretic reason I missed, it'd
> be good to have that documented somewhere.
I already filed a bug report:
https://ghc.haskell.org/trac/ghc/ticket/13655
In a comment, Simon says that this behavior is according to the rules. I
am just not sure whether the rules have to be as they are.
All the best,
Wolfgang
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
[Haskell] Haskell in Leipzig 2017: 1st call for papers
Event:Haskell in Leipzig 2017 Time: October 26–28, 2017 Place:HTWK Leipzig, Germany Homepage: https://hal2017.softbase.org/ About = Haskell is a modern functional programming language that allows rapid development of robust and correct software. It is renowned for its expressive type system, its unique approaches to concurrency and parallelism, and its excellent refactoring capabilities. Haskell is both the playing field of cutting-edge programming language research and a reliable base for commercial software development. The workshop series Haskell in Leipzig (HaL), now in its 12th year, brings together Haskell developers, Haskell researchers, Haskell enthusiasts, and Haskell beginners to listen to talks, take part in tutorials, join in interesting conversations, and hack together. To support the latter, HaL will include a one-day hackathon this year. The workshop will have a focus on functional reactive programming (FRP) this time, while continuing to be open to all aspects of Haskell. As in the previous year, the workshop will be in English. Contributions = Everything related to Haskell is on topic, whether it is about current research, practical applications, interesting ideas off the beaten track, education, or art, and topics may extend to functional programming in general and its connections to other programming paradigms. Contributions can take the form of * talks (about 30 minutes), * tutorials (about 90 minutes), * demonstrations, artistic performances, or other extraordinary things. Please submit an abstract that describes the content and form of your presentation, the intended audience, and required previous knowledge. We recommend a length of 2 pages, so that the program committee and the audience get a good idea of your contribution, but this is not a hard requirement. Please submit your abstract as a PDF document at https://easychair.org/conferences/?conf=hal2017 until Friday, August 4, 2017. You will be notified by Friday, August 25, 2017. Hacking Projects Projects for the hackathon can be presented during the workshop. A prior submission is not needed for this. Program Committee = * Edward Amsden, Plow Technologies, USA * Heinrich Apfelmus, Germany * Jurriaan Hage, Utrecht University, The Netherlands * Petra Hofstedt, BTU Cottbus-Senftenberg, Germany * Wolfgang Jeltsch, Tallinn University of Technology, Estonia (chair) * Andres Löh, Well-Typed LLP, Germany * Keiko Nakata, SAP SE, Germany * Henrik Nilsson, University of Nottingham, UK * Ertuğrul Söylemez, Intelego GmbH, Germany * Henning Thielemann, Germany * Niki Vazou, University of Maryland, USA * Johannes Waldmann, HTWK Leipzig, Germany Questions = If you have any questions, please do not hesitate to contact Wolfgang Jeltsch at wolfgang...@jeltsch.info. ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
ConstraintKinds seems to be automatically enabled
Hi! In my previous e-mail, I showed some code that uses the Constraint kind. I forgot to enable the ConstraintKinds extension though, but GHC 8.0.1 did not complain. Is this a bug? All the best, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Untouchable type variables
Hi!
Today I encountered for the first time the notion of an “untouchable”
type variable. I have no clue what this is supposed to mean. A minimal
example that exposes my problem is the following:
> {-# LANGUAGE Rank2Types, TypeFamilies #-}
>
> import GHC.Exts (Constraint)
>
> type family F a b :: Constraint
>
> data T b c = T
>
> f :: (forall b . F a b => T b c) -> a
> f _ = undefined
This results in the following error message from GHC 8.0.1:
> Untouchable.hs:9:6: error:
> • Couldn't match type ‘c0’ with ‘c’
> ‘c0’ is untouchable
> inside the constraints: F a b
> bound by the type signature for:
> f :: F a b => T b c0
> at Untouchable.hs:9:6-37
> ‘c’ is a rigid type variable bound by
> the type signature for:
> f :: forall a c. (forall b. F a b => T b c) -> a
> at Untouchable.hs:9:6
> Expected type: T b c0
> Actual type: T b c
> • In the ambiguity check for ‘f’
> To defer the ambiguity check to use sites, enable AllowAmbiguousTypes
> In the type signature:
> f :: (forall b. F a b => T b c) -> a
I have no idea what the problem is. The type of f looks fine to me. The
type variable c should be universally quantified at the outermost level.
Why does the type checker even introduce a type variable c0?
All the best,
Wolfgang
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Ambiguity check and type families
Hi Adam,
yes, this seems to be the same bug.
I just annotated ticket #10009. I hope the fix will make it into
GHC 7.10.2.
Can anyone say when GHC 7.10.2 will be released approximately?
All the best,
Wolfgang
Am Dienstag, den 02.06.2015, 13:00 -0400 schrieb adam vogt:
Hi Wolfgang,
https://ghc.haskell.org/trac/ghc/ticket/10009 might be the same
regression (fixed in HEAD)
Regards,
Adam
On Tue, Jun 2, 2015 at 12:28 PM, Wolfgang Jeltsch
g9ks1...@acme.softbase.org wrote:
Hi,
the following (contrived) code is accepted by GHC 7.8.3, but
not 7.10.1:
{-# LANGUAGE TypeFamilies #-}
type family F a :: *
type family G b :: *
x :: G (F a) ~ a = F a
x = undefined
GHC 7.10.1 reports:
Could not deduce (F a0 ~ F a)
from the context (G (F a) ~ a)
bound by the type signature for x :: (G (F a) ~ a) = F a
at Test.hs:7:6-23
NB: ‘F’ is a type function, and may not be injective
The type variable ‘a0’ is ambiguous
In the ambiguity check for the type signature for ‘x’:
x :: forall a. (G (F a) ~ a) = F a
To defer the ambiguity check to use sites, enable
AllowAmbiguousTypes
In the type signature for ‘x’: x :: G (F a) ~ a = F a
At a first look, this complaint seems reasonable, and I have
already
wondered why GHC 7.8.3 actually accepts the above code.
From an intuitive standpoint, however, the code seems actually
acceptable to me. While it is true that type families are
generally not
injective, it is possible to derive the type a from F a by
applying G.
It would great if this code would be accepted by GHC again and
if there
was a workaround to make it work with GHC 7.10.1. At the
moment, this
change in the type checker from 7.8.3 to 7.10.1 breaks the
incremental-computing package in a rather fundamental way.
All the best,
Wolfgang
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Ambiguity check and type families
Hi,
the following (contrived) code is accepted by GHC 7.8.3, but not 7.10.1:
{-# LANGUAGE TypeFamilies #-}
type family F a :: *
type family G b :: *
x :: G (F a) ~ a = F a
x = undefined
GHC 7.10.1 reports:
Could not deduce (F a0 ~ F a)
from the context (G (F a) ~ a)
bound by the type signature for x :: (G (F a) ~ a) = F a
at Test.hs:7:6-23
NB: ‘F’ is a type function, and may not be injective
The type variable ‘a0’ is ambiguous
In the ambiguity check for the type signature for ‘x’:
x :: forall a. (G (F a) ~ a) = F a
To defer the ambiguity check to use sites, enable AllowAmbiguousTypes
In the type signature for ‘x’: x :: G (F a) ~ a = F a
At a first look, this complaint seems reasonable, and I have already
wondered why GHC 7.8.3 actually accepts the above code.
From an intuitive standpoint, however, the code seems actually
acceptable to me. While it is true that type families are generally not
injective, it is possible to derive the type a from F a by applying G.
It would great if this code would be accepted by GHC again and if there
was a workaround to make it work with GHC 7.10.1. At the moment, this
change in the type checker from 7.8.3 to 7.10.1 breaks the
incremental-computing package in a rather fundamental way.
All the best,
Wolfgang
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Rules for class methods and Safe Haskell
Am Freitag, den 15.08.2014, 23:10 +0300 schrieb Wolfgang Jeltsch: Hi, the module Control.Arrow declares a set of rules for the Arrow class. It is marked “Trustworthy”, probably to allow these rules to actually fire. Now these rules are only correct for class instances that actually satisfy the arrow laws. If the author of another module defines an instance of Arrow that does not respect the laws, this other module could still be considered “Safe” by GHC, although the rules from Control.Arrow are bogus now. Is this considered a problem? All the best, Wolfgang Hi, could someone please answer this e-mail? This issue is important for me. All the best, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Under what conditions are finalizers not run?
Hi, the documentation of System.Mem.Weak under http://hackage.haskell.org/package/base-4.7.0.1/docs/System-Mem-Weak.html says the following: It is not guaranteed that a finalizer will eventually run, and no attempt is made to run outstanding finalizers when the program exits. In which situations are finalizers not run? I see that they might not be run when the program ends while the weak pointer is still alive, but are there also other situations? The above quote seems to say that even an implementation that ignores any finalizers would conform to the API specification. I think it is actually quite bad if you do not have any guarantees about when finalizers are run. In the memo table example, for instance, this would mean that the memo table could grow very large, which would not just result in bad space complexity, but also bad time complexity for lookups. I am actually particularly interested in adding finalizers to IORefs. Are there any stronger guarantees for finalizers attached to IORefs and MVars? All the best, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Are safe coercions safe in the sense of Safe Haskell?
Hi, the GHC 7.8.2 installation on my machine refuses to import GHC.Prim if Safe is enabled. The locally generated documentation still claims that GHC.Prim is Safe-Inferred, though. So this seems to be indeed a documentation bug. All the best, Wolfgang Am Sonntag, den 17.08.2014, 11:26 -0400 schrieb Richard Eisenberg: Have you tried doing this? If so, `coerce` is the least of our problems: `unsafeCoerce#` is much worse! When I just tried, GHC told me that I couldn't import GHC.Prim into a module with -XSafe enabled. So, this seems to be a documentation bug (the Haddock description of GHC.Prim indeed says Safe Inferred), but not a real bug. Let me know if you see otherwise! Thanks, Richard On Aug 16, 2014, at 6:06 PM, Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: Hi, thank you for these links. Still, it is interesting that also in GHC 7.8 you can have a coerce that is considered “Safe”, although the discussions on Trac concluded that this should not be the case. You can just import coerce via GHC.Prim, which is “Safe-Inferred”. All the best, Wolfgang Am Freitag, den 15.08.2014, 19:40 -0400 schrieb Richard Eisenberg: See https://ghc.haskell.org/trac/ghc/ticket/8745 and https://ghc.haskell.org/trac/ghc/ticket/8827 which discuss this problem at length. The short answer: It's conceivable that a role-unaware library author would have abstraction expectations that are defeated through the use of `coerce`. I would strongly welcome a proposal for how to make `coerce`, and hence GeneralizedNewtypeDeriving, to be considered Safe for 7.10. Richard On Aug 15, 2014, at 4:04 PM, Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: Hi, I would expect the function coerce :: Coercible a b = a - b to be safe in the sense of Safe Haskell. However, the Data.Coerce module is marked “Unsafe”. The coerce function is also available via GHC.Exts and GHC.Prim. The former module is marked “Unsafe”, but the latter is (surprisingly) marked “Safe-Inferred”. What are the reasons behind this? All the best, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Are safe coercions safe in the sense of Safe Haskell?
Hi, thank you for these links. Still, it is interesting that also in GHC 7.8 you can have a coerce that is considered “Safe”, although the discussions on Trac concluded that this should not be the case. You can just import coerce via GHC.Prim, which is “Safe-Inferred”. All the best, Wolfgang Am Freitag, den 15.08.2014, 19:40 -0400 schrieb Richard Eisenberg: See https://ghc.haskell.org/trac/ghc/ticket/8745 and https://ghc.haskell.org/trac/ghc/ticket/8827 which discuss this problem at length. The short answer: It's conceivable that a role-unaware library author would have abstraction expectations that are defeated through the use of `coerce`. I would strongly welcome a proposal for how to make `coerce`, and hence GeneralizedNewtypeDeriving, to be considered Safe for 7.10. Richard On Aug 15, 2014, at 4:04 PM, Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: Hi, I would expect the function coerce :: Coercible a b = a - b to be safe in the sense of Safe Haskell. However, the Data.Coerce module is marked “Unsafe”. The coerce function is also available via GHC.Exts and GHC.Prim. The former module is marked “Unsafe”, but the latter is (surprisingly) marked “Safe-Inferred”. What are the reasons behind this? All the best, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Are safe coercions safe in the sense of Safe Haskell?
Hi, I would expect the function coerce :: Coercible a b = a - b to be safe in the sense of Safe Haskell. However, the Data.Coerce module is marked “Unsafe”. The coerce function is also available via GHC.Exts and GHC.Prim. The former module is marked “Unsafe”, but the latter is (surprisingly) marked “Safe-Inferred”. What are the reasons behind this? All the best, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Rules for class methods and Safe Haskell
Hi, the module Control.Arrow declares a set of rules for the Arrow class. It is marked “Trustworthy”, probably to allow these rules to actually fire. Now these rules are only correct for class instances that actually satisfy the arrow laws. If the author of another module defines an instance of Arrow that does not respect the laws, this other module could still be considered “Safe” by GHC, although the rules from Control.Arrow are bogus now. Is this considered a problem? All the best, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Call to arms: lambda-case is stuck and needs your help
Am Freitag, den 13.07.2012, 13:40 +0100 schrieb Ross Paterson:
Remember that there is a \ in arrow notation in addition to proc.
So one might expect any abbreviation for \x - case x of {...}
to mean the same \ thing in arrow notation too.
I completely agree. I had forgotten about the \ in arrow notation.
If the abbreviation contained no \, there would be no way to replace
it with a proc.
Exactly. It seems, however, that it has finally been decided to use the
syntax with \case, so all looks good so far. :-)
Best wishes,
Wolfgang
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Call to arms: lambda-case is stuck and needs your help
Am Montag, den 16.07.2012, 21:26 +0300 schrieb Wolfgang Jeltsch:
Am Freitag, den 13.07.2012, 13:40 +0100 schrieb Ross Paterson:
Remember that there is a \ in arrow notation in addition to proc.
So one might expect any abbreviation for \x - case x of {...}
to mean the same \ thing in arrow notation too.
I completely agree. I had forgotten about the \ in arrow notation.
I have opened a new ticket for arrow analogs of lambda case and
multi-way if:
http://hackage.haskell.org/trac/ghc/ticket/7081
Best wishes,
Wolfgang
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Call to arms: lambda-case is stuck and needs your help
Am Donnerstag, den 12.07.2012, 13:38 -0400 schrieb Cale Gibbard:
Personally I don't see why everyone appears to prefer the syntax with
\ in it over just the obvious case section syntax which was originally
proposed.
case of { ... }
looks much better to me than
\case of { ... }
and the former makes sense to me as a simple extension of operator
sections to another part of the syntax.
Does anyone else agree?
I’m strongly opposed to the
case of { ... }
syntax, because there seems to be no natural arrow expression analog of
it.
A notation that starts with \ (like “\case”) can be carried over to
arrow expressions by replacing the \ with proc (like in “proc case”).
Best wishes,
Wolfgang
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Call to arms: lambda-case is stuck and needsyour help
Am Freitag, den 13.07.2012, 06:57 -0700 schrieb Donn Cave:
Quoth Cale Gibbard:
Personally I don't see why everyone appears to prefer the syntax with
\ in it over just the obvious case section syntax which was originally
proposed.
case of { ... }
...
Does anyone else agree?
Yes. I don't see this as an `anonymous function' in any special sense,
only inasmuch as the workaround in its absence involves one. I.e., if
I for some reason had been compelled to write
\ a - hPutStrLn stdout a
... that wouldn't make hPutStrLn stdout an anonymous function in my book.
Neither is `case of ...' an anonymous function, or functions.
Donn
What is an anonymous function? A function that has no name, that is, a
function that is not assigned to an identifier. So (+ 1), \x - x + 1,
and any lambda case are all anonymous functions.
Best wishes,
Wolfgang
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Call to arms: lambda-case is stuck and needs your help
Am Dienstag, den 10.07.2012, 08:53 +0100 schrieb Simon Marlow: On 09/07/2012 17:32, Mikhail Vorozhtsov wrote: Would you still expect tuples for \case if you didn't see the way `case x, y of ...` was implemented (or thought that it is a primitive construct)? Yes, I still think it's strange. We don't separate arguments by commas anywhere else in the syntax; arguments are always separated by whitespace. This is the point I wanted to make in my e-mail yesterday. Using a comma here seems to be against established Haskell syntax conventions. Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Call to arms: lambda-case is stuck and needs your help
Am Dienstag, den 10.07.2012, 06:53 + schrieb Simon Peyton-Jones: I strongly favor a solution where lambda-case expressions start with \, because this can be generalized to proc expressions from arrow syntax simply by replacing the \ with proc. […] I think it's very helpful if lambdas start with a lambda, which to me suggests \case. I'm not keen on \of; case says case analysis more clearly. But you presumably do not want \proc, because proc is the lambda. So that would leave use with \case and proc of as the two constructs. Perhaps the lesser of the evils, but a bit inconsistent. If we use \case for functions, we should use proc case for arrows; if we use \of for functions, we should use proc of for arrows. By the way, is proc a layout herald already? Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Call to arms: lambda-case is stuck and needs your help
Am Samstag, den 07.07.2012, 00:08 -0400 schrieb Tyson Whitehead:
I've thought some more about this and it seems to me that there are
two ways people might intuitively think about doing grouping via
indentation.
1 - the first item is on the same line and subsequent ones are lined
up with it
do stmt1
stmt2
2 - the first item is on a new line and subsequent ones are lined up
with it.
do
stmt1
stmt2
The current layout engine is targeted at (1). It appears to do (2),
but it is not really reliable as things start to go south if the first
line happened to open more than one grouping (precisely the problem
that make '\' a group token would introduce in codes). For an
example, consider
let greet name = do
putStr hello
putStrLn name
in f world
It currently translates into
let { greet name = do {} } putStr hello putStrLn name in f world
This results in an unituituve Empty 'do' construct error message.
The problem is that your example is not consistently using (2). A pure
(2)-example would look like this:
let
greet name = do
putStr hello
putStrLn name
in greet world
And this works. :-)
Best wishes,
Wolfgang
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Call to arms: lambda-case is stuck and needs your help
Am Montag, den 09.07.2012, 21:04 +0700 schrieb Mikhail Vorozhtsov: Could you express your opinion on the case comma sugar, i.e. case x, y of P1, P2 - ... P3, P4 - ... as sugar for case (# x, y #) of (# P1, P2 #) - ... (# P3, P4 #) - ... and respectively \case P1, P2 - ... P3, P4 - ... as sugar for \x y - case x, y of P1, P2 - ... P3, P4 - ... ? Although I wasn’t asked, I want to express my opinion. I think, the use of the comma is strange. When declaring functions with multiple arguments, we don’t have commas: f Nothing y = y f (Just x) y = x In lambda expressions for multi-argument functions, we also don’t have commas: \x y - x + y Why should we have them when using a case-lambda expression for a multi-argument function? Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Call to arms: lambda-case is stuck and needs your help
Am Montag, den 09.07.2012, 10:20 -0600 schrieb Chris Smith: Right, it seems to me that there are basically three reasonable proposals here: 1. \ of with multiple arguments. This is consistent with existing layout, and seems like a nice generalization of lambda syntax. 2. case of with a single argument. This is consistent with existing layout, and seems like a nice generalization of sections. 3. \ introducing layout, possibly with changes to layout rules. A much more intrusive change, but it does have a nice efficiency to it. I strongly favor a solution where lambda-case expressions start with \, because this can be generalized to proc expressions from arrow syntax simply by replacing the \ with proc. Take, for example, the following function definition: f (Left x) = g x f (Right y) = h y Now, let’s make an arrow version of it: f = proc e - case e of Left x - g - x Right y - h - y It would be great if we could write something like this instead: f = proc of Left x - g - x Right y - h - y This is not just a contrived issue. In my current work on Grapefruit, I encounter this situation quite often, and I would love to get rid of the extra overhead I have to deal with now. Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1
Am Donnerstag, den 22.12.2011, 00:02 +0100 schrieb Bas van Dijk:
On 21 December 2011 19:29, Ian Lynagh ig...@earth.li wrote:
* There is a new feature constraint kinds (-XConstraintKinds):
http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/constraint-kind.html
I'm trying to run the ConstraintKinds example from the documentation:
{-# LANGUAGE ConstraintKinds, TypeFamilies #-}
type family Typ a b :: Constraint
type instance Typ Int b = Show b
type instance Typ Bool b = Num b
But GHC complains:
Not in scope: type constructor or class `Constraint'
By the way, is there a reason behind the fact that “Constraint” uses the
ordinary case, while “BOX” has all three letters capitalized? Wouldn’t
it be more sensible if it were “Box” instead of “BOX”?
Things like capitalization might not seem very important first, but
unfortunately, decisions about them seem to persist.
Best wishes,
Wolfgang
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] A Mascot
Am Mittwoch, den 16.11.2011, 10:46 +0100 schrieb Bas van Dijk: Is ⊥ the right symbol to express the non-strict evaluation of the language? Is it true that non-strict evaluation requires that ⊥ inhabits every type? In typical strict languages, ⊥ also inhabits every type. The difference is that the domains of all types except function types are flat. That is, they don’t contain any partially defined values like ⊥ : ⊥, but only ⊥ and completely defined values. Where a Haskell expression would result in a partially defined value, the same expression in a corresponding strict language would result in ⊥. So strict languages are “more ⊥” than Haskell. Thus I cannot see why ⊥ should be used as a symbol for non-strictness at all. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll: Do you want a mascot?
No. Am Mittwoch, den 23.11.2011, 13:11 -0600 schrieb heathmatlock: Question: Do you want a mascot? Answers: Yes No -- This is an attempt to figure out if this idea is going anywhere. ___ 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: Records in Haskell
Am Montag, den 07.11.2011, 21:41 + schrieb Barney Hilken: The problem with this approach is that different labels do not have different representations at the value level. I think this is an advantage, because it means you don't have to carry this stuff about at runtime. This allows me to pattern match records, since I can construct record patterns that contain fixed labels: X : MyName1 := myValue1 : MyName2 := myValue2 I cannot see how this could be done using kind String. Do you see a solution for this? A similar problem arises when you want to define a selector function. You could implement a function get that receives a record and a label as arguments. However, you could not say something like the following then: get myRecord MyName1 Instead, you would have to write something like this: get myRecord (Label :: MyName1) Just define a constant myName1 = Label :: MyName1 for each label you actually use, and you can use it in both get and pattern matching You cannot use such a constant in a pattern. You need a data constructor if you want to use pattern matching. Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Records in Haskell
Am Montag, den 07.11.2011, 23:30 + schrieb Simon Peyton-Jones: Wolfgang Is there a wiki page giving a specific, concrete design for the proposal you advocate? Something at the level of detail of http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields? Well, I don’t propose a new record system as a language feature. Instead, I’ve implemented a record system as a library. The paper at http://www.informatik.tu-cottbus.de/~jeltsch/research/ppdp-2010-paper.pdf describes this in detail, and the records package at http://hackage.haskell.org/package/records is the actual library. My stance is that it is possibly better if we do not try to include a one-size-fits-it-all record system into the language, but if the language provided support for basic things that almost all record system *libraries* would need. In my opinion, there is at least one such thing that should get language support: field labels. There is already the proposal at http://hackage.haskell.org/trac/haskell-prime/wiki/FirstClassLabels for first-class field labels. I am unsure whether you regard it as an alternative to the above, or something that should be done as well. And if the former, how does it relate to the challenge articulated on http://hackage.haskell.org/trac/ghc/wiki/Records, namely how to make Haskell's existing named-field system work better? I don’t think that everyone should use my record system. I see it as one member of a family of reasonable record systems. My intention, when developing my record system, was not to make the existing system better, since I needed quite a lot of advanced features that anything near Haskell’s existing record system couldn’t give me. So I started something completely new. Thanks Simon Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: problems with impredicativity
Am Freitag, den 04.11.2011, 20:16 -0400 schrieb wagne...@seas.upenn.edu:
Quoting wagne...@seas.upenn.edu:
Quoting Wolfgang Jeltsch g9ks1...@acme.softbase.org:
this code is accepted by GHC 7.0.4:
snip
However, this one isn?t:
{-# LANGUAGE ImpredicativeTypes #-}
polyId :: (forall a. Maybe a) - Maybe a
polyId x = x
polyIdMap :: [forall a. Maybe a] - [forall a. Maybe a]
polyIdMap xs = fmap polyId xs
Is there a way to make it accepted?
[…]
The first thing to observe is that, ideally, the following two types
would mean slightly different things:
polyId :: forall b. (forall a. Maybe a) - Maybe b
polyId :: (forall a. Maybe a) - (forall b. Maybe b)
[…]
Unfortunately, in GHC, these two types do not mean different things:
foralls on the result side of an arrow are silently floated to the
top level, even if you explicitly choose to put them later in your
type annotation.
That’s the problem. I could have written the second type in the type
signature, which would directly express my intension, but I didn’t,
since GHC silently transforms it into the first type anyway.
The only way I know of to prevent this is to make a newtype barrier.
This is what I already thought of worth trying.
For example, the following works:
newtype PolyMaybe = PolyMaybe (forall a. Maybe a)
polyId :: PolyMaybe - PolyMaybe
polyId x = x
polyIdMap :: [PolyMaybe] - [PolyMaybe]
polyIdMap xs = fmap polyId xs
Then, later, you can unwrap the PolyMaybe -- but only when you're
ready to turn it into a monomorphic Maybe! (Note that none of these
things is using ImpredicativeTypes, which is what made me jump to my
first, probably mistaken impression of what you were trying to do.
Rank2Types is enough for the above to compile.)
I shouldn’t need impredicativity in the result, so I’ll try this route.
~d
Best wishes,
Wolfgang
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: problems with impredicativity
Am Montag, den 07.11.2011, 14:49 +0200 schrieb Wolfgang Jeltsch: Am Freitag, den 04.11.2011, 20:16 -0400 schrieb wagne...@seas.upenn.edu: The first thing to observe is that, ideally, the following two types would mean slightly different things: polyId :: forall b. (forall a. Maybe a) - Maybe b polyId :: (forall a. Maybe a) - (forall b. Maybe b) […] Unfortunately, in GHC, these two types do not mean different things: foralls on the result side of an arrow are silently floated to the top level, even if you explicitly choose to put them later in your type annotation. That’s the problem. I could have written the second type in the type signature, which would directly express my intension, but I didn’t, since GHC silently transforms it into the first type anyway. The only way I know of to prevent this is to make a newtype barrier. This is what I already thought of worth trying. For example, the following works: newtype PolyMaybe = PolyMaybe (forall a. Maybe a) polyId :: PolyMaybe - PolyMaybe polyId x = x polyIdMap :: [PolyMaybe] - [PolyMaybe] polyIdMap xs = fmap polyId xs Then, later, you can unwrap the PolyMaybe -- but only when you're ready to turn it into a monomorphic Maybe! (Note that none of these things is using ImpredicativeTypes, which is what made me jump to my first, probably mistaken impression of what you were trying to do. Rank2Types is enough for the above to compile.) I shouldn’t need impredicativity in the result, so I’ll try this route. Yes, this works. Thank you. Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
Am Montag, den 07.11.2011, 17:53 + schrieb Barney Hilken: Here is my understanding of the current state of the argument: Instead of Labels, there will be a new kind String, which is not a subkind of *, so its elements are not types. The elements of String are strings at the type level, written just like normal strings. If you want labels, you can define them yourself, either empty: data Label (a :: String) or inhabited data Label (a :: String) = Label these definitions give you a family of types of the form Label name, in the first case empty (except for undefined), in the second case inhabited by a single element (Label :: Label name) There are several similar proposals for extensible records defined using labels, all of which (as far as I can see) could be defined just as easily using the kind String. The problem with this approach is that different labels do not have different representations at the value level. In my record system, I use label definitions like the following ones: data MyName1 = MyName1 data MyName2 = MyName2 This allows me to pattern match records, since I can construct record patterns that contain fixed labels: X : MyName1 := myValue1 : MyName2 := myValue2 I cannot see how this could be done using kind String. Do you see a solution for this? A similar problem arises when you want to define a selector function. You could implement a function get that receives a record and a label as arguments. However, you could not say something like the following then: get myRecord MyName1 Instead, you would have to write something like this: get myRecord (Label :: MyName1) Whis is ugly, I’d say. Yes, Simon’s proposal contains syntactic sugar for selection, but this sugar might not be available for other record systems, implemented in the language. The situation would be different if we would not only have kind String, but also an automatically defined GADT that we can use to fake dependent types with string parameters: data String :: String - * -- automatically defined A string literal abc would be of type String abc then. However, I am not sure at the moment, if this would solve all the above problems. Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
Am Montag, den 07.11.2011, 18:16 +0100 schrieb Claus Reinke: I am unsure which of this list of proposals you are referring to. The URL you quote is this http://hackage.haskell.org/trac/haskell-prime/wiki/FirstClassLabels That sounds familiar, I think I wrote that when I was younger;-) but it doesn't seem to actually contain a design, merely some options for a design that is implicit. Please note that this particular instance of FirstClassLabels was *not* about record systems themselves (already a hopeless mess of proposals and preferences back then), but about a feature that would help defining record systems *in the language*. Indeed. And I think it is important to make implementing new record systems in the language easier. Each record system built into the language might lack some features that someone wants. So it would be good if one could come up with one’s own record system easily. Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
problems with impredicativity
Hello,
this code is accepted by GHC 7.0.4:
{-# LANGUAGE ImpredicativeTypes #-}
polyId :: (forall a. a) - a
polyId x = x
polyIdMap :: [forall a. a] - [forall a. a]
polyIdMap xs = fmap polyId xs
However, this one isn’t:
{-# LANGUAGE ImpredicativeTypes #-}
polyId :: (forall a. Maybe a) - Maybe a
polyId x = x
polyIdMap :: [forall a. Maybe a] - [forall a. Maybe a]
polyIdMap xs = fmap polyId xs
Is there a way to make it accepted?
Best wishes,
Wolfgang
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Two Proposals
Am Freitag, den 30.09.2011, 19:28 +0200 schrieb George Giorgidze: Basically the idea is to treat list literals like: [1,2,3] as fromList [1,2,3] where class IsList l where type Item l fromList :: [Item l] - l Could we *please* not have classes whose names start with “Is”? We don’t have classes IsNum, IsEq, or IsOrd, so why should we have IsList and IsString? I know that the identifier String is already taken, but please don’t tie an identifier like IsString or IsList to a language feature, so that it’ll be difficult to change it later. Let’s search for a better solution. In the following I give useful instances of the IsList class. […] instance (Ord a) = IsList (Set a) where type Item (Set a) = a fromList = Set.fromList As a set is definitely not a list, the class should better be named differently anyway, shouldn’t it? Don’t know if these issues have already been pointed out, since I didn’t read through the complete thread. Sorry, if they have already. Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell-cafe] package cache being out of date
Hi, I have a freshly installed Haskell Platform 2010.2.0.0 on Windows 7. When I run ghc-pkg list, I get the following message (besides the expected package info): WARNING: cache is out of date: C:/Program Files (x86)/Haskell Platform/2010.2.0.0\lib\package.conf.d\package.cache use 'ghc-pkg recache' to fix. What does this mean? Is this harmful? (In principal, I could just run ghc-pkg recache, but the installation is replicated on about 20 machines, and I don’t have admin rights on these.) Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: backward compatibility
Am Donnerstag, den 20.01.2011, 23:25 +0900 schrieb 山本和彦: I'm asking why GHC breaks backward compatibility (e.g. FlexibleInstances and BangPatterns) and why maintainers of packages should do boring fixes. What are benefits of such overhead? Hi, what are the changes in GHC wrt. FlexibleInstances and BangPatterns? Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] H98, OOHaskell - getting started with objects in Haskell
Am Sonntag, den 16.01.2011, 14:48 -0800 schrieb gutti: Looking at life u probably could save time, if u only would evaluate code on cells, where the neighbors have changed status. So rather than triggering them all centrally and each checks its neighbours, we could use the concept: - let the active ones trigger the neighbours so pass on activity But then you would have to take care to avoid cycles. You could also use on-demand updates with a centralized approach, and a centralized approach would probably make cycle detection easier. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] H98, OOHaskell - getting started with objects in Haskell
Am Donnerstag, den 13.01.2011, 15:23 -0800 schrieb gutti: I'm especially interestes in engineering calculation tasks where cellular automata could be used. In that case all u have to do is to give the class the right properties and that let it grow. Such a localised intelligence approach seems an ideal OO - task. I don't know whether something functional could achieve the same. Is this really ideal for OO? I thought that in a cellular automaton, all cells have to change synchronously. In addition, cells have to access the old states of their neighbours to compute their new states. So you would have to heavily synchronize the objects. In this light, I’d say that the distributed OO approach isn’t very practical. A global control of the whole system might be better. Note that I’m by no way an expert in cellular automata. I’m just thinking of the game of life. :-) Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Improving HList programming/debugging (longish)
Am Dienstag, den 11.01.2011, 20:05 -0500 schrieb jeff p: This message shows how to slightly reformulate HLists (and other type-level things) to get better type-checking and more informative error messages. The technique is interesting in that it uses GADTs and functional dependencies and seems to not be implementable with associated type synonyms. It also makes higher-order HList programming/debugging much more tractable. Hi, a few years ago, I also experienced with using GADTs for representing heterogenous lists. However, I dropped this idea, since GADTs force you to provide type signatures in certain situations. For example, you cannot leave out the type signatures in the following definitions: hHead :: HList (x :* xs) - x hHead (x :* _) = x hTail :: HList (x :* xs) - HList xs hTail (_ :* xs) = xs This was at odds with a feature I wanted: It should be possible to match a polymorphic value representing a family of heterogenous lists against a pattern such that the type of the pattern specifies the concrete list to use. I finally switched back to the traditional approach used in today’s HList. You can read about the pattern-matching thing in Subsection 5.4 of my paper “Generic Record Combinators with Static Type Checking” [1]. Best wishes, Wolfgang [1] http://www.informatik.tu-cottbus.de/~jeltsch/research/ppdp-2010-paper.pdf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Coding conventions for Haskell?
Am Sonntag, den 26.09.2010, 17:25 +0100 schrieb Maciej Piechotka: I use it in following way; 1. For short sharing name (rarely) let a = b ++ c in (a, a) 2. Default let a :: [Int] a = b ++ c f :: Int - String f 0 = f x = show x in map f a I like to separate declaration by empty lines: let a :: [Int] a = b ++ c f :: Int - String f 0 = f x = show x in map f a I think this is much more readable, since you can easily see which of those lines belong together. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] record update
Am Dienstag, den 14.09.2010, 13:31 -0600 schrieb Jonathan Geddes: Wow, I had no idea there were so many record packages! The trouble is that only one of them (i.e., mine) is categorized under “Records” on Hackage. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] record update
Am Samstag, den 11.09.2010, 11:21 -0600 schrieb Jonathan Geddes:
I know that record updates is a topic that has become a bit of a dead
horse, but here I go anyway:
I find that most of the record updates I read and write take the form
someUpdate :: MyRecord - MyRecord
someUpdate myRecord = myRecord
{ field1 = f $ field1 myRecord
, field2 = g $ field2 myRecord
, field3 = h $ filed3 myRecord
}
I find myself wishing I could write something more like
someUpdate :: MyRecord - MyRecord
someUpdate myRecord = myRecord
{ field1 = f
, field2 = g
, field3 = h
}
with equivalent semantics. Here = reads is transformed by. Operator
= could still be used for assignment as in current record updates.
The best part about such an extension, in my opinion, is that it would
open the door for anonymous lambda record updates. Something like:
someUpdate :: MyRecord - MyRecord
someUpdate = \{field1 = f, field2 = g, field3 = h}
again, with the same semantics. This becomes possible because you no
longer need to refer to the record within the {} part of the update.
This would be useful, for example, in the State monad. We could write:
someStateTransform :: State MyRecord ()
someStateTransform = do
modify $ \{field1 = (++!)}
...
where currently we see code like
someStateTransform :: State MyRecord ()
someStateTransform = do
modify $ \record-record{field1 = (++!) $ field1 record}
...
which repeats the record name 3 times and the field name twice. The
repetition just feels out of place next to all the other terse,
readable Haskell code in the program.
So what do my fellow haskellers think? Is this idea worth writing up a
proposal for?
Alternatively, can you offer me some advice on writing code in Haskell
2010 that avoids the ugly, repetitive style of record update?
--Jonathan
You might want to have a look at the records package:
http://hackage.haskell.org/package/records
Here is a code example:
import Data.Kind
import Data.TypeFun
import Data.Record
import Data.Record.Combinators
data Surname = Surname deriving (Show)
data Age = Age deriving (Show)
data Room= Roomderiving (Show)
instance Name Surname where name = Surname
instance Name Age where name = Age
instance Name Roomwhere name = Room
oldData = X : Surname := Jeltsch
: Age := 31
: Room:= EH/202
`withStyle` Id KindStar
newData = modify (X : Age := (+2) : Room := const HG/2.39) oldData
Evaluating newData gives you:
X : Surname := Jeltsch : Age := 33 : Room := HG/2.39
If you have any question regarding the records package, please ask,
since I’m its author. :-)
Best wishes,
Wolfgang
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: new keyword: infixlr?
Am Freitag, den 10.09.2010, 23:18 +0200 schrieb S. Doaitse Swierstra: On 10 sep 2010, at 20:13, Ian Lynagh wrote: How would the compiler work out which parsing to prefer? Or would it assume that infixlr expressions are best balanced? Yes, that is the idea. To me, it seems weird that optimization should be done at the level of syntax. Note that optimization would only trigger if you write concrete applications of the infix operator, not if you construct them programmatically. Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell-cafe] Haskell, arrows and signal processing
Am Mittwoch, den 08.09.2010, 11:47 -0300 schrieb Rafael Gustavo da Cunha Pereira Pinto: The input and output are infinite streams. I have a few questions: 1) Is it possible to change it to use arrows? How would it look like? 2) How would one implement an continuous time version? Have you had a look at Yampa? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] overloaded list literals?
Am Montag, den 06.09.2010, 11:47 +0100 schrieb Neil Brown: I would have thought you have two obvious choices for the type-class (things like folding are irrelevant to overloading list literals): class IsList f where fromList :: [a] - f a or: class IsList f where cons :: a - f a - f a empty :: f a We should definitely get rid of these Is* class identifiers like IsString and IsList. We also don’t have IsNum, IsMonad, etc. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] overloaded list literals?
Am Montag, den 06.09.2010, 19:38 +0400 schrieb Bulat Ziganshin: btw, i also had proposal to automatically convert typeclasses used in type declarations into constraints, so that: putStr :: StringLike - IO () treated as putStr :: StringLike s = s - IO () This blurs the distinction between classes and types, which are two fundamentally different concepts in Haskell. In addition, it works only for special cases. I would like the language to be simple. Alas, more and more sugar is added to Haskell, which makes it unnecessarily complicated. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] generalized newtype deriving allows the definition of otherwise undefinable functions
Am Donnerstag, 11. März 2010 00:37:18 schrieb wren ng thornton: Wolfgang Jeltsch wrote: Hello, some time ago, it was pointed out that generalized newtype deriving could be used to circumvent module borders. Now, I found out that generalized newtype deriving can even be used to define functions that would be impossible to define otherwise. To me, this is surprising since I thought that generalized newtype deriving was only intended to save the programmer from writing boilerplate code, not to extend expressiveness. Let's dig down and figure out the problem. When you annotate the type Wrapped a with deriving (Iso a) what are you saying? You're saying that the compiler should derive an instance (Iso a (Wrapped a)). Well, that instance gives you the method instance conv :: forall f. f a - f (Wrapped a). The funny thing is that the only implementation for ---something like--- that type would be fmap Wrap. If the parameter of f is contravariant then we would need a “contraMap”, not an fmap. Example: newtype CoFun a b = CoFun (b - a) class ContraFunctor f where contraMap :: (a - b) - f b - f a instance ContraFunctor (CoFun a) where contraMap f (CoFun g) = CoFun (g . f) coFun :: CoFun Int Char coFun = CoFun ord directlyConverted :: CoFun Int (Wrapped Char) directlyConverted = conv coFun manuallyConverted :: CoFun Int (Wrapped Char) manuallyConverted = contraMap unwrap coFun Here, unwrap is the inverse of Wrap. Let us look at the Set example from John Meacham. Set is a (covariant) functor, not a contravariant functor. However, it isn’t a functor from and to the category of Haskell types and functions but the category of types of class Ord and Ord homomorphisms (functions that respect ordering). The problem in John Meacham’s Set example is that Down doesn’t preserve ordering. If conv is used with a newtype wrapper constructor that does preserve ordering, this is the same as applying Set.map or Set.mapMonotonic. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
nasty things possible with generalized newtype deriving
Hello guys, are you following this Haskell Cafe thread: http://www.mail-archive.com/haskell-c...@haskell.org/msg72300.html Seems that you can do ugly things with GHC’s current implementation of generalized newtype deriving. For example, you can easily construct sets with corrupted internal structure even if there are no bogus Ord instances. Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Haskell course, training
Am Montag, 8. März 2010 23:17:56 schrieb Henning Thielemann: On Sun, 7 Mar 2010, G?nther Schmidt wrote: I think I've reached the point where I need some tutoring, so provided I've got money for travel and course fees, and time, where do I get it? I'm not a student so some courses aren't available to me. How about visiting our Haskell meeting in Leipzig, June 4th? By the way, has this been announced already? Is the program already fixed or are applications for a talk or a tutorial still welcome? To be more precise, would the organizers be interested in something about dependent types? I might be able to offer something in this direction. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] generalized newtype deriving allows the definition of otherwise undefinable functions
Am Dienstag, 9. März 2010 07:24:35 schrieb Steffen Schuldenzucker: On 03/08/2010 10:45 PM, Wolfgang Jeltsch wrote: The point is, of course, that such conversions are not only possible for binary operations but for arbitrary values and that these conversions are done by a single generic function conv. I don’t think it would be possible to implement conv without generalized newtype deriving. Any thoughts? Hi Wolfgang, it's not exactly the same, but... import Control.Applicative newtype Wrapped a = Wrap a deriving Show instance Functor Wrapped where fmap f (Wrap x) = Wrap $ f x instance Applicative Wrapped where pure = Wrap (Wrap f) * (Wrap x) = Wrap $ f x convBinOp :: (a - a - a) - (Wrapped a - Wrapped a - Wrapped a) convBinOp op x y = pure op * x * y I think this is fundamentally different. As I said above: The point is, of course, that such conversions are not only possible for binary operations but for arbitrary values and that these conversions are done by a single generic function conv. Your applicative functor Wrapped allows conversions only for n-ary functions, so, for example, John Meachem’s trick to break the invariant of Set doesn’t work. On the other hand, you need a separate conversion function for each arity (pure, fmap, liftA2, liftA3, …) whereas generalized newtype deriving allows you to use the same conversion function for all arities. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] generalized newtype deriving allows the definition of otherwise undefinable functions
Am Dienstag, 9. März 2010 11:53:14 schrieben Sie: Isn't this just an extension of the notion that multi-parameter typeclasses without functional dependencies or type families are dangerous and allow for type-naughtiness? Multi-parameter typeclasses are dangerous? It’s the first time I hear that. Could you elaborate, please? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] generalized newtype deriving allows the definition of otherwise undefinable functions
Am Dienstag, 9. März 2010 15:54:16 schrieb Jan-Willem Maessen: On Mar 9, 2010, at 5:53 AM, Max Cantor wrote: Isn't this just an extension of the notion that multi-parameter typeclasses without functional dependencies or type families are dangerous and allow for type-naughtiness? I wondered the same thing, but came up with an analogous problematic case that *only* uses generalized newtype deriving: […] Originally, I had a more restricted example in mind which is similar to yours. However, I wanted to generalize the problem and therefore introduced the general Iso class which made MultiParamTypeClasses and FlexibleInstances necessary. The actual problem is related neither to MultiParamTypeClasses nor to FlexibleInstances. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] generalized newtype deriving allows the definition of otherwise undefinable functions
Hello,
some time ago, it was pointed out that generalized newtype deriving could be
used to circumvent module borders. Now, I found out that generalized newtype
deriving can even be used to define functions that would be impossible to
define
otherwise. To me, this is surprising since I thought that generalized newtype
deriving was only intended to save the programmer from writing boilerplate
code, not to extend expressiveness.
Have a look at the following code:
{-# LANGUAGE
GeneralizedNewtypeDeriving,
MultiParamTypeClasses,
FlexibleInstances
#-}
class Iso a b where
conv :: item a - item b
instance Iso a a where
conv = id
newtype Wrapped a = Wrap a deriving (Iso a, Show)
Now any value whose type contains some type t can be converted into a value of
the type that you get if you replace t by Wrap t. Here is some code to
demonstrate this for binary operations:
newtype BinOp a = BinOp (a - a - a)
convBinOp :: (a - a - a) - (Wrapped a - Wrapped a - Wrapped a)
convBinOp op = let BinOp op' = conv (BinOp op) in op'
Now, you can enter
convBinOp (*) (Wrap 5) (Wrap 3)
into GHCi, and you will get
Wrap 15
as the result.
The point is, of course, that such conversions are not only possible for
binary operations but for arbitrary values and that these conversions are done
by a single generic function conv. I don’t think it would be possible to
implement conv without generalized newtype deriving.
Any thoughts?
Best wishes,
Wolfgang
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] generalized newtype deriving allows the definition of otherwise undefinable functions
Am Montag, 8. März 2010 22:45:19 schrieb Wolfgang Jeltsch:
Hello,
some time ago, it was pointed out that generalized newtype deriving could
be used to circumvent module borders. Now, I found out that generalized
newtype deriving can even be used to define functions that would be
impossible to define otherwise. To me, this is surprising since I thought
that generalized newtype deriving was only intended to save the programmer
from writing boilerplate code, not to extend expressiveness.
Have a look at the following code:
{-# LANGUAGE
GeneralizedNewtypeDeriving,
MultiParamTypeClasses,
FlexibleInstances
#-}
class Iso a b where
conv :: item a - item b
instance Iso a a where
conv = id
newtype Wrapped a = Wrap a deriving (Iso a, Show)
Now any value whose type contains some type t can be converted into a value
of the type that you get if you replace t by Wrap t. Here is some code to
demonstrate this for binary operations:
newtype BinOp a = BinOp (a - a - a)
convBinOp :: (a - a - a) - (Wrapped a - Wrapped a - Wrapped a)
convBinOp op = let BinOp op' = conv (BinOp op) in op'
Now, you can enter
convBinOp (*) (Wrap 5) (Wrap 3)
into GHCi, and you will get
Wrap 15
as the result.
The point is, of course, that such conversions are not only possible for
binary operations but for arbitrary values and that these conversions are
done by a single generic function conv. I don’t think it would be possible
to implement conv without generalized newtype deriving.
Generalized newtype deriving doesn’t just allow otherwise undefinable functions
to be defined. It probably also allows for faster function implementations. For
example, with the above conv method, you could probably convert a list of some
type [t] into a list of type [Wrapped t] in O(1) time. If you would code this
conversion by hand, it would take O(n) time, of course.
Best wishes,
Wolfgang
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: GPL answers from the SFLC (WAS: Re: ANN: hakyll-0.1)
Am Samstag, 6. März 2010 03:45:02 schrieb Maciej Piechotka: PS. There is also GPL-with-linking-exception which allows linking etc. but does not require relinking capability. I'd believe that in such case the cross-module inlining is not a problem since it is 'linking' for compiler. The term “linking” is quite well-defined in computer science. You seem to redefine it and assume that copyright holders will accept your redefinition. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GPL answers from the SFLC (WAS: Re: ANN: hakyll-0.1)
Am Donnerstag, 4. März 2010 18:57:03 schrieb MightyByte: Interesting. It seems to me that the only solution for the BSD-oriented haskell community is to practically boycott GPL'd libraries. From what I understand, this is exactly what the LGPL is for. I've known the basic idea behind the GPL/LGPL distinction for quite awhile, but I didn't realize that mistaking the two had such far-ranging consequences. Since GPL seems to be the big elephant in the room, it seems very easy to make this mistake. At the very least we should try to educate the community about this. To my knowledge, the LGPL only allows *linking* with non-(L)GPL software. But GHC doesn’t just link but performs massive cross-module inlining. So in my opinion, LGPL is not a solution, too. Use BSD3! Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] grapefruit on windows or osX
Am Sonntag, 21. Februar 2010 21:57:45 schrieb gladst...@gladstein.com: I'm unable to get grapefruit going on osx or windows because (I think) I can't get the underlying GTK installed. Hi, thank you for giving Grapefruit a try. Yes, you are most likely right that Gtk2Hs is the stumbling block. Grapefruit itself doesn’t do anything OS-specific, and since it works on Linux, it should also work on OS X. I strongly suggest that you try out the current development version of Grapefruit instead of the version on Hackage, since the latter is lacking a bunch of features. If you have any Grapefruit-related questions, please ask here or on the Grapefruit mailing list. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: GHC 6.12.1 and impredicative polymorphism
Am Freitag, 30. Oktober 2009 10:51:37 schrieb Simon Peyton-Jones: Friends One more update about GHC 6.12, concerning impredicative polymorphism. GHC has had an experimental implementation of impredicative polymorphism for a year or two now (flag -XImpredicativePolymorphism). But a) The implementation is ridiculously complicated, and the complexity is pervasive (in the type checker) rather than localized. I'm very unhappy about this, especially as we add more stuff to the type checker for type families. b) The specification (type system) is well-defined [1], but is also pretty complicated, and it's just too hard to predict which programs will typecheck and which will not. So it's time for a re-think. I propose to deprecate it in 6.12, and remove it altogether in 6.14. We may by then have something else to put in its place. (There is no lack of candidates [2,3,4]!) Fortunately, I don't think a lot of people use the feature in anger. Please yell if you *are* using impredicative polymorphism for something serious. But if you are, we need to think of a workaround. The current situation seems unsustainable. Simon [1] http://research.microsoft.com/en-us/um/people/simonpj/papers/boxy/ [2] http://research.microsoft.com/en-us/um/people/crusso/qml/ [3] http://research.microsoft.com/en-us/um/people/daan/pubs.html [4] http://gallium.inria.fr/~remy/mlf/ Hello Simon and others, unfortunately, I missed this e-mail. Yes, removal of impredicative polymorphism hurts me, since impredicativity plays a crucial role in the Grapefruit FRP library at the moment. This is described in section 5 of my paper “Signals, Not Generators!” [5]. It’s probably possible to use a workaround involving a newtype wrapper, in case polymorphic fields in newtypes are still supported. However, this makes things more awkward for library users. Best wishes, Wolfgang [5] http://www.informatik.tu-cottbus.de/~jeltsch/research/tfp-2009-paper.pdf ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] job at the University of Technology in Cottbus
Hello, the Programming Languages and Compiler Construction Group at the University of Technology in Cottbus, Germany is seeking for a research and teaching assistent. Our focus is on declarative programming languages, so people with a strong background in functional programming might be especially interested in this position. The full announcement (in German) is at http://tinyurl.com/btu-pscb-job-2009. Best wishes, Wolfgang ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Examples
Am Samstag, 8. August 2009 13:29 schrieb Andrew Coppin: As some of you may remember, I recently released a couple of packages on Hackage. I'd like to also release some example programs using these packages, but I'm not sure of the best way to do this. Do I make the example programs part of the package itself? Do I release a seperate package which just contains the example code? Something else entirely? What's the recommendation here? I had to make this decision for Grapefruit, and I decided to put the examples into a separate package named grapefruit-examples. Note that the rest of Grapefruit was already split into several packages with names of the form grapefruit-*. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage and version control
Am Montag, 20. Juli 2009 05:25 schrieb Robin Green: community.haskell.org requires you to wait for a volunteer to review every new project request. However, response times are usually low. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK
Am Sonntag, 19. Juli 2009 23:42 schrieben Sie: On Jul 18, 2009, at 9:26 PM, Wolfgang Jeltsch wrote: I don’t think, it’s a good idea to have German identifiers, since Haskell’s keywords are English. Put it this way: if Haskell's keywords were in German, do you suppose I would write my Haskell code in anything but English? At least, many people all over the world write their code in something other than their native language. :-) Does the fact that 'data' is a Latin word mean that some fraction of our Haskell identifiers should be in Latin? data is also an English word nowadays. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK
Am Samstag, 18. Juli 2009 06:31 schrieben Sie: On Jul 18, 2009, at 2:35 AM, Wolfgang Jeltsch wrote: So I should upload a package with German identifiers to Hackage? Sure, why not? The fact that I can't read it is my loss, not your fault, and there will be plenty of other German-reading Haskellers to benefit from it. I've happily worked with programs in French (not large ones (:-)). I don’t think, it’s a good idea to have German identifiers, since Haskell’s keywords are English. On the other hand, I strongly argue that a library about Bézier curves uses the identifier Bézier, not Bezier. So non-ASCII identifiers are useful even if identifiers are in English. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: newtype deriving, was Re: [Haskell-cafe] is closing a class this easy?
Am Samstag, 18. Juli 2009 11:43 schrieb Conor McBride: The trouble here is that somewhere along the line (GADTs? earlier?) it became possible to construct candidates for p :: * - * which don't respect isomorphism. Hello Conor, I’m not sure whether I exactly understand what you mean here. I think, it’s the following: Say, you have a type A and define a type B as follows: newtype B = B A Then, for any p :: * - *, the type p A should be isomorphic to p B, i.e., it should basically contain the same values. This is no longer true with GADTs since you can define something like this: data GADT a where GADT :: GADT A Now, GADT :: GADT A but not GADT :: GADT B. Is this what you mean? These tend to be somewhat intensional in nature, and they mess up the transfer of functionality. Could you maybe elaborate on this? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] is closing a class this easy?
Am Samstag, 18. Juli 2009 08:58 schrieb Miguel Mitrofanov: Oops... Sorry, wrong line. Should be isAB :: forall p. p A - p B - p x Is this a well-known approach for closing classes? I came across the same idea and implemented a generic framework for closing classes in this way. I did this to simulate algebraic data kinds and kind polymorphism over such kinds. I needed this for the record system of Grapefruit. The code is here: http://code.haskell.org/grapefruit/main/grapefruit-records/src/ Explaination of the techniques used in this code will probably follow as part of an IFL 2009 paper. Now I wonder which of my ideas are actually new and which are just old hat. Could you maybe answer this question? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative IO
Am Freitag, 10. Juli 2009 23:41 schrieben Sie: On Jul 10, 2009, at 4:35 AM, Wolfgang Jeltsch wrote: I fear that this instance doesn’t satisfy required laws. As far as I know, the following equalities should hold: (*) = () f * empty = empty empty | g = g This implies the following: (f empty) | g = g But this wouldn’t hold with your instance. (f empty) | g would cause the side effects of f and of g, while g would (obviously) only cause the side effects of g. I think the third equality you provide is too strong (which isn't to say that it might not be the law that people have documented and expect). Lots of useful alternative instances fail it, not least any parser combinator library (such as Parsec) without automatic backtracking. Really? The third equality is required since Alternative instances have to be monoids with empty as the neutral element and (|) as composition. […] Additionally, the second equality you provide is just wrong. f * empty = empty is no more true than f * g = g, I don’t understand this. The equation f * g = g is much more general than f * empty = empty. (|) usually denotes non-determinism and empty should be the neutral element of non-determinism, which is failing. This leads me to f * empty = empty. […] Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative IO
Am Samstag, 11. Juli 2009 00:16 schrieben Sie: On Friday 10 July 2009 4:35:15 am Wolfgang Jeltsch wrote: I fear that this instance doesn’t satisfy required laws. As far as I know, the following equalities should hold: (*) = () f * empty = empty IO already fails at this law, because (f * empty) is not the same as empty, Huh? There was no Applicative instance for IO. This was the reason for Cristiano to define one, and my mail pointed out a problem in his definition. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK
Am Dienstag, 7. Juli 2009 14:42 schrieb Robin Green: On Fri, 10 Jul 2009 10:44:51 +0200 Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: PASCAL uses “program”, not “programme”, The word program (as in computer program) is spelled program in both British and American English. Probably just because British English took it from American English. It’s similar to the “German” word “Computer”. It’s not native. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK
Am Mittwoch, 15. Juli 2009 05:27 schrieben Sie: On Jul 10, 2009, at 8:44 PM, Wolfgang Jeltsch wrote: Why do we use English for identifiers? Because English is the language of computer science. What English should we use? It’s tempting to say, we should use the original English, which is British English. But we should ask again what is the language of computer science. And the language of computer science is American English. It was possible to adopt such an attitude in the 20th century. But this is the 21st century. We have globalisation, internationalisation, localisation. We have Unicode, so that people are no longer limited to the set of characters that technicians from the USA found tolerable back in 1967. So I should upload a package with German identifiers to Hackage? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What's the status with unicode characters on haddock ?
Am Freitag, 10. Juli 2009 09:54 schrieb david48: Hello all, I made a small program for my factory and I wanted to try to document it using haddock. The thing is, the comments are in French and the resulting html pages are unreadable because the accentuated letters are mangled. It's not acceptable to use HTML entities, as I'd like the comments to remain readable when/if I edit the code. Anyone has had the same problem ? Found a workaround ? Thanks, David. To my knowledge, Haddock only supports ASCII as input encoding. If you want to have characters outside ASCII, you have to escape them using something like #xA0;. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What's the status with unicode characters on haddock ?
Am Freitag, 17. Juli 2009 16:43 schrieben Sie: On Fri, Jul 17, 2009 at 4:37 PM, Wolfgang Jeltschg9ks1...@acme.softbase.org wrote: To my knowledge, Haddock only supports ASCII as input encoding. If you want to have characters outside ASCII, you have to escape them using something like #xA0;. Which would mean, while editing the code I'd have to read comments like that : -- | s#xA0;lection de l'#xA0;tat Which becomes totally unreadable. :( Yes, it’s a pity. For me, it’s not such a big problem since I don’t write my Haddock comments in my native language (German) but in English. I only experience this problem because I use nice typography, i.e., “ ” – instead of -. GHC supports UTF-8 input, and Haddock uses GHC nowadays. So, in my opinion, Haddock should also support UTF-8 input. Do you want to file a feature request? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pattern matching with where free variables can be used more than once
Am Freitag, 17. Juli 2009 20:38 schrieb Stefan Holdermans: Christopher, Wouldn't it be great if pattern variables could be used more than once in a pattern? Like so: foo [x,x,_,x] = The values are the same! foo _ = They're not the same! These are called nonlinear patterns. I think Miranda (a precursor of Haskell, sort of) used to have them. Yes, Miranda had them. I see the following problem with them: Patterns are about the structure of data. So using the same variable twice in the same pattern should mean that the values that match the variable must have the same structure. This would break data abstraction. For example, matching a pair of sets against the pattern (x,x) would succeed if both sets were represented by the same tree internally, but not succeed if both sets were equal but represented differently. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is the point of the 'What the bleep' names in haskell?
Am Freitag, 17. Juli 2009 21:06 schrieb Daryoush Mehrtash: Why do Haskell programmers (and libraries) name their function like @ or ###?Why not use a more descriptive label for functions? It’s for the same reason that mathematicians say 2 + 3 instead of plus(2,3): it’s more readable at times. :-) Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Am Montag, 16. Februar 2009 15:27 schrieben Sie: On Mon, 16 Feb 2009, Wolfgang Jeltsch wrote: [redirecting to haskell-cafe] Am Sonntag, 15. Februar 2009 00:25 schrieben Sie: Hi Wolfgang, I was wondering if I can use FLTK as GUI backend for Grapefruit? This should be possible in principal. It just could be that my assumptions about how widgets are created and composed were too tight so that Grapefruit’s general interface doesn’t fit FLTK. In this case, please just tell me and I will try to make the interface more general. Ok, great I ll have to use them then I will see and know what improvement is needed. I believe for this to make it happen, I would have to output FLTK's C++ into C then create bindings for Haskell (via FFI). Is that doable or an quite tall order? Recently, a student of mine has written a program which generates a Haskell Qt binding fully automatically from Qt header files. The generated binding consists of three layers. The first layer is C++ code which reexports Qt’s functionality as a pure C interface. The C interface is ugly for humans and not type safe (because C doesn’t know classes). The second layer consists of a couple of FFI declarations. The third layer is Haskell code which provides a nice interface similar to the original C++ interface. I still have to get the source code of the binding generator from that student but I hope this will happen soon. I want to publish it then on the web. It hope that it is possible to reuse this binding generator for other C++ libraries. That would be very helpful, I ll be looking forward. Hello Jamie, it’s been quite some time that we had this discussion about writing a FLTK-based GUI backend for Grapefruit. I’m sorry that I have to tell you that the above-mentioned student never managed to send me a final version of this Qt binding generator. At least, I was able to make him send me the current state of his code. I don’t think he will improve this code anymore. If you want to have a look at the code, please visit http://haskell.org/haskellwiki/HQK and follow the link to the code and have a look at the building tips. In case you would like to improve the binding generator, I’d be happy to receive patches. :-) Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Hello Jeff, it’s been some time that we had the conversation below and I have to tell you the same thing I told Jamie in a haskell-cafe mail sent a few minutes ago: The student who wrote the Qt binding generator never managed to send me a final version of his code. At least, I was able to make him send me the current state. I don’t think he will improve this code anymore. If you want to have a look at the code, please visit http://haskell.org/haskellwiki/HQK and follow the link to the code and have a look at the building tips. In case you would like to improve the binding generator, I’d be happy to receive patches. :-) Sorry for these bad news. Best wishes, Wolfgang Am Mittwoch, 18. Februar 2009 15:42 schrieb Jeff Heard: When he gives you the code, could you let me know? I would really love to bind Open Scene Graph, but it's entirely C++ and that makes for a lot more difficult coding to say the least. On Wed, Feb 18, 2009 at 4:17 AM, Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: Am Dienstag, 17. Februar 2009 19:36 schrieben Sie: If you have problems with Gtk2Hs on Windows, it might be better to write a Win32-based backend for Grapefruit instead of a wxWidgets-based one. What do you think about that? Win32-based backend would make more sense as it is one less layer to deal with. But how? Same thing with Mac. A student of mine wrote a fully automatic binding generator for C++ libraries which also supports Qt extensions (signals and slots). (However, this guy still has to give me the code. :-/ ) One could do a similar thing for generating Win32 and Cocoa bindings. Then one could write Grapefruit UI backends based on these bindings. Best wishes, Wolfgang ___ 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: Proposal: Deprecate ExistentialQuantification
Am Samstag, 27. Juni 2009 12:44 schrieb Niklas Broberg: Hi all, Following the discussion on the use of 'forall' and extensions that use it [1], I would hereby like to propose that the ExistentialQuantification extension is deprecated. My rationale is as follows. With the introduction of GADTs, we now have two ways to write datatype declarations, the old simple way and the GADTs way. Isn’t ExistentialQuantification more powerful than using GADTs for emulating existential quantification? To my knowledge, it is possible to use lazy patterns with existential types but not with GADTs. Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Alternative IO
Am Donnerstag, 9. Juli 2009 15:27 schrieb Cristiano Paris:
As a joke, I wrote an instance of Alternative for IO actions:
{-# LANGUAGE ScopedTypeVariables #-}
module Main where
import Control.Applicative
import Control.Exception
instance Alternative IO where
empty = undefined
x | y = handle (\ (_ :: SomeException) - y) x
This would allow to write IO code which failsafes to a value if the
previous computation failed, i.e.:
*Main Control.Applicative undefined | print Hello
Hello
*Main Control.Applicative print Hello | undefined
Hello
It seems a neat way to catch exception in some scenarios. What do you
think? Why is not Alternative IO defined in Control.Applicative?
Thanks,
Cristiano
Hello Cristiano,
I fear that this instance doesn’t satisfy required laws. As far as I know, the
following equalities should hold:
(*) = ()
f * empty = empty
empty | g = g
This implies the following:
(f empty) | g = g
But this wouldn’t hold with your instance. (f empty) | g would cause the
side effects of f and of g, while g would (obviously) only cause the side
effects of g.
If empty would be a real empty, it would have to undo the effects of previous
actions (like f above). So an Applicative instance makes sense for STM but
not for IO.
Best wishes,
Wolfgang
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK
Am Freitag, 10. Juli 2009 05:26 schrieb rocon...@theorem.ca: I find it amazing that you independently chose to spell colour with a `u'. It makes me feel better about my choice. I have to admit that it makes me unhappy. :-( Why do we use English for identifiers? Because English is the language of computer science. What English should we use? It’s tempting to say, we should use the original English, which is British English. But we should ask again what is the language of computer science. And the language of computer science is American English. To my knowledge, most early developments in computer science had their roots in the US. One consequence of this is that reserved words of programming languages are typically in American English. PASCAL uses “program”, not “programme”, and BASIC uses “COLOR”, not “COLOUR”. So, in my opinion, Haskell color packages should use the identifier Color, not Colour. By the way, I also write my papers and documentation in American English. Best wishes, Wolfgang (who is neither British nor American) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: Top Level
Am Freitag, 19. Juni 2009 21:35 schrieb Ian Lynagh: So, I'd be fine with Control.Reactive.FRP, Control.Reactive.Yampa, etc, or even just Reactive.Yampa etc. Where should the modules of Conal’s reactive package be rooted then? Under Control.Reactive.Reactive? I don't know anything about the package, but if putting the modules directly under Control.Reactive wouldn't make sense then it sounds to me like the package name is poor (too generic). reactive is a specific FRP implementation by Conal Elliott. So it shouldn’t be put directly under Control.Reactive since other reasonable FRP implementations exist. Best wishes, Wolfgang ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Creating a new Haskell mailing list
Am Donnerstag, 18. Juni 2009 16:21 schrieb Henning Thielemann: Ryan Trinkle schrieb: Hi all, I'm interested in starting a mailing list on haskell.org http://haskell.org. Who should I talk to about such things? Is it a mailing list related to a project? Then you may request a project on community.haskell.org, then you can start a mailing list at yourproj...@project.haskell.org See http://community.haskell.org/. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: Top Level
Am Mittwoch, 17. Juni 2009 11:05 schrieb Malcolm Wallace: The problem with a top-level namespace like FRP is that it is a cryptic acronym: it means nothing to a novice, and may be easily confused with other acronyms by an expert. I believe top-level names should _at_the_ _very_least_ be minimally descriptive of the category of things that live in it. So, I'd be fine with Control.Reactive.FRP, Control.Reactive.Yampa, etc, or even just Reactive.Yampa etc. Where should the modules of Conal’s reactive package be rooted then? Under Control.Reactive.Reactive? Best wishes, Wolfgang ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Top Level
Am Mittwoch, 17. Juni 2009 11:29 schrieb Anton van Straaten: Malcolm Wallace wrote: The problem with a top-level namespace like FRP is that it is a cryptic acronym: it means nothing to a novice, and may be easily confused with other acronyms by an expert. I believe top-level names should _at_the_ _very_least_ be minimally descriptive of the category of things that live in it. So, I'd be fine with Control.Reactive.FRP, Control.Reactive.Yampa, etc, or even just Reactive.Yampa etc. Besides, it hardly seems necessary to emphasize Functional and Programming in the Haskell context... When we discussed where to place modules of FRP libraries in the hierarchy, it was argued that FRP had become a “brand”. It’s not just about programming reactive systems but describes a certain basic approach to it. Best wishes, Wolfgang ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [grapefruit] can't run Grapefruit
Am Samstag, 23. Mai 2009 21:58 schrieb Dean Herington: I'm trying to give Grapefruit a try. I installed it as described in section 4.1 of http://www.haskell.org/haskellwiki/Grapefruit. When I tried to run the Simple.hs example, I got the problem shown below. Any ideas? My machine is running Windows XP Pro 2002 SP3. TIA Dean Hello Dean, were you able to solve this problem meanwhile? Since this seems to be a Gtk2Hs problem and I don’t use Windows, I probably cannot be of much help. :-( Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] ANNOUNCE: OpenGLRaw 1.0.0.0
Am Freitag, 12. Juni 2009 11:24 schrieb Sven Panne: A few final remarks: Leaving out Graphics. completely would be a very bad idea, the naming hierarchy should reflect the underlying conceptual hierarchy. The only problem with hierarchies in general is that sometimes the position in it is not very clear. I have e.g. never fully understood why Monad and Applicative are below Control, but Foldable is below Data... This is a reason for me thinking that the naming hierarchy should not reflect the underlying conceptual hierarchy (completely). I’d like to propose a more flat structure. The Yampa people and I (the Grapefruit maintainer) already agreed to introduce a top-level FRP namespace instead of putting FRP under Control or whatever. Graphics.UI is a bad choice in my opinion, since not all user interfaces are graphical (ncurses) and for those who are, it’s not so important anymore that they are (it was important in the 1980ies). So it might be good to change Graphics.UI to just UI. Then we might want to change Graphics.Rendering to just Graphics. What do others think? Best wishes, Wolfgang ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] GUIs, FRP, (Delimited) Continuations and Zippers
Am Samstag, 16. Mai 2009 16:18 schrieb Günther Schmidt: Hi all, In my app, there is one part which has a rather complicated GUI logic, it involves n drop downs with n choices each. Whenever the current selection in one of the drop downs changes by user interaction, the other (n-1) drop downs need to be notified and their item list need to possible change too. Now I have managed to code all this and it actually behaves correctly. But I'm also using tons of IORefs and tons of bookkeeping code for it. While I'd not be ashamed to show any other part of my code to another Haskeller, this part of the code is the most clumsiest I've ever written. And I have no clue if that piece of code *can* be written in any other way, ie. without the tons of IORefs and bookkeeping. The GUI library is WXHaskell. In the last few days I read up on Conal Elliotts FRP stuff (reactive) but also on Olegs ZFS (Zippers, Delimited Continuations), the latter leaving me totally baffled. Could either of those approaches (FRP / Delimited Continuations) be a solution for implementing complex GUI code? Günther Hello Günther, FRP can definitely help you a lot for these kinds of problems. You have n widgets where each widget outputs a discrete signal (event (stream)) of requests from the user. These are transformed and combined to form signals (behaviors) that describe the contents of the n widgets over time. Have you looked at Grapefruit? It’s an FRP library, I’m developing, which already has integrated GUI support. If you want to try it out, better take the darcs version instead of the released version since there have been some important developments since the release date. You find Grapefruit’s homepage here: http://haskell.org/haskellwiki/Grapefruit. If you have questions, please ask. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [darcs-users] [Haskell-cafe] Darcs as undo/redo system?
Am Mittwoch, 13. Mai 2009 02:55 schrieb Trent W. Buck: Wolfgang Jeltsch g9ks1...@acme.softbase.org writes: Am Freitag, 8. Mai 2009 18:43 schrieb Jason Dagit: If you wanted to work on this, I would encourage you to read more about patch theory[1,2,3,4] and also try out libdarcs[5]. Is libdarcs the same as the darcs library package on Hackage (which exports the darcs API)? The Darcs package (both on Hackage and elsewhere) builds two things: the darcs(1) binary, and libHSdarcs. The latter is what Jason was referring to. Note that currently it just exposes all our internal functions, rather than providing a coherent (or stable!) API. I know. My students, who worked on a darcs GUI frontend, already experienced this. ;-) Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Removing mtl from the Haskell Platform
Am Mittwoch, 13. Mai 2009 01:03 schrieb rocon...@theorem.ca: I wanted to pass this idea around the cafe to get some thoughts before submitting a trac on this topic. I'd like to see the mtl removed from the Haskell Platform. The mtl was a tremendous step forward when it was developed. However, we have learned a few things about monad transformers since the development of the mtl, and it is time that we moved forward. There are at least 3 significant problem with the mtl. 1) `pass' should not be a member functions of the MonadWriter class. It is my understanding that there is no `MonadWriter w m = MonadWriter w (ContT s m)' instance because the `pass' function cannot be implemented. I'm also highly suspicious of some other methods too (I'm looking at you `local'). 2) The `StateT s (Cont r a)' instance of callCC is wrong. The paper on modular monad transformers http://www.cs.nott.ac.uk/~mjj/pubs/mmt/mmt.pdf describes why this is wrong. 3) I am told by many people that the order of the state and value pair in `State' is backwards. Actually, I'm not entirely sure what the issue is here, but I trust the people who say this. 4) The identifiers State and StateT are flawed. Something of value State s a doesn’t denote a state but a state transformer or however you want to name it. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [darcs-users] [Haskell-cafe] Darcs as undo/redo system?
Am Freitag, 8. Mai 2009 18:43 schrieb Jason Dagit: If you wanted to work on this, I would encourage you to read more about patch theory[1,2,3,4] and also try out libdarcs[5]. Is libdarcs the same as the darcs library package on Hackage (which exports the darcs API)? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] commending Design concepts in programming languages
Am Freitag, 8. Mai 2009 14:31 schrieb Daniel Fischer: Though I had no contact with algebraists in the 1980s, I also hadn’t. However, nowadays I have contact with someone who was an algebraist in the 1980s. It’s my boss (professor), by the way. :-) I think, also category theorists often wrote (write?) composition with the first morphism on the left, i.e., “the other way round”. Yeah, I heard that, too. It's a field where the advantages of postfix notation show clearly and a young one, so for them it was relatively easy to switch. However, I fear that all those other mathematicians who define f . g = \x - f(g(x), have made the category theorists switch to this suboptimal notation (first morphism on the right). At least, I cannot remember seeing the other notation (first morphism on the left) in category theory literature so far. It’s just that my above-mentioned professor told me that category theorists would use the first-morphism-on-the-left notation. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] commending Design concepts in programming languages
Am Donnerstag, 7. Mai 2009 14:42 schrieb Daniel Fischer: Of course, if centuries ago people had decided to write the argument before the function, composition would've been defined the other way round. They haven't. Algebraists used to write x f instead of f(x) at least in the 1980s. I think, also category theorists often wrote (write?) composition with the first morphism on the left, i.e., “the other way round”. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interesting Thread on OO Usefulness (scala mailing list)
Am Dienstag, 5. Mai 2009 18:39 schrieb Bulat Ziganshin: Hello Wolfgang, Tuesday, May 5, 2009, 8:27:17 PM, you wrote: i know two problems in Haskell/GHC that require OO-loke features - extensible exceptions and GUI widget types hierarchy Note that you don’t need different types for different kinds of GUI widgets if you use Functional Reactive Programming (FRP). You need different types if you use OO because you have to explicitely modify widgets after you have created them, and what modifications you are allowed to do, depends on the kind of widget. With FRP, you specify the behavior over all time when you create the widget, so no need for later method calls. (i don't know anything about FRP) i think it doesn't change anything. the main reason why i need common operations is because i write generic procedures. another erason os what i can't remember 100 individual 'setSize' operations for 100 types of widgets. so we need to have some generic names, short of they are used due initialization or later Yes, you need generic names also with FRP. The difference is that with OO, every property (e.g., size) corresponds to a pair of methods (setSize, getSize) while in FRP every property correspond to an input (or a parameter of the constructor if you think in OO terms). So with FRP, you need some kind of record system, preferably with the possibility to extend records. At least, this is the solution I use in Grapefruit. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
