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
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
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: 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
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
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: 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
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: [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: length of module name affecting performance??
Am Montag, 29. Dezember 2008 12:54 schrieb Simon Peyton-Jones: What a great bug -- I would never have predicted it, but in retrospect it makes perfect sense. Record selectors had better get fixed. Can I read somewhere about what caused this bug? What is its trac URL? Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Type families: module export of instance data constructor
Am Montag, 15. Dezember 2008 02:17 schrieb Ben Horsfall: I have a type family class Lang term where data Token term :: * with instance Lang Term where newtype Token Term = T String I can't work out how to export the type constructor T from the module, unless I make no explict exports from the module at all. Ben Hello Ben, try Lang (type Token) in the export list. Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: More detail on breakage with ghc-6.10
Am Samstag, 11. Oktober 2008 09:36 schrieb Duncan Coutts: All, We've been using the cabal-install build reporting stuff to get more detailed info on build failures with ghc-6.10 vs 6.8. cabal-install generates these build-reports.log files and individual log files for each build. build-reports.log informs me that configure failed for the lax package with both GHC 6.8 and GHC 6.10. However, lax used to build fine on my machine with GHC 6.8. So I looked at logs/lax-0.0.0.1.log but this file is empty. Why? Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
could not find link destinations
Hello, I built GHC 6.10.0.20080927 on Debian GNU/Linux for i386. At the end of the build process I got numerous warnings of the form “could not find link destinations for: […]”. Is this intensional? Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GADTs and functional dependencies
Am Dienstag, 23. September 2008 19:07 schrieben Sie:
{-# LANGUAGE GADTs, MultiParamTypeClasses, FunctionalDependencies #-}
data GADT a where
GADT :: GADT ()
class Class a b | a - b
instance Class () ()
fun :: (Class a b) = GADT a - b
fun GADT = ()
I’d expect this to work but unfortunately, using GHC 6.8.2, it fails with
the
following message:
FDGADT.hs:12:11:
Couldn't match expected type `b' against inferred type `()'
`b' is a rigid type variable bound by
the type signature for `fun' at FDGADT.hs:11:16
In the expression: ()
In the definition of `fun': fun GADT = ()
What’s the reason for this? Is there a workaround? Does this work in
6.8.3 or 6.10.1?
This similar code using type families compiles in 6.8.3 and 6.9:
data GADT a where
GADT :: GADT ()
type family F a
type instance F () = ()
fun :: GADT a - F a
fun GADT = ()
Exactly. But this makes my code incompatible with GHC 6.6. :-(
I thought, someone said that with the new typing machinery in GHC 6.10, more
functional dependency programs are accepted because functional dependencies
are handled similarly to type families (or something like that). Is this
true? Since the type family version is okay, why shouldn’t the functional
dependency version be okay?
Best wishes,
Wolfgang
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GADTs and functional dependencies
Am Mittwoch, 24. September 2008 15:11 schrieb Ian Lynagh: On Wed, Sep 24, 2008 at 12:55:29PM +0200, Wolfgang Jeltsch wrote: I thought, someone said that with the new typing machinery in GHC 6.10, more functional dependency programs are accepted because functional dependencies are handled similarly to type families (or something like that). Is this true? Since the type family version is okay, why shouldn’t the functional dependency version be okay? In http://hackage.haskell.org/trac/ghc/ticket/345 Simon says: Ultimately, I think we can implement fundeps using type families, and then the fundep version will work too. Until then, it'll only work in type-family form. Thanks Ian And further: So, since we now have a good workaround (well, actually, a better way to write the program rather than a workaround), I'll leave it open, but at low priority and with milestone bottom. So for now the answer is: Use type families and thereby drop 6.6 compatibility? Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GADTs and functional dependencies
Hello Simon, thank you for your extensive answer! I think, I’ll try to work around the fundep deficiencies and if that doesn’t work, switch to type families. But your answer raised further questions/comments: class (F a ~ b) = C a b type family F a (Note for 6.10 users: type equalities in superclasses is the piece we still have not implemented.) Do you mean type equalities like the one in the example above? Didn’t this already work in 6.8.2? Almost all fundep programs can be translated in this way. (Maybe all, I'm not 100% certain.) Not all, I’m afraid. There was a mailing list discussion between us several months ago where we talked about this. The translation from fundeps to type families doesn’t work as soon as overlapping instances are involved. The type equality check from HList is an example for this. You told me that such a check can be implemented with type families as soon as we have closed TFs: type family TypeEq t1 t2 :: * where TypeEq t t = True TypeEq t1 t2 = False Greetings to Victoria! (from Cottbus) Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Debian stable not supported?
Am Montag, 22. September 2008 08:52 schrieb Yitzchak Gale: […] Unfortunately, the so-called generic Linux binary distribution package for GHC 6.8.3 does not work on the current, up-to-date Debian stable distribution because it is too old. GHC 6.8.2 worked for me (on i386). […] Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GADTs and functional dependencies
Am Dienstag, 23. September 2008 18:19 schrieben Sie:
On Tue, Sep 23, 2008 at 6:07 PM, Wolfgang Jeltsch
[EMAIL PROTECTED] wrote:
Hello,
please consider the following code:
{-# LANGUAGE GADTs, MultiParamTypeClasses, FunctionalDependencies #-}
data GADT a where
GADT :: GADT ()
class Class a b | a - b
instance Class () ()
fun :: (Class a b) = GADT a - b
fun GADT = ()
I'd expect this to work but unfortunately, using GHC 6.8.2, it fails with
the following message:
bear in mind that the only instance you defined is
instance Class () ()
which doesn't involve your GADT at all.
This is correct. (It’s only a trimmed-down example, after all.)
Maybe you meant something like:
instance Class (GADT a) ()
No, I didn’t.
Moreover, your fun cannot typecheck, regardless of using MPTC or
GADTs. The unit constructor, (), has type () and not b.
Pattern matching against the data constructor GADT specializes a to (). Since
Class uses a functional dependency, it is clear that b has to be (). So it
should typecheck. At least, I want it to. ;-)
Best wishes,
Wolfgang
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Is FPH implemented in GHC?
Am Donnerstag, 11. September 2008 00:09 schrieben Sie: If an FRP library provides first-class signals then often the problem arises that these are actually signal generators—their behavior might depend on the time they are started. To get rid of this deficiency, my signal types now have an additional type argument which denotes the starting time. This way, I’m able to fix the starting time using the type system. The idea is similar to the usage of the “state” type argument of ST. Dependencies on an absolute clock always caused trouble in Fran/FRP programming and were one of the things I tried to get rid of in my FunWorlds experiments (sigh, way too long ago..). Hmm, maybe you misunderstood. The extra type argument cannot be instantiated to the current time since that would need dependent types or something similar. Actually, we never instantiate this argument but only force it to be independent to other such time arguments via forall, and force it to be equal to other such time arguments by using the same type variable multiple times in the same type. So the whole thing is only about whether something happens at the same time or not. It’s really similar to the first ST type argument without using RealWorld. You never instantiate it, you just put constraints on it in the form that it has to be equal to some other such argument. Thinking of behaviours as functions from *all* times to values is an unimplementable theoretical ideal and completely at odds with FRP's more practical ideal of compositional programming (leading to the less sung about arts of actual programming in FRP, aging behaviours, start times, etc.). At least, I try to help the FRP programmer to get aging etc. right by using the time argument trick to make wrong signal use result in a type error. In Grapefruit, a signal is a function from a time *interval* to values where the time interval is denoted by this type argument. […] Many of the FunWorlds aspects would need revision, if I ever get round to that.. but dropping absolute time was the right thing to do (as if physics hadn't told us about that anyway;-). In Grapefruit, you could implement a continous signal which represents an absolute clock. This is because you can make a continuous signal out of any continuous source that can be asked to tell its current value by means of an I/O action. But absolute time isn’t fundamental to Grapefruit. You could think of some totally ordered set representing time and continuous signals being functions from this set to values. But you can only access continuous signals by sampling them using a discrete signal. So you can only get the value of a continous signal at those times where some event occurs. You have the advantage that you can abstract from sampling rates and similar stuff by composing continuous signals. But at some point you have to sample explicitely. Claus Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GADT pattern match in non-rigid context
Hello, I have some code giving me the error message: “GADT pattern match in non-rigid context for … Tell GHC HQ if you'd like this to unify the context”. I reduced my code to the following example which still gives this error message: data T a b where C :: T a [b] f :: (forall a'. T a' b) - T a b f t = case t of C - C How do I work around this error? Some former e-mail discussion gave the hint of adding a type signature but this probably doesn’t work in my case. Note also that specializing the type of the argument t to T a b inside the definition of f is not an option since in the real code I need the first argument of T to be universally quantified for calling another function which needs this quantification. I use GHC 6.8.2. Don’t know whether this problem still shows up with GHC HEAD but am interested in hearing whether this is the case. I’m thankful for any 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-cafe] Re: a help for install
Am Dienstag, 19. Februar 2008 11:36 schrieb Wolfgang Jeltsch: Am Montag, 18. Februar 2008 19:46 schrieb Carlos Gomez A.: hi, my name is carlos I need information for correct installor what are dependencies on ghc ? I have a Debian System. Always use your distribution’s packages until they aren’t any or there is good reason not to do so. Try “aptitude install ghc6”. Best wishes, Wolfgang Sorry, this should go to [EMAIL PROTECTED] :-( 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] Re: a help for install
Am Dienstag, 19. Februar 2008 12:03 schrieb Wolfgang Jeltsch: Am Dienstag, 19. Februar 2008 11:36 schrieb Wolfgang Jeltsch: Am Montag, 18. Februar 2008 19:46 schrieb Carlos Gomez A.: hi, my name is carlos I need information for correct installor what are dependencies on ghc ? I have a Debian System. Always use your distribution’s packages until they aren’t any or there is good reason not to do so. Try “aptitude install ghc6”. Best wishes, Wolfgang Sorry, this should go to [EMAIL PROTECTED] :-( Best wishes, Wolfgang Sorry, this has gone to haskell-cafe but should not go to this list. :-( But the original message should, of course: Always use your distribution’s packages until they aren’t any or there is good reason not to do so. Try “aptitude install ghc6”. That’s all I wanted to say. :-) Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Will implicit parameters survive?
Hello, what are the plans for implicit parameters? Will GHC continue to support them or could it be that they will be removed at some time? I think that implicit parameters can be very useful for implementing global variables as described in http://www.cs.chalmers.se/~rjmh/Globals.ps. Surprisingly, the interest in implicit parameters seems to be rather low as the GHC survey from 2005 suggests. Despite this, I’d propose that support for implicit parameters continues. But what do the GHC developers think? Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: A suggestion for GHC download pages
Am Montag, 28. Januar 2008 18:52 schrieb Albert Y. C. Lai: On GHC version-specific download pages (e.g., http://www.haskell.org/ghc/download_ghc_682.html), under Source Distribution, it would reduce a major confusion of the form I built GHC from source, now I use it, it says Network.CGI not found if after the filename ghc-6.8.2-src.tar.bz2 it is also said compiler and almost no libraries, and after the filename ghc-6.8.2-src-extralibs.tar.bz2 it is also said most libraries, but it takes hours to build, Hackage has them piecemeal and more. Perhaps it would also be nice to say how to use the latter, e.g., unpack this over the compiler source before building, before even building the compiler. Does it need to be said? Seems to be yes according my experience in #haskell. Here is how it can be misunderstood. Given the word extralibs and the file sizes, and no other words, what would an outsider think? Between the disproportionate 7MB and 2MB, 7MB must be because all the popular libraries are there, 2MB must be because extralibs means fringe, niche libraries. There lies the misunderstanding. Isn't it already said in the build guide? Yes it is, but the path between the download page and the build guide is not obvious. There is mention of the build guide, but it is put under the precondition if your platform is not supported. IMO there should be no precondition; absolutely everyone building from source should be tempted to see the build guide. Perhaps the source section should also be close to the bottom of the download page, not to the top, reflecting what we recommend for most people. While the situation might be improvable, I want to add that I had no big problems building GHC because, as far as I remember, the README and INSTALL files told me the meaning of extralibs etc. Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Maps, was Re: GHC source code improvement ideas
Am Sonntag, 6. Januar 2008 13:37 schrieb Adrian Hey: It's the GT class here.. Short remark: Wouldn’t a longer, more descriptive identifier be better? Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: whole program optimization
Am Sonntag, 23. Dezember 2007 13:35 schrieb Isaac Dupree: GHC optimizes less effectively when parts of a program are in different modules, or are exported from a module. By the way, does GHC do cross-package optimization (not just cross-module optimization within packages)? […] Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Type Relations
Am Montag, 17. Dezember 2007 20:32 schrieb Paulo J. Matos: Hello all, I've came across a problem which would be best implemented if I could define what I think to be a Type Relation. Let's consider classes as being type properties. When you say: class Num a where (+) :: a - a - a ... it defines a property of the type a. Basically all types a of class Num are addable, etc.. However, how can I (if I can) represent the fact that you can coerce a type a to a type b? A particular example of that is the fromInteger function from Num class where you say that if your type a is of class Num, you must be able to coerce an Int to a. I would like to define a relation between types and then say that two types are in the relation if they define the coerce function. Something I imagine would be: typerelation Coercible a b where coerce :: a - b And then you would define instances of Coercible if you could define the function coerce between the types. You could then define function only over types which can be coerced from one to the other. Any suggestions on how to do something like this? Isn’t this what multi-parameter type classes are about? By the way, such questions are better asked on the Haskell Mailing List or the Haskell Café Mailing List. This list is more about using GHC, not so much about topics related to the language Haskell as such. Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: C Preprocessor
Am Donnerstag, 6. Dezember 2007 10:43 schrieb Bernd Brassel: Is it already a known problem that the preprocessor cannot cope with the whole set of possible string declarations? Yes, it is. There is cpphs (http://www.cs.york.ac.uk/fp/cpphs/) as an alternative. […] Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: About -Wall option
Am Mittwoch, 5. Dezember 2007 13:43 schrieb Luis Cabellos: Hi, I have a question, what's the best way to program? - put all the signatures in the Haskell Code? - Only put the type signatures needed to compile (like monomorphism errors or ambiguous signature)? Until now, I prefer the second one, but when I use the -Wall option, there's a lot of complains about type signature. Maybe the type signature is something that not need to be checked as a warning. But if the best practice is to put all the signatures, I found that Cabal generated code need to be fixed, because -Wall complains about it also. Inserting all type signatures is definitely best practice. Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: type equality symbol
Am Mittwoch, 5. Dezember 2007 17:05 schrieb Simon Peyton-Jones: […] Anyway, while on this subject, I am considering making the following change: make all operator symbols into type constructors (currently they are type variables) This would be highly problematic! Concerning syntax, everything that holds for values should also hold for types. For values, identifiers starting with a capital letter and operators starting with a colon denote “constants”, everything else denotes variables. Exactly the same should hold for types since otherwise we would get a very confusing result. So we should keep things as they are concerning type constructors and type variables. And we should think about type functions being denoted by lower case identifiers and operators not starting with a colon because they are similar to non-constructor functions on the value level. We should strive for a systematic language and therefore not make ad-hoc decisions which for the moment seem to serve a purpose in some specific cases. […] Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Haddocumentation of 6.8.1
Am Montag, 3. Dezember 2007 13:38 schrieben Sie: […] I just thought it would be nice to have all installed libraries together because that would facilitate deciding whether I use something from the containers package, or the collections package or edison. Do you mean you want a combined contents page and a combined index? Then have a look at libraries/gen_contents_index in the GHC 6.8.1 source tarball. You might want to reuse this script. […] Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Haddocumentation of 6.8.1
Am Freitag, 30. November 2007 15:23 schrieb Daniel Fischer: Question 2: When I build a package via Cabal, is there a way to merge the documentation into the installed library docs (and if yes, how do I do it)? I think, if you do runhaskell Setup.[l]hs haddock before runhaskell Setup.[l]hs install then the latter installs the Haddock-generated API documentation and this documentation will be linked to by future Haddock-generated documentations when using Cabel to make them. Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: suggestion: add a .ehs file type
Am Dienstag, 27. November 2007 19:21 schrieb Alex Jacobson: Simon, I think we've been trying to be too clever... The simple question is: for a given extension, what is the risk of leaving it turned on by default? The risk is that one thinks that one’s program is Haskell-98-compliant while it isn’t. Or that it is compatible with another compiler while it isn’t. […] Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: suggestion: add a .ehs file type
Am Mittwoch, 21. November 2007 19:38 schrieb Alex Jacobson: Isn't use of the extensions detectable by the compiler? So you want extension inference. ;-) […] In any case, I'm pretty sure the correct answer is not 50 language pragmas with arbitrary spellings for various language features at the top of each source file. You can put them into a Cabal file. -Alex- Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: suggestion: add a .ehs file type
Am Donnerstag, 22. November 2007 02:07 schrieb Alex Jacobson: Duncan Coutts wrote: On Wed, 2007-11-21 at 19:26 -0500, Alex Jacobson wrote: Ok, I'm game to default to haskell98 in the presence of ambiguity, but in most cases the extension involves new syntax and that should be enough. In these cases ghc does generally give an error message which mentions which extension it is that you should use. This is actually better than the case where you forget to import something when ghc doesn't helpfully tell you which module you forgot to import. My point is that the default should be to give a warning rather than an error and provide the user with the ability to turn those warnings off. As others have said, one major reason for declaring extensions is for portability. The warning should be enough information for people who want to avoid accidentally adding features that will cause their code not to run on other compilers. For those that don't care, forcing them to add zillions of pragmas is an excessive burden. -Alex- Dont’t just think in terms of single modules. If I have a Cabal package, I can declare used extensions in the Cabal file. A user can decide not to start building at all if he/she sees that the package uses an extension unsupported by the compiler. Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: suggestion: add a .ehs file type
Am Dienstag, 20. November 2007 22:35 schrieb Alex Jacobson:
[…]
{-# LANGUAGE TemplateHaskell, FlexibleInstances,
OverlappingInstances, UndecidableInstances, CPP,
ScopedTypeVariables, PatternSignatures, GADTs,
PolymorphicComponents, FlexibleContexts,
MultiParamTypeClasses, DeriveDataTypeable,
PatternGuards #-}
FYI, I grabbed the above from a source file that had been upgraded to
6.8 in which I kept adding pragmas until it compiled. Forcing the user
to do this sort of thing manually every time they write code is
ridiculous.
It made me discover that I use more language extensions than I thought I was
using.
I think, it’s a good thing if you have to be clear about what extensions you
use and what you don’t use. What if someone wants to compile your code with
a different compiler which doesn’t support all of GHC’s extensions?
Taken to its logical conclusion, why don't we also add RecordSyntax
and DoSyntax etc.
Because they are part of the standard. If Haskell' will be released at some
point in the future, we won’t have to include MultiParamTypeClasses,
Concurrency, etc. into our LANGUAGE pragmas.
The compiler obviously knows which extensions are actually being used
when the user uses them.
I don’t think so. For example, if you don’t use rank-2 polymorphism and
similar things, forall is a perfect name for a type variable.
[…]
-Alex-
Best wishes,
Wolfgang
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: if-them_else
Am Mittwoch, 21. November 2007 15:03 schrieb Serge D. Mechveliani: Dear GHC developers, when compiling the function f x = if x them False else True ghc-8.8.1 reports:parse error on input `else' . When there is a large expession after `them', it is sometimes difficult to locate a typo. Why does not it report parsing if-then-else: cannot find `then' ? Regards, them is a perfect identifier. So probably x them False gets parsed as an expression (x applied to them and the result applied to False). Haskell’s lightweight syntax makes programs short and easy to read (in my opinion) but it often makes the compiler unable to guess where your mistake lies. Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
single-stepping and infinite recursion
Hello, please consider the following program: main = putChar 'A' main I load this into GHCi, enter :step main, followed by :step and a second :step. Although I would expect to get the As in the output step by step, GHCi now hangs inside the infinite loop. Is this intentional? To me, this seems rather weird. I wanted to use GHCi’s debugger to find the reason for an infinite recursion but from my experience it looks as if this might not be possible. :-( Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: suggestion: add a .ehs file type
Am Dienstag, 20. November 2007 22:15 schrieb Alex Jacobson: .ehs stands for extended haskell and encapsulates the 90% case of people just wanting -fglasgow-exts with a minimum of fuss. Having a filetype seesm better than the alternatives of either adding boilerplate language/options pragmas to the top of your source files or putting them in a cabal file. -Alex- And if a new Haskell standard is released, we have to rename lots of files from *.ehs to *.hs. :-( Extended Haskell is Haskell in a different version. So it’s still Haskell and should be put into *.hs files. Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.8.1 is impressive!
Am Freitag, 9. November 2007 08:24 schrieb Lennart Augustsson: I'd like to second that. 6.8 is quite an improvement. Well done! -- Lennart So those language shootouts should be updated to use GHC 6.8.1 for their benchmarks. Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: type families not advertised for 6.8
Am Freitag, 19. Oktober 2007 11:32 schrieben Sie: […] | In fact, after thinking and experimenting I came to the conclusion that | it’s probably just not possible to define a type function TypeEqTF t1 t2 | which for *all* types t1 and t2 yields True or False, depending on | whether t1 and t2 are equal or not. That's a nice crisp example. It's a pure function, at the level of types, so you'd think it should be definable. And I don't think there is any reason we couldn't do so (in due course). For example, overlap is fine, so long as when we *use* an equation there is only one that applies, so that there is a unique answer. But the problem in the HList example is that two equations apply where the most specific one should be taken. […] (Oh, it's just possible that HList might be architected differently if type functions were available.) Yes, but as soon as you start to implement records where field names are types, you have to have a compile-time type equality check since you need it for lookup and for making sure that the same field name doesn’t occur twice in one record. So even if HList would be architectured rather differently, it would probably still need an equality test. Simon Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Default name of target executable
Am Montag, 10. Oktober 2005 08:38 schrieb Tomasz Zielonka: On 10/10/05, Ketil Malde [EMAIL PROTECTED] wrote: Tomasz Zielonka [EMAIL PROTECTED] writes: Because of this long syntax and comand-line completion I've even once lost the source code. I forgot to remove the .hs at the end of line: $ ghc --make Prog -o Prog.hs If you want, I can tell you about this great version control system I'm using :-) It was before I acquired the habit to put even the smallest programs in darcs. And even if I did use darcs - I usually at least try to compile the new code before recording it. Anyway, this is not the biggest reason for my request. What bothers me more is typing the redundant command over and over again. Why don't you use a small shell script for this? Best regards Tomasz Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Default name of target executable
Am Montag, 10. Oktober 2005 11:55 schrieb Niklas Broberg: [...] Using a shell script is a possible work-around, but certainly not *the* solution. If there is no real reason for ghc to spit out a.out files, then surely choosing the exe name from the main input file would simplify a programmer's life. And for applications that desperately want a.out, well, there's still the -o flag, right? Maybe the makers of GHC wanted GHC to be GCC compatible. [...] Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
unsafePerformIO and optimizations
Hello, http://haskell.org/ghc/docs/latest/html/libraries/base/ System.IO.Unsafe.html#v%3AunsafePerformIO talks about what optimizations you should disable if you apply unsafePerformIO to an action which contains side effects. These are: * inlining of functions which call unsafePerformIO * common subexpression elimination (on the module which contains the unsafePerformIO application, if I understand correctly) * let-floating Alas, the documentation is very terse, in my opinion, and I don't understand these things fully. First, what is the problem with inlining a function call? Say, I have a function f defined as follows: f :: Char - () f c = unsafePerformIO (putChar c) If inlining is allowed, the expression f '*' becomes unsafePerformIO (putChar '*'). Is this a problem? Or is inlining dangerous in other situations? On the other hand, I can see that inlining non-functions could cause harm. Say I have something like this: u :: () u = unsafePerformIO (putChar '*') Now, inlining u would transform (u,u) to (unsafePerformIO (putChar '*),unsafePerformIO (putChar '*')) which could result in putChar '*' being executed multiple times. So why does the library documentation only talk about disabling inlining of functions? I understand that common subexpression elimination could cause harm. It could transform the expression (unsafePerformIO (putChar '*),unsafePerformIO (putChar '*')) to let u = unsafePerformIO (putChar '*') in (u,u), couldn't it? This would result in the I/O action be performed at most once which is not what was intended. But couldn't the same thing also happen if I use the expression (f '*',f '*'), probably in a different module? Does this mean that I have to use -fno-cse not only in the module which contains the unsafePerformIO application but also in every other module which uses unsafePerformIO indirectly via f or functions using f? Does let-floating only have to be disabled in the module which uses unsafePerformIO? Say, I have f defined as above and have the following definition in a module different from the one f is defined in: g :: Int - () g n = f '*' Couldn't it be that the asterisk is output only once instead of every time, g is called? I would be thankful for any help. Best regards, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: switching off let-floating
Am Mittwoch, 27. Juli 2005 21:39 schrieben Sie: Wolfgang Jeltsch [EMAIL PROTECTED] writes: But how do I switch off let-floating? -fno-full-laziness, I believe. I just tried using this flag. Result: GHC 6.2.2 doesn't recognize it. :-( --sigbjorn Regards, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: switching off let-floating
Am Donnerstag, 28. Juli 2005 16:42 schrieb Peter Simons: Wolfgang Jeltsch writes: where is this switch documented? http://haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html #id3128647 Peter Thank you. Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC 6.4 Debian packages (was: Re: switching off let-floating)
Am Donnerstag, 28. Juli 2005 16:45 schrieben Sie: On Thu, 28 Jul 2005, Wolfgang Jeltsch wrote: (snip) Related question: Can anybody tell me when there will be Debian packages of GHC 6.4 available? See http://packages.debian.org/unstable/devel/ghc6 -- Mark Okay, I wasn't precise enough. What I'm looking for are GHC 6.4 packages for Debian stable. Alas, the GHC website as well as Haskell Experimental or whatever it is called now don't have a respective backport. Regards, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
more on GHC 6.4 Debian packages (was: Re: switching off let-floating)
Am Donnerstag, 28. Juli 2005 16:58 schrieb Ian Lynagh: On Thu, Jul 28, 2005 at 04:37:40PM +0200, Wolfgang Jeltsch wrote: Related question: Can anybody tell me when there will be Debian packages of GHC 6.4 available? There are 6.4 packages in unstable. They aren't installable in unstable, but I think they should be installable on a stable system. The unstable packages aren't installable on unstable but on stable? That's cool. :-) I will try to install them on stable. Shortly after 6.4.1 is released ghc6 should be installable in unstable again. Are backports for stable planned for GHC 6.4.1? Thanks Ian Best regards, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
private modules
Hello, I thought, I heard something about a private modules feature in GHC. Was I just dreaming or is there in fact something like this. I cannot find information about such a thing. Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
option for enabling generalized deriving for newtypes
Hello, isn't there an option for enabling just generalized deriving for newtypes without enabling all this other stuff by using -fglasgow-exts? Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
specifying the name of the executable under Windows
Hi, if I enter ghc -o foo foo.hs under Windows, is the resulting executable named foo or foo.exe? (Please send replies not only to the list as I'm not subscribed to it.) Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Please mail every answer also to wolfgang@jeltsch.net.] No hierarchical module names with GHC 5?
Hello, I use GHC 5.00.2 on Solaris 2.6 at the university and am unable to use hierarchical module names --- with and without the -fglasgow-exts switch. GHCi notifies me of parse errors on the module name. What is interesting is that if my module with hierarchical name imports a module which cannot be found GHC tells me that it cannot find the latter module instead of first recognizing that the name of the former module is in its opinion illegal and complaining about this. Aren't hierarchical module names supported yet in GHC 5.00.2? At home with GHC 5.02 under Linux everything works fine. By the way, I couldn't find anything about hierarchical module names in the documentation. Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
