Re: [GHC] #5555: support qualified names for invoking a quasiquoter
#: support qualified names for invoking a quasiquoter --+- Reporter: nfrisby| Owner: pcapriotti Type: feature request| Status: new Priority: normal | Milestone: 7.6.1 Component: Compiler (Parser) | Version: 7.0.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown|Testcase: Blockedby: |Blocking: Related: | --+- Changes (by pcapriotti): * owner: = pcapriotti * difficulty: = Unknown -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/#comment:2 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] #5976: Panic in a user Template Haskell function is wrongly reported as a GHC bug
#5976: Panic in a user Template Haskell function is wrongly reported as a GHC bug -+-- Reporter: SimonMeier | Owner: pcapriotti Type: bug | Status: patch Priority: normal | Milestone: 7.4.2 Component: Compiler|Version: 7.4.1 Resolution: | Keywords: Os: Linux | Architecture: Unknown/Multiple Failure: Compile-time crash | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: -+-- Comment(by pcapriotti): You're right, `safeShowException` can be used regardless. I simplified the patch. Ok to push? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5976#comment:7 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] #5555: support qualified names for invoking a quasiquoter
#: support qualified names for invoking a quasiquoter --+- Reporter: nfrisby| Owner: pcapriotti Type: feature request| Status: patch Priority: normal | Milestone: 7.6.1 Component: Compiler (Parser) | Version: 7.0.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown|Testcase: Blockedby: |Blocking: Related: | --+- Changes (by pcapriotti): * status: new = patch Comment: The attached patch adds a qualified quasi quote token to the lexer, and the corresponding production to the parser. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/#comment:3 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] #5763: Confusing error message
#5763: Confusing error message -+-- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.6.1 Component: Compiler | Version: 7.2.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: indexed-types/should_fail/T5763 Blockedby:|Blocking: Related:| -+-- Changes (by simonpj): * owner: = simonpj -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5763#comment:3 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] #5984: TH: newtypes are converted to datas
#5984: TH: newtypes are converted to datas +--- Reporter: mikhail.vorozhtsov | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.5 | Keywords: Os: Unknown/Multiple| Architecture: Unknown/Multiple Failure: None/Unknown| Testcase: Blockedby: | Blocking: Related: | +--- Commit b857c8ad367877f424b5fca50bd45199f39f86c7 has a typo in `cvtDec` that causes a `NewtypeD` to be translated to `TyData` with `tc_ND=DataType` instead of `NewType`. Trivial fix attached. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5984 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] #5826: Refer to Control.Concurrent instead of GHC.Conc in GHC 7.4.1 User's Guide
#5826: Refer to Control.Concurrent instead of GHC.Conc in GHC 7.4.1 User's Guide +--- Reporter: shelarcy | Owner: Type: task | Status: closed Priority: high | Milestone: 7.4.2 Component: Documentation |Version: 7.4.1-rc2 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Documentation bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: +--- Changes (by pcapriotti): * status: merge = closed * resolution: = fixed Comment: Reverted merges on the 7.4 branch, as we don't want to add a new public function. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5826#comment:5 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] #5976: Panic in a user Template Haskell function is wrongly reported as a GHC bug
#5976: Panic in a user Template Haskell function is wrongly reported as a GHC bug -+-- Reporter: SimonMeier | Owner: pcapriotti Type: bug | Status: patch Priority: normal | Milestone: 7.4.2 Component: Compiler|Version: 7.4.1 Resolution: | Keywords: Os: Linux | Architecture: Unknown/Multiple Failure: Compile-time crash | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: -+-- Comment(by simonpj): Yes, fine except * I suggest you put the `failWithTc` part into `mk_msg`, renaming it `failWithException` or something. * Can you add a `Note [Concealed exceptions]` in `TcSplice` that gives a concrete example (along the lines of the test case you added) of what the deal here is? In two years time we will have forgotten, and a concrete example is a huge help. Then, go ahead and commit. Thanks. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5976#comment:8 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] #5820: defining instance in GHCi leads to duplicated instances
#5820: defining instance in GHCi leads to duplicated instances -+-- Reporter: guest | Owner: Type: bug | Status: merge Priority: high| Milestone: 7.4.2 Component: GHCi|Version: 7.4.1-rc1 Resolution: fixed | Keywords: Os: Unknown/Multiple| Architecture: Unknown/Multiple Failure: None/Unknown| Difficulty: Unknown Testcase: ghci/scripts/T5820 | Blockedby: Blocking: |Related: -+-- Comment(by simonpj): This patch does not merge cleanly on the 7.4 branch, so I propose that we do not fix it on the branch. It only affects instances declared at the GHCi prompt, and maybe we can manage without them working properly. If this is going to ruin your life, yell. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5820#comment:7 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] #5984: TH: newtypes are converted to datas
#5984: TH: newtypes are converted to datas ---+ Reporter: mikhail.vorozhtsov | Owner: pcapriotti Type: bug | Status: new Priority: normal | Milestone: Component: Compiler| Version: 7.5 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple| Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by pcapriotti): * owner: = pcapriotti * difficulty: = Unknown -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5984#comment:1 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] #5985: Type operators are not accepted as variables in contexts
#5985: Type operators are not accepted as variables in contexts
+---
Reporter: mikhail.vorozhtsov | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.5 | Keywords:
Os: Unknown/Multiple| Architecture: Unknown/Multiple
Failure: None/Unknown| Testcase:
Blockedby: | Blocking:
Related: |
+---
The following code is accepted by 7.4.1 (and 7.2/7.0/6.12), but rejected
by HEAD:
{{{
$ ghci-7.5.20120402 -XTypeOperators
GHCi, version 7.5.20120402: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
λ import Control.Category
λ let f :: Category (-) = (a - b); f = undefined
interactive:3:19: Not in scope: type constructor or class `-'
interactive:3:31: Not in scope: type constructor or class `-'
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5985
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] #5985: Type operators are not accepted as variables in contexts
#5985: Type operators are not accepted as variables in contexts -+-- Reporter: mikhail.vorozhtsov | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler|Version: 7.5 Resolution: invalid | Keywords: Os: Unknown/Multiple| Architecture: Unknown/Multiple Failure: None/Unknown| Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: -+-- Changes (by simonpj): * status: new = closed * difficulty: = Unknown * resolution: = invalid Comment: Indeed I have changed the behavoiur of `TypeOperators` as described here http://www.mail-archive.com/glasgow-haskell- us...@haskell.org/msg21084.html There were few replies, and mostly supportive, so I went ahead. Yell if you disagree strenuously. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5985#comment:1 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] #5977: Allow ignoring global package db
#5977: Allow ignoring global package db --+- Reporter: duncan| Owner: Type: feature request | Status: new Priority: normal| Component: Compiler Version: 7.4.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Testcase: Blockedby:| Blocking: Related:| --+- Changes (by JeremyShaw): * cc: JeremyShaw (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5977#comment:1 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] #5612: Better support for kinds in Template Haskell
#5612: Better support for kinds in Template Haskell ---+ Reporter: guest | Owner: igloo Type: feature request | Status: new Priority: low | Milestone: 7.6.1 Component: Compiler| Version: 7.3 Keywords: PolyKinds, TemplateHaskell | Os: Unknown/Multiple Architecture: Unknown/Multiple| Failure: Other Difficulty: |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by goldfire): * owner: goldfire = igloo Comment: Implementation complete and straightforward. Check out the attached patches. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5612#comment:11 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] #5986: HSQL won't install: missing FlexibleInstances
#5986: HSQL won't install: missing FlexibleInstances --+- Reporter: volker-wysk | Owner: Type: bug | Status: new Priority: normal| Component: libraries (other) Version: 7.4.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Testcase: Blockedby:| Blocking: Related:| --+- There is a FlexibleInstances entry needed, in hsql.cabal's extensions field. Otherwise, it won't compile. I'm talking about hsql-1.8.1. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5986 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] #5986: HSQL won't install: missing FlexibleInstances
#5986: HSQL won't install: missing FlexibleInstances -+-- Reporter: volker-wysk |Owner: Type: bug | Status: closed Priority: normal|Component: libraries (other) Version: 7.4.1 | Resolution: fixed Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Testcase:|Blockedby: Blocking:| Related: -+-- Changes (by volker-wysk): * status: new = closed * resolution: = fixed Comment: Fixed in version 1.8.2 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5986#comment:1 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
Potential GSoC proposal: Reduce the speed gap between 'ghc -c' and 'ghc --make'
Hi all,
[Hoping it's not too late.]
During my work on parallelising 'ghc --make' [1] I encountered a
stumbling block: running 'ghc --make' can be often much faster than
using separate compile ('ghc -c') and link stages, which means that
any parallel build tool built on top of 'ghc -c' will be significantly
handicapped [2]. As far as I understand, this is mainly due to the
effects of interface file caching - 'ghc --make' only needs to parse
and load them once. One potential improvement (suggested by Duncan
Coutts [3]) is to produce whole-package interface files and load them
in using mmap().
Questions:
Would implementing this optimisation be a worthwhile/realistic GSoC project?
What are other potential ways to bring 'ghc -c' performance up to par
with 'ghc --make'?
[1] https://github.com/23Skidoo/ghc-parmake
[2] https://gist.github.com/1360470
[3]
http://www.reddit.com/r/haskell/comments/qwj5j/the_cabal_of_my_dreams/c41a5gx
--
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Potential GSoC proposal: Reduce the speed gap between 'ghc -c' and 'ghc --make'
Questions: Would implementing this optimisation be a worthwhile/realistic GSoC project? What are other potential ways to bring 'ghc -c' performance up to par with 'ghc --make'? I implemented a ghc server that runs several persistent ghcs, and distributes compiles among them. It seemed to work, but the speed gains weren't what I'd hoped for. But perhaps I was doing something dumb that hurt performance. I'd be happy to upload the source if you're interested. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
What do the following numbers mean?
Dear all, I ran a small example program, and this is what I got from using the -s flag: 486,550,118,368 bytes allocated in the heap 323,749,418,440 bytes copied during GC 1,842,979,344 bytes maximum residency (219 sample(s)) 204,653,688 bytes maximum slop 4451 MB total memory in use (0 MB lost due to fragmentation) Generation 0: 924208 collections, 0 parallel, 1861.17s, 1866.05s elapsed Generation 1: 219 collections, 0 parallel, 283.44s, 284.01s elapsed INIT time0.00s ( 0.00s elapsed) MUT time 740.61s (745.45s elapsed) GCtime 2144.61s (2150.06s elapsed) EXIT time0.00s ( 0.00s elapsed) Total time 2885.23s (2895.51s elapsed) %GC time 74.3% (74.3% elapsed) Alloc rate656,953,176 bytes per MUT second Can anyone tell me what the exact difference is between 1,842,979,344 bytes maximum residency (219 sample(s)) and 4451 MB total memory in use (0 MB lost due to fragmentation) I could not find this information in the docs anywhere, but I may have missed it. best, Jur ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] A Modest Records Proposal
Lesson learned: for next year, write a Haskell program that tells if a given -cafe thread or reddit discussion is a April Fool's joke or not. On Sun, Apr 1, 2012 at 7:10 PM, Christopher Done chrisd...@googlemail.comwrote: I actually read the first couple paragraphs and thought “sounds interesting I'll read it later”. After reading it properly, I lol'd. After some initial feedback, I'm going to create a page for the Homotopy Extensional Records Proposal (HERP) on trac. There are really only a few remaining questions. 1) Having introduced homotopies, why not go all the way and introduce dependent records? In fact, are HERP and Dependent Extensional Records Proposal (DERP) already isomorphic? My suspicion is that HERP is isomorphic, but DERP is not. ___ Haskell-Cafe mailing list haskell-c...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Alp Mestanogullari ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] A Modest Records Proposal
On 2 April 2012 14:41, Michael Snoyman mich...@snoyman.com wrote: import Data.Time main = do now - getCurrentTime let (_, month, day) = toGregorian $ utctDay now putStrLn $ if month == 4 day == 1 then It's a joke else It's real import Data.Time main = do now - getCurrentTime let (_, month, day) = toGregorian $ utctDay now putStrLn $ if month == 4 day == 1 then It's a joke else It's real. (This output is not a joke. But run this program again to be sure.) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: cabal install version selection
Thanks, that was a rather curious problem then. With more version annotations, hackage compiled everything. Thanks for for testing! Gruss, Christian * Albert Y. C. Lai tre...@vex.net [31.03.2012 03:58]: On 12-03-30 06:37 PM, Christian Höner zu Siederdissen wrote: I fail to remember or re-google the package version selection for cabal, if no version constraints are given. If I depend on iteratee, and there are no constraints, does it take the lowest version? It takes the highest version. To verify, I fetched RNAFold.cabal of 1.99.1.0 and tried: cabal install --dry-run Its answer: Resolving dependencies... In order, the following would be installed (use -v for more details): ListLike-3.1.4 MonadCatchIO-transformers-0.2.2.3 OneTuple-0.2.1 PrimitiveArray-0.2.1.1 ADPfusion-0.0.1.0 bytestring-lexing-0.4.0 cmdargs-0.9.5 csv-0.1.2 file-embed-0.0.4.1 iteratee-0.8.8.1 ... It chooses the newest iteratee alright. I don't know what is going on with hackage's build bot. And I can't control it anyway. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users pgpKciJD4zPci.pgp Description: PGP signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Potential GSoC proposal: Reduce the speed gap between 'ghc -c' and 'ghc --make'
I for one think this would make a good GSoC project. Make sure you get your application in in time though. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] A Modest Records Proposal
On Mon, Apr 2, 2012 at 5:41 AM, Michael Snoyman mich...@snoyman.com wrote: On Mon, Apr 2, 2012 at 3:38 PM, Alp Mestanogullari alpmes...@gmail.com wrote: Lesson learned: for next year, write a Haskell program that tells if a given -cafe thread or reddit discussion is a April Fool's joke or not. import Data.Time main = do now - getCurrentTime let (_, month, day) = toGregorian $ utctDay now putStrLn $ if month == 4 day == 1 then It's a joke else It's real My strategy next year will be to not read any email on the 1st. I'll just wait until the 2nd to read it all. Foolproof! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: A Modest Records Proposal
ROTFL!
Ben
Gershom B wrote:
The records discussion has been really complicated and confusing. But
I have a suggestion that should provide a great deal of power to
records, while being mostly[1] backwards-compatible with Haskell 2010.
Consider this example:
data A a = A{a:a, aa::a, aaa :: a - A (a - a)}
data B a = B{aaa :: a - A (a - a), a :: A}
Now what is the type of this?
a a aa = a{a = a, aaa = aa}
Using standard Haskell typeclasses this is a difficult question to
answer. The types of for A and B do not unify in an obvious way.
However, while they are intensionally quite distinct, they unify
trivially extensionally. The obvious thing to do is then to extend the
type system with extensional equality on record functions.
Back when Haskell was invented, extensional equality was thought to be
hard. But purity was thought to be hard too, and so were Monads. Now,
we know that function existentionality is easy. In fact, if we add the
Univalence Axiom to GHC[2], then this is enough to get function
existensionality. This is a well-known result of Homotopy Type
Theory[3], which is a well-explored approach that has existed for at
least a few years and produced more than one paper[4]. Homotopy Type
Theory is so sound and well understood that it has even been
formalized in Coq.
Once we extend GHC with homotopies, it turns out that records reduce
to mere syntactic sugar, and there is a natural proof of their
soundness (Appendix A). Furthermore, there is a canonical projection
for any group of fields (Appendix B). Even better, we can make .
into the identity path operator, unifying its uses in composition and
projection. In fact, with extended (parenthesis-free) section rules,
. can also be used to terminate expressions, making Haskell friendly
not only to programmers coming from Java, but also to those coming
from Prolog!
After some initial feedback, I'm going to create a page for the
Homotopy Extensional Records Proposal (HERP) on trac. There are really
only a few remaining questions. 1) Having introduced homotopies, why
not go all the way and introduce dependent records? In fact, are HERP
and Dependent Extensional Records Proposal (DERP) already isomorphic?
My suspicion is that HERP is isomorphic, but DERP is not. However, I
can only get away with my proof using Scott-free semantics. 2) Which
trac should I post this too? Given how well understood homotopy type
theory is, I'm tempted to bypass GHC entirely and propose this for
haskell-prime. 3) What syntax should we use to represent homotopies?
See extend discussion in Appendix C.
HTH HAND,
Gershom
[1] To be precise, 100% of Haskell 2010 programs should, usually, be
able to be rewritten to work with this proposal with a minimal set of
changes[1a].
[1a] A minimal set of changes is defined as the smallest set of
changes necessary to make to a Haskell 2010 program such that it works
with this proposal. We can arrive at these changes by the following
procedure: 1) Pick a change[1b]. 2) Is it minimal? If so keep it. 3)
are we done? If not, make another change.
[1b] To do this constructively, we need an order. I suggest the lo
mein, since noodles give rise to a free soda.
[2] I haven't looked at the source, but I would suggest putting it in
the file Axioms.hs.
[3] http://homotopytypetheory.org/
[4] http://arxiv.org/
*Appendix A: A Natural Proof of the Soundness of HERP
Take the category of all types in HERP, with functions as morphisms.
Call it C. Take the category of all sound expressions in HERP, with
functions as morphisms. Call it D. Define a full functor from C to D.
Call it F. Define a faithful functor on C and D. Call it G. Draw the
following diagram.
F(X)F(Y)
| |
| |
| |
G(X)G(Y)
Define the arrows such that everything commutes.
*Appendix B: Construction of a Canonical Projection for Any Group of
Fields.
1) Take the fields along the homotopy to an n-ball.
2) Pack them loosely with newspaper and gunpowder.
3) Project them from a cannon.
In an intuitionistic logic, the following simplification is possible:
1) Use your intuition.
*Appendix C: Homotopy Syntax
Given that we already are using the full unicode set, what syntax
should we use to distinguish paths and homotopies? At first, I thought
we could avoid providing any syntax for homotopies at all. Haskell is
a language with type inference, so we should just be able to infer
paths and homotopies behind the scenes by adding homotopies to the
type system. That's a very nice answer in theory. But in the real
world, when we're writing code that solves actual problems,
theoretical niceties break down. What if a user wants to use a
nonstandard homotopy?
Why should we stop them just because we're too lazy to come up with a
good syntax? I then realized that we keep running out of syntax
because we've limited
Re: What do the following numbers mean?
On 02/04/2012, at 10:10 PM, Jurriaan Hage wrote: Can anyone tell me what the exact difference is between 1,842,979,344 bytes maximum residency (219 sample(s)) and 4451 MB total memory in use (0 MB lost due to fragmentation) I could not find this information in the docs anywhere, but I may have missed it. The maximum residency is the peak amount of live data in the heap. The total memory in use is the peak amount that the GHC runtime requested from the operating system. Because the runtime system ensures that the heap is always bigger than the size of the live data, the second number will be larger. The maximum residency is determined by performing a garbage collection, which traces out the graph of live objects. This means that the number reported may not be the exact peak memory use of the program, because objects could be allocated and then become unreachable before the next sample. If you want a more accurate number then increase the frequency of the heap sampling with the -isec RTS flag. Ben. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] 6th International School on Rewriting (ISR), July 16-20, 2012
Call for Participation ISR 2012 6th International School on Rewriting http://www.dsic.upv.es/~isr2012 July 16th - 20th Universitat Politecnica de Valencia Valencia, Spain Rewriting is a branch of computer science whose origins go back to the origins of computer science itself (with Thue, Church, Post, and many other prominent researchers). It has strong links with mathematics, algebra, and logic, and it is the basis of well-known programming paradigms like functional and equational programming, which are taught at the universitary level in many countries. In these programming paradigms and corresponding languages, the notions of reduction, pattern matching, confluence, termination, strategy, etc., are essential. Rewriting provides a solid framework for understanding, using, and teaching all these notions. Rewriting techniques are also used in many other areas of software engineering (scripting, prototyping, automated transformation of legacy systems, refactoring, web services, etc.) and are implemented in popular systems like Mathematica, Autocad, and others. Rewriting techniques play a relevant role in computing research, education, and industry. The International School on Rewriting is promoted by the IFIP Working Group 1.6 Term Rewriting. The school is aimed at master and PhD students, researchers, and practitioners interested in the study of rewriting concepts and their applications. Two tracks are offered, including the lectures and the courses: - Track A: for newcomers in the field, or just for people who want to obtain a new, updated exposure. * Jose Meseguer. Introduction to Term Rewriting * Albert Rubio. Termination of Rewriting: Foundations and Automation * Santiago Escobar. A Rewriting-Based Specification and Programming Language: Maude * Beatriz Alarcon Raul Gutierrez. Exercises on Term Rewriting - Track B: for those who want to get deeper in the most recent developments and applications of rewriting. * Maria Alpuente: Narrowing Techniques and Applications * Temur Kutsia: Matching, unification, and generalizations * Pierre Lescanne: Lambda Calculus: extensions and applications * Narciso Marti-Oliet: Rewriting Logic and Applications * Georg Moser: Automated Complexity Analysis of Term Rewriting Systems * Albert Oliveras: SAT and SMT techniques in Proof and Verification * Sophie Tison: Tree Automata, Turing Machines and Term Rewriting * Xavier Urbain: Certification of Rewriting Properties * Andrei Voronkov: Automated Reasoning and Theorem Proving Registration fees: 250 euro (early registration, before June 15, 2012) 350 euro (late registration, after June 15, 2012) Visit our web site for more information about registration and accommodation. The registration will be open in few weeks. For more information, please visit our web site or contact isr2...@dsic.upv.es Organizing Committee: Salvador Lucas (chair) Beatriz Alarcon Santiago Escobar Marco A. Feliu Raul Gutierrez Sonia Santiago Alicia Villanueva ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] (no subject)
a href=http://isukeworld.com/test/cat13/02efpk.html; http://isukeworld.com/test/cat13/02efpk.html/a___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] WING 2012: Final Call for Papers -- Extended Deadline
[Please post - apologies for multiple copies.] *** Submission deadline extended to April 13, 2012 *** WING 2012 - 4th International Workshop on INvariant Generation http://cs.nyu.edu/acsys/wing2012/ June 30, 2012 Manchester, UK (a satellite Workshop of IJCAR 2012) --- Final Call for Papers --- General --- The ability to automatically extract and synthesize auxiliary properties of programs has had a profound effect on program analysis, testing, and verification over the last several decades. A key impediment for program verification is the overhead associated with providing, debugging, and verifying auxiliary invariant annotations. Releasing the software developer from this burden is crucial for ensuring the practical relevance of program verification. In the context of testing, suitable invariants have the potential of enabling high-coverage test-case generation. Thus, invariant generation is a key ingredient in a broad spectrum of tools that help to improve program reliability and understanding. As the design and implementation of reliable software remains an important issue, any progress in this area will have a significant impact. The increasing power of automated theorem proving and computer algebra has opened new perspectives for computer-aided program verification; in particular for the automatic generation of inductive assertions in order to reason about loops and recursion. Especially promising breakthroughs are invariant generation techniques by Groebner bases, quantifier elimination, and algorithmic combinatorics, which can be used in conjunction with model checking, theorem proving, static analysis, and abstract interpretation. The aim of this workshop is to bring together researchers from these diverse fields. Scope - We encourage submissions presenting work in progress, tools under development, as well as work by PhD students, such that the workshop can become a forum for active dialogue between the groups involved in this new research area. Relevant topics include (but are not limited to) the following: * Program analysis and verification * Inductive Assertion Generation * Inductive Proofs for Reasoning about Loops * Applications to Assertion Generation using the following tools: - Abstract Interpretation, - Static Analysis, - Model Checking, - Theorem Proving, - Theory Formation, - Algebraic Techniques * Tools for inductive assertion generation and verification * Alternative techniques for reasoning about loops Invited speaker - * Aditya Nori (Microsoft Research) Committee - Program Chairs: * Gudmund Grov (University of Edinburgh, UK) * Thomas Wies (New York University, USA) Program Committee: * Clark Barrett (New York University, USA) * Nikolaj Bjorner (Microsoft Research, USA) * Gudmund Grov (University of Edinburgh, UK) * Ashutosh Gupta (IST Austria) * Bart Jacobs (Katholieke Universiteit Leuven, Belgium) * Moa Johansson (Chalmers University of Technology, Sweden) * Laura Kovacs (Vienna University of Technology, Austria) * David Monniaux (VERIMAG, France) * Enric Rodriguez Carbonell (Technical University of Catalonia, Spain) * Helmut Veith (Vienna University of Technology, Austria) * Thomas Wies (New York University, USA) Important Dates --- Submission deadline: April 13, 2012 Notification of acceptance: May 11, 2012 Final version due: June 08, 2012 Workshop: June 30, 2012 Submission -- WING 2012 encourages submissions in the following two categories: * Original papers: contain original research (simultaneous submissions are not allowed) and sufficient detail to assess the merits and relevance of the submission. Given the informal style of the workshop, papers describing work in progress, with sufficient detail to assess the contribution, are also welcome. Original papers should not exceed 15 pages. * Extended abstracts: contain preliminary reports of work in progress, case studies, or tool descriptions. These will be judged based on the expected level of interest for the WING community. They will be included in the CEUR-WS proceedings. Extended abstracts should not exceed 5 pages. All submissions should conform to Springer's LNCS format. Formatting style files can be found at http://www.springer.de/comp/lncs/authors.html Technical details may be included in an appendix to be read at the reviewers' discretion and to be omitted in the final version. Please prepare your submission in accordance with the rules described above and submit a pdf file via https://www.easychair.org/?conf=wing2012 Publication --- All submissions will be peer-reviewed by the program committee. Accepted contributions will be published in archived electronic notes, as a volume of CEUR Workshop Proceedings. A special issue of the Journal of Science of Computer
Re: [Haskell-cafe] Generalizing (++) for monoids instead of using ()
See the relevant trac ticket [1] and the linked mailing list thread. Erik [1] http://hackage.haskell.org/trac/ghc/ticket/3339 On Sun, Apr 1, 2012 at 22:58, aditya bhargava bluemangrou...@gmail.com wrote: After asking this question: http://stackoverflow.com/questions/9963050/standard-way-of-joining-two-data-texts-without-mappend I found out that the new infix operator for `mappend` is (). I'm wondering why ghc 7.4 didn't generalize (++) to work on monoids instead. To me, (++) is much more clear. () means not equal to for me. Can anyone shed light on this decision? Adit -- adit.io ___ 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] Generalizing (++) for monoids instead of using ()
Plus one might argue that using to mean different is a bad choice, as it graphically means strictly inferior or strictly superior which implies comparability, whereas equality and comparison are two different things. (e.g. Eq and Ord are two distinct classes in Haskell). Le 1 avril 2012 23:06, Daniel Peebles pumpkin...@gmail.com a écrit : There are many reasons, but some of the more cited ones are that () will break less code than (++) would, since (++) is ubiquitous and () is most used in some pretty printers. Yes, mappend's type can be refined to that of the current list (++), but the increased polymorphism still has the potential to break existing code by making it harder to resolve instances. As for () meaning not equal to, do you also have a problem with Monad's () meaning a right bitwise shift, or the mutationey form of it, (=)? :) I don't think anyone in Haskell has ever used () to mean (/=), so the fact that there exist a couple of languages out there that do use it that way shouldn't affect our decision. Dan On Sun, Apr 1, 2012 at 4:58 PM, aditya bhargava bluemangrou...@gmail.comwrote: After asking this question: http://stackoverflow.com/questions/9963050/standard-way-of-joining-two-data-texts-without-mappend I found out that the new infix operator for `mappend` is (). I'm wondering why ghc 7.4 didn't generalize (++) to work on monoids instead. To me, (++) is much more clear. () means not equal to for me. Can anyone shed light on this decision? Adit -- adit.io ___ 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Towards a single, unified API for incremental data processing
That would be a great idea... too bad it's an April hoax ;) Le 1 avril 2012 21:50, John Millikin jmilli...@gmail.com a écrit : There are currently several APIs for processing strict monoidal values as if they were pieces of a larger, lazy value. Some of the most popular are based on Oleg's left-fold enumerators, including the iteratee, enumerator, iterIO. Other choices include comonads, conduits, and pipes. Despite having various internal implementations and semantics, these libraries generally export a similar-looking API. This is a terrible duplication of effort, and it causes dependant packages to be strongly tied to the underlying implementation. I propose that a new package, tzinorot, be written to provide a single API based on Data.List. It should be pretty easy to use, requiring only a few common extensions to the type system. For example, the enumerator package's 'mapM' function could be generalized for use in tzinorot through a few simple modifications to the type signature: -- -- enumerator mapM mapM :: Monad m = (ao - m ai) - Enumeratee ao ai m b -- tzinorot mapM mapM :: (Monad m, Tzinorot t, ListLike l1 a1, ListLike l2 a2) = (l1 a1 - m (l2 a2)) - t Void s (TzinorotItems (l1 a1)) (TzinorotItems (l2 a2)) m r -- To make it easier to install and use the tzinorot package, it will depend on all of its supported implementations (iteratee, enumerator, conduits, pipes, etc), and use Michael Snoyman's cabala tool to manage dependency versions. See the cabala announcement for details on use: http://www.yesodweb.com/blog/2012/04/replacing-cabal ___ 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] A Modest Records Proposal
Lesson learned: for next year, write a Haskell program that tells if a given -cafe thread or reddit discussion is a April Fool's joke or not. On Sun, Apr 1, 2012 at 7:10 PM, Christopher Done chrisd...@googlemail.comwrote: I actually read the first couple paragraphs and thought “sounds interesting I'll read it later”. After reading it properly, I lol'd. After some initial feedback, I'm going to create a page for the Homotopy Extensional Records Proposal (HERP) on trac. There are really only a few remaining questions. 1) Having introduced homotopies, why not go all the way and introduce dependent records? In fact, are HERP and Dependent Extensional Records Proposal (DERP) already isomorphic? My suspicion is that HERP is isomorphic, but DERP is not. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Alp Mestanogullari ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A Modest Records Proposal
On Mon, Apr 2, 2012 at 3:38 PM, Alp Mestanogullari alpmes...@gmail.com wrote: Lesson learned: for next year, write a Haskell program that tells if a given -cafe thread or reddit discussion is a April Fool's joke or not. import Data.Time main = do now - getCurrentTime let (_, month, day) = toGregorian $ utctDay now putStrLn $ if month == 4 day == 1 then It's a joke else It's real ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A Modest Records Proposal
On 2 April 2012 14:41, Michael Snoyman mich...@snoyman.com wrote: import Data.Time main = do now - getCurrentTime let (_, month, day) = toGregorian $ utctDay now putStrLn $ if month == 4 day == 1 then It's a joke else It's real import Data.Time main = do now - getCurrentTime let (_, month, day) = toGregorian $ utctDay now putStrLn $ if month == 4 day == 1 then It's a joke else It's real. (This output is not a joke. But run this program again to be sure.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Regarding simple xml string parser code review
Hi, I am trying to fetch the values under tags in an xml string given the tag string and xml string. Actually, I don't want to use xml parser since I need to parse very small xml strings. Also, I dont want to use anything else other than haskell platform. I wrote some routines and want to know whether there is any better option available. Please review them and the comments will be highly appreciated. please find routines posted at http://hpaste.org/66357 Thanks in advance. Regards, Rajendra ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] (no subject)
a href=http://dreadscottart.com/mynewwebsite/wp-content/plugins/extended-comment-options/02efpk.html; http://dreadscottart.com/mynewwebsite/wp-content/plugins/extended-comment-options/02efpk.html/a___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] mueval leaving behind tmp files
The following program prints Right (test,Bool,True)
as it should, but it leaves behind in /tmp
two files (name is a long string of digits)
and an empty directory (name is ghcN_N).
... and it deletes the input file (/tmp/Main.hs).
That's not nice. Ideally, I would want to read input
from a String (instead of the file), and not write to disk at all.
But cleaning up properly would be OK as a work-around.
import Language.Haskell.Interpreter
import Mueval.Interpreter
import Mueval.ArgsParse
main = do
writeFile /tmp/Main.hs test = True
result - runInterpreter $ interpreter $ Options
{ timeLimit =1, modules =Just [Prelude], expression =test
, loadFile =/tmp/Main.hs, user=what, printType =True
, extensions =False,namedExtensions = []
, noImports =False, rLimits =False, help=True
}
print result
ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.4.1
ghc-pkg list| egrep 'mueval|hint'
hint-0.3.3.4
mueval-0.8.1.1
uname -a
Linux octopus 3.0.0-16-generic #29-Ubuntu SMP Tue Feb 14 12:48:51 UTC 2012
x86_64 x86_64 x86_64 GNU/Linux
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] mueval leaving behind tmp files
mueval-0.8.1.1 this is actually 0.8.2 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Generalizing (++) for monoids instead of using ()
It is somewhat idiomatic to read it as TeX's \diamond symbol. Various papers set with Lhs2TeX use it for general composition operator (sometimes concat / mappend). On 2 April 2012 10:05, Yves Parès yves.pa...@gmail.com wrote: Plus one might argue that using to mean different is a bad choice, as it graphically means strictly inferior or strictly superior which implies comparability, whereas equality and comparison are two different things. (e.g. Eq and Ord are two distinct classes in Haskell). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is this a correct explanation of FRP?
On Mon, 2012-04-02 at 04:03 +0200, Ertugrul Söylemez wrote: Peter Minten peter.min...@orange.nl wrote: As I see FRP it has three components: the basic concepts, the underlying theory and the way the libraries actually work. As far as I understand FRP (which is not very far at all) the basic concepts can, simplified, be formulated as: * There are things which have a different value depending on when you look at them. (behaviors) That's already specific to traditional FRP. In AFRP the value mutates. It's not a function of some notion of time. It is similar to a list. That list contains the current value as well as a description of the future of the value: newtype SF a b = SF (a - (b, SF a b)) The current value and the future depend on a momentary input value of type 'a' (which usually comes from another SF). I think I understand what you're saying now. Basically instead of behaviors netwire has signal functions which are basically the same idea as simplified conduits/enumeratees. When you step (run) a signal function you get two things: an output value and a replacement for the signal function. Because the signal functions can be replaced a system of signal functions can change between steps. Netwire doesn't actually have a notion of time as such. If you need to know the current time you'll have to supply that yourself. Wires also don't run continuously, only when stepped explicitly. Where in traditional FRP you (in some libraries) could ask for the value of a behavior at any time in netwire you can only get the equivalent value (the output value of a signal function) by stepping. The big difference between netwire and traditional AFRP libraries are ArrowChoice instances which allow if-then-else and case constructions in proc notation. This simplifies programming greatly as it requires less thinking in FRP terms. When you say Event a b = SF a (Maybe b) you're basically saying that for netwire events are the same thing as behaviors: they're both signal functions. Events can be expressed as signal functions that sometimes have a value. If they have a value during a step the event occurs during that step. The whole system is very discrete, time isn't a primitive at all. If time plays a role it's just as an input, it's not built into something. To get something return 1 but from second 10 onward return 2 you pass time as an input and once you see that the time is greater than 10 you can change the signal function to arr (const 2) to fix it to return 2, whatever the new time is. Greetings, Peter Minten ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A Modest Records Proposal
On Mon, Apr 2, 2012 at 5:41 AM, Michael Snoyman mich...@snoyman.com wrote: On Mon, Apr 2, 2012 at 3:38 PM, Alp Mestanogullari alpmes...@gmail.com wrote: Lesson learned: for next year, write a Haskell program that tells if a given -cafe thread or reddit discussion is a April Fool's joke or not. import Data.Time main = do now - getCurrentTime let (_, month, day) = toGregorian $ utctDay now putStrLn $ if month == 4 day == 1 then It's a joke else It's real My strategy next year will be to not read any email on the 1st. I'll just wait until the 2nd to read it all. Foolproof! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A Modest Records Proposal
On Mon, Apr 2, 2012 at 16:30, Evan Laforge qdun...@gmail.com wrote: On Mon, Apr 2, 2012 at 5:41 AM, Michael Snoyman mich...@snoyman.com wrote: On Mon, Apr 2, 2012 at 3:38 PM, Alp Mestanogullari alpmes...@gmail.com wrote: Lesson learned: for next year, write a Haskell program that tells if a given -cafe thread or reddit discussion is a April Fool's joke or not. import Data.Time main = do now - getCurrentTime let (_, month, day) = toGregorian $ utctDay now putStrLn $ if month == 4 day == 1 then It's a joke else It's real My strategy next year will be to not read any email on the 1st. I'll just wait until the 2nd to read it all. Foolproof! Hmm, nope, still failed. I was following along until it got to HERP at which point I scrolled back up to see that it was sent on the 1st and then continued to read and LOL. -R. Kyle Murphy -- Curiosity was framed, Ignorance killed the cat. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
