Re: [Haskell-cafe] question about singletons
Thanks Richard, now I have my answers. Richard Eisenberg wrote: - The type system of Haskell is based on theoretical work that resolutely assumes that types of non-* kind are uninhabited. While it is possible to stretch imagination to allow types like 'Zero to be inhabited, the designers of Haskell would have a lot of work to do to prove that the new language is actually type-safe. [...] Technically, yes, we could have a different definition of undefined, but it would fly in the face of a lot of theory about type-safe programming languages. This is not to say that such a thing is impossible, but just perhaps imprudent. Ok, this is a convincing reason to admit that non-* kinded types must be uninhabited, even by undefined. Bottom is inherently uninteresting, because you never see bottom in running code, and you can never know where bottom is lurking (other than after your program has crashed). [...] So, all of this is to say that undefined is entirely uninteresting, as your program can never know when it encounters one without dying. Ok: Haskell refuses to show undefined for a type of kind * if it has not another inhabitant, because the type is deemed uninteresting. Technically, bottom should have this definition (which is perfectly valid Haskell): bottom :: a bottom = bottom In other words, bottom is infinite recursion -- a term that never finishes evaluating. Let's say a show method tried to print its argument and its argument is bottom. Well, that method would have to examine its argument and would immediately fall into an infinite loop. Bottom is a little like Medusa when you have no mirrors around. Once you look at it, it's too late. In Haskell, we don't usually use bottom in this way; we use undefined. undefined masquerades as bottom, but instead of forcing a running program into an infinite loop, looking at undefined causes a running program to instantly terminate. This is generally much nicer than an infinite loop, but this niceness is simply a convenience that the compiler gives us. From a theoretical point of view, a hung program is much cleaner. To recover the consistency of the theory, Haskell provides no way to recover from a discovery of undefined in a running program. (GHC has implemented an exception that allows exception-handling code, written in the IO monad, to catch a use of undefined, but I would be highly suspicious of code that used this feature.) Interesting, I will remember that. Thanks TP ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Announce: Leksah 0.13.2.2 (still a bit experimental)
Mostly just a refresh of the current development version binary installers, so people can use it with the latest Haskell Platform (which uses GHC 7.6.3). Unfortunately an official 0.14 release may still be a be a way off. I have been doing some work on getting Code Mirror working, but there are threading issues that will need to be resolved before it works (so best to leave the editor config set to GtkSourceView). I recommend you remove your ~/.leksah-0.13/prefs.lkshp file before installing as the format has changed slightly and it is not backwards compatibly. Hop on #leksah if you have any questions. OS X (Still no WebKit features) --- Choose the version that matches your installed GHC http://leksah.org/packages/leksah-0.13.2.2-ghc-7.0.4.dmg http://leksah.org/packages/leksah-0.13.2.2-ghc-7.4.1.dmg http://leksah.org/packages/leksah-0.13.2.2-ghc-7.4.2.dmg http://leksah.org/packages/leksah-0.13.2.2-ghc-7.6.3.dmg Sorry, I am still having trouble building WebKitGTK+ on OSX. If you want a challenge... https://github.com/jralls/gtk-osx-build https://github.com/leksah/leksah/blob/master/osx/gtk.sh Alternatively we might have to build Leksah with -f-webkit to leave out the webkit stuff. Windows --- Choose the version that matches your installed GHC http://leksah.org/packages/leksah-0.13.2.2-ghc-7.0.3.exe http://leksah.org/packages/leksah-0.13.2.2-ghc-7.0.4.exe http://leksah.org/packages/leksah-0.13.2.2-ghc-7.4.1.exe http://leksah.org/packages/leksah-0.13.2.2-ghc-7.4.2.exe http://leksah.org/packages/leksah-0.13.2.2-ghc-7.6.3.exe Linux - Follow the steps in the .travis.yml file... https://github.com/leksah/leksah/blob/master/.travis.yml Should go something like this... https://travis-ci.org/leksah/leksah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Two GHC-related GSoC Proposals
It is not obvious that semantics is preserved for optimisations which remove non-constants like bar a b = a + b - a - b -- the RHS is should be optimized away to 0 Calling bar undefined undefined throws an error, but the optimised bar would return 0. On Sat, Jun 1, 2013 at 8:10 PM, Patrick Palka patr...@parcs.ath.cx wrote: Yeah, I am going to use the MVar approach. Alternative implementations will be investigated if this approach happens to not scale well. On Fri, May 31, 2013 at 9:10 AM, Thomas Schilling nomin...@googlemail.com wrote: [I'll be the mentor for this GSoC project.] I used the MVar approach a while ago and so did Simon Marlow's original solution. Using MVars and Threads for this should scale well enough (1000s of modules) and be relatively straightforward. Error/exception handling could be a bit tricky, but you could use (or copy ideas from) the 'async' package to deal with that. / Thomas On 30 May 2013 18:51, Ryan Newton rrnew...@gmail.com wrote: What's the plan for what control / synchronization structures you'll use in part 2 of the plan to implement a parallel driver? Is the idea just to use an IO thread for each compile and block them on MVars when they encounter dependencies? Or you can use a pool of worker threads and a work queue, and only add modules to the work queue when all their dependencies are met (limits memory use)... many options for executing a task DAG. Fortunately the granularity is coarse. -Ryan On Sun, Apr 21, 2013 at 10:34 PM, Patrick Palka patr...@parcs.ath.cx wrote: Good points. I did not take into account whether proposal #2 may be worth it in light of -fllvm. I suppose that even if the LLVM codegen is able to perform similar optimizations, it would still be beneficial to implement proposal #2 as a core-to-core pass because the transformations it performs would expose new information to subsequent core-to-core passes. Also, Haskell has different overflow rules than C does (whose rules I assume LLVM's optimizations are modeled from): In Haskell, integer overflow is undefined for all integral types, whereas in C it's only undefined for signed integral types. This limits the number of optimizations a C-based optimizer can perform on unsigned arithmetic. I'm not sure how I would break up the parallel compilation proposal into multiple self-contained units of work. I can only think of two units: making GHC thread safe, and writing the new parallel compilation driver. Other incidental units may come up during development (e.g. parallel compilation might exacerbate #4012), but I still feel that three months of full time work is ample time to complete the project, especially with existing familiarity with the code base. Thanks for the feedback. On Sun, Apr 21, 2013 at 5:55 PM, Carter Schonwald carter.schonw...@gmail.com wrote: Hey Patrick, both are excellent ideas for work that would be really valuable for the community! (independent of whether or not they can be made into GSOC sided chunks ) --- I'm actually hoping to invest some time this summer investigating improving the numerics optimization story in ghc. This is in large part because I'm writing LOTs of numeric codes in haskell presently (hopefully on track to make some available to the community ). That said, its not entirely obvious (at least to me) what a tractable focused GSOC sized subset of the numerics optimization improvement would be, and that would have to also be a subset that has real performance impact and doesn't benefit from eg using -fllvm rather than -fasm . - For helping pave the way to better parallel builds, what are some self contained units of work on ghc (or related work on cabal) that might be tractable over a summer? If you can put together a clear roadmap of work chunks that are tractable over the course of the summer, I'd favor choosing that work, especially if you can give a clear outline of the plan per chunk and how to evaluate the success of each unit of work. basically: while both are high value projects, helping improve the parallel build tooling (whether in performance or correctness or both!) has a more obvious scope of community impact, and if you can layout a clear plan of work that GHC folks agree with and seems doable, i'd favor that project :) hope this feedback helps you sort out project ideas cheers -Carter On Sun, Apr 21, 2013 at 12:20 PM, Patrick Palka patr...@parcs.ath.cx wrote: Hi, I'm interested in participating in the GSoC by improving GHC with one of these two features: 1) Implement native support for compiling modules in parallel (see #910). This will involve making the compilation pipeline thread-safe, implementing the logic for building modules in parallel (with an emphasis on keeping compiler output deterministic), and
Re: [Haskell-cafe] Two GHC-related GSoC Proposals
Right, these optimizations are done on the unboxed level, where bottom is not a concern. GHC would transform bar a b = a + b - a - b to bar (I# a) (I# b) = I# (a +# b -# a -# b) whose RHS could be optimized away to I# 0#. bar is still strict in its two arguments, so calling bar undefined undefined would still throw an error. On Sun, Jun 2, 2013 at 7:24 AM, Boris Lykah lyk...@gmail.com wrote: It is not obvious that semantics is preserved for optimisations which remove non-constants like bar a b = a + b - a - b -- the RHS is should be optimized away to 0 Calling bar undefined undefined throws an error, but the optimised bar would return 0. -- Regards, Boris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [haskell.org Google Summer of Code 2013] Approved Projects
Hi Edward, Thanks for this comprehensive answer (and also thanks to participants in the follow-up dissuasion). How is the public good determined? (sounds rather Benthamite). I would have been disappointed if charts using diagrams had not been selected yet I don't recall being canvassed. Sorry to sound picky. I think from what you say that in this particular year it was obvious which projects should be selected; in future it may not be. I think an acceptable reason would be there was only one user who wanted it. Maybe we should use something like: https://www.uservoice.com. Sadly it seems this requires payment but there may be a free equivalent Dominic Steinitz domi...@steinitz.org http://idontgetoutmuch.wordpress.com On 28 May 2013, at 16:11, Edward Kmett ekm...@gmail.com wrote: Hi Dominic, The proposal is admittedly rather unfortunately opaque. The parts I can shed light on: Students come up with proposals with the help of the community and then submit them to google-melange.com. A bunch of folks from the haskell community sign up as potential mentors, vote on and discuss the proposals. (We had ~25 candidate mentors and ~20 proposals this year). The student application template contains a number of desirable criteria for a successful summer of code application, which is shown on the google-melange website under our organization -- an old version is available http://hackage.haskell.org/trac/summer-of-code/wiki/StudApply2012 contains Once we have the proposals in hand, and some initial ranking, we ask google for slots. Allocation is based on past performance, arcane community parameters that only they know, mentor ratio, etc. This should be our largest year in the program, despite the fact that in general organizations have been getting fewer slots as more organizations join, so we're apparently doing rather well. In general we do try to select projects that maximize the public good. Most of the time this can almost be done by just straight cut off based on the average score. There is some special casing for duplicate applications between different students and where students have submitted multiple applications we can have some flexibility in how to apply them. This year we also received an extra couple of special-purpose darcs slots from Google in exchange for continuing to act as an umbrella organization over darcs at the request of the administrator of the program at Google. In previous years I had requested an extra slot for them, this year the request came in the other direction. We do inevitably get more good proposals than we get slots. This year we could have easily used another 3-4 slots to good effect. The main part I can't shed light on: Google requests that the final vote tallies remain private. This is done so that students who put in proposals to a high volume orgs and don't get accepted, or who are new to the process and don't quite catch all the rules, don't wind up with any sort of publicly visible black mark. This unfortunately means, that we can't really show the unaccepted proposals with information about how to avoid getting your proposal rejected. I hope that helps. If you have any more questions or if my answer didn't suffice please feel free to follow up! -Edward Kmett On Tue, May 28, 2013 at 6:52 AM, Dominic Steinitz domi...@steinitz.org wrote: Hi Edward, Although the project I am interested in (as a user) has been accepted :-), I can't help feeling the selection process is a bit opaque. Is it documented somewhere and I just missed it? Apologies if I did. BTW I appreciate all the hard work that goes into the selection process. Dominic Steinitz domi...@steinitz.org http://idontgetoutmuch.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Different answers on different machines
On Sat, Jun 1, 2013 at 7:55 PM, nadine.and.he...@pobox.com wrote: Yesterday I decided to take a look at the most recent Euler problem, number 249, and give it a shot. I have a couple of computers at home, a Dell laptop and a desktop. I compiled this message with ghc -O2 --make ex429.lhs and ran it on each machine. On the Dell I get: Odds are good it's integer overflow. Change Int to Integer or Int64 and retry. G -- Gregory Collins g...@gregorycollins.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Typeable typeclass and type-level naturals
Hi all,
I try to play with the Typeable typeclass, and I have some difficulties to
make it work in this simple case where I use type-level naturals:
-
{-# LANGUAGE GADTs #-}
{-# LANGUAGE DeriveDataTypeable #-}
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE StandaloneDeriving #-}
import Data.Typeable
data Nat = Zero | Succ Nat
deriving ( Show, Eq, Ord, Typeable )
data Box where
Box :: (Typeable s, Show s, Eq s) = s - Box
deriving Typeable
data Proxy a = P deriving Typeable
deriving instance Show Box
instance Eq Box where
(Box s1) == (Box s2) = Just s1 == cast s2
main = do
let one = undefined :: Main.Proxy ('Succ 'Zero)
let foo = Box one
print foo
-
I obtain:
-
No instance for (Typeable Nat 'Zero) arising from a use of ‛Box’
In the expression: Box one
In an equation for ‛foo’: foo = Box one
In the expression:
do { let one = ...;
let foo = Box one;
print foo }
-
Note that it is necessary to use the HEAD version of GHC to obtain this
message (I use version 7.7.20130525); with GHC 7.6.2, the message is
different because recent improvements in Typeable are not present (1).
What is the problem? I've tried different things without success.
Tell me if the beginners diffusion list is more suitable than Haskell-
Cafe.
Thanks,
TP
(1):
http://hauptwerk.blogspot.fr/2012/11/coming-soon-in-ghc-head-poly-kinded.html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [haskell.org Google Summer of Code 2013] Approved Projects
Public good is a nebulous concept, but it is something that each of the folks who sign up as mentors judges independently when they are rating the projects and talking about them. Most of the folks who are offering to mentor have been involved in the community for quite some time and have a pretty good overview of what is going on, and what are currently active pain points. With 25 mentors we get a pretty good cross section of the community. We aren't really able to canvas outside of the mentor group during the approval process by google's guidelines, since we shouldn't leak information about unaccepted projects. Something like that uservoice site might be used to gauge public opinion of general ideas before the proposals start coming in, but in the end students write the proposals we get, so the things we would have polled about are inevitably not quite what we're rating anyways. We rarely get something that is just cut and pasted from the ideas list. Consequently a generic rating that doesn't take into consideration the actual proposal isn't worth a whole lot, beyond giving students an idea of what might be a successful proposal. There is a lot of variability in the ratings for projects based simply on what we know about the student, how clear the proposal is, and how achievable his or her particular goals are. In practice, we've been able to make sure that a couple of slots go to separable tasks in projects like cabal, haddock, and ghc that benefit everyone and that exceptional one-off projects don't get shut out completely just by asking each mentor to rate all of the projects, even the ones they aren't interested in mentoring, and from the discussions between the mentors and between the mentors and students that ensue within melange. My main advice is that if you want to get involved in the process, the easiest way to peel back the curtain is to volunteer to mentor! We're generally quite open to adding new voices to the discussion. -Edward On Sun, Jun 2, 2013 at 10:14 AM, Dominic Steinitz domi...@steinitz.orgwrote: Hi Edward, Thanks for this comprehensive answer (and also thanks to participants in the follow-up dissuasion). How is the public good determined? (sounds rather Benthamite). I would have been disappointed if charts using diagrams had not been selected yet I don't recall being canvassed. Sorry to sound picky. I think from what you say that in this particular year it was obvious which projects should be selected; in future it may not be. I think an acceptable reason would be there was only one user who wanted it. Maybe we should use something like: https://www.uservoice.com. Sadly it seems this requires payment but there may be a free equivalent Dominic Steinitz domi...@steinitz.org http://idontgetoutmuch.wordpress.com On 28 May 2013, at 16:11, Edward Kmett ekm...@gmail.com wrote: Hi Dominic, The proposal is admittedly rather unfortunately opaque. The parts I can shed light on: Students come up with proposals with the help of the community and then submit them to google-melange.com. A bunch of folks from the haskell community sign up as potential mentors, vote on and discuss the proposals. (We had ~25 candidate mentors and ~20 proposals this year). The student application template contains a number of desirable criteria for a successful summer of code application, which is shown on the google-melange website under our organization -- an old version is available http://hackage.haskell.org/trac/summer-of-code/wiki/StudApply2012contains Once we have the proposals in hand, and some initial ranking, we ask google for slots. Allocation is based on past performance, arcane community parameters that only they know, mentor ratio, etc. This should be our largest year in the program, despite the fact that in general organizations have been getting fewer slots as more organizations join, so we're apparently doing rather well. In general we do try to select projects that maximize the public good. Most of the time this can almost be done by just straight cut off based on the average score. There is some special casing for duplicate applications between different students and where students have submitted multiple applications we can have some flexibility in how to apply them. This year we also received an extra couple of special-purpose darcs slots from Google in exchange for continuing to act as an umbrella organization over darcs at the request of the administrator of the program at Google. In previous years I had requested an extra slot for them, this year the request came in the other direction. We do inevitably get more good proposals than we get slots. This year we could have easily used another 3-4 slots to good effect. The main part I can't shed light on: Google requests that the final vote tallies remain private. This is done so that students who put in proposals to a high volume orgs and don't get accepted, or who are
Re: [Haskell-cafe] Different answers on different machines
Gregory Collins greg at gregorycollins.net writes: On Sat, Jun 1, 2013 at 7:55 PM, nadine.and.henry at pobox.com wrote: Yesterday I decided to take a look at the most recent Euler problem, number 249, and give it a shot. I have a couple of computers at home, a Dell laptop and a desktop. I compiled this message with ghc -O2 --make ex429.lhs and ran it on each machine. On the Dell I get: Odds are good it's integer overflow. Change Int to Integer or Int64 and retry.G-- Gregory Collins greg at gregorycollins.net Yes, that was it. The dell was a 32 bit system, and the desktop a 64. I changed everything from Int to Integer, and now both agree. Thanks for the pointer. Best wishes, Henry Laxen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Int is broken [Was: Different answers on different machines]
On Jun 2, 2013, at 12:52 , Henry Laxen nadine.and.he...@pobox.com wrote: Yes, that was it. The dell was a 32 bit system, and the desktop a 64. I changed everything from Int to Integer, and now both agree. Thanks for the pointer. Isn't that just terrible? I hate the fact that Haskell was defined to neither trap the overflow or just treat everything as Integer [like Scheme]. A sacrifice of program safety in the name of efficiency. I disagree with this choice and posit that a clever implementation can minimize the cost of the overflow checking in most relevant cases. I wish this fatal flaw would be reconsidered for the next major revision. Tommy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Int is broken [Was: Different answers on different machines]
On Sun, Jun 2, 2013 at 11:02 PM, Tommy Thorn tt1...@yahoo.com wrote: On Jun 2, 2013, at 12:52 , Henry Laxen nadine.and.he...@pobox.com wrote: Yes, that was it. The dell was a 32 bit system, and the desktop a 64. I changed everything from Int to Integer, and now both agree. Thanks for the pointer. Isn't that just terrible? I hate the fact that Haskell was defined to neither trap the overflow or just treat everything as Integer [like Scheme]. A sacrifice of program safety in the name of efficiency. If you want to use Integer for everything, just do that. -- mithrandi, i Ainil en-Balandor, a faer Ambar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Int is broken [Was: Different answers on different machines]
On Sunday, June 2, 2013 at 5:02 PM, Tommy Thorn wrote:
On Jun 2, 2013, at 12:52 , Henry Laxen nadine.and.he...@pobox.com
(mailto:nadine.and.he...@pobox.com) wrote:
Yes, that was it. The dell was a 32 bit system, and the desktop a 64. I
changed everything from Int to Integer, and now both agree. Thanks for the
pointer.
Isn't that just terrible? I hate the fact that Haskell was defined to neither
trap the overflow
or just treat everything as Integer [like Scheme]. A sacrifice of program
safety in the name
of efficiency.
I disagree with this choice and posit that a clever implementation can
minimize the cost
of the overflow checking in most relevant cases.
I wish this fatal flaw would be reconsidered for the next major revision.
Tommy
In addition to Haskell already having an arbitrary-width integer type called
Integer, consider the case where you have some program that basically boils
down to
f :: Int - Int
f x = {- some super-complicated mathematical expression -}
f can only have bounds checks eliminated if the values of the inputs are known
in advance. How often are you really going to know that? If you do something
like
main = do
x - read $ getLine
print $ f x
then you have to put all the bounds checks in *anyway*.___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Int is broken [Was: Different answers on different machines]
On Jun 2, 2013, at 14:13 , Kata lightqu...@amateurtopologist.com wrote:
In addition to Haskell already having an arbitrary-width integer type called
Integer
But I wasn't asking for arbitrary-width. I was asking for explicit failures
(overflow) rather
than C-like silent corruption.
, consider the case where you have some program that basically boils down to
f :: Int - Int
f x = {- some super-complicated mathematical expression -}
f can only have bounds checks eliminated if the values of the inputs are
known in advance. How often are you really going to know that? If you do
something like
1. I said minimize the cost of the overflow checking, I didn't say anything
about bounds checking elimination.
A conditional branch on the overflow from an add is nearly zero cost as it
predicts perfectly and can be issued
in parallel with all other instructions. Even better, some architectures
(eg. SPARC) have overflow checking
variants with zero overhead.
And yes, for many instances it's trivial to see that overflow can't happen.
2. Even if that wasn't the case, I never want to sacrifice safety for a trivial
perf overhead (for that stuff I use C).
Tommy
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Int is broken [Was: Different answers on different machines]
There was a quite long discussion here: http://conal.net/blog/posts/notions-of-purity-in-haskell On 2 June 2013 22:02, Tommy Thorn tt1...@yahoo.com wrote: ... I wish this fatal flaw would be reconsidered for the next major revision. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Typeable typeclass and type-level naturals
Try adding
deriving instance Typeable 'Zero
deriving instance Typeable a = Typeable ('Succ a)
to your module.
(I haven't tested it — you might need to tweak it a bit.)
Roman
* TP paratribulati...@free.fr [2013-06-02 18:08:02+0200]
Hi all,
I try to play with the Typeable typeclass, and I have some difficulties to
make it work in this simple case where I use type-level naturals:
-
{-# LANGUAGE GADTs #-}
{-# LANGUAGE DeriveDataTypeable #-}
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE StandaloneDeriving #-}
import Data.Typeable
data Nat = Zero | Succ Nat
deriving ( Show, Eq, Ord, Typeable )
data Box where
Box :: (Typeable s, Show s, Eq s) = s - Box
deriving Typeable
data Proxy a = P deriving Typeable
deriving instance Show Box
instance Eq Box where
(Box s1) == (Box s2) = Just s1 == cast s2
main = do
let one = undefined :: Main.Proxy ('Succ 'Zero)
let foo = Box one
print foo
-
I obtain:
-
No instance for (Typeable Nat 'Zero) arising from a use of ‛Box’
In the expression: Box one
In an equation for ‛foo’: foo = Box one
In the expression:
do { let one = ...;
let foo = Box one;
print foo }
-
Note that it is necessary to use the HEAD version of GHC to obtain this
message (I use version 7.7.20130525); with GHC 7.6.2, the message is
different because recent improvements in Typeable are not present (1).
What is the problem? I've tried different things without success.
Tell me if the beginners diffusion list is more suitable than Haskell-
Cafe.
Thanks,
TP
(1):
http://hauptwerk.blogspot.fr/2012/11/coming-soon-in-ghc-head-poly-kinded.html
___
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] Int is broken [Was: Different answers on different machines]
There is a package that implements an Int that throws an exception on overflow: http://hackage.haskell.org/package/safeint Since Int's existence is pretty much all about trading for performance, I wouldn't recommend holding your breath on the above becoming the default. If you want things to work like Scheme, that's exactly what Integer is (in GHC, anyhow). And Integer is what you get by default(ing) unless you use something else that is specifically defined to use Int, or specify it yourself. On Sun, Jun 2, 2013 at 5:02 PM, Tommy Thorn tt1...@yahoo.com wrote: On Jun 2, 2013, at 12:52 , Henry Laxen nadine.and.he...@pobox.com wrote: Yes, that was it. The dell was a 32 bit system, and the desktop a 64. I changed everything from Int to Integer, and now both agree. Thanks for the pointer. Isn't that just terrible? I hate the fact that Haskell was defined to neither trap the overflow or just treat everything as Integer [like Scheme]. A sacrifice of program safety in the name of efficiency. I disagree with this choice and posit that a clever implementation can minimize the cost of the overflow checking in most relevant cases. I wish this fatal flaw would be reconsidered for the next major revision. Tommy ___ 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] How to write a pure String to String function in Haskell FFI to C++
Hi, I want to implement a function in C++ via Haskell FFI, which should have the (final) type of String - String. Say, is it possible to re-implement the following function in C++ with the exact same signature? import Data.Char toUppers:: String - String toUppers s = map toUpper senter code here In particular, I wanted to avoid having an IO in the return type because introducing the impurity (by that I mean the IO monad) for this simple task is logically unnecessary. All examples involing a C string I have seen so far involve returning an IO something or Ptr which cannot be converted back to a pure String. The reason I want to do this is that I have the impression that marshaling is not easy with FFI. Maybe if I can fix the simplest case above (other than primitive types such as int), then I can do whatever data parsing I want on the C++ side, which should be easy, practically. The cost of parsing is negligible compared to the computation that I want to do between the marshalling to/from strings. Thanks in advance. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] APLAS 2013 second call for papers
===
APLAS 2013
11th Asian Symposium on Programming Languages and Systems
9-11 December 2013
Melbourne, Australia (colocated with CPP 2013)
CALL FOR PAPERS
===
==
BACKGROUND
==
APLAS aims to stimulate programming language research by providing a
forum for the presentation of latest results and the exchange of ideas
in programming languages and systems. APLAS is based in Asia, but is
an international forum that serves the worldwide programming language
community.
APLAS is sponsored by the Asian Association for Foundation of Software
(AAFS) founded by Asian researchers in cooperation with many researchers
from Europe and the USA. Past APLAS symposiums were successfully held
in Kyoto ('12), Kenting ('11), Shanghai ('10), Seoul ('09), Bangalore
('08), Singapore ('07), Sydney ('06), Tsukuba ('05), Taipei ('04) and
Beijing ('03) after three informal workshops. Proceedings of the past
symposiums were published in Springer's LNCS.
==
TOPICS
==
The symposium is devoted to foundational and practical issues in
programming languages and systems. Papers are solicited on topics such
as
* semantics, logics, foundational theory;
* design of languages, type systems and foundational calculi;
* domain-specific languages;
* compilers, interpreters, abstract machines;
* program derivation, synthesis and transformation;
* program analysis, verification, model-checking;
* logic, constraint, probabilistic and quantum programming;
* software security;
* concurrency and parallelism;
* tools and environments for programming and implementation.
Topics are not limited to those discussed in previous symposiums.
Papers identifying future directions of programming and those
addressing the rapid changes of the underlying computing platforms
are especially welcome. Demonstration of systems and tools in the
scope of APLAS are welcome to the System and Tool presentations
category. Authors concerned about the appropriateness of a topic
are welcome to consult with program chair prior to submission.
==
SUBMISSION
==
We solicit submissions in two categories:
*Regular research papers* describing original scientific research
results, including tool development and case studies. Regular
research papers should not exceed 16 pages in the Springer LNCS
format, including bibliography and figures. They should clearly
identify what has been accomplished and why it is significant.
Submissions will be judged on the basis of significance, relevance,
correctness, originality, and clarity. In case of lack of space,
proofs, experimental results, or any information supporting the
technical results of the paper could be provided as an appendix or a
link to a web page, but reviewers are not obliged to read them.
*System and Tool presentations* describing systems or tools that support
theory, program construction, reasoning, or program execution in the
scope of APLAS. System and Tool presentations are expected to be
centered around a demonstration. The paper and the demonstration
should identify the novelties of the tools and use motivating
examples. System and Tool papers should not exceed 8 pages in the
Springer LNCS format, including bibliography and figures. Submissions
will be judged based on both the papers and the described systems or
tools. It is highly desirable that the tools are available on the
web.
Papers should be submitted electronically via the submission web page:
https://www.easychair.org/conferences/?conf=aplas2013
Acceptable formats are PostScript or PDF. Submitted papers must be
unpublished and not submitted for publication elsewhere. Papers must
be written in English. The proceedings will be published as a volume
in Springer's LNCS series. Accepted papers must be presented at the
conference. (While the general chair and the program chair cannot
submit papers, other members of the program committee can.)
=
DATES
=
Abstract due:10 June 2013 (Monday), 23:59 UTC
Submission due: 14 June 2013 (Friday), 23:59 UTC
Notification:26 August 2013 (Monday)
Final paper due: 19 September 2013 (Thursday)
Conference: 9-11 December 2013 (Monday-Wednesday)
==
ORGANIZERS
==
General chair:
Peter Schachte (University of Melbourne)
Program chair:
Chung-chieh Shan (Indiana University)
Program committee:
Filippo Bonchi (CNRS, ENS-Lyon, France)
Yu-Fang Chen (Academia Sinica, Taiwan)
Shigeru Chiba (The University of Tokyo, Japan)
Jacques Garrigue (Nagoya University, Japan)
Robert Glück (University of Copenhagen, Denmark)
R. Govindarajan (Indian Institute of Science, India)
Kazuhiro Inaba (Google, Inc., Japan)
Jie-Hong Roland Jiang (National Taiwan University, Taiwan)
Shin-ya Katsumata (Kyoto University, Japan)
Gabriele Keller
Re: [Haskell-cafe] How to write a pure String to String function in Haskell FFI to C++
On Sun, Jun 2, 2013 at 7:22 PM, Ting Lei tin...@gmail.com wrote: In particular, I wanted to avoid having an IO in the return type because introducing the impurity (by that I mean the IO monad) for this simple task is logically unnecessary. All examples involing Anything that comes into or goes out of a Haskell program is in IO, period. If you have an FFI function which is guaranteed to not change anything but its parameters and those only in a pure way, then you can use unsafeLocalState to hide the IO; but claiming that when it's not true can lead to problems ranging from incorrect results to core dumps, so don't try to lie about it. a C string I have seen so far involve returning an IO something or Ptr which cannot be converted back to a pure String. Haskell String-s are *not* C strings. Not even slightly. C cannot work with Haskell's String type directly at all. Some kind of marshaling is absolutely necessary; there are functions in Foreign.Marshal.String that will marshal Haskell String-s to and from C strings. (String is a linked list of Char, which is also not a C char; it is a constructor and a machine word large enough to hold a Unicode codepoint. And because Haskell is non-strict, any part of that linked list can be an unevaluated thunk which requires forcing the evaluation of arbitrary Haskell code elsewhere to reify the value; this obviously cannot be done in the middle of random C code, so it must be done during marshaling.) -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to write a pure String to String function in Haskell FFI to C++
On 2 Jun 2013, at 16:48, Brandon Allbery allber...@gmail.com wrote: On Sun, Jun 2, 2013 at 7:22 PM, Ting Lei tin...@gmail.com wrote: In particular, I wanted to avoid having an IO in the return type because introducing the impurity (by that I mean the IO monad) for this simple task is logically unnecessary. All examples involing Anything that comes into or goes out of a Haskell program is in IO, period. If you have an FFI function which is guaranteed to not change anything but its parameters and those only in a pure way, then you can use unsafeLocalState to hide the IO; but claiming that when it's not true can lead to problems ranging from incorrect results to core dumps, so don't try to lie about it. a C string I have seen so far involve returning an IO something or Ptr which cannot be converted back to a pure String. Haskell String-s are *not* C strings. Not even slightly. C cannot work with Haskell's String type directly at all. Some kind of marshaling is absolutely necessary; there are functions in Foreign.Marshal.String that will marshal Haskell String-s to and from C strings. (String is a linked list of Char, which is also not a C char; it is a constructor and a machine word large enough to hold a Unicode codepoint. And because Haskell is non-strict, any part of that linked list can be an unevaluated thunk which requires forcing the evaluation of arbitrary Haskell code elsewhere to reify the value; this obviously cannot be done in the middle of random C code, so it must be done during marshalling.) I'm not convinced that that's obvious – though it certainly requires functions (that go through the FFI) to grab each character at a time. Thanks Tom Davie ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to write a pure String to String function in Haskell FFI to C++
On Sun, Jun 2, 2013 at 8:01 PM, Thomas Davie tom.da...@gmail.com wrote: On 2 Jun 2013, at 16:48, Brandon Allbery allber...@gmail.com wrote: (String is a linked list of Char, which is also not a C char; it is a constructor and a machine word large enough to hold a Unicode codepoint. And because Haskell is non-strict, any part of that linked list can be an unevaluated thunk which requires forcing the evaluation of arbitrary Haskell code elsewhere to reify the value; this obviously cannot be done in the middle of random C code, so it must be done during marshalling.) I'm not convinced that that's obvious – though it certainly requires functions (that go through the FFI) to grab each character at a time. I think you underestimate the complexity of the Haskell runtime and the interactions between it and the FFI. Admittedly it is probably not obvious in the sense of anyone can tell without knowing anything about it that it can't possibly work, but it should be at least somewhat obvious to someone who sees why there needs to be an FFI in the first place that the situation is not trivial, and that they probably should not blindly assume that the only reason one can't just pass Haskell values directly to C is that some GHC developer was feeling lazy at the time. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to write a pure String to String function in Haskell FFI to C++
Thanks for your answers so far. It seems that the laziness of String or [char] is the problem. My question boils then down to this. There are plenty of Haskell FFI examples where simple things like sin/cos in math.h can be imported into Haskell as pure functions. Is there a way to extend that to String without introducing an IO (), but maybe sacrificing laziness? If String has to be lazy, is there another Haskell data type convertible to String that can do the job? The C++/C function (e.g. toUppers) is computation-only and as pure as cos and tan. The fact that marshaling string incurs an IO monad in current examples is kind of unintuitive and like a bug in design. I don't mind making redundant copies under the hood from one type to another.. On Sun, Jun 2, 2013 at 8:08 PM, Brandon Allbery allber...@gmail.com wrote: On Sun, Jun 2, 2013 at 8:01 PM, Thomas Davie tom.da...@gmail.com wrote: On 2 Jun 2013, at 16:48, Brandon Allbery allber...@gmail.com wrote: (String is a linked list of Char, which is also not a C char; it is a constructor and a machine word large enough to hold a Unicode codepoint. And because Haskell is non-strict, any part of that linked list can be an unevaluated thunk which requires forcing the evaluation of arbitrary Haskell code elsewhere to reify the value; this obviously cannot be done in the middle of random C code, so it must be done during marshalling.) I'm not convinced that that's obvious – though it certainly requires functions (that go through the FFI) to grab each character at a time. I think you underestimate the complexity of the Haskell runtime and the interactions between it and the FFI. Admittedly it is probably not obvious in the sense of anyone can tell without knowing anything about it that it can't possibly work, but it should be at least somewhat obvious to someone who sees why there needs to be an FFI in the first place that the situation is not trivial, and that they probably should not blindly assume that the only reason one can't just pass Haskell values directly to C is that some GHC developer was feeling lazy at the time. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to write a pure String to String function in Haskell FFI to C++
The C++/C function (e.g. toUppers) is computation-only and as pure as cos and tan. The fact that marshaling string incurs an IO monad in current examples is kind of unintuitive and like a bug in design. I don't mind making redundant copies under the hood from one type to another.. If you can guarantee that the call is pure, then you can execute it directly using `unsafePerformIO`. Simply call the external function as usual, then invoke `unsafePerformIO` on the result. See http://hackage.haskell.org/packages/archive/base/4.6.0.1/doc/html/System-IO-Unsafe.html. On another note, if you really care about performance, you should use the `bytestring` and `text` packages instead of String. They are implemented in terms of byte arrays, instead of linked lists, hence are both faster and more FFI-friendly. On Sun, Jun 2, 2013 at 8:08 PM, Brandon Allbery allber...@gmail.com wrote: On Sun, Jun 2, 2013 at 8:01 PM, Thomas Davie tom.da...@gmail.com wrote: On 2 Jun 2013, at 16:48, Brandon Allbery allber...@gmail.com wrote: (String is a linked list of Char, which is also not a C char; it is a constructor and a machine word large enough to hold a Unicode codepoint. And because Haskell is non-strict, any part of that linked list can be an unevaluated thunk which requires forcing the evaluation of arbitrary Haskell code elsewhere to reify the value; this obviously cannot be done in the middle of random C code, so it must be done during marshalling.) I'm not convinced that that's obvious – though it certainly requires functions (that go through the FFI) to grab each character at a time. I think you underestimate the complexity of the Haskell runtime and the interactions between it and the FFI. Admittedly it is probably not obvious in the sense of anyone can tell without knowing anything about it that it can't possibly work, but it should be at least somewhat obvious to someone who sees why there needs to be an FFI in the first place that the situation is not trivial, and that they probably should not blindly assume that the only reason one can't just pass Haskell values directly to C is that some GHC developer was feeling lazy at the time. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Chris Wong, fixpoint conjurer e: lambda.fa...@gmail.com w: http://lfairy.github.io/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
