Re: Pattern synonym 'Required' constraints === Datatype Contexts(?)

[Lennart Augustsson]

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

[Lennart Augustsson]

For instance, at your day job, the Array type.

On Wed, Oct 5, 2011 at 12:23 PM, Roman Leshchinskiy wrote:

> 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

[Lennart Augustsson]

What are the defaulting rules for IsList?  It needs to be backwards compatible.

   -- Lennart (iPhone)

On Sep 30, 2011, at 19:28, George Giorgidze  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

[Lennart Augustsson]

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  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
>  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
>> |   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

[Lennart Augustsson]

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  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)

[Lennart Augustsson]

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
 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

[Lennart Augustsson]

Thanks!

On Sat, Mar 27, 2010 at 11:59 PM, Ian Lynagh  wrote:
> On Thu, Mar 25, 2010 at 10:14:34PM +0000, 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

[Lennart Augustsson]

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  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=new&status=assigned&status=reopened&priority=highest&priority=high&milestone=6.12.2&order=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

[Lennart Augustsson]

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
 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  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?

[Lennart Augustsson]

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-Jones 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.*

[Lennart Augustsson]

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  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?

[Lennart Augustsson]

Excellent, is there a -fuse-catch flag for ghc? :)

On Tue, May 19, 2009 at 12:01 PM, Neil Mitchell  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?

[Lennart Augustsson]

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  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?

[Lennart Augustsson]

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
 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

[Lennart Augustsson]

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  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?

[Lennart Augustsson]

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  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?

[Lennart Augustsson]

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.

But I don't think that bug at all affects the function you had in your
original email.

  -- Lennart

On Thu, Mar 26, 2009 at 5:39 PM, Claus Reinke  wrote:
> Sorry to be the odd man out - perhaps an example will help to
> clarify my reading of the language definition.
>
>> 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.
>
> When you say "test", which can decide multiple arms in a case, do you
> mean that, say 'null e' being 'True' implies that matching '[]' against 'e'
> will succeed while matching '_:_' against 'e' will fail? Because that kind
> of test is not what the Haskell'98 report talks about. It talks about
> individual matches of  expressions against alternatives, and it does
> specify precisely in what order these are to be performed, hence
> which pattern is reached first:
>
>   A case expression is evaluated by pattern matching the expression e
> against the individual alternatives. The alternatives are tried
> sequentially,   from top to bottom.
>
>   Patterns are matched against values. Attempting to match a pattern can
> have one of three results: it may fail; it may succeed, returning a binding
>   for each variable in the pattern; or it may diverge (i.e. return _|_).
> Pattern matching proceeds from left to right, ..
>
> Nothing abstract about that. So for a function application 'f e', where
>
>   f [] = True
>   f (_:_) = False
>
> the Haskell'98 report specifies that 'e' is first matched against '[]', then
> (if that fails) against (_:_). So the first pattern is reached/tried before
> the second. Of course, we can make use of the fact that these two
> matches are complementary, so we only need one "test" to decide,
> and if there are further '[]' patterns after the first, we don't have to
> match them again, but that is all in the realm of optimization, not language
> definition.
> The definition explicitly provides room for such optimization, but it still
> requires conformance to the rules set out in the definition, which include:
>
>   case e of {p1->e1;p2->e2} =   case e of {p1->e1;_->case e of
> {p2->e2;_->error "No match"}}
>
> GHC violates that rule, as we can demonstrate:
>
>   newtype N = N Int deriving (Show,Eq)
>     instance Num N where
>     fromInteger 0 = error "0"
>     fromInteger 1 = N 0
>     fromInteger _ = N 1
>     f x = case x of
>           1 -> False
>           0 -> True
>     g x = case x of
>           1 -> False
>           _ -> case x of
>                 0 -> True
>                 _ -> error "No match"
>     main = do
>     print $ g (N 0)
>     print $ f (N 0)
>
>   -- ghc
>   $ ghc -w -e main PMOrderSpec.hs
>   False
>   : 0
>
>   -- hugs
>   Main> main
>   False
>   False
>
> One can presumably construct similar examples using 'Data.String.IsString',
> or using pattern guards, so just fixing the special case of 'Num' is not
> going
> to help, but this example seems firmly within Haskell'98.
>
>> 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.
>
> Any semantics should conform to the language definition, right?
>
>> On the other hand, adding some kind of pragma that indicates the
>> likelyhood of a branch seems quite sensible to me.
>
> Which doesn't mean that I wouldn't try such a pragma, if it existed.
> I'm just having difficulties understanding this universal resistance to
> what seems one of the few unambiguously defined parts of Haskell'98;-)
>
> 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?

[Lennart Augustsson]

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  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?

[Lennart Augustsson]

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  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 

Re: compilation of pattern-matching?

[Lennart Augustsson]

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
 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?

[Lennart Augustsson]

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  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?

[Lennart Augustsson]

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  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: ANNOUNCE: GHC 6.10.2 Release Candidate 1

[Lennart Kolmodin]

Ian Lynagh wrote:
> We are pleased to announce the first release candidate for GHC 6.10.2:
> 
> http://www.haskell.org/ghc/dist/6.10.2-rc1/
> 
> This includes two source bundles:
> 
> ghc-6.10.1.20090314-src.tar.bz2
> ghc-6.10.1.20090314-src-extralibs.tar.bz2

Awesome!

This release candidate is also available for testing purposes through
the gentoo haskell overlay. http://code.haskell.org/gentoo/gentoo-haskell/

You can use the overlay either through layman (overlay called haskell)
http://www.gentoo.org/proj/en/overlays/userguide.xml
or by yourself a la old school, PORTDIR_OVERLAY in make.conf.

We don't yet have any ebuilds for the extralibs.

GHC is hard masked, meaning only available for testing purposes, use
caution :)

 $ echo dev-lang/ghc >> /etc/portage/package.unmask

It's also keyworded ~amd64 ~x86, meaning you'll have to allow
potentially unstable packages:

 $ echo dev-lang/ghc >> /etc/portage/package.keywords

Last but not least, the ebuild does not provide any bootstrapping binary
to compile ghc, so you need to already have a version of ghc installed
to bootstrap with. Then emerge with

 $ USE="ghcbootstrap -binary" emerge dev-lang/ghc

Please report any issues in #gentoo-haskell @ freenode.

Cheers,
  Lennart Kolmodin -- Gentoo Dev
___
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?

[Lennart Augustsson]

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 :
> 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

[Lennart Augustsson]

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  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

Re: git

[Lennart Augustsson]

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  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

git

[Lennart Augustsson]

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: length of module name affecting performance??

[Lennart Augustsson]

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  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

[Lennart Augustsson]

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: ANNOUNCE: GHC version 6.10.1

[Lennart Kolmodin]

Hello fellow GHC users,


Ian Lynagh wrote:

   ==
The (Interactive) Glasgow Haskell Compiler -- version 6.10.1
   ==


[snip]



How to get it
~

The easy way is to go to the web page, which should be self-explanatory:

http://www.haskell.org/ghc/


Gentoo Linux users can get it from the gentoo-haskell overlay[1].

If you're not familiar with this overlay (a gold mine for haskell 
hackers using gentoo), you can easily use layman[2] to get access. Make 
sure you have darcs installed, as it is a requirement for our overlay.


Once layman is set up, add the overlay with:

 $ layman -a haskell

Note that ghc-6.10.1 still is masked by keyword, and you need to unmask 
it first. If you're not familiar with how to do this, here's a quick guide:


 # make sure /etc/portage exists
 $ [[ -d /etc/portage ]] || mkdir /etc/portage
 # accept ghc being ~arch
 $ echo "dev-lang/ghc" >> /etc/portage/package.keywords
 # ghc requires the very latest libedit package
 $ echo "dev-libs/libedit" >> /etc/portage/package.keywords

You may then install ghc-6.10.1 by saying:

 # this requires that you already have an older ghc version installed
 $ USE="ghcbootstrap -binary" emerge ghc

The USE flags are required as we don't just yet provide the required 
binaries to bootstrap ghc. The command above requires that you already 
have a ghc version installed to bootstrap with. This version will be 
replaced with ghc-6.10.1 once the installation finishes.


GHC binaries will follow shortly, which will shorten the procedure to:

 $ emerge ghc

The packages from extralibs will also be available from the overlay.

If you run into trouble, reply to the ml, or find us in #gentoo-haskell 
at freenode.


Cheers,
  Lennart Kolmodin -- using his Gentoo Linux Developer hat

 [1] http://code.haskell.org/gentoo/gentoo-haskell/
 [2] http://www.gentoo.org/proj/en/overlays/userguide.xml
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC 6.10.1 RC 1

[Lennart Kolmodin]

Anatoly Yakovenko wrote:

I am using the gentoo package for 6.10.1 and when i start ghci it
tries to allocate over 1gb of memory, which hits my ulimit.

Is anyone else getting absurd memory usage when trying to start ghci?
$ ghci
GHCi, version 6.10.0.20081007: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
ghc: out of memory (requested 1048576 bytes


Likely the same bug we've seen before with libedit, or related;
GHC bug reported at http://hackage.haskell.org/trac/ghc/ticket/2716 
(closed as invalid as the problem isn't with GHC)

Gentoo bug report at http://bugs.gentoo.org/237882 to fix gentoo's libedit.

You can try to apply the patch in the gentoo bug locally and see if that 
resolves the issue.


Cheers,
  Lennart K

___
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?

[Lennart Augustsson]

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: Strictness in data declaration not matched in assembler?

[Lennart Augustsson]

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: ANNOUNCE: GHC 6.10.1 RC 1

[Lennart Kolmodin]

Ian Lynagh wrote:

We are pleased to announce that the GHC 6.10.0.20081007 snapshot is the
first release candidate for GHC 6.10.1.

You can download the release candidate from here:
http://www.haskell.org/ghc/dist/stable/dist/6.10.1-rc-1/rc.html
This page includes:
* a Windows installer
* an OS X installer
* bindists for amd64/Linux and ix86/Linux
* the sources



It's also available in Gentoo Linux, hard masked.

If you're not already familiar with the Gentoo Haskell overlay, use 
layman[1] to get the haskell overlay and unmask[2] the packages 
dev-lang/ghc and dev-haskell/cabal.


Then, simply:

 $ emerge ghc

Cheers,
  Lennart Kolmodin

 [1] http://www.gentoo.org/proj/en/overlays/userguide.xml
 [2] http://gentoo-wiki.com/Masked#Hard_Masked
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: desperately seeking RULES help

[Lennart Augustsson]

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

[Lennart Augustsson]

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: desperately seeking RULES help

[Lennart Augustsson]

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: ANNOUNCE: GHC 6.8.3 Release Candidate

[Lennart Augustsson]

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?

[Lennart Augustsson]

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

[Lennart Augustsson]

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

[Lennart Augustsson]

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/---
>
> ___
> 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

[Lennart Augustsson]

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

[Lennart Augustsson]

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

[Lennart Augustsson]

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

[Lennart Augustsson]

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: GHC 6.8.1 is impressive!

[Lennart Augustsson]

I'd like to second that.  6.8 is quite an improvement.  Well done!

  -- Lennart

On Nov 8, 2007 12:18 PM, Ravi Nanavati <[EMAIL PROTECTED]> wrote:
> I just finished a running Bluespec's regression suite on a version of
> our tools compiled with ghc 6.8.1. The results were impressive on two
> fronts:
>
> 1. All of our tests (almost 14,000) had the same behavior as with ghc 6.6.1
> 2. Our Haskell code was roughly 33% faster (relative to ghc 6.6.1). It
> seems that pointer-tagging made a big difference for our code base
> (since, if I'm reading the release notes correctly, constructor
> specialization isn't in yet).
>
> We just wanted to take a moment to say that we were pleasantly
> surprised by ghc 6.8.1 (so much so that we're going to try and use it
> for released builds sooner than we would have otherwise planned) and
> to thank everyone involved for the effort they put into it.
>
> Thank you,
>
>  - Ravi Nanavati (and the rest of Bluespec, Inc.)
> ___
> 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

[Lennart Augustsson]

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

ghc-pkg bash completion

[Lennart Kolmodin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all!

I wrote a bash completion to ghc-pkg last year, just cleaned it up a bit
and thought I should share it with you guys.

You get your copy by typing:

; darcs get http://haskell.org/~kolmodin/code/ghc-bash-completion/

Then, to load it (quick'n'dirty without proper install):

; cd ghc-bash-completion
; source ./ghc-pkg
; source ./ghci

A session could look like:

; ghc-pkg   # hit the tab key twice.
  # it gives your valid options
- --auto-ghci-libs  --package-conf=   -Vhide
- --define-name=--simple-output   -flatest
- --force   --user-glist
- --global  --version describe  register
- --global-conf=-?exposeunregister
- --help-Dfield update

; ghc-pkg hide  # gives you a list of
  # packages and optional flags

The ghci support is very minimalistic at this point... it only completes
on packages.

That's it!

Cheers,
  Lennart
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGsiF14txYG4KUCuERAnxMAJ4nzs8UPrNGevihKKVdSnsyOy3+twCgqQ0J
itCHvhD13LEE88UBjBsmXmA=
=Sndh
-END PGP SIGNATURE-
___
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

[Lennart Augustsson]

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 
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

[Lennart Augustsson]

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: GADT + Newtype deriving = Erroneous errors

[Lennart Augustsson]

We don't have to wait for the type checkers to rule.  The semantics  
of GADTs is pretty clear (if it's implemented correctly is another  
matter).  If you write

   data IsIntT x where
 IsIntT :: IsIntT Int
then there is only one (non-bottom) value in the IsIntT families of  
types and that is IsIntT::IsInt Int


And since Haskell uses nominal type equality there is no type equal  
to Int that is not Int.


The fact that you can derive IsIntC looks like a good ole' bug to me.

    -- Lennart


On Mar 28, 2007, at 23:22 , Stefan O'Rear wrote:


On Wed, Mar 28, 2007 at 12:03:41PM +0100, Chris Kuklewicz wrote:

Stefan O'Rear wrote:

On Tue, Mar 27, 2007 at 11:32:29AM +0100, Chris Kuklewicz wrote:

Stefan O'Rear wrote:



newtype Foo = Foo Int deriving(IsIntC)





Note that (Foo 2) + 2 is an attempt to add a Foo and an Int,  
which cannot

possibly compile.  So I replaced it with just a 2.


Why not?  They are the same type, and I have Curry-Howard proof  
of this fact.


Stefan


Foo is isomorphic to Int in structure.  But it is not the same  
type.  Foo is a
new type that is distinct from Int.  That means I get type safety  
-- you cannot
pass an Int to a function that expects a Foo and vice versa.   
Since (+) is
defined as (Num a => a->a->a) it cannot add type different types  
and thus you

*cannot* add a Foo and an Int.


Well, I thought I had a non-bottom value of type IsIntT Foo, but when
I tried to seq it ghc crashed: http://hackage.haskell.org/trac/ghc/ 
ticket/1251


Let's postpone this discussion until the people who maintain the
typechecker have a chance to rule :)

Stefan
___
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: Feature proposal: ghc --full-flag-help ?

[Lennart Augustsson]

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: Parsing GHC Core

[Lennart Kolmodin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Neil Mitchell wrote:
> Hi,
> 
> I would like to parse GHC Core to an abstract syntax tree, as the old
> GHC Core library used to allow the user to do. I do not want to depend
> on the GHC API (too big), but don't mind depending on a small and
> separately available .cabal'd package. I also don't mind copying a few
> modules into my program. The types are of no interest to me, if that
> makes it any easier
> 
> Does anyone have the code/library to do this sitting around?

I belive Aarne Ranta wrote a parser for some Core language of GHC 5 a
couple of years ago. Um... 2003. It seems to be part of the bnfc[1]
tarball as an example. Perhaps you can use that somehow?

[1] http://www.cs.chalmers.se/~markus/BNFC/

Cheers,
  Lennart Kolmodin
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF8ET04txYG4KUCuERAmmoAJ4jto4N+d9uEBhE7Z/+fofhTqGePwCgm023
dpCTk9bHmGIXVm5xYuiDQDc=
=XEXw
-END PGP SIGNATURE-
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: unsafePerformIO safety.

[Lennart Augustsson]

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.

[Lennart Augustsson]

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: hasktags - small patch

[Lennart Kolmodin]

Marc Weber wrote:

Without really knowing in which context this function is going to be

HaskTags.hs from ghc distribution.

Mm, yes. I meant I was to lazy to check which results are appropriate :)

K
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: hasktags - small patch

[Lennart Kolmodin]

Marc Weber wrote:

This small patch introduces a now mywords function which recognizes a::b as 
words a,::,b
which is what we need here (?) It does work in the above example.

Here is the diff. Is it worth applying?

154c154
<   let wordlines = map words aslines
---

  let wordlines = map mywords aslines

161a162,174

  -- my words is mainly copied from Data.List.
  -- difference abc::def is split into three words instead of one.
  mywords :: String -> [String]
  mywords (':':':':xs) = "::" : mywords xs
  mywords s   =  case dropWhile {-partain:Char.-}isSpace s of
  "" -> []
  s' -> w : mywords s''
where (w, s'') = myBreak s'
  myBreak [] = ([],[])
  myBreak (':':':':xs) = ([], "::"++xs)
  myBreak (' ':xs) = ([],xs);
  myBreak (x:xs) = let (a,b) = myBreak 
xs
   in  (x:a,b)


Without really knowing in which context this function is going to be
used, expected results and so on, I've cooked up another alternative.
Naturally it's possible to remove the spaces too if it's really required.


let wordlines =
  map (groupBy (\a b -> isVarChar a == isVarChar b)) aslines
isVarChar x = any ($ x) [isDigit, isAlpha, (== '_'), (== '\'')]


It parses

data LogInController =
  LogInController {rLoggedIn::R Bool, rwUserName::RWE String,
rwPasswd::RWE String}

as

["data"," ","LogInController"," = ","LogInController","
{","rLoggedIn","::","R"," ","Bool",", ","rwUserName","::","RWE","
","String",", ","rwPasswd","::","RWE"," ","String","}"]

Cheers,
  Lennart K

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell] GHC Error question

[Lennart Augustsson]

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

[Lennart Augustsson]

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" 
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
| 

Re: [Haskell] GHC Error question

[Lennart Augustsson]

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

[Lennart Augustsson]

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: Type wildcards, was: Re: [Haskell] GHC Error question

[Lennart Augustsson]

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: Type wildcards, was: Re: [Haskell] GHC Error question

[Lennart Augustsson]

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

[Lennart Augustsson]

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: [Haskell] GHC Error question

[Lennart Augustsson]

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: Common subexpression elemination (CSE)

[Lennart Augustsson]

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)

[Lennart Augustsson]

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: Gtk2Hs and GHC 6.6

[Lennart Kolmodin]

> I'm trying to build Gtk2Hs under GHC 6.6.  I've built it successfully
> under 6.4.1 and 6.4.2 -- no muss, no fuss, no bother.  Something big
> seems to have changed in 6.6, however, that breaks the Gtk2Hs build in a
> bad way.  Here are some representative errors:
>
> First, we see that it did find the right GHC version:
>
> checking for ghc... /usr/local/bin/ghc
> checking version of GHC... 6.6
> checking for ghc-pkg... /usr/local/bin/ghc-pkg
>
>
> But now we get some strange package problems.  Each of these is a
> representative.  The full build has dozens of these -- I think I've got
> each flavour though:
>
>
> tools/c2hs/base/general/Binary.hs:59:7:
> Could not find module `Data.FiniteMap':
>   Use -v to see a list of the files searched for.
> make[1]: *** Deleting file `tools/c2hs/c2hsLocal.deps'
>
> tools/c2hs/base/admin/Common.hs:54:0:
> Failed to load interface for `Config':
>   it is a member of package ghc-6.6, which is hidden
> make[2]: *** [tools/c2hs/base/admin/Common.o] Error 1
> make[2]: Leaving directory
> `/home/michael/Development/Gtk2Hs/gtk2hs-0.9.10'
> make[1]: *** [glib/System/Glib/Types.hs] Error 2
> make[1]: Leaving directory
> `/home/michael/Development/Gtk2Hs/gtk2hs-0.9.10'
>
> : can't find file: glib/System/Glib/Types.hs
> make: *** Deleting file `glib/libHSglib_a.deps'
>
> glib/System/Glib.hs:12:0:
> Failed to load interface for `System.Glib.UTFString':
>   Use -v to see a list of the files searched for.
> make[1]: *** [glib/System/Glib.o] Error 1
> make[1]: Leaving directory
> `/home/michael/Development/Gtk2Hs/gtk2hs-0.9.10'
> make: *** [all] Error 2
>
>
> So I'm left with the question: what am I doing wrong (if anything)?  Or
> what do I need to do to get Gtk2Hs to compile under 6.6?

The problem is that gkt2hs 0.9.10 doesn't support GHC 6.6.
Try the darcs version instead:

darcs get --partial http://darcs.haskell.org/gtk2hs/

As usual, it will be released when it's ready :)

Cheers,
  Lennart Kolmodin

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: hsman

[Lennart Kolmodin]

> Hi
>
>> How would it work on Unix? I assume that the command-line program just
>> takes it's input "from the command line", so it doesn't get invoked
>> until after you've finished typing the command...

Not necessarily true if completion is involved ... see below.

> However, I know that zsh can do funky things like
> autocompleting ssh paths etc - and I think I remember seeing that
> there was some way a program could tell zsh what it could autocomplete
> to - but that is a hazy memory from a while ago.

Have a look at the (unreleased) bash completion for ghc-pkg:

http://www.haskell.org/~kolmodin/code/ghc-bash-completion/ghc-pkg

source it in bash to get it started.
As you can see that ghc-pkg doesn't have special support for
autocompletion, but it's possible anyway.

To make it a bit simpler to write the completion, it's nice if the
application in question has support for it. A nice example of this is
darcs[1] which implements the command '--commands' and the flag
'--list-option'.

Cheers,
  Lennart Kolmodin

[1] http://www.abridgegame.org/repos/darcs-unstable/darcs_completion

___
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?

[Lennart Augustsson]

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: GHC on MacOS

[Lennart Augustsson]

I could set you up with an account on my laptop, it's mostly  
connected to the Internet, but sometimes I take it with me.


If you don't get any other offers, tell me.

It's x86 MacBook.

    -- Lennart

On Sep 28, 2006, at 06:01 , Simon Peyton-Jones wrote:


Folks

Quite a few of you are using GHC on MacOS -- for example, there were
lots of Macs at the GHC Hackathon earlier this month.  However, we  
don't
have access to a machine running MacOS, so it's pretty difficult  
for us

to deal with bug reports.

So this message is to ask:

a) Can anyone give us remote access to a Mac?

b) Does anyone feel able to help look after GHC's Mac port?

Simon, Simon, and 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: Change Data.Bits.rotate to rotate Integer (unbounded) types

[Lennart Augustsson]

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

[Lennart Augustsson]

On Aug 30, 2006, at 20:44 , Jan-Willem Maessen wrote:



On Aug 30, 2006, at 6:04 PM, Lennart Augustsson wrote:



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.


I always wondered why we didn't instead ask for "the number that  
has the fewest digits of significand which converts to the Double  
in question."  Of course, for doubles with a single ulp of  
difference, that's still an awfully long decimal.
The reading and printing of floating point numbers in Haskell is  
patterned after two PLDI papers (doing it in Scheme).
I think the code has exactly the property you ask for, if you expect  
conversion from Double to decimal to be sensible.





I feel like I looked into this once when I was trying to understand  
the bignum-heavy Read instance for Double in the report, and ended  
up with a nasty headache and some fixed-point code which used cute  
hacks and seemed to work with limited testing and the vagaries of  
gcc as a back end.


I'm sure it can be done with less bignums, but it's quite tricky to  
get right even with bignums.


-- Lennart

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Floating point problems

[Lennart Augustsson]

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: Floating point problems

[Lennart Augustsson]

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: returning to cost of Integer

[Lennart Augustsson]

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

[Lennart Augustsson]

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?

[Lennart Augustsson]

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?

[lennart]

No, the timer thread starts even without -threaded.
If you use -threaded it gets worse because then you have
a bunch of other threads that don't exit properly.

 -- Lennart

Quoting Simon Marlow <[EMAIL PROTECTED]>:


Lennart Augustsson wrote:


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.


Is this with -threaded?

Simon




___
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?

[Lennart Augustsson]

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?

[Lennart Augustsson]

I'm not implying anything, except that I've plugged the space
leak of 256M every time a DLL is loaded&unloaded.

-- 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?

[Lennart Augustsson]

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 
#include 

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

[Lennart Augustsson]

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?

[Lennart Augustsson]

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.

[Lennart Augustsson]

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.

[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.

-- 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: GHCI and archive libraries.

[Lennart Augustsson]

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: jhc vs ghc and the surprising result involving ghcgeneratedassembly.

[Lennart Augustsson]

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: Error compiling using Network module

[Lennart Kolmodin]

Jorge Guerra wrote:


Hello to all,

I have recently began using ghc, in particular the network module and
I'm having problems with it. The following code ilustrates my problem,
is very simple all I try to do is connect to a socket in my local
machine send a request and print the response.

 


[snip]


When I try to compile it using the command:

ghc -o socketTest socketTest.hs

 


Try adding the network package as well;
$ ghc -o socketTest socketTest.hs -package network

You might also find the command
$ ghc --make -o socketTest socketTest.hs
useful since it will add exposed packages for you.

Cheers,
 Lennart Kolmodin

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

ghc-pkg query feature request

[Lennart Kolmodin]

Hi!

When working with multiple versions of a package you often want to use 
  the most recent version.
A feature that would help for package systems is to be able to query 
ghc-pkg for the best version, or to list the versions in increasing 
version order.


Something like:

$ ghc-pkg best_version Cabal
Cabal-1.1.1

$ ghc-pkg versions Cabal
Cabal-1.0 Cabal-1.1.1

You get the picture. Obviously, this feature isn't critical since we 
could use 'ghc-pkg list' and work our way from there, but it would be nice.

If you like the idea we might send you a patch.
What do you think?

Cheers,
  Lennart Kolmodin

--
"The only thing that interferes with my learning is my education."
-- Albert Einstein
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: unsafeness of unsafeInterleaveIO

[Lennart Augustsson]

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: unsafeness of unsafeInterleaveIO

[Lennart Augustsson]

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: Parser for Glasgow Extensions?

[Lennart Kolmodin]

mcnster wrote:
> Hello there,
> 
> Has anyone written a version of
> libraries/haskell-src/Language/Haskell/Parser.ly (and friends) to parse
> the language plus Glasgow extensions?  I have code with | <- guards that
> the current parser barfs on.
> 
>   - the mcnster -
> 
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

You might want to have a look at this library:
http://www.cs.chalmers.se/~d00nibro/haskell-src-exts/
by Niklas Broberg.

There is also a parser in Haddock which saves Haddock comments
(naturally :)) :
http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/haddock/
by Simon Marlow and friends. I don't know whether it's good on
extensions or not.

/ Lennart Kolmodin

-- 
"The only thing that interferes with my learning is my education."
-- Albert Einstein
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC as a package

[Lennart Kolmodin]

Simon Marlow wrote:
To compile GHC as a package, get a recent GHC source tree and set
'BuildPackageGHC=YES' in your mk/build.mk.  You should also set
$(GHC_PKG) to point to your ghc-pkg command.  Then build ghc as normal,
and in ghc/compiler say 'make install-inplace-pkg' to register the
package (this won't do any actual installation, just register the
package with your installed GHC).
 

I have ghc-6.2.2 installed on my system and it could not build ghc if I 
set BuildPackageGHC=YES.
It failed with
WARNING: error while reading directory gnore-package
ghc-6.2.2: file `ghc' does not exist
so I guess it didn't understand the parameters "-ignore-package ghc".
If I download a recent snapshot of ghc-6.4, compile it, set 
BuildPackageGHC=YES, how can I compile the package using that compiler? 
And will that package be compatible with my installation of ghc-6.2.2?

Thanks in advance,
   Lennart
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

GHC as a package

[Lennart Kolmodin]

Hi!

I'm working on an IDE for Haskell, written in Haskell.
Currently, I'm looking for a way to parse .hs-files for a module browser
and I recall that Simon Marlow was going to release GHC as a package
"soon".
We could also use that package to compile source code without invoking ghc
as a separate process.

What is the status of the package and where can I get it?
I can't find it in the CVS or in any of the snapshots.

/Lennart

___
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

[Lennart Augustsson]

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'

[Lennart Augustsson]

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: Space usage

[Lennart Augustsson]

Simon Peyton-Jones wrote:
I had a look at this.  It's an old chestnut: lazy pattern matching.  You
have
let ((commands, s), x) = run (read iters) 5
in do   ...do something with commands...
print x
Trouble is, the 'x' hangs onto both components of the pair, even though
it only needs one.
It's not enough to force the pair earlier, which you probably tried,
because the state monad you are using is itself lazy, and uses masses of
lazy pattern matching.
You could return the state paired with each item, rather than just the
state at the end, perhaps, or use a stricter state monad.
This lazy-pattern-matching leak is a well-known problem, to which I do
not know a good solution.  There was a paper from Chalmers about 8 years
ago about building more cleverness into the compiler, but it amounted to
extending Core with a lazy tuple binding.  Fair enough, but quite a big
addition to Core and one I've never done.
Simon, I suggest that you take another look at Jan Sparud's paper.
No extension of Core is needed to implement it.  All that is needed
is a strange (impure) primitive function.  To maintain type correctness
you also need a family of functions that are really the identity, but
with different types.  Read the paper, I think you could add it to ghc
without too much trouble.
-- Lennart
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Space usage

[Lennart Augustsson]

Adrian Hey wrote:
On Tuesday 17 Aug 2004 5:11 pm, Malcolm Wallace wrote:
It is also possible to use Wadler's
garbage-collector fix for this space leak, as implemented in nhc98.
   P Wadler, "Fixing a Space Leak with a Garbage Collector", SP&E Sept
1987.
When the GC discovers a selector function applied to an evaluated
argument, it "evaluates" the selector on-the-fly by just swizzling
pointers.  It needs some co-operation from the compiler to make
selector functions look obvious, but that isn't too difficult.

So ghc doesn't do this (or something better)? I'm surprised
because it seems like a really basic and simple feature to me. I
implemented a toy FPL a few years ago and even my gc incorporated
this optimisation. It's a bit strange that this should have been
overlooked considering in all other respects ghc is far more
sophisticated than my efforts were :-)
As Simon pointed out, it's not so easy to do this with an
optimizing compiler that may inline selector functions.
The "right" way to do this is to have specialized code
that runs during GC for each thunk.  This was investigated
in Christina von Dorrien's licentiate thesis "Stingy evaluation".
-- Lennart
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: optimization question

[Lennart Augustsson]

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