Re: Pattern synonym 'Required' constraints === Datatype Contexts(?)
The required context on pattern synonyms isn't just useful, it's
necessary. Since arbitrary computation can happen in both the pattern
matching and construction we need the context.
Take Richard's example, without the context on Positive we would infer the
wrong type for any use of the Positive synonym.
On Thu, Mar 11, 2021 at 7:09 AM Richard Eisenberg wrote:
> You're right that these features sit in a similar space. The difference is
> that, with a pattern synonym, the required context might be useful. This is
> because pattern synonyms can perform computation (via view patterns), and
> this computation might plausibly require some class constraint. An easy
> example:
>
> pattern Positive :: (Ord a, Num a) => a
> pattern Positive <- ((>0) -> True)
>
>
> Here, the required context is helpful. On the other hand, because matching
> against a data constructor never does computation, the constraints are
> never useful in this way.
>
> Richard
>
> On Mar 9, 2021, at 7:02 PM, Anthony Clayden
> wrote:
>
> I must be slow on the uptake. I've just grokked this equivalence -- or is
> it? Consider
>
> >data Eq a => Set a = NilSet | ConsSet a (Set a) -- from the
> Language report
> >
> >-- ConsSet :: forall a. Eq a => a -> Set a => Set a -- inferred/per
> report
> >
> >-- equiv with Pattern syn 'Required' constraint
> >data Set' a = NilSet' | ConsSet' a (Set' a) -- no DT context
> >
> >pattern ConsSetP :: (Eq a) => () => a -> (Set' a) -> (Set' a)
> >pattern ConsSetP x xs = ConsSet' x xs
> >
> >ffP ((ConsSet x xs), (ConsSetP y ys)) = (x, y)
> >
> >-- ffP :: forall {a} {b}. (Eq a, Eq b) => (Set a, Set' b) -> (a, b)
> -- inferred
>
> The signature decl for `ConsSetP` explicitly gives both the Required `(Eq
> a) =>` and Provided `() =>` constraints, but the Provided could be omitted,
> because it's empty. I get the same signature for both `ConsSetP` as
> `ConsSet` with the DT Context. Or is there some subtle difference?
>
> This typing effect is what got DT Contexts called 'stupid theta' and
> deprecated/removed from the language standard. ("widely considered a
> mis-feature", as GHC is keen to tell me.) If there's no difference, why
> re-introduce the feature for Patterns? That is, why go to the bother of the
> double-context business, which looks weird, and behaves counter to usual
> signatures:
>
> >foo :: (Eq a) => (Show a) => a -> a
> >-- foo :: forall {a}. (Eq a, Show a) => a -> a -- inferred
>
> There is a slight difference possible with Pattern synonyms, compare:
>
> >pattern NilSetP :: (Eq a) => () => (Set' a)
> >pattern NilSetP = NilSet'
> >
> >-- NilSetP :: forall {a}. Eq a => Set' a -- inferred
> >-- NilSet :: forall {a}. => Set a --
> inferred/per report
>
> Using `NilSetP` somewhere needs giving an explicit signature/otherwise
> your types are ambiguous; but arguably that's a better discipline than
> using `NilSet` and allowing a Set with non-comparable element types.
>
> AntC
> ___
> 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
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Two Proposals
For instance, at your day job, the Array type. On Wed, Oct 5, 2011 at 12:23 PM, Roman Leshchinskiy r...@cse.unsw.edu.auwrote: Simon Peyton-Jones wrote: I'm not sure if this plan would support [(fred,45), (bill,22)] :: Map String Int. Probably not. Maybe that's a shortcoming... but such Maps are a rather surprising use of list literals. What data structures other than lists do we want to construct using list literals? I'm not really sure what the use cases are. Roman ___ 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: Two Proposals
What are the defaulting rules for IsList? It needs to be backwards compatible. -- Lennart (iPhone) On Sep 30, 2011, at 19:28, George Giorgidze giorgi...@gmail.com wrote: GHC Users, I would like to make to the following two proposals: * Eliminate the default grouping close from SQL-like comprehensions * Introduce a GHC extension for list literal overloading OK, let me start with the first proposal. Currently, the SQL-like comprehension notation (both in its list comprehension and monad comprehension variants) features the following five clauses: then f then f by e then group by e then group using f then group by e using f The first two clauses are used for specifying transformations of type [a] - [a] (or Monad m = m a- m a for monad comprehensions). The following three clauses are used for specifying transformations of type [a] - [[a]] (or Monad m, Functor f = m a - m (f a) for monad comprehensions). See [1] for further details. Note that the third clause does not mention which function is used for grouping. In this case GHC.Exts.groupWith function is used as a default for list comprehensions and the mgroupWith function from the MonadGroup class is used as a default for monad comprehensions. I would like to suggest to remove the third clause for the following reasons: * Currently the syntax is asymmetrical. Note that there is the default case for the 'then group' clause and not for the 'then' clause. * In the current notation it is not clear which grouping function is used in the default case * For many monads including lists it is not clear which function should be selected as a default (e.g., the groupWith function also does sorting and it is not clear to me why this should be the default) * Gets rid of the MonadGroup class. Currently the sole purpose of this class is to introduce a default grouping function for monad comprehensions. * Explicit mention of the grouping function would make monad/list comprehensions much easier to read by making it immediately apparent which function is used for grouping. My second proposal is to introduce the OverloadedLists extension that overloads list literals. See Section 5.2 in [1] for details. 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 In the following I give useful instances of the IsList class. instance IsList [a] where type Item [a] = a fromList = id instance (Ord a) = IsList (Set a) where type Item (Set a) = a fromList = Set.fromList instance (Ord k) = IsList (Map k v) where type Item (Map k v) = (k,v) fromList = Map.fromList instance IsList (IntMap v) where type Item (IntMap v) = (Int,v) fromList = IntMap.fromList instance IsList Text where type Item Text = Char fromList = Text.pack As you can see the extension would allow list literals to be used for sets, maps and integer maps. In addition the suggested OverloadedLists extension would subsume OverloadedStrings extension (see the instance for Text, for example). Having said that, for now, I am not suggesting to remove the OverloadedStrings extension as it appears to be widely used. This extension could also be used for giving data-parallel array literals instead of the special syntax used currently. Unless there is a vocal opposition to the aforementioned two proposals, I would like to implement them in GHC. Both changes appear to be straightforward to implement. Thanks in advance for your feedback. Cheers, George [1] http://www-db.informatik.uni-tuebingen.de/files/giorgidze/haskell2011.pdf ___ 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: Can't find interface-file declaration for type constructor or class integer-gmp:GHC.Integer.Type.Integer
Also beware that Typeable uses the original names of types, which means that moving basic types around totally wrecks backwards compatibility for those of us who use the type name for serialization etc. -- Lennart (iPhone) On Aug 19, 2011, at 11:00, Johan Tibell johan.tib...@gmail.com wrote: These two parallel discussions are getting a bit confusing so I suggest we continue the discussion on the ticket. :) On Fri, Aug 19, 2011 at 12:39 AM, Simon Peyton-Jones simo...@microsoft.com wrote: It's hard to know what Ian had in mind, but I'm sure he'll tell us when he gets back from holiday. Meanwhile, yes, it is hard to reconcile * The wish to have multiple implementations of Integer * The wired-in knowledge that GHC has * The desire to have optimising rewrite rules in client libraries I suggested one approach in the ticket earlier today; there might be others. It might be good to figure out a good design before going much further into implementation. Simon | -Original Message- | From: Johan Tibell [mailto:johan.tib...@gmail.com] | Sent: 18 August 2011 18:14 | To: Simon Peyton-Jones | Cc: glasgow-haskell-users | Subject: Re: Can't find interface-file declaration for type constructor or class | integer-gmp:GHC.Integer.Type.Integer | | On Thu, Aug 18, 2011 at 7:07 PM, Simon Peyton-Jones | simo...@microsoft.com wrote: | | I shouldn't have to modify PrelNames since I kept GHC.Integer.Type, | | no? Or does PrelNames have to contain the name of the module that | | originally defined the type? | | Yes, exactly! | | This causes some trouble though, as the module named in PrelNames must | exist in both in integer-gmp and integer-simple i.e. it must be some | generic name like GHC.Integer.Type rather than a name containing e.g. | GMP. I could keep the data type definition where it is | (GHC.Integer.Type) but then I would have a hard time exporting it from | e.g. GHC.Integer.GMP.Internals without undoing Ian's patch which | removed the slightly odd GHC.Integer - GHC.Integer.GMP.Internals - | GHC.Integer.Type module dependency in integer-gmp. ___ 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: How to develop on a (GHC) branch with darcs
Like everyone else I have no good solution. When I had a ghc branch I used diff and patch to move my patches forward. Not exactly what you expect to have to do with a version control system. On Mon, Dec 6, 2010 at 1:57 AM, Iavor Diatchki iavor.diatc...@gmail.com wrote: Hello, I am doing some work on a GHC branch and I am having a lot of troubles (and spending a lot of time) trying to keep my branch up to date with HEAD, so I would be very grateful for any suggestions by fellow developers of how I might improve the process. Here is what I have tried so far: First Attempt ~ My branch, called 'ghc-tn', was an ordinary darcs repo. I recorded my changes as needed, and every now and then would pull from the HEAD repo. If conflicts occurred, I would resolve them and record a patch. Very quickly I run into what, apparently, is a well-known darcs problem where trying to pull from HEAD would not terminate in a reasonable amount of time. Second Attempt ~~ Avoid conflict patches by constantly changing my patches. This is how I've been doing this: Initial state: ghc: a repository with an up-to-date version of GHC head ghc-tn: my feature repo based on a slightly out-of-date GHC HEAD. Goal: Merge ghc-tn with ghc (i.e., integrate developments in GHC HEAD into my branch) Process: 1. Create a temporary repository for the merge: darcs clone --lazy ghc ghc-tn-merge 2. Create a backup of the feature branch (strictly speaking not necessary but past experience shows that it is a good idea to have one of those). darcs clone --lazy ghc-tn ghc-tn-backup 3. Pull features patches from 'ghc-tn' into 'ghc-tn-merge', one at a time. darcs pull ghc-tn y d 3.1. If a feature patch causes a conflict, then resolve the conflict and create a new patch, obliterating the old one: darcs amend-record (creates a new patch, not a conflict patch, I think) After repeating this for all branch patches, I have an updated branch in 'ghc-tn-merge' with two caveats: 1. The new repository does not contain my previous build so I have to re-build the entire GHC and libraries from scratch. This is a problem because GHC is a large project and rebuilding everything takes a while, even on a pretty fast machine. I work around this problem like this: 1.1 Obliterate all branch patches from 'ghc-tn'. This, essentially, rewinds the repository to the last point when I synchronised with HEAD. To do this properly I need to know which patches belong to my branch, and which ones are from GHC. (I've been a bit sloppy about this--- I just use the e-mails of the branch developers to identify these and then look at the patches. A better way would be to have some kind of naming convention which marks all branch patches). 1.2 Pull from 'ghc-tn-merge' into 'ghc-tn'. By construction we know that this will succeed and reintroduce the feature changes, together with any new updates to GHC into 'ghc-tn'. Now 'ghc-tn-merge' and 'ghc-tn-backup' can be deleted. 2. The new repository contains rewritten versions of the branch patches so---if I understand correctly---it is not compatible with the old one (i.e., I cannot just push from my newly updated branch to the public repo for my branch as there will be confusion between the old feature patches and the new ones). I can think of only one solution to this problem, and it is not great: 2.1 Delete the original public repo, and publish the new updated repo, preferably with a new name. In this way, other developers who have the old patches can either just clone the new repo, or go through steps 1.1--1.2 but will not accidentally get in a confused state by mixing up the new feature patches with the old ones. For background, my solution is essentially a manual implementation of what is done by git's rebase command---except that there branch patches and various repository states are automatically managed by the system so there is no need to follow various naming conventions which tend to be error prone. Apologies for the longish e-mail but this seems like an important problem and I am hoping that there's a better way to do things. -Iavor ___ 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: Modules and their explicit export lists (are an annoyance)
Encapsulation is essential for constructing robust software. How could we get rid of that and claim to have a serious language? On Sat, Jun 19, 2010 at 8:38 PM, Christian Höner zu Siederdissen choe...@tbi.univie.ac.at wrote: Hi everybody, I'd like some input on other peoples' thoughts on this. Recently, I played around with a library that uses an explicit export list. While there are reasons for having one: - efficiencey (inlining in the module) - encapsulation in practice, it seems to me that they are more annoying than useful. For once, it would think that ghc should produce efficient good across modules with -O / -O2 anyway. But the more important thing is, that it makes extending module functionality a pain (eg. if a constructor is not exported using (..)). So, should I really fork a library just to be able to add a function? Btw. there are libraries, where an explicit export list is used, that export the right amount of information. For example, in 'vector' enough is exported to allow you to extend unboxed vectors. ___ 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: Plans for GHC 6.12.2
Thanks! On Sat, Mar 27, 2010 at 11:59 PM, Ian Lynagh ig...@earth.li wrote: On Thu, Mar 25, 2010 at 10:14:34PM +, Lennart Augustsson wrote: #3904 should also be really easy to fix. Yup, done. Thanks Ian ___ 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: Plans for GHC 6.12.2
I would really like to see #3900 in there. On trac it's slated for the 6.12.2 release, but I don't see it in your list. #3904 should also be really easy to fix. On Tue, Mar 23, 2010 at 6:38 PM, Ian Lynagh ig...@earth.li wrote: Hi all, This is a summary of our plans for GHC 6.12.2. We plan to put out a release candidate 6.12.2-rc1 shortly and, assuming there are no serious regressions found, 6.12.2 will follow soon after. The bugs that we're planning to fix for 6.12.2 are the high priority tickets in the 6.12.2 milestone: http://hackage.haskell.org/trac/ghc/query?status=newstatus=assignedstatus=reopenedpriority=highestpriority=highmilestone=6.12.2order=priority If there is a bug not in that list that is important to you, please let us know. Thanks Ian ___ 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: Shared GHC libraries and the runtime system
The usual way to do this would be to include the dependency on the RTS in the library and then vary the RTS by using LD_PRELOAD. I think ghc does it the wrong way. -- Lennart On Mon, Feb 22, 2010 at 10:00 PM, Max Bolingbroke batterseapo...@hotmail.com wrote: Hi Tyson, This blog post (http://blog.well-typed.com/2009/05/buildings-plugins-as-haskell-shared-libs/) might help explain the motivation (actually there are a few relevant posts on the well-typed site). Essentially, I believe that this is done so that you can vary the RTS by changing LD_LIBRARY_PATH. I've never used this facility so I'm unable to say how useful this actually is (or if it actually works at the moment). Cheers, Max On 22 February 2010 21:34, Tyson Whitehead twhiteh...@gmail.com wrote: I was working on a shared library that loads up the GHC runtime (via hs_init) and have been running into a bunch of undefined stg symbols. A bit of digging and it seems that GHC doesn't embed - the dependency libHSrts-ghc6.12.1.so, and - the associated rpath /usr/lib/ghc-6.12.1 into shared libraries that it builds. Thus, if your main executable isn't GHC generated (and hence has these), you run into unresolved symbols. I can work around this by manually adding them myself. Is there any reason GHC can't put this information by default into shared libraries though? Thanks! -Tyson PS: Further digging into the various shared libraries packaged with GHC (Debian GHC package 6.12.1-2) reveal that they are actually missing - the dependency libHSrts-ghc6.12.1.so, and - all rpaths (i.e., there are absolutely no rpaths in any of them) $ objdump -p /usr/lib/ghc-6.12.1/base-4.2.0.0/libHSbase-4.2.0.0-ghc6.12.1.so ... Dynamic Section: NEEDED libHSinteger-gmp-0.2.0.0-ghc6.12.1.so NEEDED libgmp.so.3 NEEDED libHSghc-prim-0.2.0.0-ghc6.12.1.so NEEDED libc.so.6 SONAME libHSbase-4.2.0.0-ghc6.12.1.so ... ___ 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: [Haskell-cafe] generalize RecordPuns and RecordWildCards to work with qualified names?
At a minimum I think the error message should be better.
I also think it would be natural to use the DisambiguateRecordFields
for the places where RecordWildcards are used.
I mean, if I change from unqualified import to a qualified one, and
then change all visible names to be qualified I would expect things to
still work.
For RecordPuns I don't have an opinion on what to do.
-- Lennart
On Sun, Aug 9, 2009 at 9:42 PM, Simon Peyton-Jonessimo...@microsoft.com wrote:
Oh, now I get it, thanks. This message concerns design choices for
record-syntax-related GHC extensions. Lennart, pls tune in. You don’t need
to have read the thread to understand this message.
| I think that Even refers to an example like this:
|
| module A where
| data A = A { a :: Int }
|
| The following works:
|
| {-# LANGUAGE NamedFieldPuns #-}
| module B where
| import A
| f (A { a }) = a
|
| However, if we import A qualified, then punning does not seem to work:
|
| {-# LANGUAGE NamedFieldPuns #-}
| module B where
| import qualified A
| f (A.A { a }) = a
|
| This results in: Not in scope: `a'
Right. What is happening is that GHC looks up the first 'a' (the one on the
LHS) and finds it not in scope. If you add -XDisambiguateRecordFields, it
works fine. But admittedly, the error message is unhelpful. I could improve
that.
Now on to the suggested change:
| {-# LANGUAGE NamedFieldPuns #-}
| module B where
| import qualified A
|
| f (A.A { A.a }) = a
|
| This results in: Qualified variable in pattern: A.a
|
| Even is suggesting that instead of reporting an error, in the second
| case we could use the translation:
|
| f (A.A { A.a }) = a -- f (A.A { A.a = a })
|
| (i.e., when punning occurs with a qualified name, use just the
| unqualified part of the name in the pattern)
Yes, that'd be possible. But it seems debatable -- it doesn't *look* as if
the pattern (A.A { A.a }) binds 'a' -- and it seems even less desirable in
record construction and update. To be concrete, would you expect these to
work too?
g a = A.A { A.a } -- g a = A.A { A.a = a }
h x a = x { A.a } -- h x a = a { A.a = a }
In these cases, I think the abbreviated code looks too confusing.
With -XDisambiguateRecordFields you could say
g a = A.A { a }
which seems better. (But there's no help for record update, since we don’t
know which data constructor is involved.)
So my current conclusion is: improve the error message, perhaps suggesting
the flag -XDismabiguateRecordFields, but don't add the change you suggest.
Comments?
Simon
___
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: mtl and network packages in GHC 6.10.3.*
6.10.4 is a bug fix release. A bug fix release cannot remove packages no matter what state the platform is in, that's just seriously broken. On Wed, May 27, 2009 at 7:44 AM, Don Stewart d...@galois.com wrote: Not part of the core libs, so these are slowly disappearing from the extralibs bundled shipped with GHC (in favour of the platform bundle). The 6.10.3 windows installer is due out June 1. -- Don ndmitchell: Hi, I just downloaded the Windows snapshot of 6.10.3.20090526, and found that mtl and network don't seem to be included. $ ghc-pkg list c:/ghc/ghc-6.10.3.20090526\package.conf: Cabal-1.6.0.1, Cabal-1.6.0.3, Win32-2.2.0.0, array-0.2.0.0, base-3.0.3.1, base-4.1.0.0, bytestring-0.9.1.4, containers-0.2.0.1, directory-1.0.0.3, extensible-exceptions-0.1.1.0, filepath-1.1.0.2, (ghc-6.10.3.20090526), ghc-prim-0.1.0.0, haddock-2.4.2, haskell98-1.0.1.0, hpc-0.5.0.3, integer-0.1.0.1, old-locale-1.0.0.1, old-time-1.0.0.2, packedstring-0.1.0.1, pretty-1.0.1.0, process-1.0.1.1, random-1.0.0.1, rts-1.0, syb-0.1.0.1, template-haskell-2.3.0.1, time-1.1.2.4 In addition, I can't install network under Cygwin, Mingw, or the Windows command line. Here are the errors from Cygwin: Preprocessing library network-2.2.1.2... In file included from Network\BSD.hsc:17: include/HsNet.h:78:22: sys/uio.h: No such file or directory include/HsNet.h:81:25: sys/socket.h: No such file or directory include/HsNet.h:84:26: netinet/tcp.h: No such file or directory include/HsNet.h:87:25: netinet/in.h: No such file or directory include/HsNet.h:90:21: sys/un.h: No such file or directory include/HsNet.h:93:24: arpa/inet.h: No such file or directory include/HsNet.h:96:19: netdb.h: No such file or directory In file included from Network\BSD.hsc:17: include/HsNet.h:138: error: syntax error before addr include/HsNet.h: In function `my_inet_ntoa': include/HsNet.h:146: error: storage size of 'a' isn't known include/HsNet.h:147: error: `addr' undeclared (first use in this function) include/HsNet.h:147: error: (Each undeclared identifier is reported only once include/HsNet.h:147: error: for each function it appears in.) include/HsNet.h:148: warning: return makes pointer from integer without a cast Network\BSD.hsc: In function `main': Network\BSD.hsc:145: error: invalid application of `sizeof' to incomplete type ` servent' And Mingw: * Missing header file: HsNet.h This problem can usually be solved by installing the system package that provides this library (you may need the -dev version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. cabal.exe: Error: some packages failed to install: network-2.2.1.2 failed during the configure step. The exception was: exit: ExitFailure 1 And Windows command line: Resolving dependencies... Configuring network-2.2.1.2... cabal: Error: some packages failed to install: network-2.2.1.2 failed during the configure step. The exception was: sh: runProcess: does not exist (No such file or directory) Was removal of these packages on the stable branch was an oversight? Could network at the very least be reinstated soon? I'd love to report back whether the GHC 6.10.4 fixes work or not in practice. Thanks Neil ___ 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: Should exhaustiveness testing be on by default?
Excellent, is there a -fuse-catch flag for ghc? :) On Tue, May 19, 2009 at 12:01 PM, Neil Mitchell ndmitch...@gmail.com wrote: ... exhaustive pattern checking might well help out a lot of people coming from untyped backgrounds... Or even people from typed backgrounds. I worship at the altar of exhaustiveness checking. Do you really want exhaustiveness, or is what you actually want safety? With -fwarn-incomplete-patterns: test1 = head [] test2 = x where (x:xs) = [] test3 = (\(x:xs) - 1) [] test4 = f [] where f [] = 1 GHC reports that test4 has incomplete patterns, but the others don't. However, test4 is safe, but the others aren't. Exhaustiveness is a poor approximation of safety. GHC's exhaustiveness checker is a poor approximation of exhaustiveness. 2 is a poor approximation of pi :-) Using Catch, it reports that test1..3 were faulty, but test4 is safe. Thanks Neil ___ 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: Should exhaustiveness testing be on by default?
The exhaustiveness checker in ghc is not good. It reports non-exhaustive matching a bit too often and also the error messages are often not in terms of the original source but some desugared version. If those things were improved I think it should be always on. On Mon, May 18, 2009 at 12:53 AM, Don Stewart d...@galois.com wrote: I'm not sure I'd want -Wall on by default (though being -Wall clean is very good). But exhaustive pattern checking might well help out a lot of people coming from untyped backgrounds. http://ocaml.janestreet.com/?q=node/64 Ron's also wondering why exhaustive pattern checking isn't on ? Anyone know why it isn't the default? -- Don ___ 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: [Haskell] deriving Show for GADT?
If it's easy I think just generating the code and let the type checker report any problems would be a great thing for standalone deriving. -- Lennart On Tue, Apr 14, 2009 at 10:10 AM, Simon Peyton-Jones simo...@microsoft.com wrote: Yes, indeed, see http://hackage.haskell.org/trac/ghc/ticket/3012 Incidentally, the main Haskell list isn't the right place for GHC-specific questions. glasgow-haskell-us...@haskell.org is the place Simon | -Original Message- | From: haskell-boun...@haskell.org [mailto:haskell-boun...@haskell.org] On Behalf Of | Norman Ramsey | Sent: 14 April 2009 05:28 | To: hask...@haskell.org | Subject: [Haskell] deriving Show for GADT? | | I've got a fairly large GADT for which I wished to use | deriving (Show) | but I got a mysterious error message: | | Exp.hs:13:11: | Can't make a derived instance of `Show (Exp a)' | (`Exp' has non-Haskell-98 constructor(s)) | In the data type declaration for `Exp' | | | This is from GHC. Does anybody know a compiler option or other trick | that will coax the compiler into producing a Show instance. | (I know I can write one by hand, but I'd rather not bother.) | | | Norman | ___ | Haskell mailing list | hask...@haskell.org | http://www.haskell.org/mailman/listinfo/haskell ___ 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: [Haskell] Re: ANNOUNCE: GHC version 6.10.2
And to make many, many peoples life easier the binaries could have been included in ghc 6.10.2 (but I know there are some philosophical reasons against it). -- Lennart On Sun, Apr 5, 2009 at 5:48 PM, Don Stewart d...@galois.com wrote: daniel.is.fischer: Am Sonntag 05 April 2009 10:24:25 schrieb Ashley Yakeley: Duncan Coutts wrote: In the mean time you can just: $ cabal install time Where do I get the cabal command? I'm installing GHC on a new machine and I was hoping it would be included. I can't obtain it via cabal install cabal-install because I don't have the cabal command and I don't know how to tie the knot in this case. Download the cabal-install .tar.gz from Hackage, unpack it. There's a script bootstrap.sh in the directory, run that, it wgets zlib and HTTP and installs them, after that, it installs cabal-install and you're ready to go. If you're on windows, there's a cabal binary installer somewhere (should be findable from the cabal homepage, I believe). ___ There are binaries of the 'cabal' command on many distros too. -- Don ___ 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: compilation of pattern-matching?
I find this reordering discussion somewhat nonsensical. Haskell specifies top-to-botton, left-to-right matching. This specifies exactly which tests that have to be made and in what order, and ghc does exactly those and in the correct order. One can have a perception that when there are multiple arms in a case decided by a single test, then the first arm should somehow be reached quicker than the second one etc But that is something that the Haskell standard has never promised, nor has any compiler ever promised this. And to me such a perception is counter-intuitive; Haskell is about specifying functions abstractly so order should only matter when it's a matter of semantics. On the other hand, adding some kind of pragma that indicates the likelyhood of a branch seems quite sensible to me. -- Lennart On Thu, Mar 26, 2009 at 9:09 AM, Simon Marlow marlo...@gmail.com wrote: Claus Reinke wrote: Strange. I don't think it is my idea (older implementations used to work that way, and iirc, it also matches what Prolog systems used to do), and I didn't think it was anything but straightforward to avoid case transformations unless there is a clear benefit, so I doubt there is a useful paper in there (also, I can't afford to plan that far ahead atm). What is the benefit of changing the ordering (not just joining paths to avoid redundant tests, but actually modifying the order of tests, to sort by their order in the data type declaration)? Is there any documentation of these case transformations that I could look up? It's not that GHC deliberately re-orders case alternatives, it's that it doesn't deliberately not do it. That's quite an important difference. To check whether case alternatives ever get reordered, we'd have to look at the whole compiler. It's a new constraint on which transformations are valid, and global constraints should not be added lightly. I some kind of annotation is a much more promising avenue to explore. Cheers, Simon ___ 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: compilation of pattern-matching?
Sorting by constructor tag is perfectly safe when done right. You can read about how to do it in my 1985 FPCA paper or in Simon's book. When pattern matching against against things that that are not constructors (like literals etc) it's much trickier to reorder them since you have to prove harder pattern commutation properties. I don't think there is any controversy at all about Haskell pattern matching semantics. As you say, it's pretty clearly spelled out. (It wouldn't hurt to have it written down as a denotational semantics, though.) And ghc happens to have a bug. -- Lennart On Fri, Mar 27, 2009 at 12:10 AM, Claus Reinke claus.rei...@talk21.com wrote: So a first comment on this. I spoke too soon, ghc clearly has a bug here. It shouldn't reorder those matches against literals like that. I suggest you report that bug, because, as you say, it violates the H98 report. It would be nice if we could first reach a common understanding, so that I can actually report the right problem, not just isolated symptoms. But I don't think that bug at all affects the function you had in your original email. The argument goes like this: - Haskell does prescribe the order in which patterns are matched - Haskell does permit alternative implementations if they respect certain equations; in other words, there is a proof obligation associated with things like reordering patterns - for types like 'data AB = A | B', we know that a successful match for 'A' implies a failing match for 'B', and vice-versa - disregarding performance (which the language definition does not talk about), we therefore know that in 'case e of A-a;B-b', we don't need to match for both 'A' and 'B'; instead, we can either match for 'A' and enter 'a' on success and 'b' on failure, or match for 'B' and enter 'b' on success and 'a' on failure - another view of this is that 'not isB' is actually the same as 'isA', so we're matching for both in one test - so, if we want to, we can fulfill the proof obligation involved with reordering the patterns, or we can argue that by matching for 'B', we are actually matching for 'A' as well So far, we have: - pattern order does matter, by language definition - GHC can nevertheless reorder patterns where it can prove that this isn't observable You are right that this doesn't help my performance argument, as performance issues are outside the language definition (not observable in the language definition sense). It was merely an answer to the vehement claims that pattern order is irrelevant. And it has practical implications, too: the proof obligations are getting harder to fulfill as pattern-match expressiveness improves. For Haskell'98, we can't reorder: guards, overlapping patterns, numeric literals, (others?). For GHC Haskell, we also can't reorder: view patterns, string literals (IsString/fromString), quasiquotes?, .. . And the list keeps growing, as DSL authors want IsBool/fromBool, container-library authors want IsList/fromList, etc. In other words, this |It's not that GHC deliberately re-orders case alternatives, |it's that it doesn't deliberately not do it. no longer is a safe default strategy (actually, it never was, as the bug shows;-). Neither is sorting patterns by constructor tag, as seems to happen on the way to Core. GHC needs to consider every individual case before being lax about pattern order, and the result of that consideration might change over time: in Haskell'98, []/: patterns can be reordered for [a], in GHC Haskell, []/:. patterns can be reordered for [a], as long as a/=Char, in GHC Haskell with an IsList class, []/: patterns can not be reordered in general. This is independent of performance considerations, just a consequence of the language definition, and our abilities to observe deviations from the prescribed sequential order. Claus ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: compilation of pattern-matching?
You could imagine a pragma to say which branch is likely.
f p1 = e1
f p2 = {-# LIKELY #-} e2
f p3 = e3
Is there some way to propagate pragmas through core transformations?
-- Lennart
On Wed, Mar 25, 2009 at 9:18 AM, Simon Peyton-Jones
simo...@microsoft.com wrote:
Indeed GHC does not attempt to retain the order of alternatives, although
a) it might be possible to do so by paying more attention in numerous places
b) GHC may do so already, by accident, in certain cases
Observations:
* The issue at stake is a small one: not the *number of tests* but *which
tests branch, and which fall through*.
* Simply ordering the equations doesn't really work, because pattern-match
compilation will match an entire column at once:
f (x:xs) True = ...
f [] True = ...
f [] False = ...
f (x:xs) False = ...
Which order should the (:)/[] test go in?
* Not only does GHC currently not attempt to retain order, but for a
particular order it makes no guarantees about which falls through. For
example, given
case ... of { A - e1; C - e2; B - e3 }
We might test for A and then
either fall though to e1
or fall through to the test for C
* When the number of constructors is larger, instead of a linear sequence of
tests, GHC may generate a table-jump; or a balanced tree of tests.
* Which plan performs best is tremendously architecture dependent, and may
well vary a lot between different chips implementing the same instruction
set. It's a losing battle to fix the strategy in source code.
* More promising might be to say this is the hot branch. That information
about frequency could in principle be used by the back end to generate better
code. However, I am unsure how
a) to express this info in source code
b) retain it throughout optimisation
Claus, if you think this thread is worth capturing, then do write a
Commentary page, and I'll check its veracity.
Thanks
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Claus Reinke
| Sent: 23 March 2009 23:17
| To: glasgow-haskell-users@haskell.org
| Subject: compilation of pattern-matching?
|
| I just noticed that GHC (6.11.20090320) seems to compile both
|
| f (a:b:c) =
| f (a:[]) =
| f [] =
|
| and
|
| f [] =
| f (a:[]) =
| f (a:b:c) =
|
| to something like (looking at Core, but writing source)
|
| f x = case x of { [] - ..; (a:t) - case t of { [] -..; (b:c) -..}}
|
| That doesn't seem right to me: if I try to give the patterns in
| the order from frequent to rare, in order to reduce jumps, I
| don't expect GHC to rearrange things. What is the rationale
| for this? And where can I read about GHC's pattern match
| compilation approach in general?
|
| Claus
|
| ___
| 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: compilation of pattern-matching?
When you tried switching Nil and Cons, did you try it on many examples?
For a single example a 2-3% could be easily attributed to random
effects like different instruction cache hit patterns. If you get it
consistently over several programs then it seems likely to mean
something, but I'm not sure what.
On Wed, Mar 25, 2009 at 6:01 PM, Claus Reinke claus.rei...@talk21.com wrote:
Indeed GHC does not attempt to retain the order of alternatives, although
a) it might be possible to do so by paying more attention in numerous
places
b) GHC may do so already, by accident, in certain cases
That adds even more unpredictability. One thing that I don't want whenever I
have to care about performance is small changes
having odd/unexplainable effects (I vaguely recall a case where removing an
unused parameter from a recursion made the program
slower, or eliminating returned constructors by using continuations
made one inner-loop function faster, another slower..).
Lennart is of course right: even if GHC would respect the ordering indicated
in my source program, I might not be able to tune that source to make good
use of even a single target processor (I tried defining a foldl over a
user-defined List type, so that I could switch
the order of Nil/Cons, and hence the test order used by GHC, and found the
Nil-before-Cons order to be 2-3% faster for folding a
very long list than the Cons-before-Nil order I wanted), but it is very
frustrating if I'm not even given the chance because GHC
sorts the alternatives, not even according to its own interpretation
of branching performance, but completely arbitrarily!-)
* The issue at stake is a small one: not the *number of tests* but *which
tests branch, and which fall through*.
Right on the issue, but I'm not quite sure how small it is: the test
case source I attached a few messages ago consistently showed one ordering
to be 5% faster than the other for the extreme case
of one test nearly always failing. There may well be more profitable
optimizations remaining to be implemented first - what disturbs me is that
Haskell code is full of conditionals and matches, which I tend to arrange
according to expected frequency, and GHC simply ignores all those hints.
With the hint about branch prediction, I also found this old ticket (which
seems to have been waiting for the new backend, and
indicates rather larger performance differences):
Offer control over branch prediction
http://hackage.haskell.org/trac/ghc/ticket/849
* Simply ordering the equations doesn't really work, because pattern-match
compilation will match an entire column at once:
f (x:xs) True = ...
f [] True = ...
f [] False = ...
f (x:xs) False = ...
Which order should the (:)/[] test go in?
In the order indicated in the source!? The usual pattern-match
optimizations should not change that, they will just skip the two
'[]' cases if the list isn't empty, or use the constructor tag to jump
directly to a sub-column. Haskell specifies left-to-right, top-down.
* Not only does GHC currently not attempt to retain order, but for a
particular order it makes no guarantees about which falls through. For
example, given
case ... of { A - e1; C - e2; B - e3 }
We might test for A and then
either fall though to e1
or fall through to the test for C
That is the part I missed, and which might give the UNLIKELY
pragma, as suggested in #849, more expressive power than
plain clause ordering. However, since Haskell specifies a match
order, I don't see why that couldn't be used as the basis for
mapping to branches as well, with the clauses listed in decreasing
likelyhood, and GHC generating the branch predictions and fallthroughs to
match this information to the target processor characteristics?
* When the number of constructors is larger, instead of a linear sequence
of tests, GHC may generate a table-jump; or a balanced tree of tests.
The table-jump would make all alternatives equally costly/fast,
with no penalty for adding infrequent alternatives, right? The
balanced tree sounds like one of the pattern-match state machines, and there
would still be room for representing expected frequency in terms of
tree-path/-rotation/-representation.
* Which plan performs best is tremendously architecture dependent, and may
well vary a lot between different chips implementing the same instruction
set. It's a losing battle to fix the strategy in source code.
* More promising might be to say this is the hot branch. That
information about frequency could in principle be used by the back end to
generate better code. However, I am unsure how
a) to express this info in source code
b) retain it throughout optimisation
So it should be specified in the source, after all, just in a way
that gives programmers room to express their knowledge while
leaving GHC free to implement that knowledge on the target.
Things like the UNLIKELY pragma
Re: compilation of pattern-matching?
The only way to see the impact of very low level things like which way branches go is to generate assembly code and the make simple controlled changes of that. But even doing that is very dodgy since you are subject to the whims of cache misses etc. As far as branching goes, conditional branches that are in loops and that almost always go the same way are free on all modern processors. The branch predictor will learn quickly which way the the branch goes and prefetch along the right path. -- Lennart On Tue, Mar 24, 2009 at 11:30 AM, Claus Reinke claus.rei...@talk21.com wrote: [commented cmm and asm elided - thanks, though! Some examples like this would be helpful in the commentary (or are they there and I've not yet seen them?)] |I guess this is a long winded way of saying that the branches are being |ordered such that the fall though case is not the one that you put first, |which, if I recall correctly, is somewhat bad as the x86 branch predictor |guesses a forward branch that hasn't been seen before will fall through. | |Perhaps they are being ordered by the constructor tag? In Core, case alternatives are stored in an order determined by the data constructor tag of the thing being matched on - this is independent of the order you wrote them in the source code. I believe the reason for this is just to reduce the work done by the code generator a tiny bit (and it's sometimes handy to know that the default case, if any, is always the first alternative). I don't know if preserving the order of the alts as written by the user would be a significant gain for the code generator. Maybe codegen should just output those tests for data alternatives that contain a recursive use of the data type first - e.g. the cons constructor for lists or the branch constructor for trees? Ok, so the answer seems to be: yes, GHC ignores my preferences but modern branch prediction might make this issue less relevant than it was in the early days?-) The recursive-case-first heuristic sounds useful, but not all pattern-match recursions fall into the fold-over-recursive-type category (see attached test). And what about different processors, with differing branch-prediction capabilities? I've attached an attempt at a test program, using Either with various options for testing Left first vs Right first on data with varying ratios of Left vs Right, and varying predicability. The effect seems small here (Pentium M760, 2 GHz), not zero (5-8%), but not easily predictable, eg the largest effect so far was where I expected none at all: rml 10 2: 0m47.632s rmr 10 2: 0m44.150s (that should be a rightfirst match with equal mix Left and Right, so perhaps we need a different test?) There does seem to be a visible effect of ~5% between leftfirst and rightfirst in the extreme all-Left/Right cases, though, suggesting that the source order should be preserved to give programmers control over this, in spite of recent processors. What are the results elsewhere? Claus ___ 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: compilation of pattern-matching?
How could you match the first case with less than two case constructs?
There are two (:) to check for, so I'm not sure what you are complaining about.
-- Lennart
On Tue, Mar 24, 2009 at 12:16 AM, Claus Reinke claus.rei...@talk21.com wrote:
I just noticed that GHC (6.11.20090320) seems to compile both
f (a:b:c) =
f (a:[]) = f [] =
and
f [] = f (a:[]) = f (a:b:c) =
to something like (looking at Core, but writing source)
f x = case x of { [] - ..; (a:t) - case t of { [] -..; (b:c) -..}}
That doesn't seem right to me: if I try to give the patterns in
the order from frequent to rare, in order to reduce jumps, I
don't expect GHC to rearrange things. What is the rationale
for this? And where can I read about GHC's pattern match
compilation approach in general?
Claus
___
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: Type (class) recursion + families = exponential compile time?
Just Hindley-Milner type inference is exponential, making the type system more complex isn't going to make things better. 2009/2/26 Ben Franksen ben.frank...@online.de: Hi the attached module is a much reduced version of some type-level assurance stuff (inspired by the Lightweight Monadic Regions paper) I am trying to do. I am almost certain that it could be reduced further but it is late and I want to get this off my desk. Note the 4 test functions, test11 .. test14. The following are timings for compiling the module only with all test functions commented out, except respectively, test11, test12, test13, and test14: b...@sarun[1] time ghc -c Bug2.hs ghc -c Bug2.hs 1,79s user 0,04s system 99% cpu 1,836 total b...@sarun[1] time ghc -c Bug2.hs ghc -c Bug2.hs 5,87s user 0,14s system 99% cpu 6,028 total b...@sarun[1] time ghc -c Bug2.hs ghc -c Bug2.hs 23,52s user 0,36s system 99% cpu 23,899 total b...@sarun[1] time ghc -c Bug2.hs ghc -c Bug2.hs 102,20s user 1,32s system 97% cpu 1:45,89 total It seems something is scaling very badly. You really don't want to wait for a version with 20 levels of nesting to compile... If anyone has a good explanation for this, I'd be grateful. BTW, I am not at all certain that this is ghc's fault, it may well be my program, i.e. the constraints are too complex, whatever. I have no idea how hard it is for the compiler to do all the unification. Also, the problem is not of much practical relevance, as no sensible program will use more than a handfull levels of nesting. Cheers Ben ___ 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: ./T and ./T log
I'm just guessing, but it looks like a buffering problem.
When a program dies an abnormal death (like the Bug: thing probably
is) then the stdout buffer is not flushed and you'll miss that bit of
the output.
You could set stdout in NoBuffering mode and see if that helps.
-- Lennart
On Fri, Feb 20, 2009 at 9:38 AM, Serge D. Mechveliani mech...@botik.ru wrote:
People,
I observe the output difference in running ./Bug
and ./Bug log
(under Linux) for the program
import Dumatel
main = do calcInput - readFile List0.inp
(putStr $ parseComputeShow calcInput)
where
parseComputeShow calcInput = concat [t = , showsn 3 t \n,
tR = , showsn 3 tR \n]
where
calc = addInput_default nilParseOpts (bool rpos) calcInput
t= parse_default calc parsing Term (a:nil) + (b:nil)
tR = evaluate emptyUMRMemo AllRules calc t
-- I think, it can be reduced to much simpler one.
The error break has to occur while computing tR.
The difference is in printing or skipping of the result part before tR.
The first command outputs
-
t = ((a : nil) + (b : nil))
Bug:
substitute {(X, a), (Xs, nil), (Ys, (b : nil))} X:
sort mismatch in substitution
-
And the second command skips (in ./log) the line of t = ...
Who can tell what is the matter?
How to have identic outputs in this example?
Thank you in advance for explanation.
-
Serge Mechveliani
mech...@botik.ru
___
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
git
What port is git using for getting the ghc repo via http? I'm getting this message behind our thick firewall: fatal: http://darcs.haskell.org/ghc.git/info/refs download error - Failed connect to darcs.haskell.org:1080; Operation now in progress It makes me think port 1080 is involved, and I don't think any access to that port is allowed. If the repo is not totally available on port 80 (or the https port) then it's impossible to get from behind paranoid firewalls. -- Lennart ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: git
I have set the 'http_proxy' environment variable to point at our proxy. Before that it complained about not being able to look up the host name. On Wed, Jan 21, 2009 at 3:30 PM, Sigbjorn Finne s...@galois.com wrote: 1080 is SOCKS, so there's some defaulting proxy setup kicking in here. Set the 'http_proxy' environment variable to point it at your local proxy server. --sigbjorn On 1/21/2009 07:05, Lennart Augustsson wrote: What port is git using for getting the ghc repo via http? I'm getting this message behind our thick firewall: fatal: http://darcs.haskell.org/ghc.git/info/refs download error - Failed connect to darcs.haskell.org:1080; Operation now in progress It makes me think port 1080 is involved, and I don't think any access to that port is allowed. If the repo is not totally available on port 80 (or the https port) then it's impossible to get from behind paranoid firewalls. -- Lennart ___ 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: length of module name affecting performance??
That's a truly awesome feature! I'll shorten all my module names to single letters tomorrow. -- Lennart On Tue, Dec 16, 2008 at 12:43 AM, Don Stewart d...@galois.com wrote: dons: Running time as a function of module name length, http://galois.com/~dons/images/results.png 10 is the magic threshold, where indirections start creeping in. Codegen cost heuristic fail? Given this, could you open a bug ticket for it, with all the info we have, http://hackage.haskell.org/trac/ghc/newticket?type=bug E.g. the graph, the code, the asm diff. Cheers, Don ___ 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: Type checker loops with type families, overlapping and undecidable instances
Turning on UndecidableInstances is the same as saying: OK typechcker,
you can loop if I make a mistake.
I've not looked closely at your code, but if you turn on that flag,
looping is probably not a bug.
-- Lennart
2008/12/4 José Pedro Magalhães [EMAIL PROTECTED]:
Hello all,
Please consider the following code:
{-# OPTIONS -Wall #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE FlexibleInstances#-}
{-# LANGUAGE TypeOperators#-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE OverlappingInstances #-}
{-# LANGUAGE UndecidableInstances #-}
module Test where
-- Some view
class Viewable a where
type View a
to :: a - View a
-- Structural representations
data Unit= Unit
data a :+: b = L a | R b
instance Viewable Unit where
type View Unit = Unit
to = id
instance (Viewable a, Viewable b) = Viewable (a :+: b) where
type View (a :+: b) = a :+: b
to = id
-- Worker class
class F' a where
f' :: a - ()
instance F' Unit where
f' Unit = ()
instance (F a, F b) = F' (a :+: b) where
f' (L x) = f x
f' (R x) = f x
-- Dispatcher class
class (Viewable a, F' (View a)) = F a where
f :: a - ()
f = f' . to
instance F Unit where
f = f'
instance (F a, F b) = F (a :+: b) where
f = f'
-- All generic instances
instance (Viewable a, F' (View a)) = F a
-- A recursive datatype
data Nat = Zero | Succ Nat
-- Instance of Viewable
instance Viewable Nat where
type View Nat = Unit :+: Nat
to = undefined
-- Uncommenting the line below causes the typechecker to loop (GHC 6.10.1,
Windows)
--test = f Zero
Is this expected behavior or a bug?
Thanks,
Pedro
___
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: Strictness in data declaration not matched in assembler?
I totally agree. Getting the value of the field should just evaluate x and then use a pointer indirection; there should be no conditional jumps involved in getting the value. GHC is just doing the wrong thing. -- Lennart On Wed, Oct 15, 2008 at 3:58 PM, Tyson Whitehead [EMAIL PROTECTED] wrote: On Wednesday 15 October 2008 10:48:26 you wrote: Strictness does not imply unboxing. To see why not, think about the fact that unboxing breaks sharing. By keeping the pointer-indirection in place, we can share even strict fields between related values. I believe I realize that. What I was wondering about was the fact that it seemed to think the pointer might be to a thunk (instead of constructor closure). Doesn't the strictness flag mean the following assembler would work sni_info: movq 7(%rbx),%rbx movq $snj_info,(%rbp) jmp snj_info (which could be cleaned up further by combining it with snj_info) instead of sni_info: movq 7(%rbx),%rbx movq $snj_info,(%rbp) testq $7,%rbx jne snj_info jmp *(%rbx) (i.e., the whole test if it is a thunk and conditionally evaluate it bit is unnecessary due to constructor the strictness flag). Cheers! -Tyson ___ 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: Strictness in data declaration not matched in assembler?
True, if there can be indirections then that's bad news. That would make strict fields much less efficient. But I don't see why indirections should be needed. Simon? On Wed, Oct 15, 2008 at 4:21 PM, Jan-Willem Maessen [EMAIL PROTECTED] wrote: On Oct 15, 2008, at 11:08 AM, Lennart Augustsson wrote: I totally agree. Getting the value of the field should just evaluate x and then use a pointer indirection; there should be no conditional jumps involved in getting the value. GHC is just doing the wrong thing. Can indirection nodes occur in this context? [I'd think not, but it depends on what pointer we're storing when we force the thunk in the constructor.] I could see the need for the test if indirection handling is required. -Jan -- Lennart On Wed, Oct 15, 2008 at 3:58 PM, Tyson Whitehead [EMAIL PROTECTED] wrote: On Wednesday 15 October 2008 10:48:26 you wrote: Strictness does not imply unboxing. To see why not, think about the fact that unboxing breaks sharing. By keeping the pointer-indirection in place, we can share even strict fields between related values. I believe I realize that. What I was wondering about was the fact that it seemed to think the pointer might be to a thunk (instead of constructor closure). Doesn't the strictness flag mean the following assembler would work sni_info: movq 7(%rbx),%rbx movq $snj_info,(%rbp) jmp snj_info (which could be cleaned up further by combining it with snj_info) instead of sni_info: movq 7(%rbx),%rbx movq $snj_info,(%rbp) testq $7,%rbx jne snj_info jmp *(%rbx) (i.e., the whole test if it is a thunk and conditionally evaluate it bit is unnecessary due to constructor the strictness flag). Cheers! -Tyson ___ 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: desperately seeking RULES help
Here it is:
{-# OPTIONS_GHC -O2 -Wall -fglasgow-exts -ddump-simpl #-}
-- compile with: ghc -fno-method-sharing -c F.hs
module F(test) where
-- | Domain of a linear map.
class AsInt a where
toInt' :: a - Int
fromInt' :: Int - a
{-# INLINE[1] toInt #-}
toInt :: (AsInt a) = a - Int
toInt = toInt'
{-# INLINE[1] fromInt #-}
fromInt :: (AsInt a) = Int - a
fromInt = fromInt'
{-# RULES
toInt/fromInt forall m . toInt (fromInt m) = m
#-}
{-# INLINE onInt #-}
onInt :: AsInt a = (Int - Int) - (a - a)
onInt f x = fromInt (f (toInt x))
test :: AsInt a = (Int - Int) - (Int - Int) - (a - a)
test h g = onInt h . onInt g
{-
Glasgow Haskell Compiler, Version 6.8.2.20080211, for Haskell 98,
stage 2 booted by GHC version 6.6.1
F.test =
\ (@ a_a6C)
($dAsInt_a6M :: F.AsInt a_a6C)
(h_a67 :: GHC.Base.Int - GHC.Base.Int)
(g_a68 :: GHC.Base.Int - GHC.Base.Int)
(eta_s77 :: a_a6C) -
case $dAsInt_a6M of tpl_B1 { F.:DAsInt tpl1_B2 tpl2_B3 -
tpl2_B3 (h_a67 (g_a68 (tpl1_B2 eta_s77)))
}
-}
On Mon, Jun 9, 2008 at 11:00 AM, Claus Reinke [EMAIL PROTECTED] wrote:
could you please send the complete options/commandline and
the expect final form of 'test'? i did play with Conal's example
as well, but couldn't find a combination to make it work.
perhaps i'm looking at the wrong output, but it seems i either get
non-inlined 'onInt's in various forms or multiple matches out of the same
dictionary, but with generic method names rather than the original
'fromInt'/'toInt'.
claus
Thanks a million, Lennart! -fno-method-sharing was the missing piece. -
Conal
On Sat, Jun 7, 2008 at 5:07 AM, Lennart Augustsson
[EMAIL PROTECTED]
wrote:
Here's something that actually works. You need to pass
-fno-method-sharing on the command line.
Instead of using rules on methods it uses rules on global functions,
and these global functions don't get inlined until late (after the
rule has fired).
-- Lennart
module F where
-- | Domain of a linear map.
class AsInt a where
toInt' :: a - Int
fromInt' :: Int - a
{-# INLINE[1] toInt #-}
toInt :: (AsInt a) = a - Int
toInt = toInt'
{-# INLINE[1] fromInt #-}
fromInt :: (AsInt a) = Int - a
fromInt = fromInt'
{-# RULES
toInt/fromInt forall m . toInt (fromInt m) = m
#-}
{-# INLINE onInt #-}
onInt :: AsInt a = (Int - Int) - (a - a)
onInt f x = fromInt (f (toInt x))
test :: AsInt a = (Int - Int) - (Int - Int) - (a - a)
test h g = onInt h . onInt g
2008/6/7 Conal Elliott [EMAIL PROTECTED]:
I'm trying to do some fusion in ghc, and I'd greatly appreciate help
with
the code below (which is simplified from fusion on linear maps). I've
tried
every variation I can think of, and always something prevents the
fusion.
Help, please! Thanks, - Conal
{-# OPTIONS_GHC -O2 -Wall -fglasgow-exts -ddump-simpl
-ddump-simpl-stats
#-}
-- {-# OPTIONS_GHC -ddump-simpl-iterations #-}
module F where
-- | Domain of a linear map.
class AsInt a where
toInt :: a - Int
fromInt :: Int - a
{-# RULES
toInt/fromInt forall m. toInt (fromInt m) = m
#-}
{-# INLINE onInt #-}
onInt :: AsInt a = (Int - Int) - (a - a)
onInt f = fromInt . f . toInt
test :: AsInt a = (Int - Int) - (Int - Int) - (a - a)
test h g = onInt h . onInt g
-- The desired result:
--
-- test h g
-- == onInt h . onInt g
-- == (fromInt . h . toInt) . (fromInt . g . toInt)
-- == \ a - (fromInt . h . toInt) ((fromInt . g . toInt) a)
-- == \ a - (fromInt . h . toInt) (fromInt (g (toInt a)))
-- == \ a - fromInt (h (toInt (fromInt (g (toInt a)
-- == \ a - fromInt (h (g (toInt a)))
___
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
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: desperately seeking RULES help
Interesting. The problem seems to be that GHC always inlines toInt
and fromInt early, but this means that the rewrite rule no longer
applies.
And, of course, it doesn't inline toInt and fromInt in the rewrite rule.
I have no idea if you can write a rule that will actually work,
because after toInt and fromInt have been inlined you can no longer
write rules that apply, since the types involve dictionaries and the
terms pattern match on dictionaries.
-- Lennart
2008/6/7 Conal Elliott [EMAIL PROTECTED]:
I'm trying to do some fusion in ghc, and I'd greatly appreciate help with
the code below (which is simplified from fusion on linear maps). I've tried
every variation I can think of, and always something prevents the fusion.
Help, please! Thanks, - Conal
{-# OPTIONS_GHC -O2 -Wall -fglasgow-exts -ddump-simpl -ddump-simpl-stats #-}
-- {-# OPTIONS_GHC -ddump-simpl-iterations #-}
module F where
-- | Domain of a linear map.
class AsInt a where
toInt :: a - Int
fromInt :: Int - a
{-# RULES
toInt/fromInt forall m. toInt (fromInt m) = m
#-}
{-# INLINE onInt #-}
onInt :: AsInt a = (Int - Int) - (a - a)
onInt f = fromInt . f . toInt
test :: AsInt a = (Int - Int) - (Int - Int) - (a - a)
test h g = onInt h . onInt g
-- The desired result:
--
-- test h g
-- == onInt h . onInt g
-- == (fromInt . h . toInt) . (fromInt . g . toInt)
-- == \ a - (fromInt . h . toInt) ((fromInt . g . toInt) a)
-- == \ a - (fromInt . h . toInt) (fromInt (g (toInt a)))
-- == \ a - fromInt (h (toInt (fromInt (g (toInt a)
-- == \ a - fromInt (h (g (toInt a)))
___
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: desperately seeking RULES help
Here's something that actually works. You need to pass
-fno-method-sharing on the command line.
Instead of using rules on methods it uses rules on global functions,
and these global functions don't get inlined until late (after the
rule has fired).
-- Lennart
module F where
-- | Domain of a linear map.
class AsInt a where
toInt' :: a - Int
fromInt' :: Int - a
{-# INLINE[1] toInt #-}
toInt :: (AsInt a) = a - Int
toInt = toInt'
{-# INLINE[1] fromInt #-}
fromInt :: (AsInt a) = Int - a
fromInt = fromInt'
{-# RULES
toInt/fromInt forall m . toInt (fromInt m) = m
#-}
{-# INLINE onInt #-}
onInt :: AsInt a = (Int - Int) - (a - a)
onInt f x = fromInt (f (toInt x))
test :: AsInt a = (Int - Int) - (Int - Int) - (a - a)
test h g = onInt h . onInt g
2008/6/7 Conal Elliott [EMAIL PROTECTED]:
I'm trying to do some fusion in ghc, and I'd greatly appreciate help with
the code below (which is simplified from fusion on linear maps). I've tried
every variation I can think of, and always something prevents the fusion.
Help, please! Thanks, - Conal
{-# OPTIONS_GHC -O2 -Wall -fglasgow-exts -ddump-simpl -ddump-simpl-stats #-}
-- {-# OPTIONS_GHC -ddump-simpl-iterations #-}
module F where
-- | Domain of a linear map.
class AsInt a where
toInt :: a - Int
fromInt :: Int - a
{-# RULES
toInt/fromInt forall m. toInt (fromInt m) = m
#-}
{-# INLINE onInt #-}
onInt :: AsInt a = (Int - Int) - (a - a)
onInt f = fromInt . f . toInt
test :: AsInt a = (Int - Int) - (Int - Int) - (a - a)
test h g = onInt h . onInt g
-- The desired result:
--
-- test h g
-- == onInt h . onInt g
-- == (fromInt . h . toInt) . (fromInt . g . toInt)
-- == \ a - (fromInt . h . toInt) ((fromInt . g . toInt) a)
-- == \ a - (fromInt . h . toInt) (fromInt (g (toInt a)))
-- == \ a - fromInt (h (toInt (fromInt (g (toInt a)
-- == \ a - fromInt (h (g (toInt a)))
___
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: ANNOUNCE: GHC 6.8.3 Release Candidate
There are no rules written down. But the fast exponentiation algorithm used by (^) assumes that (*) is associative. I also don't think that fast exponentiation should ever multiply by 1. -- Lennart On Sun, Jun 1, 2008 at 6:34 PM, Serge D. Mechveliani [EMAIL PROTECTED] wrote: On Sun, Jun 01, 2008 at 03:34:00PM +0100, Ian Lynagh wrote: On Sun, Jun 01, 2008 at 05:39:49PM +0400, Serge D. Mechveliani wrote: This is why res and 1*res are not equivalent in Haskell-98 for res :: Num a = a. Am I missing something? The library functions assume that class instances obey some unwritten laws; it's all a bit vague, but if your instances don't obey them then you might find that things go wrong when using library functions. For example, if your (*) isn't associative then (^) is going to give odd results, and if the type of the second argument to (^) doesn't do arithmetic in the normal way then very strange things could happen. Anyway, I've just tweaked the (^) definition again, so your code should work in 6.8.3. Thank you. This helps -- in that the public DoCon-2.11 test will run (I hope). But I think that you have found a bug in the DoCon test program. Thank you. More precisely, here are my indeas. 1. Generally, for t = Num a = a, the expessions res :: tand ((fromInteger 1) :: t) * res are not equivalent in Haskell-98, and the compiler has not rigth to replace the former with the latter. Right? 2. But I guess, our current questions are different: (2.1) For t = Num a = a, has a Haskell implementation for (f^n) :: t right to base on certain natural properties of the operation fromInteger :: Integer - t ? (2.2) Has a reliable mathematical application right to base on that for n 0 the expression (f^n) :: Polynomial Integer does not imply computing fromInteger 1 :: Polynomial Integer ? Concerning (2.1): I do not know whether Haskell-98 allows to rely on that f^3 is equivalent to (fromInteger 1)*(f^3). But concerning (2.2), I think that (independently of the question (2.1)) a reliable mathematical application must not presume the above properties of (^) and fromInteger. Concerning f^3 :: UPol Integer in my test for DoCon: 1) fromInteger _ :: UPol _ is defined as error ... use fromi instead. 2) (*) is defined via polMul ... 3) The expression f ^ 3 relies on the Haskell-98 library for (^). The Haskell library defines (^) via (*) -- all right. 4) DoCon has the function `power' to use instead of (^), and its library avoids (^). But for n 0, I considered f^n :: UPol _ as also correct. Because the Haskell library performs this via repeated application of (*). And I thought that if n 0, then (fromInteger _ :: UPol _) will not appear. Maybe it does not appear in old GHC-s and does appear 6.8.3 ? I was using expressions like [(f ^ n) :: UPol Integer | n - [2 .. 9]] in my _test programs_ for DoCon. But this relies on a particular property of the Haskell library definition for (f^n) :: a -- on that if n 0 then (fromInteger _ :: a) does not appear in this computation. Now, I think, either I need to hide the standard (^) and overload it or to replace (^) with `power' in my examples too. Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ 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: simple CSE?
GHC is bad at CSE. Of course, in general CSE might not be a good idea, but
with strict computations it is. So someone needs to add a CSE pass.
On Sat, Mar 29, 2008 at 2:23 AM, Don Stewart [EMAIL PROTECTED] wrote:
conal:
I'd like to know if it's possible to get GHC to perform some simple
CSE
for function-level programming. Here's a simple example:
liftA2 (*) sin sin :: Double - Double
which inlines and simplifies to
\ t - sin t * sin t
A more realistic, equivalent, example:
let b = sin $ id in liftA2 (*) b b
Can GHC be nudged into computing 'sin t' once rather than twice?
So GHC does do some light CSE, but not in this case, as far as I could
see.
I had a go with a rewrite rule that I felt should have matched, but it
didn't seem to want to fire. Possibly the dictionaries were getting in
the way.
import System.Environment
import Prelude hiding (sin)
import qualified Prelude
sin :: Double - Double
sin x = Prelude.sin x
{-# NOINLINE sin #-}
times :: Double - Double - Double
times x y = x * y
{-# NOINLINE times #-}
{-# RULES
sin/cse forall x.
times (sin x) (sin x) = case Prelude.sin x of y - y * y
#-}
main = do
[x] - getArgs
let n = read x
print $ sin n `times` sin n
___
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: [Haskell-cafe] class default method proposal
I had it pretty well worked out for single parameter type classes, but I couldn't see any nice extension to multiple parameters. On Dec 11, 2007 5:30 PM, Simon Peyton-Jones [EMAIL PROTECTED] wrote: | If it really would work ok we should get it fully specified and | implemented so we can fix the most obvious class hierarchy problems in a | nice backwards compatible way. Things are only supposed to be candidates | for Haskell' if they're already implemented. Getting it fully specified is the first thing. Personally I am not keen about a) coupling it to explicit import/export (independently-desirable though such a change might be) b) having instance declarations silently spring into existence Concerning (b) here's a suggestion. As now, require that every instance requires an instance declaration. So, in the main example of http://haskell.org/haskellwiki/Class_system_extension_proposal, for a new data type T you'd write instance Monad T where return = ... (=) = ... instance Functor T instance Applicative T The instance declaration for (Functor T) works just as usual (no explicit method, so use the default method) except for one thing: how the default method is found. The change is this: Given instance C T where ..., for any method 'm' not defined by ...: for every class D of which C is a superclass where there is an instance for (D T) see if the instance gives a binding for 'm' If this search finds exactly one binding, use it, otherwise behave as now This formulation reduces the problem to a more manageable one: a search for the default method. I'm not sure what is supposed to happen if the instance is for something more complicated (T a, say, or multi-parameter type class) but I bet you could work it out. All these instances would need to be in the same module: - you can't define Functor T without Monad T, because you want to pick up the monad-specific default method - you can't define Monad T without Functor T, because the latter is a superclass of the former It still sounds a bit complicated. Simon ___ 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: type equality symbol
I agree. There are other ways that to solve the same problem as the case distinction does. On Dec 7, 2007 12:45 PM, Johannes Waldmann [EMAIL PROTECTED] wrote: On Fri, 7 Dec 2007, Manuel M T Chakravarty wrote: The problem is that Haskell 98 already messed that up. If type functions are to use lower-case letters, [...] Yes. The broken thing is that the upper/lower case distinction has syntactic importance in the language definition at all. I guess this was introduced to avoid writing out some declarations. This is a bad design goal, especially so for a declarative language. Reminds me of ancient Fortran using the first letter of an identifier for implicit typing (I .. N for integer, others for real). Best regards, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- http://www.imn.htwk-leipzig.de/~waldmann/http://www.imn.htwk-leipzig.de/%7Ewaldmann/--- ___ 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: type equality symbol
I don't think it's highly problematic. I agree that it would be nice to have the type and value levels have a similar structure, but if there are compelling reasons to do otherwise that fine too. You could still allow symbol type variables if they have an explicit binding occurence, which you can always(?) do with type variables. -- Lennart On Dec 5, 2007 11:34 PM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: 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 ___ 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
Or use a preprocessor that inserts a LANGUAGE pragma. :)
On Nov 22, 2007 9:14 AM, Simon Marlow [EMAIL PROTECTED] wrote:
Alex Jacobson wrote:
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 probably won't like any of these, but there are many ways to avoid
writing out all the pragmas at the top of each file.
1. Use Cabal's extensions field.
2. Use CPP
MyExtensions.h:
{-# LANGUAGE TemplateHaskell, FlexibleInstances,
OverlappingInstances, UndecidableInstances, CPP,
ScopedTypeVariables, PatternSignatures, GADTs,
PolymorphicComponents, FlexibleContexts,
MultiParamTypeClasses, DeriveDataTypeable,
PatternGuards #-}
MyModule.hs:
{-# LANGUAGE CPP #-}
#include MyExtensions.h
3. Use a shell alias
alias ghce='ghc -XTemplateHaskell -XFlexibleInstances ...'
4. use a script wrapper for GHC
#!/bin/sh
exec ghc -XTemplateHaskell -XFlexibleInstances ... $*
I'm sure there are more...
Cheers,
Simon
-Alex-
Simon Marlow wrote:
Alex Jacobson wrote:
I'm fine with that as well. I'm just opposed to being force to look
up the precise names the compiler happens to use for each language
extension I happen to use. Having -fglasgow-exts turned on by
default also works.
-fglasgow-exts is a historical relic. It's just an arbitrary
collection of extensions. It doesn't contain all the extensions
provided by GHC, as many of them steal syntax and you probably don't
want them all on at the same time. We're trying to move away from
-fglasgow-exts, which is why GHC 6.8.1 provides separate flags for all
the extensions we provide. Eventually we'll have a new standard
(Haskell' or whatever) that will collect many of the extensions
together, so you'll just have to write {-# LANGUAGE Haskell' #-}.
Cheers,
Simon
___
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: [Haskell] recursive deriving
This seems very, very wrong. The missing instance(s) might be left out because of some good reason (e.g. if you have implemented sets with list and not provided Ord). On Nov 21, 2007 12:59 AM, Duncan Coutts [EMAIL PROTECTED] wrote: On Tue, 2007-11-20 at 19:18 -0500, Alex Jacobson wrote: When you want automated deriving of show/read etc., you need all the components of your type also to be instances of show/read but you won't want to *require* them to be automatically generated verions. Standalone deriving does the wrong thing here. Standalone deriving should not cause an overlapping instance error if someone derives an instance manually. Instead, the manually derived instance should be treated as more specific and win out. The other part of this problem is that you can't do automatic recursive deriving and this results in a ridiculous amount of boilerplate. I know some people have a theory that they want to avoid accidentally creating instances for things that shouldn't have them, but the solution to that is probably to add some declaration for types that prohibits automatic deriving for those types. The 99% case is that automatic deriving is ok. Proposed syntax: derive instance Show T recursively data T = T no-deriving (Ord,Eq) I would expect that if the data constructor for T is not exported then standalone deriving should not work. However this appears not to be the case which breaks module abstraction. Foo.hs: module Foo ( T, t ) where data T = T t = T Bar.hs: import Foo deriving instance Eq T $ ghci Bar.hs -XStandaloneDeriving [1 of 2] Compiling Bar ( Bar.hs, interpreted ) [2 of 2] Compiling Main ( Baz.hs, interpreted ) Ok, modules loaded: Bar, Main. *Main t == t True You could write that Eq instance by hand since they do not have access to the T constructor, then StandaloneDeriving should not be able to so either. I think it's a design flaw in standalone deriving. Does anyone else agree? Should we file a bug report? Duncan ___ 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: suggestion: add a .ehs file type
I'm very much in favor of listing the exact extensions used in each file, because I try to keep them to a minimum. I would like to see a LANGUAGE Haskell' which includes the things that are likely to be in Haskell' (if there is ever a Haskell'). -- Lennart On Nov 20, 2007 9:42 PM, Alex Jacobson [EMAIL PROTECTED] wrote: I'm fine with that as well. I'm just opposed to being force to look up the precise names the compiler happens to use for each language extension I happen to use. Having -fglasgow-exts turned on by default also works. -Alex- Wolfgang Jeltsch wrote: 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 ___ 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: Type Synonyms and termination checking
Look at the end of http://haskell.org/haskellwiki/GHC/Indexed_types -- Lennart On 8/31/07, Jim Apple [EMAIL PROTECTED] wrote: Regarding http://www.haskell.org/pipermail/cvs-ghc/2007-August/037655.html and Are type functions checked for termination? If so, where can I find the details? Jim ___ 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: All warnings but type signatures
For me the type is important, I want to see it for every top level function. Using named types it serves as documentation. -- Lennart On Sun, 13 May 2007, Joel Reymont wrote: Date: Sun, 13 May 2007 14:23:42 +0100 From: Joel Reymont [EMAIL PROTECTED] To: GHC Users Mailing List glasgow-haskell-users@haskell.org Subject: All warnings but type signatures Is there a way to enable all warnings but the following: Hope/Item/DBDesc.hs:6:0: Warning: Definition but no type signature for `item_db' Overall, is there an advantage to type signatures in GHC as opposed to letting the compiler derive them? Thanks, Joel -- http://wagerlabs.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Lennart ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Release plans
On Apr 16, 2007, at 15:54 , Simon Marlow wrote: - left-to-right impredicative instantiation: runST $ foo Is this really a good idea? This will just make people complain that € (x € f = f x) doesn't work when you do foo € runST (or maybe it does?). -- Lennart ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Feature proposal: ghc --full-flag-help ?
Sorry, but I'm not always connected to the Internet. I'd like to be able to get flag help easily anyway. -- Lennart On Mar 13, 2007, at 14:28 , Simon Peyton-Jones wrote: Suppose ghc --full-flag-help simply printed the URL http://www.haskell.org/ghc/docs/latest/html/users_guide/ flag-reference.html Now you can see it in your web browser by clicking on it. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow- [EMAIL PROTECTED] On | Behalf Of Neil Mitchell | Sent: 13 March 2007 13:08 | To: Sittampalam, Ganesh | Cc: glasgow-haskell-users@haskell.org | Subject: Re: Feature proposal: ghc --full-flag-help ? | | Hi | | What about integrating a complete list into ghc which can accessed by | ghc --full-flag-help | less ? | | Sure I can fake it and get that list out of the html documentation. I | just want to know if someone else would like this flag, too | | I would find it very useful too. | | Me too. At the same time --help should probably direct the user at the | section of the manual which deals with flags, as well as the | documentation overview. I always find myself searching for the flags | reference | | Thanks | | Neil | ___ | 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: unsafePerformIO safety.
I wouldn't like if unsafePerformIO could never be inlined, sometimes
you want it inlined for performance.
And not all uses are hacky, it's just that when I use it, then burden
is on me to convince myself that it is safe.
On Mar 6, 2007, at 23:56 , Neil Mitchell wrote:
Hi
On 3/6/07, Lennart Augustsson [EMAIL PROTECTED] wrote:
Yeah, you really need {-# NOINLINE var #-} to make it reasonable
safe.
Couldn't GHC bake in knowledge about unsafePerformIO, and never inline
it? It is a slightly hacky solution, but since unsafePerformIO is
pretty much only used in hacks, I think its almost fitting.
Thanks
Neil
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: unsafePerformIO safety.
Yeah, you really need {-# NOINLINE var #-} to make it reasonable safe.
On Mar 6, 2007, at 23:18 , David Brown wrote:
Seth Kurtzberg wrote:
On Tue, 06 Mar 2007 12:03:05 -0800
David Brown [EMAIL PROTECTED] wrote:
I've noticed quite a few pages referencing constructs such as:
var :: MVar ([Foo])
var = unsafePerformIO (newMVar ([]))
and the likes. Is there a danger of different uses of 'var' getting
new MVars instead of all sharing one.
Having a reliable way to create a piece of global state would be
very
convenient.
This operation is unsafe by definition. I use it extensively,
without problems. The unsafe in the name reminds you that there
are situations for which the function is inappropriate, but all of
my deployed commercial programs have functionality of this sort.
Understand the risk, but don't hesitate to use it.
Do you do anything to keep 'var' from getting inlined? I can envision
a case where the code would be inlined, and then each use would get a
separate MVar.
Thanks,
Dave
___
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: [Haskell] GHC Error question
If the type checker really deduces the type 'forall a b . C a b = a - a' then an inference algorithm that works seems easy. Do type inference for f, then check that the signature the user has given is alpha-convertible with the deduced type (well, in general it's more complicated than that, of course). If the type checker doesn't really deduce 'forall a b . C a b = a - a' then it shouldn't print what it does. So I'm curious, what is the exact deduced type? -- Lennart On Dec 11, 2006, at 07:16 , Simon Peyton-Jones wrote: | Tell me how this make sense: | 1. I enter the definition for f. | 2. I ask ghc for the type of f and get an answer. | 3. I take the answer and tell ghc this is the type of f, and ghc | tells me I'm wrong. | Somewhere in this sequence something is going wrong. I agree! Indeed I wrote: | It doesn't get much simpler than that! With the type sig, GHC can't see that the (C a b) provided can | satisfy the (C a b1) which arises from the call to op. However, without the constraint, GHC simply | abstracts over the constrains arising in the RHS, namely (C a b1), and hence infers the type | f :: C a b1 = a - a | It is extremely undesirable that the inferred type does not work as a type signature, but I don't see | how to fix it If you have an idea for an inference algorithm that would typecheck this program, I'd be glad to hear it. Just to summarise, the difficulty is this: I have a dictionary of type (C a b1) I need a dictionary of type (C a b2) There is no functional dependency between C's parameters Simon PS: the complete program is this: class C a b where op :: a - a f :: C a b = a - a f x = op x ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] GHC Error question
What Claus says. What is the real type that ghc infers? If it's really what it claims it to be, then this is definitely a bug. And it might not be common to you, but I have several places in my code base where I have to leave off type signatures, because the inferred signature is not accepted. And I turn on the warning for a missing type sig. And if it were feasible to make this an error I would. -- Lennart On Dec 13, 2006, at 13:42 , Claus Reinke wrote: call me a stickler for details, if you must, but I am still worried that this is not an undesirable inability to use the type signature, but rather a real bug in how the result of type inference is presented. note that Lennart considers both options, and asks which option is the one relevant for this example (or: what is the internal representation of the type inferred by GHCi?). without further constraints, there is nothing linking the b1 needed for op :: C a b1 = a - a to the b2 provided by f :: C a b2 = a - a (and the original example had several uses of class method, with no indication that they were all linked to the same dictionary). so I think that GHC is perfectly right in not using the signature to discharge the constraint for op. imho, there is a real error in the way GHCi presents the type of f: *Main :t f f :: forall t b. (C t b) = t - t in spite of this presentation, we can not use any old b here! the body of f requires a specific b' for op, we just happen to have not a single clue about which b' that might be. which is why I suggested that the type should be represented differently, by marking b as not free, or by using existential quantification: http://www.haskell.org/pipermail/glasgow-haskell-users/2006- December/011758.html with such a change, GHC would still not be able to use the signature inferred by GHCi, but it would now be clear why that is the case (and why the signature above does not work). Claus - Original Message - From: Simon Peyton-Jones [EMAIL PROTECTED] To: Lennart Augustsson [EMAIL PROTECTED] Cc: GHC users glasgow-haskell-users@haskell.org Sent: Wednesday, December 13, 2006 5:19 PM Subject: RE: [Haskell] GHC Error question Hmm. GHC currently uses the signature to drive typechecking the expression; it does not infer a type and compare. (Much better error messages that way.) So (a) it's very undesirable that using the inferred type as a signature can ever not work, but (b) it affects only very few programs and ones that are almost certainly ambiguous anyway, and (c) I can't see an easy way to fix it. So my current plan is: let it lie. I'll open a low-priority bug report for it though. Simon | -Original Message- | From: Lennart Augustsson [mailto:[EMAIL PROTECTED] | Sent: 13 December 2006 13:42 | To: Simon Peyton-Jones | Cc: GHC users | Subject: Re: [Haskell] GHC Error question | | If the type checker really deduces the type 'forall a b . C a b = a - | a' then an inference algorithm that works seems easy. Do type | inference for f, then check that the signature the user has given is | alpha-convertible with the deduced type (well, in general it's more | complicated than that, of course). | If the type checker doesn't really deduce 'forall a b . C a b = a - | a' then it shouldn't print what it does. | So I'm curious, what is the exact deduced type? | | -- Lennart | | On Dec 11, 2006, at 07:16 , Simon Peyton-Jones wrote: | | | Tell me how this make sense: | | 1. I enter the definition for f. | | 2. I ask ghc for the type of f and get an answer. | | 3. I take the answer and tell ghc this is the type of f, and | ghc | | tells me I'm wrong. | | Somewhere in this sequence something is going wrong. | | I agree! Indeed I wrote: | | | It doesn't get much simpler than that! With the type sig, GHC | can't see that the (C a b) provided can | | satisfy the (C a b1) which arises from the call to op. However, | without the constraint, GHC simply | | abstracts over the constrains arising in the RHS, namely (C a | b1), and hence infers the type | | f :: C a b1 = a - a | | It is extremely undesirable that the inferred type does not work | as a type signature, but I don't see | | how to fix it | | If you have an idea for an inference algorithm that would typecheck | this program, I'd be glad to hear it. Just to summarise, the | difficulty is this: | I have a dictionary of type (C a b1) | I need a dictionary of type (C a b2) | There is no functional dependency between C's parameters | | Simon | | PS: the complete program is this: | class C a b where | op :: a - a | | f :: C a b = a - a | f x = op x | ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] GHC Error question
Sure, inferring and comparing for alpha-equal is not the best thing pragmatically. But you asked for an algorithm that would work. :) So the band-aid solution would be to first try with the signature, if that fails, try without and then then use the sig. -- Lennart On Dec 13, 2006, at 12:19 , Simon Peyton-Jones wrote: Hmm. GHC currently uses the signature to drive typechecking the expression; it does not infer a type and compare. (Much better error messages that way.) So (a) it's very undesirable that using the inferred type as a signature can ever not work, but (b) it affects only very few programs and ones that are almost certainly ambiguous anyway, and (c) I can't see an easy way to fix it. So my current plan is: let it lie. I'll open a low-priority bug report for it though. Simon | -Original Message- | From: Lennart Augustsson [mailto:[EMAIL PROTECTED] | Sent: 13 December 2006 13:42 | To: Simon Peyton-Jones | Cc: GHC users | Subject: Re: [Haskell] GHC Error question | | If the type checker really deduces the type 'forall a b . C a b = a - | a' then an inference algorithm that works seems easy. Do type | inference for f, then check that the signature the user has given is | alpha-convertible with the deduced type (well, in general it's more | complicated than that, of course). | If the type checker doesn't really deduce 'forall a b . C a b = a - | a' then it shouldn't print what it does. | So I'm curious, what is the exact deduced type? | | -- Lennart | | On Dec 11, 2006, at 07:16 , Simon Peyton-Jones wrote: | | | Tell me how this make sense: | | 1. I enter the definition for f. | | 2. I ask ghc for the type of f and get an answer. | | 3. I take the answer and tell ghc this is the type of f, and | ghc | | tells me I'm wrong. | | Somewhere in this sequence something is going wrong. | | I agree! Indeed I wrote: | | | It doesn't get much simpler than that! With the type sig, GHC | can't see that the (C a b) provided can | | satisfy the (C a b1) which arises from the call to op. However, | without the constraint, GHC simply | | abstracts over the constrains arising in the RHS, namely (C a | b1), and hence infers the type | | f :: C a b1 = a - a | | It is extremely undesirable that the inferred type does not work | as a type signature, but I don't see | | how to fix it | | If you have an idea for an inference algorithm that would typecheck | this program, I'd be glad to hear it. Just to summarise, the | difficulty is this: | I have a dictionary of type (C a b1) | I need a dictionary of type (C a b2) | There is no functional dependency between C's parameters | | Simon | | PS: the complete program is this: | class C a b where | op :: a - a | | f :: C a b = a - a | f x = op x | ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] GHC Error question
Your two examples are different, the second one is rejected by the type checker, with or without a signature. The first one isn't. Tell me how this make sense: 1. I enter the definition for f. 2. I ask ghc for the type of f and get an answer. 3. I take the answer and tell ghc this is the type of f, and ghc tells me I'm wrong. Somewhere in this sequence something is going wrong. And it is either is step 2 or 3. Maybe in step 2 ghc is lying to me, and what it tells me isn't the type of f. Then ghc is broken. Maybe in step 3 ghc misunderstands my type and doesn't know what I mean. Then ghc is broken. I don't see how steps 1-3 can happen unless there is something broken. And I think the problem is in step 2. The b there isn't quite what it seems to be. And if it isn't, it should be marked as such. -- Lennart On Dec 8, 2006, at 10:48 , Simon Peyton-Jones wrote: | And why isn't C a b equivalent to C a b1? |forall a b . C a b = a - a | and |forall a b1 . C a b1 = a - a | look alpha convertible to me. You may say it's just common sense: a) I have a dictionary of type (C a b) provided by the caller b) I need a dictionary of type (C a b1) , where b1 is an as- yet-unknown type (a unification variable in the type inference system) c) There are no other constraints on b1 So, in view of (c), perhaps we can simply choose b1 to be b, and we're done! Sounds attractive. But consider this: f :: (Read a, Show a) = String - String f x = show (read x) From this I get a) I have a dictionary of type (Show a) provided by the caller b) I need a dictionary of type (Show a1), arising from the call to show c) There are no other constraints on a1 So perhaps I should choose a1 to be a, thereby resolving the ambiguity! Well, perhaps. Or I could choose a1 to be Int, or Bool. (A similar ambiguity exists in Norman's example, if there were instances for (C a Int) or (C a Bool).) There may be a heuristic that would help more programs to go through... but I prefer asking the programmer to make the desired behaviour explicit. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] GHC Error question
And why isn't C a b equivalent to C a b1?
forall a b . C a b = a - a
and
forall a b1 . C a b1 = a - a
look alpha convertible to me. Or is the inferred type
forall a . C a b1 = a - a
Btw, this reminds me again that I'd like to be able to use _ in type
signatures.
With the meaning of _ being, there's a type here, but I can't be
bothered to write it out in full.
-- Lennart
On Dec 6, 2006, at 02:46 , Simon Peyton-Jones wrote:
I agree that this is confusing. Here is a cut-down example:
class C a b where
op :: a - a
-- f :: C a b = a - a
f x = op x
It doesn't get much simpler than that! With the type sig, GHC
can't see that the (C a b) provided can satisfy the (C a b1) which
arises from the call to op. However, without the constraint, GHC
simply abstracts over the constrains arising in the RHS, namely (C
a b1), and hence infers the type
f :: C a b1 = a - a
It is extremely undesirable that the inferred type does not work as
a type signature, but I don't see how to fix it
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:glasgow-
haskell-users-
| [EMAIL PROTECTED] On Behalf Of Norman Ramsey
| Sent: 06 December 2006 01:41
| To: Simon Peyton-Jones
| Cc: GHC users
| Subject: Re: [Haskell] GHC Error question
|
| [redirecting to ghc users]
|
| It looks like a splendid error to me.
|
| I'm not sure if you meant the error or the message was splendid :-)
| I yelled for help because my usual strategy failed. That
strategy is
|
| 1. Remove the type annotation.
| 2. Get ghci to tell me what the 'right type' is.
| 3. Put the 'right type' in the type annotation.
|
| I find it a bit depressing that the most general type inferred by
ghci
| does not work as a type signature.
|
| I can't say more without seeing the code. can you give a
small repo case?
|
| Yes, here's a case that fits in one screen of emacs :-)
|
|
| {-# OPTIONS -fglasgow-exts #-}
| module Ccomp where
|
| type Name = String
|
| data Inface = N | W
| data Outface = S | E
|
| data Sink box = Boxin Inface box | Result
| data Source box = Boxout Outface box | Arg Inface
|
| data Command = Send0
|
| class (Monad b) = Builder b box where
| box :: Command - b box
| wire :: Source box - Sink box - b ()
|
| type Env box = Name - Sink box
|
| empty = \x - error (x ++ not connected or multiply connected
in circuit)
|
| -- either of these explicit signatures causes the compiler to fail
| -- although the inferred signature is the second.
| --compile1 :: (Builder b box) = Name - Name - ANF - b Name
| compile1 :: (Builder t box) = t1 - Name - ANF - t t1 --
generated by ghci
| compile1 f x body = do env - compile body empty
|wire (Arg W) (env x)
|return f
|
| data ANF = ANF ()
|
| compile :: (Builder b box) = ANF - Env box - b (Env box)
| compile (ANF m) out = undefined
|
| | This program is rejected by GHC with the following message:
| |
| | Ccomp.hs:54:23:
| | Could not deduce (Builder b box1) from the context
(Builder b box)
| | arising from use of `wire' at Ccomp.hs:54:23-42
| | Possible fix:
| | add (Builder b box1) to the type signature(s) for
`compile1'
| | In the expression: wire (Arg W) (env x)
| | In a 'do' expression: wire (Arg W) (env x)
| | In the expression:
| | do env - compile body empty
| |wire (Arg W) (env x)
| |return f
| |
| | Note that compile1 has an explicit type signature much along
the lines
| | suggested by GHC. If I *remove* this type signature, the
function
| | compiles successfully, and ghci reporets this type for
compile1:
| |
| | compile1 :: (Builder t box) = t1 - Name - Ir.ANF - t t1
| |
| | I believe this signature is isomorphic to the explicit
signature I had
| | attempted to use.
| ___
| 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: Type wildcards, was: Re: [Haskell] GHC Error question
I would treat multiple _ in a type the same way as multiple _ in a pattern. They can all be different. It might be useful to have multiple variables, say _a, in a type too, all standing for the same type. But I'd settle for _ for now. :) And yes, contexts even more so! Contexts are really annoying in Haskell, they can become quite large, but they cannot be named. Speaking of wishlist, I'd also like to see context synonyms, e.g., context C a = (Ord a, Num a) The current situation is quite bad, there's no way to abstract contexts. Well, you can leave out type signatures altogether (but only a few people advocate this (hello John!)). -- Lennart On Dec 7, 2006, at 07:20 , Johannes Waldmann wrote: Lennart Augustsson wrote: Btw, this reminds me again that I'd like to be able to use _ in type signatures. With the meaning of _ being, there's a type here, but I can't be bothered to write it out in full. you're not alone ... what is the meaning of two _ in one expression? do they necessarily denote the same type? (probably not.) what about type classes? for example, given sort :: Ord a = [a] - [a], would it be ok to write sort :: [ _ ] - [ _ ] (that is, omitting the context) or is it more like sort :: _ = [ _ ] - [ _ ] BTW, this _ for context would be useful on its own! I have several cases where the conxtext for the type decl is longer than the implementation of the function. Well, nearly. With previous ghc versions, I could get this effect by omitting the type decl but writing f ( x :: type1) ( y :: type2 ) = ... I sometimes wish haddock would understand that. (*) Because - if you write a haddoc comment for a type declaration, then you don't have names for the function's arguments. This leads to either awkward prose (random example, from Data.Maybe:) The maybe function takes a default value, a function, and a Maybe value. If the Maybe value is Nothing ... (this only works here because all the argument types are different in this case) or you have to re-invent names, random example: approxRational :: RealFrac a = a - a - Rational approxRational, applied to two real fractional numbers x and epsilon, which looks like duplication of work. (*) of course the full form would include the return type fun (x :: type1 ) (y :: type2) :: type3 = ... I expect strong opposition from those who write functions with pattern matching (then there is a group of declarations and which one should be type-annotated?) but that's bad style anyway since constructors should not be exported :-) Best regards, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- http://www.imn.htwk-leipzig.de/~waldmann/ --- ___ 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: Type wildcards, was: Re: [Haskell] GHC Error question
I should have said that the situation in H98 is quite bad. There you can't make default instances. On Dec 7, 2006, at 07:49 , Johannes Waldmann wrote: Lennart Augustsson wrote: Speaking of wishlist, I'd also like to see context synonyms, e.g., context C a = (Ord a, Num a) The current situation is quite bad, there's no way to abstract contexts. except by writing extra classes that encode the context, see for example class NFAC: http://141.57.11.163/cgi-bin/cvsweb/lib/Autolib/NFA/Data.hs.drift? rev=1.16 but this is of course only a hack, and it duplicates information since you have to repeat the context in the default instance. At least this happens only in one place, so it is useful. -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- http://www.imn.htwk-leipzig.de/~waldmann/ --- ___ 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: Type wildcards, was: Re: [Haskell] GHC Error question
My (off-the-top-of-my-head) suggestion was much more modest. A context synonym would only allow you to shorten contexts, it would not be a new class. On Dec 7, 2006, at 10:53 , J. Garrett Morris wrote: On 12/7/06, Lennart Augustsson [EMAIL PROTECTED] wrote: Speaking of wishlist, I'd also like to see context synonyms, e.g., context C a = (Ord a, Num a) This is equivalent to John Meacham's class alias proposal, right? (http://repetae.net/john/recent/out/classalias.html) /g -- It is myself I have never met, whose face is pasted on the underside of my mind. ___ 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: Common subexpression elemination (CSE)
The relation to strictness is that you have much tighter control over when things are evaluated (typically) for something strict, so it is less likely to leak. Take the expression 'e + e' at some base type. It's harmless to CSE this to 'let x = e in x+x' because + is strict in x. Whereas '(e,e)' can't be CSE:ed to 'let x = e in (x,x)' without risking a space leak. It's not exactly strictness, it's more about knowing when a value is going to be consumed. Also, things that are small can be CSE:ed, since the evaulated form doesn't take more space than the unevaluated. -- Lennart On Nov 28, 2006, at 09:50 , Bertram Felgenhauer wrote: Dinko Tenev wrote: On 11/27/06, Lennart Augustsson [EMAIL PROTECTED] wrote: GHC doesn't normally do CSE. CSE can cause space leaks, so you can't do it willy-nilly. I'm sure there are some strict contexts where it could be done safely, but I don't think ghc uses that information (yet). -- Lennart My apologies in advance for asking possibly stupid questions, but I don't understand this. How exactly can CSE cause space leaks, and what does this have to do with strictness? Combining two expressions means that they're represented by the same memory location. In particular when you start evaluating the first, the second reference to the value will keep all of it alive even if parts of it could otherwise be freed. This is especially problematic for infinite lists. http://hackage.haskell.org/trac/ghc/ticket/947 demonstrates this problem, caused by the little CSE that ghc does. (Note: This is not of the form let x = term in ... term ..., but it will be once it's desugared and the simplifier has floated out the constant expressions from the primes0 and primes functions) I'm not sure how it relates to strictness. I'd be more worried about about the size of the data that's being kept alive. Numbers are more likely to be ok than lists. Bertram ___ 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: Common subexpression elemination (CSE)
GHC doesn't normally do CSE. CSE can cause space leaks, so you can't do it willy-nilly. I'm sure there are some strict contexts where it could be done safely, but I don't think ghc uses that information (yet). -- Lennart On Nov 27, 2006, at 08:34 , Christian Maeder wrote: the following code does not run as fast as expected: modexp a e n = if e = 0 then 1 else if even e then mod (modexp a (div e 2) n * modexp a (div e 2) n) n else mod (a * modexp a (e - 1) n) n it gets only fast if written as: modexp2 a e n = if e = 0 then 1 else if even e then let d = modexp2 a (div e 2) n in mod (d * d) n else mod (a * modexp2 a (e - 1) n) n I wonder, why the common subexpression modexp a (div e 2) n is not eliminated in the first case. Does CSE work at all? For testing the exponent e should have at least 10 digits. Cheers Christian P.S. Other alternatives are slower, too modexp1 a e n = if e = 0 then 1 else mod (a * modexp1 a (e - 1) n) n modexp3 a e n = mod (a ^ e) n ___ 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: Re[2]: [Hugs-users] Record puns, time for removal?
If we allow C{..} in patterns we should absolutely have it in
expressions too. Both for symmetry and usefulness.
-- Lennart
On Oct 31, 2006, at 14:06 , Iavor Diatchki wrote:
Hello,
I think the it may be confusing to novices argument tends to be
over-used and we should be careful before we make language decisions
solely based on it. At the very least, when there is a suggestion
that something might be confusing to someone, there should be an
explanation of what/why/to whom it is confusing.
I think record puns are a nice feature, it is easy to explain, and
without them the Haskell record system is less useful, at least to me.
By the way, if I recall correctly, in Johan Nordlander's O'Hugs the ..
notation (called record packing, I think) could also be used to create
record values. I think it worked like this:
data Point = Point { x,y :: Int }
pt = let { x = 3; y = 4 } in Point { .. }
The .. is expanded to {x = x, y = y} based on the fields for the
particular constructor. It seems that if we have the Point { .. }
pattern, we should also have the constructor version. What do people
think?
-Iavor
On 10/31/06, Seth Kurtzberg [EMAIL PROTECTED] wrote:
On Tue, 31 Oct 2006 13:59:45 +0300
Bulat Ziganshin [EMAIL PROTECTED] wrote:
Hello Neil,
Tuesday, October 31, 2006, 4:04:23 AM, you wrote:
puns like Foo { .. } would be great too.
I'd vote for enabling them with a command line switch, rather
than by default, as they can be confusing to folks learning the
language.
How discussions come full circle :) I started this discussion
on the
Hugs users list because I want to _remove_ the command line
switch for
puns from Yhc. I'm not overly fussed whether I remove the entire
feature, or just remove the command line and make it always on by
default, but I do want the command line switch gone!
compiler switch can't be made a part of Haskell' :)
and anyway, i don't see how cmdline switch may help noivices - when
they use .. by mistake and program mysteriously not fails? or
when
they stare at the other's program and understand that this unknown
.. work only because this program compiled with some special
switch?
I wasn't talking about the .., I was talking about the primary
issue raised by the email, which has nothing to do with ..
Instead of assuming that I was saying something totally useless
and worthless, it might not be a bad idea to respond to _my_
email, not an email which contains a quote of one line from my email.
and yes, record puns seems very ggod candidate for H'. it's widely
used (i used it until switched to GHC), it was already in
Haskell, and
now it is impelemnted by every compiler
wildcard puns is more discussible, but i personally need this
feature
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
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: Change Data.Bits.rotate to rotate Integer (unbounded) types
And what would rotating an Integer mean? The only sensible interpretation I can think of is to make it behave like shift. On Sep 18, 2006, at 23:46 , Peter Tanski wrote: Welcome back! Since Data.Bits is not defined in the Haskell 1998 standard, are we free to change the implementation of Data.Bits? if we are free to change the implementation of Data.Bits, would it be all right to change the operation of rotate, rotateL and rotateR over unbounded types (to my knowledge, currently only Integer)? I would like to change rotate, rotateL and rotateR to actually rotate (not shift) Integers. -Pete ___ 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: Floating point problems
On Aug 30, 2006, at 14:58 , David Roundy wrote: On Wed, Aug 30, 2006 at 07:38:35PM +0100, Jamie Brandon wrote: I recently defied my supervisor and used Haskell to write my coursework instead of C. All went well until I needed floating point and started having odd results. As far as I can tell it isn't substantially affecting my results but it is rather embarrassing after slagging off C so much. Here are some examples: *Main 0.2 + 0.1 0.30004 *Main 0.200 + 0.10 0.30004 *Main 0.3 + 0.1 0.4 *Main 0.2 + 0.1 0.30004 *Main it + 0.1 0.4 I assume this is a result of the discrepancy between binary and decimal representations of the numbers. Is there any way around? For a start, it would be nice to have a simple way to get 0.1 + 0.2 == 0.3 = True This is with GHC 6.4.1 and GCC 4.0.3 The trouble here is that ghci is printing more digits than it really ought to be printing. No, I don't think it is. Ghci is printing the number that is closest of all numbers in decimal notation to the Double in question (i.e., 0.1+0.2). Printing it with fewer decimals would yield a different number if it was read back. -- Lennart ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Floating point problems
Slightly tongue in cheek, I think the real problem is that your courses come in the wrong order. No one should use floating point numbers without first having a course in numerical analysis. :) -- Lennart On Aug 30, 2006, at 14:38 , Jamie Brandon wrote: I recently defied my supervisor and used Haskell to write my coursework instead of C. All went well until I needed floating point and started having odd results. As far as I can tell it isn't substantially affecting my results but it is rather embarrassing after slagging off C so much. Here are some examples: *Main 0.2 + 0.1 0.30004 *Main 0.200 + 0.10 0.30004 *Main 0.3 + 0.1 0.4 *Main 0.2 + 0.1 0.30004 *Main it + 0.1 0.4 I assume this is a result of the discrepancy between binary and decimal representations of the numbers. Is there any way around? For a start, it would be nice to have a simple way to get 0.1 + 0.2 == 0.3 = True This is with GHC 6.4.1 and GCC 4.0.3 Thanks, Jamie ___ 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: returning to cost of Integer
Actually, you can keep it to one test for add/subtract if you use a single word that is either a number or a pointer, the pointer being tagged in lowest bit. Then you can add first and check for tags after. Having tags is rare, so the machine should be told so, if possible. This way you can keep the overhead for bignums really low. But it requires very special handling of bignums and I'm not sure it's worth it. -- Lennart On Aug 1, 2006, at 03:02 , Simon Peyton-Jones wrote: If there was an alternative small/big rep, no matter how encoded, it'd still entail conditionals (2 for addition say) to check for that path. And the conditionals also hurt optimisations. But both possibilities would be an interesting thing to try. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow- [EMAIL PROTECTED] | On Behalf Of John Meacham | Sent: 01 August 2006 02:20 | To: glasgow-haskell-users@haskell.org | Subject: Re: returning to cost of Integer | | However because Int is often unboxable where as Integer is never | unboxable there are certainly programs where the factor is much much | greater than x2 or x3. If the Int can be unboxed into an Int# then the | operations are very quick indeed as they are simple machine | primitives. | | This has made me wonder whether we are better off getting rid of the | small integer optimization and turning Integer into a straight | unboxable ForeignPtr to a GMP number. this would also mean we could use | the standard GMP that comes with the system since ForeignPtr will take | care of GCing Integers itself. This was my plan with jhc, but at the | moment, Integer is still just intmax_t. | | Another option would be to keep the small integer optimization but make | it CPR | | data Integer = Integer Int# !(Ptr MPZ) | | where if the Ptr is NULL then the Int# contains the value... | | John | | -- | John Meacham - ⑆repetae.net⑆john⑈ | ___ | 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: returning to cost of Integer
A more clever representation of Integer could unbox numbers in big range. But that would require some runtime support, I think. -- Lennart On Jul 31, 2006, at 11:19 , Duncan Coutts wrote: On Mon, 2006-07-31 at 14:32 +0400, Serge D. Mechveliani wrote: Dear GHC developers, Long ago you wrote that GHC has made Integer only about 3/2 times slower than Int. I tested this once, and then all this time I have been relying on this. Now, with ghc-6.4.1 compiled for Linux - i386-unknown, running under Debian Linux, Intel Pentium III under ghc -O, I have an occasion to repeat the test on a certain simple program for processing lists of length 7 over Integer. And Integer shows 2.55 times slower (11.2 sec against 4.4). Showld we somehow agree that cost(Integer)/cost(Int) in GHC is about 2.55 or maybe we are missing something? The cost difference is varies with the context. In the case that the Int/Integer is always boxed then we might expect a constant factor between Int and Integer (at least for numbers that fit in an Int). However because Int is often unboxable where as Integer is never unboxable there are certainly programs where the factor is much much greater than x2 or x3. If the Int can be unboxed into an Int# then the operations are very quick indeed as they are simple machine primitives. As an extreme example, I just tried with one of my current simple ByteString benchmarks. If we swap Int for Integer in the inner loop of ByteString.map then the time to evaluate (map f . map g) s increases by 37 times! So actually that's not to say that Integer is slow, but rather that in many cases GHC is really pretty good at optimising right down to the low level details. The representation of Integer prevents many of these optimisations. So as I said, the ratio really does depend on what you're doing. Duncan ___ 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: Any way to catch runtime errors in a DLL?
Exceptions generated from Haskell you can catch, but the really bad ones are those that the runtime system itself generates (when something really bad happens, like a failed malloc). I have a set of patches that fixes those, so you can actually write safe DLLs. One of these days I'll file a bug report with them. :) -- Lennart Michael Marte wrote: Hello *, if a runtime error occurs inside a DLL compiled by ghc (like irrefutable pattern match failed or exceptions caused by error), the application that called the DLL function dies. This is ok for development but unacceptable when it happens with a user sitting in front of the display. (It has not yet happened but it's only a question of time.) So my question is: Is there any way to catch and process runtime errors? I am looking for some way to map those errors to exceptions on the C++ side that can be caught if required. It would be ok to kill the Haskell runtime system and unload the DLL if necessary. Michael ___ 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: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
Michael, I've found more bugs. There are several race conditions when a DLL is unloaded. The extra threads that the GHC runtime system starts (at least one is always started to generate timer ticks) are not shut down in a synchronized way. This means that they might be scheduled to run after the DLL has been unloaded. Which gives you an access violation. I don't have a proper fix for this yet. -- Lennart Michael Marte wrote: Lennart, do you imply that you have fixed the problem causing the crashes? May I safely assume that DLLs produced by ghc 6.4.2 will not crash upon being freed? I played around a little bit more and found two configurations that do not crash, at least not when freeing the DLL in the course of quitting the application: - compilation with -O, execution with standard heap size - compilation with -O, execution with -M128m. With 64m initial heap space, the problems described earlier occur again :-( Michael Lennart Augustsson wrote: The memory allocated by the runtime system is never freed. I've submitted a fix fir this. -- Lennart ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
I'm not implying anything, except that I've plugged the space leak of 256M every time a DLL is loadedunloaded. -- Lennart Michael Marte wrote: Lennart, do you imply that you have fixed the problem causing the crashes? May I safely assume that DLLs produced by ghc 6.4.2 will not crash upon being freed? I played around a little bit more and found two configurations that do not crash, at least not when freeing the DLL in the course of quitting the application: - compilation with -O, execution with standard heap size - compilation with -O, execution with -M128m. With 64m initial heap space, the problems described earlier occur again :-( Michael Lennart Augustsson wrote: The memory allocated by the runtime system is never freed. I've submitted a fix fir this. -- Lennart ___ 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: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
The memory allocated by the runtime system is never freed.
I've submitted a fix fir this.
-- Lennart
Michael Marte wrote:
Hello *,
before filing a bug report, I want others to comment on my problem.
Maybe it's my fault, not ghc's.
I wrapped up some Haskell modules in a Win32 DLL.
Loading the DLL dynamically (with LoadLibrary) works fine. However,
whether I actually use the library or not, the program (an application
with MFC GUI) crashes upon termination.
To find the reason for the crash, I added a new function for unloading
the DLL using FreeLibrary. FreeLibrary works fine, however the program
crashes when it returns to the main event loop. Interestingly, when I
reload the library (FreeLibrary followed by LoadLibrary) the program
continues working. However, every reload cycle causes the virtual size
of the process to increase by about 300K and the fourth reload fails
with the error message getMBlock: VirtualAlloc failed with: 8 (appears
in a message window) accompanied by many repetitions of the message
Timer proc: wait failed -- error code: 6 (appears on stderr) and
followed by the message getMBlocks: misaligned block returned (again
in a message window). Then the programm crashes.
Development takes place on Windows XP Professional using MS Visual
Studio 6.0 SP 5 and ghc 6.4.1. There are no references from the C++ side
to the Haskell heap. I build the DLL using the command
ghc --mk-dll -optdll--def -optdllFoo.def -o Foo.dll Foo.o Foo_stub.o
dllMain.c
dllMain.c looks as follows:
#include windows.h
#include Rts.h
extern void __stginit_EUzu3820zu85(void);
static char* args[] = { ghcDll, NULL };
/* N.B. argv arrays must end with NULL */
BOOL
STDCALL
DllMain(HANDLE hModule, DWORD reason, void* reserved) {
if (reason == DLL_PROCESS_ATTACH) {
/* By now, the RTS DLL should have been hoisted in, but we need
to start it up. */
startupHaskell(1, args, __stginit_Foo);
return TRUE;
} else if (reason == DLL_PROCESS_DETACH) {
shutdownHaskell();
}
return TRUE;
}
I played around with hs_exit instead of shutdownHaskell, I moved
initialization and clean-up from DllMain to my library loader, nothing
helps. Even doing no clean-up whatsoever does not change the behaviour.
Any ideas?
Michael
___
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: Bootstrapping with HC files
Donald Bruce Stewart wrote: Most distros are using binary bootstrapping. I think OpenBSD is the only one building from .hc src. And NetBSD. -- Lennart ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Optimizations for mutable structures?
Simon,
Don't worry, your implementation (and any implementation)
has strong fairness. Just run it enough times that the
hardware fails in the way peoplewant. ;)
Jest aside, I'm totally on your side in this discussion.
Asking an implementation to promise to generate all possible
interleavings is just stupid. That way lies madness...
(and slowness!).
-- Lennart
Simon Marlow wrote:
On 07 December 2005 19:57, Claus Reinke wrote:
there seem to be two issues here - can we agree on that at least?
1) scheduling non-sequential programs on sequential processors
i wasn't arguing that the scheduler should realise all possible
interleavings at once. the issue i was referring to is known as
fairness in concurrent systems literature. as with referential
transparency, various non-equivalent definitions are in use,
but one informal description might be something like:
if, for a given experiment, some event is possible according to
the semantics, it should happen eventually if the experiment is
repeated often enough.
see, eg,
http://research.microsoft.com/users/lamport/pubs/pubs.html#lamport-fairn
ess
Yes, good point. Regarding fairness, I've been working with the
assumption that we don't need to preserve (certain kinds of) fairness
properties when performing optimisations, whereas you and others want to
preserve all fairness.
Why don't I care about preserving fairness? Well you said it - it's not
practical to implement. And since the implementation already doesn't
guarantee strong fairness (or whatever it's called), it doesn't do any
harm to weaken the fairness that we do provide, because programmers
can't rely on strong fairness anyway. In practical terms, you won't
notice the difference.
Furthermore, I'd go so far as to say that a program that relies on the
kind of fairness we've been talking about (arbitrary interleaving) for
correctness or termination, is broken.
We ceratinly *do* care about some kind of fairness. The property that
we try to maintain is something like this:
If a thread is unblocked according to the semantics, then the
implementation ensures that it runs after a finite time.
I'm not familiar with the fairness literature, perhaps this property is
known?
You may well call our implementation incomplete because it doesn't
implement full fairness. I don't think that's useful though; I'd much
rather characterise exactly what fairness property we can and do
implement, and use that for reasoning with.
[snip]
2) compiler optimisation validity in sequential and non-sequential
environments
the original motivation of this thread - are sequential
transformations still valid in a non-sequential setting?
in general, the answer is no, to the surprise/annoyance of many many
compiler implementors who want their valuable optimisations to work
even when their sequential language acquires threads.
I don't think this applies in our setting. The reason we have IORef and
{M,T}Vars, and not just a single mutable reference type, is that
{M,T}Vars provide strong consistency guarantees when used to communicate
between threads, whereas IORefs do not. Hence, IORefs can be
implemented with much fewer restrictions.
If you share IORefs between threads and run on a multiprocessor, you are
at the mercy of both sequential optimisations and your architecture's
memory consistency guarantees. In other words, don't do it. Use
communication primitives that have strong properties in a multi-threaded
setting.
i'd really, really prefer concurrent haskell not to go down a route
in which demands of simpler implementation leads to subtle problems
in reasoning about programs.
If you think any of this impacts your ability to reason about programs,
please elaborate - I don't think it does.
Cheers,
Simon
___
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: GHCI and archive libraries.
You can write a simple shell script wrapper around ghci that takes care of .a files. -- Lennart Keean Schupke wrote: Thaks guys... I realise it is a simple matter of unpacking the object files, however when using ghci for prototyping, it can be more convenient to have all the '.o's packed into a '.a'. As it is a simple matter to extract the .o files from the .a, I would have thought a fairly small change to the ghci code would have enabled using archive libraries. I think this change would aid usability. I don't know the ghci code at all, so it would take me a long time to make this change, as I would first have to understand the existing code. I was wondering if anyone familier with the ghci code could add archive library support? I suppose as a work around I could write a wrapper for ghci that extracts the .o files from the .a to a temp directory, and then calls ghci with the .o files on the command line. Regards, Keean. Sven Panne wrote: Am Samstag, 3. Dezember 2005 15:17 schrieb Lennart Augustsson: And on many platforms (well, at least a few years ago) a shared library doesn't have to be PIC. The dynamic loader can do relocation when it loads the file. (Then it can't be shared.) But this was a few years ago on Solaris and BSDs, it could be different now. After a quick look this seems to be the case on current x86 Linux systems, too: Real shared libraries consist of PIC to enhance sharing code at runtime, but nevertheless the dynamic loader seems to be able to load and relocate non-PIC, at the cost of less sharing, but often slightly better code quality. So the mentioned repacking of a static library into a partially linked object file might work for most common platforms. Cheers, S. ___ 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: GHCI and archive libraries.
Can't you unpack the ar library and then link the object files into a shared library? -- Lennart Keean Schupke wrote: GHCI does not load archive libraries. Is it possible (easy?) to get it to load (.a) archive libraries as well as .o and .so files? The problem is some optimized cblas libraries are not available as shared libraries due to the performace loss. Regards, Keean. ___ 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: GHCI and archive libraries.
And on many platforms (well, at least a few years ago) a shared library doesn't have to be PIC. The dynamic loader can do relocation when it loads the file. (Then it can't be shared.) But this was a few years ago on Solaris and BSDs, it could be different now. -- Lennart Sven Panne wrote: Am Samstag, 3. Dezember 2005 14:48 schrieb Lennart Augustsson: Can't you unpack the ar library and then link the object files into a shared library? On most platforms the code in a *.a library is not shared library code, e.g. it is not PIC or something like that. Nevertheless, I think that the *.o files GHCi loads are not exactly shared libraries, they are incrementally linked relocatable object code (correct me if I'm wrong here, the details of shared libraries are still a kind of black art...). So you might have luck with unpacking and re-linking like that: ar x libblah.a ld -r -x -o /my/new/blah.o *.o The linker flags for doing this vary, depending on the platform, you can have a look at GHC's autoconf magic for hints if it doesn't work like mentioned above. Cheers, S. ___ 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: jhc vs ghc and the surprising result involving ghcgeneratedassembly.
Simon Marlow wrote: Is it correct that you use indirect gotos across functions? Such gotos aren't supported by GCC and work only by accident. Yes, but cross-function gotos are always to the beginning of a function. Is that enough to ensure that the constant pool base register is reloaded on the Alpha? -- Lennart ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: unsafeness of unsafeInterleaveIO
You pick. :) It can break referential transparency. It can break type safety. -- Lennart Andre Pang wrote: G'day all, Just looking at the documentation for System.IO.unsafeInterleaveIO, what exactly is unsafe about it? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: unsafeness of unsafeInterleaveIO
Andre Pang wrote: On 10/06/2005, at 11:16 AM, Remi Turk wrote: Are you sure you're not talking about unsafePerformIO? System.IO.Unsafe.unsafePerformIO:: IO a - a System.IO.Unsafe.unsafeInterleaveIO :: IO a - IO a [written to Lennert Augustsson]: yes, I think you misread unsafeInterleaveIO as unsafePerformIO, Lennert :) Indeed I did. :) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Re: Double - CDouble, realToFrac doesn't work
Henning Thielemann wrote: On Fri, 5 Nov 2004, Robert Dockins wrote: What IEEE has done is shoehorned in some values that aren't really numbers into their representation (NaN certainly; one could make a convincing argument that +Inf and -Inf aren't numbers). I wonder why Infinity has a sign in IEEE floating processing, as well as 0. To support this behaviour uniformly one would need a +0 or -0 offset for each number, which would lead straightforward to non-standard analysis ... IEEE floats support both affine (signed) and projective (unsigned) infinity. Projective is more natural in some circumstances (since you can do a Möbius transformation from a circle to an infinite line). Haskell, on the othet hand, does not let you specify the mode. -- Lennart ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: constant space `minimum'
On Thu, 30 Sep 2004, Serge D. Mechveliani wrote: I thought naively that the Report function definitions can be treated more flexy, varied by implementations, with preserving some declared main properties. The definitions in the Report are to be treated as specifications. Any implementation should have *exactly* the same denotation as the function in the Report. What use would the Report be if you didn't treat it this way? -- Lennart ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: optimization question
Simon Peyton-Jones wrote: generate case expressions when there is more than one string in the list, otherwise use an equality test Oh, you mean like hbc does? ;-) Sorry, couldn't resist. -- Lennart ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to modify GHC internals?
Aim To guarantee security of a Haskell program so it can be used as an applet. /Aim Method Over-ride GHC's code generator to produce an assembly language that I specify. Also disable program access to system calls and foreign functions, except for a single trusted library that I specify. /Method Since all effects that you worry about (if you trust GHC's code generation, and I think you should) happen in the IO monad, you only need to limit what's available as libraries, and outlaw unsafePerformIO. You could also make your own version of the IO monad to get better control. -- Lennart ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: buffering woes
Malcolm Wallace wrote: Hal Daume III [EMAIL PROTECTED] writes: Not for me, GHC 5.04.2 (Solaris). here it goes right the first time, but then i have to type two more letters (in this case 'b\n') to get it to respond to hello. Solaris has a slightly bizarre buffering scheme in raw terminal mode, whereby it buffers 4 characters at a time, instead of passing on each character immediately. Try stty -icanon min 1 (or something similar) to fix it? Someone must have failed setting the tty mode. :-) The 4 is (if I remember right) the VMIN value which is stored in the same place as the EOF (^D = 4) character. It has to be set to 0 when placing the tty in raw mode. -- Lennart ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Floats and Doubles
Yes, they all seem to be right. You get these funny effects because numbers like 5.2 do not have an exact representation with floating point numbers in base to (like Float and Double most likely have on your machine). The number 5.2 is stored as a slightly different number as a Float, but the toRational function is exact so it gives you the number corresponding to the internal representation. Take a course on numerical analysis. :) -- Lennart Juan Ignacio Garcia Garcia wrote: hello, I have been using some of the functions of the classes Real and Fractional and I have observed that with the funcion toRational we can obtain the fraction that represents a given number. For instance: *P2 toRational (5.2::Float) 5452595 % 1048576 Why we obtain this numbers instead of 52 % 10 or 26 % 5? I have also obtained the following results with the functions fromRational and toRational: *P2 (fromRational ((toRational 4) - ( toRational (5.2::Float) )))::Double -1.198092651367 *P2 (fromRational ((toRational 4) - ( toRational (5.2::Double) )))::Double -1.2002 *P2 (fromRational ((toRational 4) - ( toRational 5.2 ))) -1.2002 *P2 (fromRational ((toRational 4) - ( toRational (5.2::Float) )))::Float -1.198 Are all these results ok? If this is the case, why? Thanks, Ignacio ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: createAdjustor for Alpha (and Sparc)
Ken Shan wrote:
such that calling
(*adjustor)({argument values})
is equivalent to calling
(*wptr)(hptr, {undefined/ignored pointer}, {argument values}).
This goal seems difficult to achieve on the Alpha, since its
complicated calling convention puts arguments in registers, and we
don't know how many arguments there are, let alone how to adjust the
stack if needed.
And it's very complicated on the MIPS too where the argument passing
convention depends on the type of the arguments. Perhaps the GHC
way is too simplistic? I did these kinds of things for a number of platforms
many years (8?) ago and came to the conclusion that the most realiable
way was to create a fast array of functions for different argument combinations.
Once you get beyond a certain number of arguments all platforms start
using the stack and then you are safe again.
But it's a mess.
-- Lennart
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Converting float to double.
How? RULES similar to ghc? Or built-in compiler magic for this case? Built in magic. Since this was the only way to convert between floating types it obviously needed a special case. -- Lennart
RE: Converting float to double.
The compiler cannot guess that some primitive Float-Double function can be used instead of going through Rational. If enough inlining is done, then it should be able to deforest the intermediate Rational and generate the same code. But I agree, using RULES here is quicker and doesn't rely on some hefty unfoldings. Unless ghc has gotten incredibly clever I don't believe that. Look at the code involved in such a conversion. It involves, among many other things, encodeFloat and decodeFloat. So unless you have taught ghc about how floating point numbers are represented on all your target machines (I mean, it doesn't have to be IEEE) you can't really inline these at compile time. No, this is a perfect example of where you need a RULE. (BTW, hbc has optimized these conversion since about 6 years ago.) -- Lennart
Re: Dear Santa (Error Messages)
George Russell wrote: Disagree. I think it's nice fast. I challenge you to write a faster Haskell parser using a combinator library. Parser combinators are fine if the grammar is very simple or you don't care about CPU times. But using them in a serious compiler for Haskell would be like building a computer out of stone knives and bearskins. So this is your opinion, what kind of evidence have you got for this claim? -- -- Lennart
Re: Dear Santa (Error Messages)
Simon Marlow wrote: Nonsense. I contend that you really don't want an error-correcting parser. - parsing is quick - error-correction is by definition unreliable - error-correction is hard to implement well I agree, I find that I often only fix the first error even if the compiler has error recovery, because it so often recovers wrong. -- -- Lennart
Re: ghc-4.02 -- space.
Parting shot: isAlphaNum vs. isAlphanum? Haven't we been here before? Don't the committee have more amusing (and less pointless and gratuitously program-breaking) things to tinker with? (I know, nothing to do with ghc, I'm just in a mood to 'give out'...) Ah, but each new committee has to make a few gratuitous changes to put their mark on the language. And they should be such that the user feels it. This is not the only pointless thing we changed. ;-) -- Lennart
Re: Existentially quantified types and ``deriving Eq''
The correct behaviour would be to let the above pattern match fail in the case of different types at r1 and r2, because the left-hand side has to have a typing with equal types for r1 and r2 induced by the right-hand side ``r1 == r2''. But now you are assuming that there is an intentional representation of the type available at run time so that it can be tested. This pretty much against the Haskell spirit where types are compile time entities, and not available at runtime. If you need them at runtime you need sometjing like type Dynamic. No, I think the ghc (and hbc) does it is teh only reasinable way for Haskell. If you can't define the (==) function by hand there is no reason why a derived function should be possible. -- Lennart
Re: heap exhausted
Did I understand the strictness of the case statement right: case z of z' forces that z' (and z) will be in head normalform? Yes, that's right. I might have missed some of the context here, but case z of z' - e is the same as let z' = z in e according to the Haskell semantics, so it doesn't force anything to whnf. -- Lennart
