Re: [GHC] #930: ghc-6.6: panic! (the 'impossible' happened) mkWWcpr: not a product GHC-Brian-6.5.1:IdInfo.IdInfo{tc rfD}
#930: ghc-6.6: panic! (the 'impossible' happened) mkWWcpr: not a product GHC-
Brian-6.5.1:IdInfo.IdInfo{tc rfD}
-+--
Reporter: briansmith | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler|Version: 6.5
Severity: normal | Resolution:
Keywords: | Os: Unknown
Difficulty: Unknown | Architecture: Unknown
-+--
Comment (by simonpj):
This is an annoying, known, but awkward-to-fix problem concerning
mutually-recursive modules. The problem is that when compiling the
modules *inside* a loop, a data type that is only defined at the top of
the loop looks opaque; but after the loop is done, the structure of the
data type becomes apparent.
The difficulty is then that two different bits of code have different
notions of what the data type looks like.
So far this bug has bitten only GHC itself and one other person. I need
to think carefully about how to fix it. Thanks for reporting it.
Unsatisfactory workaround: compile without -O.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/930
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #933: Separate compilation fails with existential records
#933: Separate compilation fails with existential records
---+
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler |Version: 6.5
Severity: normal| Resolution:
Keywords:| Os: Unknown
Difficulty: Unknown | Architecture: Unknown
---+
Old description:
Consider M.hs:
{-# OPTIONS_GHC -fglasgow-exts #-}
module M where data D = forall a. C { l :: a }
Then consider Main.hs:
import M
main = print () where x = C { l = () }
A normal compilation works:
$ ghc --make Main.hs
[1 of 2] Compiling M( M.hs, M.o )
[2 of 2] Compiling Main ( Main.hs, Main.o )
Linking Main ...
However, separate compilation does not:
$ touch Main.hs
$ ghc --make Main.hs
[2 of 2] Compiling Main ( Main.hs, Main.o )
Main.hs:2:26:
Constructor `C' does not have field `l'
In the expression: C {l = ()}
In the definition of `x': x = C {l = ()}
In the definition of `main':
main = print ()
where
x = C {l = ()}
Where should I start looking to fix this? :-)
Thanks,
Audrey
New description:
Consider M.hs:
{{{
{-# OPTIONS_GHC -fglasgow-exts #-}
module M where data D = forall a. C { l :: a }
}}}
Then consider Main.hs:
{{{
import M
main = print () where x = C { l = () }
}}}
A normal compilation works:
{{{
$ ghc --make Main.hs
[1 of 2] Compiling M( M.hs, M.o )
[2 of 2] Compiling Main ( Main.hs, Main.o )
Linking Main ...
}}}
However, separate compilation does not:
{{{
$ touch Main.hs
$ ghc --make Main.hs
[2 of 2] Compiling Main ( Main.hs, Main.o )
Main.hs:2:26:
Constructor `C' does not have field `l'
In the expression: C {l = ()}
In the definition of `x': x = C {l = ()}
In the definition of `main':
main = print ()
where
x = C {l = ()}
}}}
Where should I start looking to fix this? :-)
Thanks,
Audrey
Comment (by simonpj):
Audrey, when you added the record fields in existentials feature, you
didn't arrange that the info is recorded in interface files.
I discovered and fixed this when cleaning up IfaceSyn to add FC to GHC;
but the fix is only in the HEAD. The patch is not easy to incorporate in
the branch,
because the FC patch was very big.
Fixing the 6.6 branch is possible, but would mean a change in interface
file format, which we strongly discourage between patch-level releases.
So I'm inclined to leave it alone in the branch, and encourage you to try
the HEAD.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/933
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #933: Separate compilation fails with existential records
#933: Separate compilation fails with existential records ---+ Reporter: guest | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Compiler |Version: 6.5 Severity: normal| Resolution: Keywords:| Os: Unknown Difficulty: Unknown | Architecture: Unknown ---+ Comment (by guest): Understood. May I commit a doc change to explain that it's a known limitation, not expected to be lifted in the 6.6.x series, then? Thanks, Audrey -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/933 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #930: ghc-6.6: panic! (the 'impossible' happened) mkWWcpr: not a product GHC-Brian-6.5.1:IdInfo.IdInfo{tc rfD}
#930: ghc-6.6: panic! (the 'impossible' happened) mkWWcpr: not a product GHC-
Brian-6.5.1:IdInfo.IdInfo{tc rfD}
-+--
Reporter: briansmith | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler|Version: 6.5
Severity: normal | Resolution:
Keywords: | Os: Unknown
Difficulty: Unknown | Architecture: Unknown
-+--
Comment (by briansmith):
Another workaround seems to be to use a makefile and ghc -c instead of
ghc --make. I compile GHC using its makefile all the time with -O2
without incident.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/930
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #934: Allow load to work correctly when executed multiple times the same session for BatchCompile
#934: Allow load to work correctly when executed multiple times the same session
for BatchCompile
+---
Reporter: briansmith |Owner:
Type: feature request | Status: new
Priority: normal |Milestone:
Component: Compiler | Version: 6.4.2
Severity: normal | Keywords:
Os: Unknown | Difficulty: Unknown
Architecture: Unknown |
+---
In GHC.hs, there is a comment that says that module stability is not
important for BatchCompile. However, isn't that only true when there is
only one load per Session? For example, if I do:
session - newSession BatchCompile Nothing
load session LoadAllTargets
load session LoadAllTargets
Wouldn't checking the module stability be useful or even required for the
second load? The problem I encountered is that, if I do not check
stability, then when I execute any load after the first, GHC does not do
dependency analysis correctly--things are getting recompiled during the
second load even though the first load already compiled everything. It
seems like this might only be the case for programs with mutually
recursive modules, since most programs I tested with seem to get compiled
okay.
There are other cases in the code where it is assumed that GHC.load will
be executed only once per session. For example, MkIface.check_old_iface.
I hastily made some modifications to GHC.load2 so that the stability check
is always made, and then changd GHC.upsweep_mod to make use of the
stability information. Once that was done, then my program works
correctly. Could somebody please let me know if this would be an
acceptable type of change to make to the API?
This relates to my message [GHC API: Problems with implementing :reload
for ghc --make] on the mailing list, which included a test program:
http://www.haskell.org/pipermail/glasgow-haskell-
users/attachments/20061008/381db0cc/GhcRemake.obj
Here is the complete text of my modified upsweep_mod. I will include the
full text of the proof-of-concept patch as an attachment.
{{{
upsweep_mod hsc_env old_hpt (stable_obj, stable_bco) summary mod_index
nmods
= do
let
this_mod_name = ms_mod_name summary
this_mod= ms_mod summary
mb_obj_date = ms_obj_date summary
obj_fn= ml_obj_file (ms_location summary)
hs_date = ms_hs_date summary
is_stable_obj = this_mod_name `elem` stable_obj
is_stable_bco = this_mod_name `elem` stable_bco
old_hmi = lookupUFM old_hpt this_mod_name
compile_it :: Maybe Linkable - IO (Maybe HomeModInfo)
compile_it = upsweep_compile hsc_env old_hpt this_mod_name
summary mod_index nmods
case ghcMode (hsc_dflags hsc_env) of
_ | is_stable_obj, isJust old_hmi - do
return old_hmi
-- object is stable, and we have an entry in the
-- old HPT: nothing to do
Interactive
| is_stable_bco -
ASSERT(isJust old_hmi) -- must be in the old_hpt
return old_hmi
-- BCO is stable: nothing to do
| Just hmi - old_hmi, Just l - hm_linkable hmi,
not (isObjectLinkable l),
linkableTime l = ms_hs_date summary -
compile_it (Just l)
-- we have an old BCO that is up to date with
respect
-- to the source: do a recompilation check as
normal.
BatchCompile
| Just obj_date - mb_obj_date, obj_date = hs_date -
do
linkable - findObjectLinkable this_mod obj_fn
obj_date
compile_it (Just linkable)
_ | is_stable_obj, isNothing old_hmi - do
linkable - findObjectLinkable this_mod obj_fn
(expectJust upseep1 mb_obj_date)
compile_it (Just linkable)
-- object is stable, but we need to load the
interface
-- off disk to make a HMI.
_ | otherwise -
compile_it Nothing
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/934
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #631: GHCi doesn't work unregisterised
#631: GHCi doesn't work unregisterised --+- Reporter: [EMAIL PROTECTED] | Owner: igloo Type: bug | Status: new Priority: low | Milestone: Component: GHCi |Version: 6.4.1 Severity: minor| Resolution: Keywords: | Os: Multiple Difficulty: Unknown | Architecture: Multiple --+- Changes (by igloo): * owner: = igloo Comment: I have a fix for this particular problem (we were generating info tables for tables-next-to-code, which we don't have when unregisterised). There are still some test failures that don't happen when registerised that I have to look in to, though. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/631 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #935: Minor documentation bug, odd defn of fibn.
#935: Minor documentation bug, odd defn of fibn. -+-- Reporter: tmcooper |Owner: Type: bug | Status: new Priority: normal|Milestone: Component: GHCi | Version: 6.6 Severity: minor | Keywords: Os: Multiple | Difficulty: Easy (1 hr) Architecture: Multiple | -+-- On this page: http://haskell.org/ghc/docs/6.6/html/users_guide/lang- parallel.html the function fibn is defined. I assume fibn is meant to give the fibonacci sequence, but it doesn't. The problem is the term 'n1 + n2 + 1' in the function definition. It should be just 'n1 + n2'. This change needs to be made in two places on this page, and additionally, an occurence of 'n2 + n1 + 1' needs to be changed to 'n2 + n1'. In case it is helpful, here is the corrected html. !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN http://www.w3.org/TR/html4/loose.dtd; htmlheadmeta http-equiv=Content-Type content=text/html; charset =ISO-8859-1title7.15. Parallel Haskell/titlelink rel=stylesheet href=lang-parallel_files/fptools.css type=text/cssmeta name=generator content=DocBook XSL Stylesheets V1.68.1link rel=start href=http://haskell.org/ghc/docs/6.6/html/users_guide/index.html; title=The Glorious Glasgow Haskell Compilation System User's Guide, Version 6.6link rel=up href=http://haskell.org/ghc/docs/6.6/html/users_guide/ghc-language- features.html title=Chapter 7. GHC Language Featureslink rel=prev href=http://haskell.org/ghc/docs/6.6/html/users_guide/monomorphism.html; title=7.14. Control over monomorphismlink rel=next href=http://haskell.org/ghc/docs/6.6/html/users_guide/ffi.html; title=Chapter 8. Foreign function interface (FFI) /head body alink=#ff bgcolor=white link=#ff text=black vlink=#840084div class=navheadertable summary=Navigation header width=100%tbodytrth colspan=3 align=center7.15. Parallel Haskell/th/trtrtd align=left width=20%a accesskey=p href=http://haskell.org/ghc/docs/6.6/html/users_guide/monomorphism.html;Prev/a /tdth align=center width=60%Chapter 7. GHC Language Features/thtd align=right width=20% a accesskey=n href=http://haskell.org/ghc/docs/6.6/html/users_guide/ffi.html;Next/a/td/tr/tbody/tablehr/divdiv class=sect1 lang=endiv class=titlepagedivdivh2 class=title style=clear: both;a name=lang-parallel/a7.15. Parallel Haskell/h2/div/div/diva class=indexterm name=id3181622/apThere are two implementations of Parallel Haskell: SMP paralellism a class=indexterm name=id3181636/a which is built-in to GHC (see a href=http://haskell.org/ghc/docs/6.6/html/users_guide/sec-using-smp.html; title=4.12. Using SMP parallelismSection 4.12, #8220;Using SMP parallelism#8221;/a) and supports running Parallel Haskell programs on a single multiprocessor machine, and Glasgow Parallel Haskella class=indexterm name=id3181653/a (GPH) which supports running Parallel Haskell programs on both clusters of machines or single multiprocessors. GPH is developed and distributed separately from GHC (see a href=http://www.cee.hw.ac.uk/%7Edsg/gph/; target=_topThe GPH Page/a)./ppOrdinary single-threaded Haskell programs will not benefit from enabling SMP parallelism alone. You must expose parallelism to the compiler in one of the following two ways./pdiv class=sect2 lang=endiv class=titlepagedivdivh3 class=titlea name=id3181681/a7.15.1. Running Concurrent Haskell programs in parallel/h3/div/div/divpThe first possibility is to use concurrent threads to structure your program, and make sure that you spread computation amongst the threads. The runtime will schedule the running Haskell threads among the available OS threads, running as many in parallel as you specified with the code class=option-N/code RTS option./p/divdiv class=sect2 lang=endiv class=titlepagedivdivh3 class=titlea name=id3181704/a7.15.2. Annotating pure code for parallelism/h3/div/div/divpThe simplest mechanism for extracting parallelism from pure code is to use the code class=literalpar/code combinator, which is closely related to (and often used with) code class=literalseq/code. Both of these are available from a href=http://haskell.org/ghc/docs/6.6/html/libraries/base/Control- Parallel.html target=_topcode class=literalControl.Parallel/code/a:/ppre class=programlistinginfixr 0 `par` infixr 1 `seq` par :: a -gt; b -gt; b seq :: a -gt; b -gt; b/prepThe expression code class=literal(x `par` y)/code span class=emphasisemsparks/em/span the evaluation of code class=literalx/code (to weak head normal form) and returns code class=literaly/code. Sparks are queued for execution in FIFO order, but are not
Re: [GHC] #935: Minor documentation bug, odd defn of fibn.
#935: Minor documentation bug, odd defn of fibn. +--- Reporter: tmcooper | Owner: Type: bug| Status: new Priority: normal | Milestone: Component: Documentation |Version: 6.6 Severity: minor | Resolution: Keywords: | Os: Multiple Difficulty: Easy (1 hr)| Architecture: Multiple +--- Changes (by tmcooper): * component: GHCi = Documentation -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/935 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: [Haskell-cafe] GHC Core still supported?
Jim, and others (I'm ccing GHC users)
External Core is a feature of GHC that is lonely and unloved. External
Core longs to have someone to look after it, tell it that it is a Truly
Useful Feature, and keep it working.
Seriously, External Core has a strong tendency to bit-rot because (so
far as I can tell) few people seem to use it, and hence it can lag
behind changes in the rest of the compiler. Yes, in principle we at GHC
HQ should push the entire compiler along in sync, but there are just too
few hours in the day. Another contributory factor is that some of the
things you might use External Core for can now be done by using the GHC
API.
So the true answer to your title line Is External Core still
supported? is there is no reason it can't be, but in fact at the
moment it probably doesn't work right. I think this is a pity because
External Core is a pretty good way for people interested in analyses and
back ends to use GHC as a front end that translates all of Haskell into
a small intermediate language.
But all is not lost. External Core is a good example of a feature that
doesn't require deep knowledge of GHC's internals to understand and
maintain, so it's perfect for someone else to undertake.
Is anyone (or a group of people) interested?
We'd give plenty of support to such an effort.
Meanwhile, if you want to use External Core, but can't because it
doesn't work properly for you, don't be afraid to yell. (E.g. File a
Trac bug report.) I don't want to promise an immediate fix, but the
more people that use it the keener we are to get it done.
thanks
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jim
| Apple
| Sent: 11 October 2006 02:35
| To: haskell-cafe@haskell.org
| Subject: [Haskell-cafe] GHC Core still supported?
|
| In
http://www.haskell.org/ghc/dist/current/docs/users_guide/ext-core.html
| , I see two notes that I can't verify:
|
| 1. I don't see any CORE pragma on
| http://www.haskell.org/ghc/dist/current/docs/users_guide/pragmas.html
|
| 2. Using GHC 6.5.20060920, I compile
|
| module Core where
| data Foo = Bar
|
| with -fext-core to get
|
| %module main:Core
| %data main:Core.Foo =
| {Bar};
|
| I then compile the resulting hcr file with no flags to get
|
| no location info:
| 1: Parse error
| :
| %data main:Core.Foo =
| {Bar};
|
| Jim
| ___
| Haskell-Cafe mailing list
| Haskell-Cafe@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [Haskell] Expecting more inlining for bit shifting
| So, my hypothesis is that the inliner doesn't recognise that
| ``if (x = 0) then ...'' is effectively a case analysis on x, and thus
the
| argument discount is not fired. So we need to figure out how to
extend
| this criterion for when to apply the argument discount.
Correct. GHC generates
case (x# =# 0#) of { True - ...; False - ... }
But the argument discount only applies when we have
case y of { ... }
So you really want a discount for the args of a primop.
The relevant file is coreSyn/CoreUnfold.lhs, and the function is
calcUnfoldingGuidance.
I see some notes there with primops, namely:
PrimOpId op - primOpSize op (valArgCount args)
-- foldr addSize (primOpSize op) (map
arg_discount args)
-- At one time I tried giving an arg-discount
if a primop
-- is applied to one of the function's
arguments, but it's
-- not good. At the moment, any unlifted-type
arg gets a
-- 'True' for 'yes I'm evald', so we collect
the discount even
-- if we know nothing about it. And just
having it in a primop
-- doesn't help at all if we don't know
something more.
At the call site, the call
f x y
gets f's arg-discount for x if x is evaluated. But in the case of
primitive types we don't just want evaluated, we want to know the
value. So one could refine that. The relevant function is
interestingArg in simplCore/SimplUtils.
| (This whole idea of argument discounting seems rather ad hoc. Is it
not
| possible try out an inline, and remove it if in the end it doesn't get
| reduced in size sufficently?)
Yes, you could try that too. It might result in a lot of wasted work,
but it'd be a reasonable thing to try. The relevant code is in
simplCore/Simplify.lhs
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [Haskell] Expecting more inlining for bit shifting
On Wed, 11 Oct 2006, Simon Peyton-Jones wrote:
Correct. GHC generates
case (x# =# 0#) of { True - ...; False - ... }
But the argument discount only applies when we have
case y of { ... }
So you really want a discount for the args of a primop.
Do you think it should be that general? I was thinking the discount
should only apply in the situtation where a case expression contains an
expression with one free varaible that is a function argument, and all
operations are primitive.
So I was thinking the right place to patch is in sizeExpr:
size_up (Case (Var v) _ _ alts)
| v `elem` top_args
= ...
And make this branch activate is a wider range of circumstances. SamB
is/was working on such a patch.
But making sure that all operations are primitive is not quite right, for
instance in
f :: Int - ...
f x | gcd x 21 1 = ...
we cannot give x an argument discount because (gcd (5::Int) 21) is not
rewritten into 1 (for some strange reason).
So, is there a way of deciding if a primitive op will be rewritten if all
its arguements are given?
--
Russell O'Connor http://r6.ca/
``All talk about `theft,''' the general counsel of the American Graphophone
Company wrote, ``is the merest claptrap, for there exists no property in
ideas musical, literary or artistic, except as defined by statute.''
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [Haskell] Expecting more inlining for bit shifting
| Do you think it should be that general? I was thinking the discount | should only apply in the situtation where a case expression contains an | expression with one free varaible that is a function argument, and all | operations are primitive. Well, if you see x =# 0 then it'd be good to inline if argument x was bound to a literal, even if the = is not scrutinised by a case. Why? Because then we can constant-fold it away. But perhaps the discount should be smaller? | So, is there a way of deciding if a primitive op will be rewritten if all | its arguements are given? The constant-folding rules for the primops are all in prelude/PrelRules.lhs in function primOpRules. Please add more rules. For example, I see that x +# 0 = x is not in there! Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [Haskell] Expecting more inlining for bit shifting
On Wed, 11 Oct 2006, Simon Peyton-Jones wrote: The constant-folding rules for the primops are all in prelude/PrelRules.lhs in function primOpRules. Please add more rules. For example, I see that x +# 0 = x is not in there! It is in libraries/base/GHC/Base.lhs x# +# 0# forall x#. x# +# 0# = x# -- Russell O'Connor http://r6.ca/ ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re[2]: [Haskell] Expecting more inlining for bit shifting
Hello Simon,
Wednesday, October 11, 2006, 2:23:59 PM, you wrote:
The constant-folding rules for the primops are all in
prelude/PrelRules.lhs
in function primOpRules. Please add more rules. For example, I see
that
x +# 0 = x
is not in there!
but GHC.Base contains
{-# RULES
x# +# 0# forall x#. x# +# 0# = x#
0# +# x# forall x#. 0# +# x# = x#
x# -# 0# forall x#. x# -# 0# = x#
x# -# x# forall x#. x# -# x# = 0#
x# *# 0# forall x#. x# *# 0# = 0#
0# *# x# forall x#. 0# *# x# = 0#
x# *# 1# forall x#. x# *# 1# = x#
1# *# x# forall x#. 1# *# x# = x#
#-}
is this not enough?
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ANNOUNCE: GHC version 6.6
=== The (Interactive) Glasgow Haskell Compiler -- version 6.6 === The GHC Team is pleased to announce a new release of GHC. There have been many changes since the 6.4.2 release. For details, see the release notes here: http://haskell.org/ghc/docs/6.6/html/users_guide/release-6-6.html How to get it ~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://www.haskell.org/ghc/docs/latest/html/building/building-guide.html Developers ~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Expecting more inlining for bit shifting
Simon Peyton-Jones simonpj at microsoft.com writes:
| So, my hypothesis is that the inliner doesn't recognise that
| ``if (x = 0) then ...'' is effectively a case analysis on x, and thus
the
| argument discount is not fired. So we need to figure out how to
extend
| this criterion for when to apply the argument discount.
Correct. GHC generates
case (x# =# 0#) of { True - ...; False - ... }
But the argument discount only applies when we have
case y of { ... }
So you really want a discount for the args of a primop.
The relevant file is coreSyn/CoreUnfold.lhs, and the function is
calcUnfoldingGuidance.
Actually it is sizeExpr. (Even so, apparantly I've been figuring this out the
hard way...)
The brach that currently handles these is the
size_up (Case e _ _ alts) = nukeScrutDiscount (size_up e) `addSize`
foldr (addSize . size_up_alt) sizeZero alts
branch. I've got a patch that seems like it ought to do a bettter job, but it
doesn't seem to give the $wrotate functions any discount (the $wshift functions
having been tagged by the {-# INLINE shift #-} pragmas I added all over).
Unfortunately I left it at home and I'm at school right now :-(.
It does get run sometimes, but I'm not sure if it is run for rotate or that its
results are kept...
I see some notes there with primops, namely:
PrimOpId op - primOpSize op (valArgCount args)
-- foldr addSize (primOpSize op) (map
arg_discount args)
-- At one time I tried giving an arg-discount
if a primop
-- is applied to one of the function's
arguments, but it's
-- not good. At the moment, any unlifted-type
arg gets a
-- 'True' for 'yes I'm evald', so we collect
the discount even
-- if we know nothing about it. And just
having it in a primop
-- doesn't help at all if we don't know
something more.
At the call site, the call
f x y
gets f's arg-discount for x if x is evaluated. But in the case of
primitive types we don't just want evaluated, we want to know the
value. So one could refine that. The relevant function is
interestingArg in simplCore/SimplUtils.
I might point out that the current code would throw out those discounts (the
nukeSrutDiscounts in that case).
| (This whole idea of argument discounting seems rather ad hoc. Is it
not
| possible try out an inline, and remove it if in the end it doesn't get
| reduced in size sufficently?)
Yes, you could try that too. It might result in a lot of wasted work,
but it'd be a reasonable thing to try. The relevant code is in
simplCore/Simplify.lhs
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] GHC Core still supported?
Hi,
I was just talking yesterday with a group of other students about
using the ExternalCore data type as the starting point for a project
we're starting to work on with the goal of having more practice
implementing various compiler components.
We were also talking about the possibility of using GHC as a sort of
front-end for this project, down the line, by having it emit external
core.
Even if we don't end up using it, I think it's a nice feature to
have, and I've been wanting to get involved in GHC development. So,
I'm volunteering to be at least one of the people to help get it up
to speed and keep it there.
Aaron
On Oct 11, 2006, at 12:47 AM, Simon Peyton-Jones wrote:
Jim, and others (I'm ccing GHC users)
External Core is a feature of GHC that is lonely and unloved.
External
Core longs to have someone to look after it, tell it that it is a
Truly
Useful Feature, and keep it working.
Seriously, External Core has a strong tendency to bit-rot because (so
far as I can tell) few people seem to use it, and hence it can lag
behind changes in the rest of the compiler. Yes, in principle we
at GHC
HQ should push the entire compiler along in sync, but there are
just too
few hours in the day. Another contributory factor is that some of the
things you might use External Core for can now be done by using the
GHC
API.
So the true answer to your title line Is External Core still
supported? is there is no reason it can't be, but in fact at the
moment it probably doesn't work right. I think this is a pity
because
External Core is a pretty good way for people interested in
analyses and
back ends to use GHC as a front end that translates all of Haskell
into
a small intermediate language.
But all is not lost. External Core is a good example of a feature
that
doesn't require deep knowledge of GHC's internals to understand and
maintain, so it's perfect for someone else to undertake.
Is anyone (or a group of people) interested?
We'd give plenty of support to such an effort.
Meanwhile, if you want to use External Core, but can't because it
doesn't work properly for you, don't be afraid to yell. (E.g. File a
Trac bug report.) I don't want to promise an immediate fix, but the
more people that use it the keener we are to get it done.
thanks
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jim
| Apple
| Sent: 11 October 2006 02:35
| To: haskell-cafe@haskell.org
| Subject: [Haskell-cafe] GHC Core still supported?
|
| In
http://www.haskell.org/ghc/dist/current/docs/users_guide/ext-core.html
| , I see two notes that I can't verify:
|
| 1. I don't see any CORE pragma on
| http://www.haskell.org/ghc/dist/current/docs/users_guide/
pragmas.html
|
| 2. Using GHC 6.5.20060920, I compile
|
| module Core where
| data Foo = Bar
|
| with -fext-core to get
|
| %module main:Core
| %data main:Core.Foo =
| {Bar};
|
| I then compile the resulting hcr file with no flags to get
|
| no location info:
| 1: Parse error
| :
| %data main:Core.Foo =
| {Bar};
|
| Jim
| ___
| Haskell-Cafe mailing list
| Haskell-Cafe@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-cafe
___
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] Expecting more inlining for bit shifting
On Wed, 11 Oct 2006, Samuel Bronson wrote:
branch. I've got a patch that seems like it ought to do a bettter job,
but it doesn't seem to give the $wrotate functions any discount (the
$wshift functions having been tagged by the {-# INLINE shift #-} pragmas
I added all over). Unfortunately I left it at home and I'm at school
right now :-(. It does get run sometimes, but I'm not sure if it is run
for rotate or that its results are kept...
The problem with rotate is that it is:
(W32# x#) `rotate` (I# i#)
| i'# ==# 0# = W32# x#
| otherwise = W32# (narrow32Word# ((x# `shiftL#` i'#) `or#`
(x# `shiftRL#` (32# -# i'#
where
i'# = word2Int# (int2Word# i# `and#` int2Word# 31#)
The i'# gets inlined, so the case statement isn't actually actually doing
an analysis on i#, rather it is doing an analysis on
i# `and#` 31#.
So this lends support to SPJ's view that we need to check to see if a
variable is being used in an application of a primop that can be
evaluated, and all the other arguements are literals.
--
Russell O'Connor http://r6.ca/
``All talk about `theft,''' the general counsel of the American Graphophone
Company wrote, ``is the merest claptrap, for there exists no property in
ideas musical, literary or artistic, except as defined by statute.''
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Link errors when using the GHC API
Dear GHC hackers, I would like to experiment with the GHC API. However I get link errors when using it. For example: - $ ghci -package ghc ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Loading package template-haskell ... linking ... done. Loading package readline-1.0 ... linking ... done. Loading package unix-1.0 ... linking ... done. Loading package Cabal-1.1.6 ... linking ... done. Loading package regex-base-0.71 ... linking ... done. Loading package regex-posix-0.71 ... linking ... done. Loading package regex-compat-0.71 ... linking ... done. Loading package haskell98 ... linking ... done. ghc-6.6: /usr/lib/ghc-6.6/HSghc.o: unknown symbol `Cabalzm1zi1zi6_DistributionziPackage_a_closure' Loading package ghc-6.6 ... linking ... ghc-6.6: unable to load package `ghc-6.6' - I also get this when compiling for example the following module testGHC.hs: - module Main where import qualified GHC import DynFlags (defaultDynFlags) main = GHC.defaultErrorHandler defaultDynFlags $ putStrLn Hello World - - $ ghc -package ghc --make testGHC [1 of 1] Compiling Main ( testGHC.hs, testGHC.o ) Linking testGHC ... /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o): In function `r6iZ_info': : undefined reference to `Cabalzm1zi1zi6_LanguageziHaskellziExtension_optional_info' /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o): In function `s6r9_info': : undefined reference to `Cabalzm1zi1zi6_LanguageziHaskellziExtension_zdwshowsPrec_info' /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o): In function `s6sJ_info': : undefined reference to `Cabalzm1zi1zi6_DistributionziCompiler_lvl31_info' /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o): In function `s6sN_info': : undefined reference to `Cabalzm1zi1zi6_DistributionziCompiler_zddEq_closure' /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o): In function `s6ID_0_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziCompiler_polyzugo_info' /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o): In function `s6IG_0_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziCompiler_polyzugo1_info' /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o):(.rodata+0x0): undefined reference to `Cabalzm1zi1zi6_LanguageziHaskellziExtension_optional_closure' /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o):(.rodata+0x1cc): undefined reference to `Cabalzm1zi1zi6_LanguageziHaskellziExtension_zdwshowsPrec_closure' /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o):(.rodata+0x1dc): undefined reference to `Cabalzm1zi1zi6_DistributionziCompiler_lvl31_closure' /usr/lib/ghc-6.6/libHSghc.a(PackageConfig.o): In function `s23t_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' /usr/lib/ghc-6.6/libHSghc.a(Packages.o): In function `s77S_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' /usr/lib/ghc-6.6/libHSghc.a(Packages.o): In function `s79E_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' /usr/lib/ghc-6.6/libHSghc.a(Packages.o): In function `s7i7_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' /usr/lib/ghc-6.6/libHSghc.a(Packages.o): In function `s7vI_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' /usr/lib/ghc-6.6/libHSghc.a(Packages.o): In function `s7yi_info': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_zeze_info' /usr/lib/ghc-6.6/libHSghc.a(Packages.o): In function `s7GC_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' /usr/lib/ghc-6.6/libHSghc.a(Linker.o): In function `s8TZ_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' /usr/lib/ghc-6.6/libHSghc.a(Linker.o): In function `s8Vv_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' /usr/lib/ghc-6.6/libHSghc.a(Finder.o): In function `s7l2_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' collect2: ld returned 1 exit status - I would like to know what is causing this and how I can fix it? Also, should I file a bugreport? Greetings, Bas van Dijk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Link errors when using the GHC API
Interesting. I was unable to reproduce your problem. What platform are you running on? Are you using a binary distribution or one you built from source? Seems like something didn't build right... You might use 'nm' to examine your libHSCabal.a to see if a similarly named symbol is present. For example, is there a leading underscore? May the version (m1zi1zi6) isn't present? On Oct 11, 2006, at 12:00 PM, Bas van Dijk wrote: Dear GHC hackers, I would like to experiment with the GHC API. However I get link errors when using it. For example: - $ ghci -package ghc ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Loading package template-haskell ... linking ... done. Loading package readline-1.0 ... linking ... done. Loading package unix-1.0 ... linking ... done. Loading package Cabal-1.1.6 ... linking ... done. Loading package regex-base-0.71 ... linking ... done. Loading package regex-posix-0.71 ... linking ... done. Loading package regex-compat-0.71 ... linking ... done. Loading package haskell98 ... linking ... done. ghc-6.6: /usr/lib/ghc-6.6/HSghc.o: unknown symbol `Cabalzm1zi1zi6_DistributionziPackage_a_closure' Loading package ghc-6.6 ... linking ... ghc-6.6: unable to load package `ghc-6.6' - I also get this when compiling for example the following module testGHC.hs: - module Main where import qualified GHC import DynFlags (defaultDynFlags) main = GHC.defaultErrorHandler defaultDynFlags $ putStrLn Hello World - - $ ghc -package ghc --make testGHC [1 of 1] Compiling Main ( testGHC.hs, testGHC.o ) Linking testGHC ... /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o): In function `r6iZ_info': : undefined reference to `Cabalzm1zi1zi6_LanguageziHaskellziExtension_optional_info' /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o): In function `s6r9_info': : undefined reference to `Cabalzm1zi1zi6_LanguageziHaskellziExtension_zdwshowsPrec_info' /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o): In function `s6sJ_info': : undefined reference to `Cabalzm1zi1zi6_DistributionziCompiler_lvl31_info' /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o): In function `s6sN_info': : undefined reference to `Cabalzm1zi1zi6_DistributionziCompiler_zddEq_closure' /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o): In function `s6ID_0_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziCompiler_polyzugo_info' /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o): In function `s6IG_0_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziCompiler_polyzugo1_info' /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o):(.rodata+0x0): undefined reference to `Cabalzm1zi1zi6_LanguageziHaskellziExtension_optional_closure' /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o):(.rodata+0x1cc): undefined reference to `Cabalzm1zi1zi6_LanguageziHaskellziExtension_zdwshowsPrec_closure' /usr/lib/ghc-6.6/libHSghc.a(HeaderInfo.o):(.rodata+0x1dc): undefined reference to `Cabalzm1zi1zi6_DistributionziCompiler_lvl31_closure' /usr/lib/ghc-6.6/libHSghc.a(PackageConfig.o): In function `s23t_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' /usr/lib/ghc-6.6/libHSghc.a(Packages.o): In function `s77S_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' /usr/lib/ghc-6.6/libHSghc.a(Packages.o): In function `s79E_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' /usr/lib/ghc-6.6/libHSghc.a(Packages.o): In function `s7i7_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' /usr/lib/ghc-6.6/libHSghc.a(Packages.o): In function `s7vI_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' /usr/lib/ghc-6.6/libHSghc.a(Packages.o): In function `s7yi_info': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_zeze_info' /usr/lib/ghc-6.6/libHSghc.a(Packages.o): In function `s7GC_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' /usr/lib/ghc-6.6/libHSghc.a(Linker.o): In function `s8TZ_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' /usr/lib/ghc-6.6/libHSghc.a(Linker.o): In function `s8Vv_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' /usr/lib/ghc-6.6/libHSghc.a(Finder.o): In function `s7l2_1_alt': : undefined reference to `Cabalzm1zi1zi6_DistributionziPackage_a_closure' collect2: ld returned 1 exit status
ghc-6.6 candidate Win32 installer
Hi, for Win32 users wanting the latest GHC goodness, a candidate 6.6 installer is now available, http://haskell.org/ghc/dist/6.6/ghc-6-6.msi If anyone's willing to download it and kick the tires a bit, that'd be great. If nothing too egregious shows up, I'm planning to publish sometime tomorrow. thx --sigbjorn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] Re: GADT: call for proper terminology
On 10/11/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Niklas Broberg wrote: Annotate the data type using a GADT: data MyData a where MyCon :: MyData a The range of the data constructor MyCon is the entire type MyData a -- so the above data type is the regular algebraic data type, and can be written just as data MyData a = MyCon which, some say, makes the fact 'a' is phantom, and the overall intent clearer. One may hear phrases how generally awesome and indispensable GADT are; it is distressing to realize then that sometimes (often?) one is talking about regular algebraic data types, only in the `where' syntax. It helps to reduce confusion about the merits of various features and additions to Haskell if we use the term GADT exclusively for truly _generalized_ algebraic data types. Right you are, I stand corrected. /Niklas ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] GADT: call for proper terminology
On Oct 11, 2006, at 03:58 , Bulat Ziganshin wrote: Hello oleg, Wednesday, October 11, 2006, 6:12:23 AM, you wrote: Annotate the data type using a GADT: data MyData a where MyCon :: MyData a It helps to reduce confusion about the merits of various features and additions to Haskell if we use the term GADT exclusively for truly _generalized_ algebraic data types. imho, the error was inventing new syntax for GADTs instead of just adding type guards to the old one Well, I think the GADT type definition syntax is the syntax data type definitions should have had from the start. Too bad we didn't realize it 15 years ago. -- Lennart ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: GHC version 6.6
=== The (Interactive) Glasgow Haskell Compiler -- version 6.6 === The GHC Team is pleased to announce a new release of GHC. There have been many changes since the 6.4.2 release. For details, see the release notes here: http://haskell.org/ghc/docs/6.6/html/users_guide/release-6-6.html How to get it ~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://www.haskell.org/ghc/docs/latest/html/building/building-guide.html Developers ~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] GADT: call for proper terminology
Lennart Augustsson wrote: Well, I think the GADT type definition syntax is the syntax data type definitions should have had from the start. Too bad we didn't realize it 15 years ago. -- Lennart I agree! In my experience teaching Haskell, the current syntax is a bit confusing for newbies, and for years I've been telling students, It really means this: ... and then I write out a syntax more like GADT's. I also think that if we had adopted this syntax from the beginning, GADT's would have been discovered far sooner than now. -Paul ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: Cabal version 1.1.6
The Haskell Cabal The Common Architecture for Building Applications and Libraries. http://haskell.org/cabal/ Cabal version 1.1.6 is now available. It is included in GHC version 6.6. For other Haskell implementations or older versions of GHC you can install it separately: DOWNLOAD: http://www.haskell.org/cabal/download.html http://www.haskell.org/cabal/release/latest/cabal-1.1.6.tar.gz DOCUMENTATION: http://www.haskell.org/cabal/release/latest/doc/users-guide/ http://www.haskell.org/cabal/release/latest/doc/API/ See both the README file and the changelog for interface changes: http://www.haskell.org/cabal/release/latest/changelog BUGS: Report bugs using our bug tracker: http://hackage.haskell.org/trac/hackage/newticket or to the [EMAIL PROTECTED] mailing list. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] GADT: call for proper terminology
Well, Kent Petersson and I proposed them as an addition to Haskell in 1994, so they are not that new. :) -- Lennart http://web.cecs.pdx.edu/~sheard/papers/silly.pdf On Oct 11, 2006, at 09:47 , Paul Hudak wrote: Lennart Augustsson wrote: Well, I think the GADT type definition syntax is the syntax data type definitions should have had from the start. Too bad we didn't realize it 15 years ago. -- Lennart I agree! In my experience teaching Haskell, the current syntax is a bit confusing for newbies, and for years I've been telling students, It really means this: ... and then I write out a syntax more like GADT's. I also think that if we had adopted this syntax from the beginning, GADT's would have been discovered far sooner than now. -Paul ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Getting a function dependency graph from source
Hello. This seems like a basic question, but I haven't been able to find an answer. I have a pile of Haskell code that is compiled into a library, and a Haskell program that uses this library. What I would like is something that will look at my program and follow the function calls until it gets to the Prelude. I want to know which functions in the library and in the Prelude actually get used (at least potentially). I believe Hat only looks at traces of an actual run of the program, and so doesn't quite give me what I want. I also think I could do this with the haskell-src library, but it looks like a lot of work to understand that and use it. Thanks. -- Durward McDonell [EMAIL PROTECTED] ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] GADT: call for proper terminology
I would prefer notation like: data Parser a | Alt (Parser a) (Parser a) | Map ( b - a) (Parser b) | Succ a Parser (a,b) | Seq (Parser a) (Parser b) Parser String | Lit (String - Bool) Parser [a]| Many (Parser a) This takes away the noise in the heading of the current GHC notation (which is just plain confusing), and enables e.g. grouping of common alternatives, Doaitse Swierstra On Oct 11, 2006, at 11:42 PM, Lennart Augustsson wrote: Well, Kent Petersson and I proposed them as an addition to Haskell in 1994, so they are not that new. :) -- Lennart http://web.cecs.pdx.edu/~sheard/papers/silly.pdf On Oct 11, 2006, at 09:47 , Paul Hudak wrote: Lennart Augustsson wrote: Well, I think the GADT type definition syntax is the syntax data type definitions should have had from the start. Too bad we didn't realize it 15 years ago. -- Lennart I agree! In my experience teaching Haskell, the current syntax is a bit confusing for newbies, and for years I've been telling students, It really means this: ... and then I write out a syntax more like GADT's. I also think that if we had adopted this syntax from the beginning, GADT's would have been discovered far sooner than now. -Paul ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Fun in the Afternoon: Thurs 16th Nov in Oxford
Dear colleagues, Graham Hutton and Conor McBride at Nottingham and I are organizing a termly seminar Fun in the Afternoon on functional programming and related topics. The idea is to have a small number of talks as an antidote to mid-term blues, three afternoons a year. The hope is that talks will be informal and fun, and that there will be plenty of scope for discussion and chat as well. Fun in the Afternoon will be peripatetic. The first meeting will be in Oxford University Computing Laboratory on Thursday 16th November, and Phil Wadler of the University of Edinburgh will be opening proceedings. All are welcome, but if you'd like to come, could you please drop me (Jeremy Gibbons) a line so that I have an idea of numbers? If you'd like to give a talk, please also propose a title and a duration. We haven't yet fixed the timetable, because it depends in part on what offers of talks we get. But our current plan is to have talks 14:00-14:45 and 15:30-17:00. Brings sandwiches to eat together beforehand, and join us for drinks in a pub afterwards. There's a webpage with more information at http://sneezy.cs.nott.ac.uk/fun/ This page also explains how to subscribe to the mailing list, to which all further announcements will be sent. Directions to OUCL are at http://web.comlab.ox.ac.uk/oucl/about/directions.html Jeremy, Graham and Conor ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: Generic Haskell 1.60 (Diamond)
Generic Haskell version 1.60 (Diamond) We are happy to announce the fourth release of Generic Haskell, an extension of Haskell that facilitates generic programming. Generic Haskell includes the following features: * type-indexed values -- generic functions that can be instantiated on all Haskell data types. * type-indexed types -- types which are indexed over the type constructors underlying Haskell datatypes. The Generic Haskell compiler takes Generic Haskell source and produces Haskell code. Changes since 1.42 (Coral) -- * Generic Views as described in the Generic Views paper [1] are now sup- ported. * This release also corrects a few errors that occur with default cases, and some of the library functions have been improved. Download The Generic Haskell compiler is available in source and binary distributions. Binaries for Linux and MacOSX are available. These are available from: http://www.generic-haskell.org/compiler.html The documentation is also available separately from that page. For more general information, point your browser to: http://www.generic-haskell.org Why Generic Haskell? Software development often consists of designing datatypes, around which functionality is added. Some functionality is datatype specific, whereas other functionality is defined on almost all datatypes in such a way that it depends only on the structure of the datatype. A function that works on many datatypes in this way is called a generic function. Examples of generic functionality include editing, pretty-printing or storing a value in a database, and comparing two values for equality. Since datatypes often change and new datatypes are introduced, we have developed Generic Haskell, an extension of the functional programming language Haskell that supports generic definitions, to save the programmer from (re)writing instances of generic functions. The original design of Generic Haskell is based on work by Ralf Hinze. Pleasant programming, The Generic Haskell Team at Utrecht University [EMAIL PROTECTED] [1] Stefan Holdermans, Johan Jeuring, Andres Löh, and Alexey Rodriguez. Generic views on data types. In Tarmo Uustalu, editor, Proceedings 8th International Conference on Mathematics of Program Construction, MPC 2006, LNCS 4014, pages 209 - 234, 2006, © Springer-Verlag. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] GADT: call for proper terminology
Doaitse Swierstra wrote:
I would prefer notation like:
data Parser a | Alt (Parser a) (Parser a)
| Map ( b - a) (Parser b)
| Succ a
Parser (a,b) | Seq (Parser a) (Parser b)
Parser String | Lit (String - Bool)
Parser [a]| Many (Parser a)
This takes away the noise in the heading of the current GHC notation
(which is just plain confusing), and enables e.g. grouping of common
alternatives,
The above is very similar to Bulat's proposal
http://www.haskell.org/pipermail/haskell/2006-September/018466.html ie
(adding the idea of using another layout block to group alternatives on the
rhs):
data
Parser a =
Alt (Parser a) (Parser a)
Map ( b - a) (Parser b)
Succ a
Parser (a,b) = Seq (Parser a) (Parser b)
Parser String = Lit (String - Bool)
Parser [a] = Many (Parser a)
I don't think there's a good reason to use | to separate alternatives when
we've already got {;} to form blocks of things, and to put things on the
same line you'd just use:
data {Hi Int = {One; Two; Three}; Hi a = Foo a}
This would also make it easier to replace the = syntax at some future point
with the guard-like | syntax used in Clean (also suggested by Bulat in the
above post).
Regards, Brian
--
Logic empowers us and Love gives us purpose.
Yet still phantoms restless for eras long past,
congealed in the present in unthought forms,
strive mightily unseen to destroy us.
http://www.metamilk.com
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Getting a function dependency graph from source
Hi, The pfe command line tool from the Programatica Project has functionality that seems to fit fairly well with what you are asking for: pfe deps -- lists function level dependencies pfe needed -- lists everything needed by a definition pfe dead -- lists unused definitions pfe slice -- extract a slice by eliminating unused defintions For more information, and downloads, see http://www.cse.ogi.edu/~hallgren/Programatica/download/ Thomas H Durward McDonell wrote: Hello. This seems like a basic question, but I haven't been able to find an answer. I have a pile of Haskell code that is compiled into a library, and a Haskell program that uses this library. What I would like is something that will look at my program and follow the function calls until it gets to the Prelude. I want to know which functions in the library and in the Prelude actually get used (at least potentially). Thanks. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Re: Trying to understand HList / hSequence now [why it works]
Hello oleg, Wednesday, October 11, 2006, 6:45:28 AM, you wrote: instance (Monad m, HSequence m HNil HNil) = HSequence m HNil HNil where hSequence _ = return HNil how can i use the goal of the declaration as one of the conditions without causing some sort of black hole in the type inference algorithm? Very easily: the instance head is implicitly the part of its own context (so that a method can be recursive). as an example: data T = C instance Eq T where C==C = True (/=) = not (==) instance declarations may be even mutually recursive: instance Eq T where a==b = compare a b == EQ instance Ord T where compare a b = EQ ab = compare a b == LT a=b = (ab) || (a==b) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] a monad for secret information
Hello Felipe, Wednesday, October 11, 2006, 4:47:59 AM, you wrote: Why does this works? Yet Another Haskell Tutorial teaches that pattern matching occurs at one stage and guard processing at other, and that there's no back (page 94). something is definitely wrong - either book or your understanding. it's very widely used feature, i just took a quick scan of Hugs Prelude and found a lot of its uses: (!!) :: [a] - Int - a xs !! n | n0 = error Prelude.!!: negative index [] !! _ = error Prelude.!!: index too large (x:_) !! 0 = x (_:xs) !! n = xs !! (n-1) lexmatch (x:xs) (y:ys) | x == y = lexmatch xs ys lexmatch xs ys = (xs,ys) showLitChar c | c '\DEL' = showChar '\\' . protectEsc isDigit (shows (fromEnum c)) showLitChar '\DEL' = showString \\DEL x ^ 0 = 1 x ^ n | n 0 = _ ^ _ = error Prelude.^: negative exponent i don't even say that i use this feature every day :) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Multiple stages in Template Haskell
Hi, because Template Haskell is a compile-time metaprogramming language, there is no metaprogram left after the first stage. Thus, it does not make sense, conceptually, to have more than one stage. In contrast, in MetaOCaml, you can generate code at run time that generates code at run time that ... In Template Haskell, you have the possibility of a sequence of files where file n+1 makes use of the templates defined in file n; and maybe sometime this will be simplified such that you can have all definitions in one file. Anyway, you do not need multiple stages. Concerning the stage count, perhaps you just forgot to insert a quasi-quote at some place, e.g., at: $ [| zipN ... -- Christoph Lyle Kopnicky wrote: Hi folks, I noticed that in Template Haskell, you can only have one level of splicing or quasi-quoting. E.g., you can't write: $(zipN ($(sel 2 3) (zip level,3,( ['a'..'Z'] [1..] (words now is the time) Because you can't have a splice inside a splice. But wouldn't it be handy to use all these macros when defining other macros? This would be like stages in MetaML, which have no such limitation. But all the stages but the last one would be evaluated at compile time. The compiler would look for the deepest level of nested splices and evaluate it first. On the other hand, I can understand why you wouldn't include splices and quasi-quotes in the Language.Haskell.TH.Syntax - programmers could write functions that dynamically created arbitrarily (even infinitely) nested splices - so it would be undecidable where to start. I'm wondering if there's some reason this restriction is imposed. Is it particularly difficult to implement, or are there more theoretical problems? Does that mean I'm volunteering? ;) - Lyle ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC Core still supported?
Hi, External Core is a feature of GHC that is lonely and unloved. External Core longs to have someone to look after it, tell it that it is a Truly Useful Feature, and keep it working. Just for reference, Yhc.Core is deeply loved and very close to my heart. There are disadvantages to Yhc Core (no types, relatively new API, only works with Yhc accepted Haskell, can't compile Core files) and advantages (loved, simple, stable, used, pretty). I'm currently addressing the last disadvantage, so it will soon be able to compile Core files. Not wanting to poach GHC users, but for some projects Yhc.Core might be a better choice. I use it for my PhD, for DrHaskell, and a few other small projects and its really handy to have. I looked at GHC Core first, but didn't get very far, partly because it looks a bit ugly :) See http://haskell.org/haskellwiki/Yhc/API/Core Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [off-topic / administrative] List Reply-to
On Tue, 10 Oct 2006, Misha Aizatulin wrote: Matthias Fischmann wrote: Some lists have the Reply-To: set to the list address. I think you can even configure the From: to be haskell-cafe instead of the poster, making the poster merely identifiable by the Sender: field. Do you have strong opinions on this subject? Here is an argument against Reply-To munging. I'd say I agree with it: http://www.unicom.com/pw/reply-to-harmful.html * It violates the principle of minimal munging. This is a valid point. It may, though, possibly be a small price to pay nowadays. * It provides no benefit to the user of a reasonable mailer. I disagree. I find it annoying to no end to either 1) get multiple copies of mails concerning discussions I participate in or 2) have to manually re-edit the header each and every time I want to keep a discussion on a mailing list, possibly with added trouble finding the right adress to send to For mailing lists which have the characteristics that most replies are meant for the list, munging is a much more comfortable way to deal with things than non-munging. * It limits a subscriber's freedom to choose how he or she will direct a response. Not much. And it reduces the amount of surprise. We have by now left the time when most lists where built as huge To/CC-lists (or at least most people have left those times), and the Reply-to-all simply is not the expected behaviour to reply to a list with one single adress. * It actually reduces functionality for the user of a reasonable mailer. I don't agree. * It removes important information, which can make it impossible to get back to the message sender. This is again a valid point. * It penalizes the person with a reasonable mailer in order to coddle those running brain-dead software. I don't agree. I view pine as something that should be classified as reasonable, and I feel penalized by non-munging. * It violates the principle of least work because complicates the procedure for replying to messages. I don't agree. * It violates the principle of least surprise because it changes the way a mailer works. I don't agree. * It violates the principle of least damage, and it encourages a failure mode that can be extremely embarrassing -- or worse. I'd be surprised if private mail leakage happens that much to Haskell-cafe, or for that matter if it'd be embarrassing to the point the author is talking about. * Your subscribers don't want you to do it. Or, at least the ones who have bothered to read the docs for their mailer don't want you to do it. I'm a subscriber. I'd prefer munging. Cheers, Misha Best, -- Mikael Johansson | To see the world in a grain of sand [EMAIL PROTECTED]| And heaven in a wild flower http://www.mikael.johanssons.org | To hold infinity in the palm of your hand | And eternity for an hour ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell-Cafe Digest, Vol 38, Issue 22
On 10/11/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Meanwhile, if you want to use External Core, but can't because it doesn't work properly for you, don't be afraid to yell. (E.g. File a Trac bug report.) I don't want to promise an immediate fix, but the more people that use it the keener we are to get it done. I did file a bug on this nine months ago: http://hackage.haskell.org/trac/ghc/ticket/670 but haven't had a chance to work on it. Cheers, Kirsten -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt That's the thing about people who think they hate computers. What they really hate is lousy programmers.-- Larry Niven and Jerry Pournelle ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] windows file locking
HiI need to open a file and keep it open for writing (a log file). Another process hasto read from this file. On windows the second process (e.g. tail -f) can not open the file.How can I open a file without this locking? regardsStefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] GHC Core still supported?
Jim, and others (I'm ccing GHC users)
External Core is a feature of GHC that is lonely and unloved. External
Core longs to have someone to look after it, tell it that it is a Truly
Useful Feature, and keep it working.
Seriously, External Core has a strong tendency to bit-rot because (so
far as I can tell) few people seem to use it, and hence it can lag
behind changes in the rest of the compiler. Yes, in principle we at GHC
HQ should push the entire compiler along in sync, but there are just too
few hours in the day. Another contributory factor is that some of the
things you might use External Core for can now be done by using the GHC
API.
So the true answer to your title line Is External Core still
supported? is there is no reason it can't be, but in fact at the
moment it probably doesn't work right. I think this is a pity because
External Core is a pretty good way for people interested in analyses and
back ends to use GHC as a front end that translates all of Haskell into
a small intermediate language.
But all is not lost. External Core is a good example of a feature that
doesn't require deep knowledge of GHC's internals to understand and
maintain, so it's perfect for someone else to undertake.
Is anyone (or a group of people) interested?
We'd give plenty of support to such an effort.
Meanwhile, if you want to use External Core, but can't because it
doesn't work properly for you, don't be afraid to yell. (E.g. File a
Trac bug report.) I don't want to promise an immediate fix, but the
more people that use it the keener we are to get it done.
thanks
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jim
| Apple
| Sent: 11 October 2006 02:35
| To: haskell-cafe@haskell.org
| Subject: [Haskell-cafe] GHC Core still supported?
|
| In
http://www.haskell.org/ghc/dist/current/docs/users_guide/ext-core.html
| , I see two notes that I can't verify:
|
| 1. I don't see any CORE pragma on
| http://www.haskell.org/ghc/dist/current/docs/users_guide/pragmas.html
|
| 2. Using GHC 6.5.20060920, I compile
|
| module Core where
| data Foo = Bar
|
| with -fext-core to get
|
| %module main:Core
| %data main:Core.Foo =
| {Bar};
|
| I then compile the resulting hcr file with no flags to get
|
| no location info:
| 1: Parse error
| :
| %data main:Core.Foo =
| {Bar};
|
| Jim
| ___
| Haskell-Cafe mailing list
| Haskell-Cafe@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] windows file locking
Hi Stefan, Haskell I/O systems implements single writer-multiple readers file locking. See http://www.haskell.org/ghc/docs/latest/html/libraries/base/System-IO.html#8 Cheers, Krasimir On 10/11/06, Stefan Aeschbacher [EMAIL PROTECTED] wrote: Hi I need to open a file and keep it open for writing (a log file). Another process has to read from this file. On windows the second process (e.g. tail -f) can not open the file. How can I open a file without this locking? regards Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] windows file locking
On 10/11/06, Stefan Aeschbacher [EMAIL PROTECTED] wrote: Hi I need to open a file and keep it open for writing (a log file). Another process has to read from this file. On windows the second process (e.g. tail -f) can not open the file. How can I open a file without this locking? Using base-package's IO-system, that is not possible as far as I know. The flag you need to pass CreateFile (api call which is used to open practically all files) is FILE_SHARE_READ. You can find these in Win32-package, but files opened via raw api bindings don't work well together with base-packages IO-system (ie, you need to read and write using rawish api calls.) Best regards, Esa ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [off-topic / administrative] List Reply-to
Mikael Johansson [EMAIL PROTECTED] writes: * It violates the principle of least damage, and it encourages a failure mode that can be extremely embarrassing -- or worse. I'd be surprised if private mail leakage happens that much to Haskell-cafe, or for that matter if it'd be embarrassing to the point the author is talking about. Well - when I specifically ask to reply to author only, it is because the message isn't appropriate for the list. If I'm lucky, it's only off topic, if I'm unlucky it contains confidential and/or embarrassing information. Either way, all subscribers get a copy each of irrelevant material. If I inadvertently mail somebody in private when intending to post to the list, I will have to repost, but apart from one person receiving one extra copy, no harm is done. I feel very strongly that the latter case is more desirable. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] beginner's problem about lists
ihope [EMAIL PROTECTED] wrote: It's possible to make both infinite list and finite list datatypes: data Inf a = InfCons a (Inf a) data Fin a = FinCons a !(Fin a) | FinNil At least, I think the Fin type there has to be finite... No, your Fin type can also hold infinite values. The strictness annotation on the (Fin a) component merely ensures that the tail exists to one constructor's depth (Head Normal Form). It does not force strictness all the way down (full Normal Form). Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] windows file locking
Hello Esa, Wednesday, October 11, 2006, 2:13:49 PM, you wrote: Using base-package's IO-system, that is not possible as far as I know. The flag you need to pass CreateFile (api call which is used to open practically all files) is FILE_SHARE_READ. You can find these in Win32-package, but files opened via raw api bindings don't work well together with base-packages IO-system (ie, you need to read and write using rawish api calls.) as usual, Streams library may be used to solve this problem, although this will need some additional programming. please write me if win32read/win32write API is inappropriate dor your needs -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] beginner's problem about lists
On Wed, 2006-10-11 at 11:40 +0100, Malcolm Wallace wrote: ihope [EMAIL PROTECTED] wrote: It's possible to make both infinite list and finite list datatypes: data Inf a = InfCons a (Inf a) data Fin a = FinCons a !(Fin a) | FinNil At least, I think the Fin type there has to be finite... No, your Fin type can also hold infinite values. The strictness annotation on the (Fin a) component merely ensures that the tail exists to one constructor's depth (Head Normal Form). It does not force strictness all the way down (full Normal Form). Are you sure? Since it does it recursively, if each cons ensures that it has a tail. Then that tail must be Nil or Cons (since we know it can't be _|_), and if it's Cons... It's not full normal form of course because it's not strict in the list elements, but it is spine strict all the way down. longList 0 = undefined longList n = n : longList (n-1) case longList 3 of n : _ - n 3 longFin 0 = undefined longFin n = n `FinCons` longFin (n-1) case longFin 3 of FinCons n _ - n *** Exception: Prelude.undefined Or am I really confused? Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Vertical tabs in source code and other obscure chars
Brian Hulley wrote: Hi, In the Haskell98 report at http://haskell.org/onlinereport/lexemes.html section 2.2 has the rule: whitechar - newline | vertab | space | tab | uniWhite Does anyone know what a vertical tab is supposed to do? Is there any reason to allow them as whitespace? (Does anyone in the universe actually use them?) To rephrase my question, what is a Haskell lexer/parser supposed to do when it encounters a vertical tab? The description of the layout rule in the report does not specify what a vertical tab means. If no-one knows the answer, perhaps the rule should be changed to: whitechar - newline | space | tab | uniWhite and a vertical tab's could just be treated as illegal characters. Regards, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] windows file locking
HiSo far the windows API seems to work for me. Currently I'm still struggling to notwrite garbage to the file but the shared access works now. Does anyone have anexample how to use it (e.g. the implementation of hPutStr on windows or something, i did not find it in the ghc source code)?I tried to use Streams before but without the windows API.regardsStefan2006/10/11, Bulat Ziganshin [EMAIL PROTECTED]:Hello Esa,Wednesday, October 11, 2006, 2:13:49 PM, you wrote: Using base-package's IO-system, that is not possible as far as I know.The flag you need to pass CreateFile (api call which is used to open practically all files) is FILE_SHARE_READ. You can find these in Win32-package, but files opened via raw api bindings don't work well together with base-packages IO-system (ie, you need to read and write using rawish api calls.)as usual, Streams library may be used to solve this problem, althoughthis will need some additional programming. please write me if win32read/win32write API is inappropriate dor your needs--Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] beginner's problem about lists
On Wed, Oct 11, 2006 at 11:40:59AM +0100, Malcolm Wallace wrote: To: haskell-cafe@haskell.org From: Malcolm Wallace [EMAIL PROTECTED] Date: Wed, 11 Oct 2006 11:40:59 +0100 Subject: Re: [Haskell-cafe] beginner's problem about lists ihope [EMAIL PROTECTED] wrote: It's possible to make both infinite list and finite list datatypes: data Inf a = InfCons a (Inf a) data Fin a = FinCons a !(Fin a) | FinNil At least, I think the Fin type there has to be finite... No, your Fin type can also hold infinite values. The strictness annotation on the (Fin a) component merely ensures that the tail exists to one constructor's depth (Head Normal Form). It does not force strictness all the way down (full Normal Form). let q = FinCons 3 q in case q of FinCons i _ - i == _|_ does that contradict, or did i just not understand what you are saying? matthias ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] beginner's problem about lists
Matthias Fischmann [EMAIL PROTECTED] wrote: No, your Fin type can also hold infinite values. let q = FinCons 3 q in case q of FinCons i _ - i == _|_ does that contradict, or did i just not understand what you are saying? That may be the result in ghc, but nhc98 gives the answer 3. It is not entirely clear which implementation is correct. The Language Report has little enough to say about strict components of data structures - a single paragraph in 4.2.1. It defines them in terms of the strict application operator ($!), thus ultimately in terms of seq, and as far as I can see, nhc98 is perfectly compliant here. The definition of seq is seq _|_ b = _|_ seq a b = b, if a/= _|_ In the circular expression let q = FinCons 3 q in q it is clear that the second component of the FinCons constructor is not _|_ (it has at least a FinCons constructor), and therefore it does not matter what its full unfolding is. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] beginner's problem about lists
Malcolm Wallace wrote: Matthias Fischmann [EMAIL PROTECTED] wrote: No, your Fin type can also hold infinite values. let q = FinCons 3 q in case q of FinCons i _ - i == _|_ does that contradict, or did i just not understand what you are saying? That may be the result in ghc, but nhc98 gives the answer 3. It is not entirely clear which implementation is correct. The Language Report has little enough to say about strict components of data structures - a single paragraph in 4.2.1. It defines them in terms of the strict application operator ($!), thus ultimately in terms of seq, and as far as I can see, nhc98 is perfectly compliant here. The definition of seq is seq _|_ b = _|_ seq a b = b, if a/= _|_ In the circular expression let q = FinCons 3 q in q it is clear that the second component of the FinCons constructor is not _|_ (it has at least a FinCons constructor), and therefore it does not matter what its full unfolding is. The translation given in the language report says this expression is equivalent to let q = (\x1 x2 - (( FinCons' $ x1) $! x2) ) 3 q in q (where FinCons' is a lazy constructor) in terms of seq let q = (\x1 x2 - x2 `seq` ( FinCons' x1 x2 ) ) 3 q in q this evaluates to let q = (q `seq` ( FinCons' 3) ) in q hence on top-level q is rather a seq-expression than a constructor-expression ;-) Regards, David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] beginner's problem about lists
On Oct 11, 2006, at 10:14 AM, Malcolm Wallace wrote: Matthias Fischmann [EMAIL PROTECTED] wrote: No, your Fin type can also hold infinite values. let q = FinCons 3 q in case q of FinCons i _ - i == _|_ does that contradict, or did i just not understand what you are saying? That may be the result in ghc, but nhc98 gives the answer 3. It is not entirely clear which implementation is correct. The Language Report has little enough to say about strict components of data structures - a single paragraph in 4.2.1. It defines them in terms of the strict application operator ($!), thus ultimately in terms of seq, and as far as I can see, nhc98 is perfectly compliant here. The definition of seq is seq _|_ b = _|_ seq a b = b, if a/= _|_ In the circular expression let q = FinCons 3 q in q it is clear that the second component of the FinCons constructor is not _|_ (it has at least a FinCons constructor), and therefore it does not matter what its full unfolding is. Let's do some algebra. data FinList a = FinCons a !(FinList a) let q = FinCons 3 q in q == let q = ((\x1 x2 - (FinCons $ x1)) $! x2) 3 q in q (translation from 4.2.1) == let q = (FinCons $ 3) $! q in q (beta) == let q = ($!) (($) FinCons 3) q in q (syntax) == let q = ($!) ((\f x - f x) FinCons 3) q in q (unfold ($)) == let q = ($!) (FinCons 3) q in q (beta) == let q = (\f x - seq x (f x)) (FinCons 3) q in q(unfold ($!)) == let q = seq q (FinCons 3 q) in q(beta) We have (from section 6.2): seq _|_ y = _|_ seq x y = yiff x /= _|_ Now, here we have an interesting dilemma. Suppose q is _|_, then: let q = seq q (FinCons 3 q) in q == let q = _|_ in q(specification of seq) == _|_ (unfold let) Instead suppose q /= _|_, then: let q = seq q (FinCons 3 q) in q == let q = FinCons 3 q in q(specification of seq) == let q = FinCons 3 q in FinCons 3 q(unfold let) == FinCons 3 (let q = FinCons 3 q in q) (float let) It seems that both answers are valid, in that they conform to the specification. Is 'seq' under-specified? Using a straightforward operational interpretation, you will probably get the first answer, _| _, and this is what I have always assumed. The second requires a sort of strange leap of faith to arrive at that answer (ie, assume 'q' is non-bottom), and is less satisfying to me. What do others think? Regards, Malcolm Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] beginner's problem about lists
[start this post by reading the last paragraph, i just needed to go through the rest to figure it out for myself.] On Wed, Oct 11, 2006 at 03:14:23PM +0100, Malcolm Wallace wrote: To: haskell-cafe@haskell.org From: Malcolm Wallace [EMAIL PROTECTED] Date: Wed, 11 Oct 2006 15:14:23 +0100 Subject: Re: [Haskell-cafe] beginner's problem about lists Matthias Fischmann [EMAIL PROTECTED] wrote: No, your Fin type can also hold infinite values. let q = FinCons 3 q in case q of FinCons i _ - i == _|_ does that contradict, or did i just not understand what you are saying? That may be the result in ghc, but nhc98 gives the answer 3. It is not entirely clear which implementation is correct. The Language Report has little enough to say about strict components of data structures - a single paragraph in 4.2.1. It defines them in terms of the strict application operator ($!), thus ultimately in terms of seq, and as far as I can see, nhc98 is perfectly compliant here. The definition of seq is seq _|_ b = _|_ seq a b = b, if a/= _|_ In the circular expression let q = FinCons 3 q in q it is clear that the second component of the FinCons constructor is not _|_ (it has at least a FinCons constructor), and therefore it does not matter what its full unfolding is. Interesting point. But one could argue that with strictness in data types this is what happens: FinCons 3 q == q `seq` FinCons 3 q == FinCons 3 q `seq` FinCons 3 q == q `seq` FinCons 3 q `seq` FinCons 3 q == ... Section 4.2.1. of the H98 standard sais: Whenever a data constructor is applied, each argument to the constructor is evaluated if and only if the corresponding type in the algebraic datatype declaration has a strictness flag... It is also reduced to strict function application ($!) there, see Section 6.2. This yields: FinCons 3 q (1.) == (\ x1 x2 - ((FinCons $ x1) $! x2)) 3 q (2.) == (FinCons $ 3) $! q(3.) == q `seq` ((FinCons $ 3) q) (4.) == FinCons 3 q `seq` ((FinCons $ 3) q) (5.) -- Hh. I suddenly see what you mean. Ok, but isn't there a difference between FinCons 3 q as an expression and FinCons box box as HNF? According to Section 4.2.1., the former is equivalent to a lambda expression in (2.), which evaluates to (5.). So the first argument to seq in (5.) should evaluate to (5.) as well, and so on. Tell me I'm wrong, I want to learn something! (-: thanks, matthias signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] beginner's problem about lists
On Wed, Oct 11, 2006 at 11:04:49AM -0400, Robert Dockins wrote: let q = seq q (FinCons 3 q) in q(beta) We have (from section 6.2): seq _|_ y = _|_ seq x y = yiff x /= _|_ Now, here we have an interesting dilemma. The meaning of a recursive definition is the least fixed point of the equation, in this case _|_. Same as let x = x in x. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] beginner's problem about lists
On Oct 11, 2006, at 11:14 AM, Ross Paterson wrote: On Wed, Oct 11, 2006 at 11:04:49AM -0400, Robert Dockins wrote: let q = seq q (FinCons 3 q) in q(beta) We have (from section 6.2): seq _|_ y = _|_ seq x y = yiff x /= _|_ Now, here we have an interesting dilemma. The meaning of a recursive definition is the least fixed point of the equation, in this case _|_. Same as let x = x in x. Ah... of course! A simple explanation; I hoped there was one. It's nice that it coincides with what I wanted the answer to be. :-) Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Trying to understand HList / hSequence now [why it works]
On Tue, Oct 10, 2006 at 07:45:28PM -0700, [EMAIL PROTECTED] wrote: To: [EMAIL PROTECTED] Cc: haskell-cafe@haskell.org From: [EMAIL PROTECTED] Date: Tue, 10 Oct 2006 19:45:28 -0700 (PDT) Subject: Re: Trying to understand HList / hSequence now [why it works] Matthias Fischmann wrote: instance (Monad m, HSequence m HNil HNil) = HSequence m HNil HNil where hSequence _ = return HNil how can i use the goal of the declaration as one of the conditions without causing some sort of black hole in the type inference algorithm? Very easily: the instance head is implicitly the part of its own context (so that a method can be recursive). A simple way to see that is the following deliberately erroneous class: That explains why it is legal, but not why it can be necessary. In my code, I had to add the instance goal to the context in order for type inference to quite complaining about incomplete context. But never mind. I should really do some reading. Your hSequence implementation I like, yes. I will try that instead of mine, perhaps that'll soothen the type checker. thanks! matthias class C a where mc :: a - Bool instance Eq a = C a where mc x = x x The error message says Could not deduce (Ord a) from the context (C a, Eq a) arising from use of `' at /tmp/f2.hs:30:36 It is revealing to observe the context that the typechecker thinks is available: it is (C a, Eq a). Eq a is there because we explicitly wrote it in the instance declaration. C a is there just by default. We could just as well written instance (Ord a, C a) = C a where mc x = x x Incidentally, the hSequence can be written as follows import TypeCastGeneric2 data ConsM instance (TypeCast (m1 l) (m l), Monad m) = Apply ConsM (m a, m1 l) (m (HCons a l)) where apply _ (me,ml) = liftM2 HCons me (typeCast ml) hSequence l = hFoldr (undefined::ConsM) (return HNil) l hlist = HCons (Just 1) (HCons (Just 'c') HNil) hlist2 = HCons ([1]) (HCons (['c']) HNil) testHSequence = hSequence hlist testHSequence2 = hSequence hlist2 *Foo :t testHSequence testHSequence :: Maybe (HCons Integer (HCons Char HNil)) *Foo testHSequence Just (HCons 1 (HCons 'c' HNil)) *Foo testHSequence2 [HCons 1 (HCons 'c' HNil)] The typechecker will complain if we try to mix different monads within the same HList, and then sequence it. signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [off-topic / administrative] List Reply-to
Mikael Johansson wrote: On Tue, 10 Oct 2006, Misha Aizatulin wrote: Here is an argument against Reply-To munging. I'd say I agree with it: http://www.unicom.com/pw/reply-to-harmful.html * It provides no benefit to the user of a reasonable mailer. [...] 1) get multiple copies of mails concerning discussions I participate in or 2) have to manually re-edit the header each and every time I want to keep a discussion on a mailing list, possibly with added trouble finding the right adress to send to A reasonable mailer has functions reply, reply-to-all and reply-to-list. I'm composing this mail using reply-to-list, have to edit no headers, the reply goes to the list and nobody gets duplicate copies. * It removes important information, which can make it impossible to get back to the message sender. This is the most important bit, actually. Anyone who wants to post a single question to haskell or haskell-cafe has to be subscribed, or the reply may go to the list, no matter what he put into the reply-to header. Is it a good thing to shut out casual users? I view pine as something that should be classified as reasonable Pein (sic!) is not reasonable. If you love it so much, please whip out the source code, implement a reply-to-list function and get at least one mailer removed from a silly debate. I disagree. I don't agree. I don't agree. I don't agree. I don't agree. Very convincing. Keep up the good work. Udo. -- Hast du zum Leben kein Motiv -- steig mal vor, vielleicht geht's schief. -- aus einem Gipfelbuch signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [off-topic / administrative] List Reply-to
On Wed, 11 Oct 2006, Udo Stenzel wrote: Mikael Johansson wrote: * It removes important information, which can make it impossible to get back to the message sender. This is the most important bit, actually. Anyone who wants to post a single question to haskell or haskell-cafe has to be subscribed, or the reply may go to the list, no matter what he put into the reply-to header. Is it a good thing to shut out casual users? Point. However, is there any sort of indication whether a poster is actually subscribed to the list? I would use reply-to-list as a default unless explicitly stated in an email that list-replies will go unread; and I tend to try to monitor lists after posing question on them at least long enough to detect any reasonably quick answers to my questions. I view pine as something that should be classified as reasonable Pein (sic!) is not reasonable. If you love it so much, please whip out the source code, implement a reply-to-list function and get at least one mailer removed from a silly debate. This point has been made abundantly lately. I disagree. I don't agree. I don't agree. I don't agree. I don't agree. Very convincing. Keep up the good work. Quite a few of the arguments made on the originally refered webpage were of a highly emotional kind. Arguing such points boils down to whether the emotions expressed are shared or not. Udo. -- Mikael Johansson | To see the world in a grain of sand [EMAIL PROTECTED]| And heaven in a wild flower http://www.mikael.johanssons.org | To hold infinity in the palm of your hand | And eternity for an hour ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [off-topic / administrative] List Reply-to
Robert Dockins wrote: I think (pure speculation) the haskell.org mail server is set up to omit people from mail it sends if they appear in the To: or Cc: of the original mail. Yes, this is a feature of recent Mailmans. Finally, I agree that reply-to munging is a bad idea, but I don't think appealing to a definition of 'reasonable mailer' that doesn't match a large portion of mail clients currently in the wild is a good way to argue the point. Gnus might have been the first one to have it, but mutt (very popular in hackerdom) was perhaps the one that popularized it. I am currently using Mozilla Thunderbird, for which it is available as an extension (unfortunately, it also requires a patch for Thunderbird; but Debian sid has already applied it). Still, when choosing between a poor hack (Reply-To munging) and the right answer (fixing mailers to support reply-to-list), I know which I prefer. The former may be appropriate in mailing lists where the audience consists solely of non-geeks (who might not be able to choose a good mailer), but in technical lists, I see no need for it. If you prefer a mail client that does not support the feature, bug your vendor to add it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: [Haskell-cafe] beginner's problem about lists
For my own edification (experts: please remark if I stray from any conventional notions--be as picky as possible) and perhaps for anyone who didn't quite grok Ross Paterson's punchline, I'm going to try to answer the question How does seq affect the definedness CPO? At the heart of these two recursive definitions q = 3 : q (1) r = r `seq` (3 : r) (2) we find these two functions f and g f x = 3 : x g x = x `seq` (3 : x) such that q = lfp f r = lfp g This is the least fixed point approach to recursive definitions. (From Scott and Strachey? I'm not sure of the origins...) In the CPO of definedness, x y means that x is less-defined than y. Since _|_ is undefined: forall x . _|_ = x. For a more meaty case, consider l1 = Cons 3 Nil l2 = Cons 3 _|_ l2 l1 because l1 is more defined. If values don't share the same structure, (a tree and a list for instance) I don't think their comparison is meaningful (experts?). The intuition behind the lfp as a definition principle is that of refinement/approximation. When constructing a value for the recursively definition, we begin with _|_ which represents no information. Finding the lfp of function means that we apply the function as many times as is necessary to define the value. Each application of the function refines the value a bit more until we have the sufficient approximation of the full value. What constitutes sufficient is determined by how the value is used: consider ((head . tail) q) versus (length q). Intuitively q = lfp f = f(f(f(f(f(f (f(f(f _|_)))...)(*) r = lfg g = g(g(g(g(g(g (g(g(g _|_)))...) (**) q is infinite 3s because f is non-strict. Operationaly, when f is applied to the thunk representing the final q value, it contributes the (3:) constructor to the definition of q, making q more defined. Note that it does not need to force the evaluation of q in order to make this contribution. Thus, the intuitive (f _|_) of (*) is never evaluated. r is _|_ because g is strict. When g is applied to the thunk representing the final q value, it forces its evaluation which operationaly leads us to g again being applied to the final q value thunk without making any contribution to the definition. Thus, the intuitive (g _|_) of (**) is always evaluated. Since g is strict, g _|_ = _|_ and this reduction trickles all the way out until r = _|_. As Robert Dockins showed, any recursive definition of a Fin value unfolds to an equation like (2) because of the strictness annotation in the datatype. We just discussed that the lfp semantics of an equation of (2)'s form will always result in _|_. On the other hand, any finite definition of a Fin value works fine. So ihope's Fin data type is either a finite list or _|_, as was purposed. Was that all square? Dotted i's and such? Nick On 10/11/06, Ross Paterson [EMAIL PROTECTED] wrote: On Wed, Oct 11, 2006 at 11:04:49AM -0400, Robert Dockins wrote: let q = seq q (FinCons 3 q) in q(beta) We have (from section 6.2): seq _|_ y = _|_ seq x y = yiff x /= _|_ Now, here we have an interesting dilemma. The meaning of a recursive definition is the least fixed point of the equation, in this case _|_. Same as let x = x in x. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ghc 6.2.2 seems to ignore -package when there's a -prof option
I have a program using HSQL that I'm trying to profile. When I do ghc program.hs -package hsql -o program it compiles fine, but when I do ghc -prof -auto-all program.hs -package hsql -o program I get error messages saying failed to load interface for `Database.HSQL' and so forth, the same way I do if I leave off the -package argument entirely. How can I work around this? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Quantifying Partial Type Annotations
I've done a bit more thinking about partial type annotations (as proposed on the Haskell' list), and I have a somewhat more concrete proposals for some of the extensions to them that perhaps also makes more sense of the original basic idea as well. I'm sending it to the Cafe this time as it's a bit early to consider this for standardisation. I'd like to propose a new quantifier for type variables, which for now I'll call unknown[1] - correspondingly I'll talk about unknown-quantified variables and probably unknown variables where it's not ambiguous. Unknown quantifiers will never be introduced by the typechecker without a corresponding annotation - only propagated inwards. Whereas universal type variables must not accumulate additional constraints during typechecking (and in a traditional Hindley-Milner implementation only become universally quantified during a generalisation step), unknown type variables can - indeed this is their raison d'etre. Furthermore, they are never propagated 'outwards' - either the variable is constrained sufficiently that it can be replaced with a monotype or, having otherwise finished typechecking the corresponding term, the unknown quantifier is replaced with a forall. For example: add' :: unknown x. x - x - x add' = (+) add'' :: unknown x. x - x - x add'' x y = (x::Int) + (y::Int) will typecheck, resulting in these types when the identifiers are used: add' :: forall x. Num x = x - x - x add'' :: Int - Int - Int It's probably also sensible to allow wildcard variables written _, generated fresh and implicitly unknown-quantified much as universal variables are now. Type synonyms seem to present an interesting question though - it seems to me most sensible to hang on to the quantification at top-level and generalise it only as we finish type-checking a module, rather than copying out the quantifier anew each time. Any comments? The amount of thinking I've done about interactions with rank-n variables is limited - I guess we'd need to prohibit unifying with type variables that're of smaller scope than the unknown variable? I'm don't think I can see any other worrying issues there. Unknown variables in method declarations seem... meaningless to me, they're not proper existentials and I don't think there's a sane meaning for them that isn't a kludge for associated types instead. I don't think they belong in instances for similar reasons. Incidentally, I think there's also a cute use case in .hs-boot files, where an unknown-quantified variable could be used to tie some knots in a manner similar to the way recursive bindings are checked now. If so, I have an interesting use for this. [1] Other names that have occurred to me are solve (as in solve for x), and meta (by analogy to metavariables in the typechecker - because by the time we've finished checking the annotated term we'll have removed the quantifier), but unknown seems by far the strongest to me. No doubt someone'll suggest a far better name shortly after I post this! -- [EMAIL PROTECTED] There is no magic bullet. There are, however, plenty of bullets that magically home in on feet when not used in exactly the right circumstances. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [off-topic / administrative] List Reply-to
Robert Dockins wrote: FWIW, I'm using Apple's Mail.app, and it doesn't have a reply-to- list. In fact, I don't know of a mail client off the top of my head that does Mutt does. But that's to be expected, considering that it was written because the author was fed up with the poor handling of mailing lists. However, I don't recall problems with multiple copies of emails. I did get your mail twice, which I don't consider a huge problem. I think (pure speculation) the haskell.org mail server is set up to omit people from mail it sends if they appear in the To: or Cc: of the original mail. Actually it's Mailman that can be set up this way. I don't think, it is done on haskell.org, though. Should an admin read this, you might consider switching that option on (and leaving reply-to-munging off). Udo. -- Two rules get you through life: If it's stuck and it's not supposed to be, WD-40 it. If it's not stuck and it's supposed to be, duct tape it. -- The Duct Tape Guys' book WD-40 signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Quantifying Partial Type Annotations
Philippa Cowderoy wrote:
I've done a bit more thinking about partial type annotations (as proposed
on the Haskell' list), and I have a somewhat more concrete proposals for
some of the extensions to them that perhaps also makes more sense of the
original basic idea as well. I'm sending it to the Cafe this time as it's
a bit early to consider this for standardisation.
I'd like to propose a new quantifier for type variables, which for now
I'll call unknown[1] - correspondingly I'll talk about unknown-quantified
variables and probably unknown variables where it's not ambiguous.
Unknown quantifiers will never be introduced by the typechecker without a
corresponding annotation - only propagated inwards. Whereas universal type
variables must not accumulate additional constraints during typechecking
(and in a traditional Hindley-Milner implementation only become
universally quantified during a generalisation step), unknown type
variables can - indeed this is their raison d'etre. Furthermore, they are
never propagated 'outwards' - either the variable is constrained
sufficiently that it can be replaced with a monotype or, having otherwise
finished typechecking the corresponding term, the unknown quantifier is
replaced with a forall.
The intention is that the unknown variable might eventually get a
concrete type, but you'd rather let the typechecker work it out?
I think in the language of the GHC typechecker you would say your
quantifier introduces a wobbly type variable, rather than the rigid
type variables of a forall.
For example:
add' :: unknown x. x - x - x
add' = (+)
add'' :: unknown x. x - x - x
add'' x y = (x::Int) + (y::Int)
will typecheck, resulting in these types when the identifiers are used:
add' :: forall x. Num x = x - x - x
add'' :: Int - Int - Int
It's probably also sensible to allow wildcard variables written _,
generated fresh and implicitly unknown-quantified much as universal
variables are now.
Type synonyms seem to present an interesting question though - it seems to
me most sensible to hang on to the quantification at top-level and
generalise it only as we finish type-checking a module, rather than
copying out the quantifier anew each time. Any comments?
I discussed something similar a while ago, in connection with the
discussions about alternate notation for class constraints, except I
suggested copying the quantifier around with the synonym. This lets you
write types like
type P a = some b . (b - a, a)
or otherwise make a type synonym that asserts some part of your type is
an instance of a certain scheme without fixing concrete types or
requiring full parametricity.
More abstractly, type synonyms exist to name and reuse parts of type
signatures. If you introduce partial type signatures, it seems fitting
to extend type synonyms to naming and reusing part of partial type
signatures as well.
The amount of thinking I've done about interactions with rank-n variables
is limited - I guess we'd need to prohibit unifying with type variables
that're of smaller scope than the unknown variable? I'm don't think I can
see any other worrying issues there.
Unknown variables in method declarations seem... meaningless to me,
they're not proper existentials and I don't think there's a sane meaning
for them that isn't a kludge for associated types instead. I don't think
they belong in instances for similar reasons.
Incidentally, I think there's also a cute use case in .hs-boot files,
where an unknown-quantified variable could be used to tie some knots in a
manner similar to the way recursive bindings are checked now. If so, I
have an interesting use for this.
[1] Other names that have occurred to me are solve (as in solve for
x), and meta (by analogy to metavariables in the typechecker - because
by the time we've finished checking the annotated term we'll have removed
the quantifier), but unknown seems by far the strongest to me. No doubt
someone'll suggest a far better name shortly after I post this
Daan Leijen calls it some.
It's implemented in Morrow, and described in his paper on existential
types. He translates type annotations to type-restricting functions,
where
e :: forall a . T
becomes
(ann :: (forall a . T) - (forall a . T)) e
and
e :: some a . T
becomes
(ann :: forall a . T - T) e
Writing type signatures for things unpacked from existentials is another
nice use for this quantifier. The some a. can unify with the skolem
constant from the unpacking. One of his examples:
type Key a = { val :: a, key :: a - Int }
absInt :: exists a. Key a
absInt = { val = 1, key i = i }
one1 = (\x - x.key x.val) (head [absInt])
one2 = let x :: some a. Key a
x = absInt
in x.key x.val
Brandon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghc 6.2.2 seems to ignore -package when there's a -prof option
On Wed, 2006-10-11 at 16:01 -0400, Seth Gordon wrote: I have a program using HSQL that I'm trying to profile. When I do ghc program.hs -package hsql -o program it compiles fine, but when I do ghc -prof -auto-all program.hs -package hsql -o program I get error messages saying failed to load interface for `Database.HSQL' and so forth, the same way I do if I leave off the -package argument entirely. How can I work around this? The likely problem is that you do not have the profiling version of hsql installed. The reason for the error message is that the .hi files for the normal and profiling versions are distinct, and in this case the .hi files for the profiling version are missing. Newer versions of GHC give a slightly more helpful error message in this case. If you built from source using Cabal then you need to rebuild and pass -p (or --enable-library-profiling) during the configure step. If you're using a distro package then you probably just need the prof variant as well. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: [Haskell-cafe] beginner's problem about lists
On 11/10/06, Nicolas Frisby [EMAIL PROTECTED] wrote: Intuitively q = lfp f = f(f(f(f(f(f (f(f(f _|_)))...)(*) r = lfg g = g(g(g(g(g(g (g(g(g _|_)))...) (**) This way of writing it would imply (at least to me) that the number of f's and g's involved is finite, when that's not really the intention. It's probably better to write something like: q = lfp f = f (f (f (f (... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Yet Another Haskell Tutorial Question
I've been working through the Yet Anther Haskell Tutorial at http://www.cs.utah.edu/~hal/docs/daume02yaht.pdf , and I've gotten up to Excercise 4.6. It says: === YAHT === Write a datatype Tuple which can hold one, two, three or four elements, depending on the constructor (that is, there should be four constructors, one for each number of arguments). Also provide functions tuple1 through tuple4 which take a tuple and return Just the value in that position, or Nothing if the number is invalid (i.e., you ask for the tuple4 on a tuple holding only two elements). === /YAHT === I've got a brute-force answer, but I'm sure that there's a better way, and I can't find it. The code I've currently got is at http://paste.lisp.org/display/27806 . Anybody want to point me in the right direction? Thanks Bill Mill bill.mill at gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Yet Another Haskell Tutorial Question
On Wed, Oct 11, 2006 at 09:16:57PM -0400, Bill Mill wrote: I've been working through the Yet Anther Haskell Tutorial at http://www.cs.utah.edu/~hal/docs/daume02yaht.pdf , and I've gotten up to Excercise 4.6. It says: Have you checked the solution? Page 167. Tamas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Yet Another Haskell Tutorial Question
That's about right, though you could shorten a few of the definitions by matching with the wildcard pattern _ like this: tuple4 :: Tuple a b c d - Maybe d tuple4 (QuadrupleTuple a b c d) = Just d tuple4 _ = Nothing It's also possible to use case: tuple3 :: Tuple a b c d - Maybe d tuple3 x = case x of (QuadrupleTuple a b c d) - c (TripleTuple a b c) - c _- Nothing On 11/10/06, Bill Mill [EMAIL PROTECTED] wrote: I've been working through the Yet Anther Haskell Tutorial at http://www.cs.utah.edu/~hal/docs/daume02yaht.pdf , and I've gotten up to Excercise 4.6. It says: === YAHT === Write a datatype Tuple which can hold one, two, three or four elements, depending on the constructor (that is, there should be four constructors, one for each number of arguments). Also provide functions tuple1 through tuple4 which take a tuple and return Just the value in that position, or Nothing if the number is invalid (i.e., you ask for the tuple4 on a tuple holding only two elements). === /YAHT === I've got a brute-force answer, but I'm sure that there's a better way, and I can't find it. The code I've currently got is at http://paste.lisp.org/display/27806 . Anybody want to point me in the right direction? Thanks Bill Mill bill.mill at gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Yet Another Haskell Tutorial Question
On 10/11/06, Tamas K Papp [EMAIL PROTECTED] wrote: On Wed, Oct 11, 2006 at 09:16:57PM -0400, Bill Mill wrote: I've been working through the Yet Anther Haskell Tutorial at http://www.cs.utah.edu/~hal/docs/daume02yaht.pdf , and I've gotten up to Excercise 4.6. It says: Have you checked the solution? Page 167. Tamas Yeah... sorry 'bout that. Thanks Bill ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Quantifying Partial Type Annotations
Philippa Cowderoy wrote: I'd like to propose a new quantifier for type variables, which for now I'll call unknown[1] - correspondingly I'll talk about unknown-quantified variables and probably unknown variables where it's not ambiguous. Unqualified type variables are of course implicitly qualified forall. In an ideal world, where compatibility with 98 were not an issue, they would be unknown and we wouldn't need an unknown keyword. But it's not, and it is, and they aren't, so perhaps we do... -- Ashley Yakeley Seattle WA ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
