Re: [Haskell-cafe] Haskell and the Software design process
> "aditya" == aditya siram writes: aditya> This is awesome! GHC-devs , please mainline the CONTRACT aditya> pragma. I think it needs a LOT more work before it is usable. (I hope I'm wrong, but Dana reckoned it needed about 7 more man-years of work.) Dana sent me a copy of her ghc 6.8 repository (which didn't compile), and I updated (by hand) a 6.11 repository. I was able to get a few test programs to be rejected as not fulfilling their contracts (due to type classes), and a few others to loop at compile time, but I couldn't find any that passed. I was supposed to have a go at debugging the loops, but never got round to it. -- Colin Adams Preston Lancashire () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANNOUNCE: happstack 0.5.0
Hey Jeremy, I see below that you included the experimental WAI support. I'm excited to try it out, but I don't see it in happstack-server (maybe I'm blind). Could you point it out? Thanks, Michael On Mon, May 3, 2010 at 8:57 PM, Jeremy Shaw wrote: > (Note: Reply-to is set to haskell-cafe@haskell.org) > > Hello, > > I am very pleased to announce Happstack 0.5.0. It should install cleanly > from hackage via: > > cabal install happstack > > If it does not, please report errors to the happstack mailing list: > > http://groups.google.com/group/HAppS > > (You will, unfortunately, need to be subscribed due to SPAM issues). > > Here are the official release notes: > > Release Notes: > > This release should fix many (hopefully all) known cabal install > related issues. It also includes many other improvements detailed > below. > > Known issues: > > * dropped support for GHC 6.8. GHC 6.10 and 6.12 currently supported. > > * happstack-data compiled with -O0 due to bug in cabal > http://thread.gmane.org/gmane.comp.lang.haskell.cafe/69215 > > You may be able to change that to -O2 if you first do: > >cabal install --reinstall syb-with-class --disable-documentation > > But we need a solution that works automatically when people run, cabal > install happstack. > > Changes since 0.4.1: > > * many IxSet improvements by Gracjan Polak > > - hide IxSet constructor. use ixSet instead. > - improved efficiency of gteTLE, getGTE, and getRange > - get rid of Dynamic, just use Data.Typeable (internal change) > - added deleteIx > - Eq and Ord instances for IxSet > - removed a bunch of cruft > - greatly improved documentation > - added stats function > - Protect user from using unindexed keys in searches in IxSet > - Runtime safeguard for badly formed inferIxSet indexes > - Fixed IxSet Default instance > - More detailed error messages in IxSet > > * work around bug in bytestring which causes the server to hang > (http://hackage.haskell.org/trac/ghc/ticket/3808) > > * support for uincode Text and lazy Text types > > - Serialize/Version instances now provided automatically by > happstack-data > - instances of EmbedAsChild and EmbedAsAttr for Text for Identity, > IdentityT, ServerPartT, and WebT. > - patches sent upstream to HSP, waiting on acceptance > > * Added Serialize/Version instances for time / Data.Time library > > * Improvements to GuestBook demo by Gracjan Polak > - better handling of Ctrl-C > - simplified .cabal to only build executable > > * Improvements to GuestBook demo by Gracjan Polak > - nice command line interface with help message and version information > - restructured parsing of command line to make it scale better with > further parameters > - added reference to Paths_guestbook module to enable incorporating > version > and path information generated by cabal. > - added withLogger transformer guaranteeing clean setup and > teardown of loggers > - Added clean shutdown to logging component. > > * fail instance for WebT now includes location of pattern match failure. > e.g. > > src\AppControl.hs:43:24: Pattern match failure in do expression > > * added expireCookie function > > * Improvements to documentation > * Additional test cases > * Fixes many build failures > > * Experimental: Added proof of concept port of happstack-server to WAI. > http://www.haskell.org/pipermail/haskell-cafe/2010-March/074142.html > > * added 'dirs' guard. (Similar to dir, but for a list of path > components). > > * set SO_KEEPALIVE so that dropped connections will eventually time out > > * happstack-util only depends on QuickCheck when compiled with > -ftests. This is wrong but solves a lot of annoy install failures. > > * file serve functions now use MonadPlus instead of setting explicit 404 > > * XMLMetaData for webHSP > > * Allow colons in cookie names > > Contributors: > > A big thanks to everyone who contributed patches for this release, > including: > > Gracjan Polak (25 patches in this release!) > Simon Meier > Paulo Tanimoto > Joachim Fasting > Antoine Latter > Simon Michael > Adam Vogt > Joe Edmonds > Andrea Vezzosi > Nils Schweinsberg > > -- > You received this message because you are subscribed to the Google Groups > "HAppS" group. > To post to this group, send email to ha...@googlegroups.com. > To unsubscribe from this group, send email to > happs+unsubscr...@googlegroups.com . > For more options, visit this group at > http://groups.google.com/group/happs?hl=en. > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Learning about Programming Languages (specifically Haskell)
Thanks Roel and Kyle for your contributions!
On 4/05/2010, at 10:35 PM, Roel van Dijk wrote:
> Here is my attempt. I tried to avoid higher concepts like folds and
> things like the ($) operator. Most recursions are written explicitly.
>
> { BEGIN CODE }
>
> module Main where
>
> -- Data type representing a door which is either Open or Closed.
> data Door = Open | Closed deriving Show
>
> toggle :: Door -> Door
> toggle Open = Closed
> toggle Closed = Open
>
> -- Applies the function f to every n'th element of a list.
> skipMap :: (a -> a) -> Int -> [a] -> [a]
> skipMap f n | n < 1 = error "skipMap: step < 1"
>| otherwise = go (n - 1)
> where
>-- Apply the function 'f' to an element of the list when the
>-- counter reaches 0, otherwise leave the element untouched.
>go _ [] = []
>go 0 (x:xs) = f x : go (n - 1) xs
>go c (x:xs) = x : go (c - 1) xs
>
> -- Calculate the final answer.
> run :: Int -> [Door]
> run n = go 1 initialDoors -- Start by toggling every door.
> where
>-- Initial list of closed doors
>initialDoors :: [Door]
>initialDoors = replicate n Closed
>
>-- Toggle every c doors, then proceed by toggling every c+1 doors
>-- of the result, etcetera... Stops after toggling the n'th door.
>go :: Int -> [Door] -> [Door]
>go c doors
>| c > n = doors
>| otherwise = go (c + 1) (skipMap toggle c doors)
>
> -- Print information about a single door.
> printDoor :: (Int, Door) -> IO ()
> printDoor (n, door) = putStrLn ("Door #" ++ show n ++ " is " ++ show door)
>
> printRun :: Int -> IO ()
> printRun n = mapM_ printDoor (zip [1..n] (run n))
>
> -- The program entry point.
> main :: IO ()
> main = printRun 100
>
> { END CODE }
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why cabal forces reinstallation of happstack-utils?
On 5 May 2010 12:04, Maciej Piechotka wrote: > 1. I downloaded happstack-utile[1] > 2. Edited cabal file > 3. Installed it successfully linking with parsec 3.1 > 4. I tried to run cabal install happstack --constraint 'parsec >= 3' > 5. It complains that happstack-utile needs to be installed against > parsec 2 > [1] Now it is HStringTemplate but problem is the same Did you try editing the HStringTemplate cabal file to remove its constraint against parsec >= 3? Also, is there any reason why you're forcing that constraint through (yes, upstream should start using parec-3, but why use --constraint to try and force it yourself)? > If I just run: > % runhaskell Setup.hs configure --user > All seems to be ok but > % cabal install > Wants to reinstall packages (or complains about constraints). Note that with its dependency resolution stuff, cabal-install tries to ensure you have an entire working and consistent set of dependencies, whereas doing it manually will happily break everything. > It is not a missing dependency. It is that the cabal-install tries to > use dependencies from hackage instead of installed packages. Not quite: if its already installed and working, cabal-install will use it; if there is some inconsistency (e.g. package Foo was built against Bar-x but you now have Bar-y installed) then cabal-install will try rebuilding that package; note that if you installed it from a local edited repository then cabal-install doesn't know this and will get the official hackage version. Also, I note that you seem to use the Gentoo Haskell overlay (as you've made bug reports about it) but you're also building packages by hand; this can also lead to problems (don't mix your packages kids!). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why cabal forces reinstallation of happstack-utils?
On Wed, 2010-05-05 at 02:17 +0200, Daniel Fischer wrote: > On Wednesday 05 May 2010 01:45:29, Maciej Piechotka wrote: > > > > I updated local copy, as shown, but cabal wants to rebuild it anyway. My > > question was rather why the repo is considered at all when the package > > is installed. > > > > Regards > > Okay, I didn't quite understand your question, sorry. > So, what's the situation? > You unpacked happstack-util, edited the cabal file to allow parsec-3.1, > cd'ed to the unpacked directory and ran cabal install there, so you had > happstack-util installed. > Then you ran cabal install --dry-run and it said > Resolving dependencies... > cabal: cannot configure happstack-util-0.5.0. > > Is that correct? > No. 1. I downloaded happstack-utile[1] 2. Edited cabal file 3. Installed it successfully linking with parsec 3.1 4. I tried to run cabal install happstack --constraint 'parsec >= 3' 5. It complains that happstack-utile needs to be installed against parsec 2 If I just run: % runhaskell Setup.hs configure --user All seems to be ok but % cabal install Wants to reinstall packages (or complains about constraints). > I don't know why cabal does that. > As a guess: it looks at the .cabal file in the package index to find out > what's needed, compares with the output of ghc-pkg list, finds a missing > dependency (parsec-2.*) and decides to reinstall. It is not a missing dependency. It is that the cabal-install tries to use dependencies from hackage instead of installed packages. Regards [1] Now it is HStringTemplate but problem is the same signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANNOUNCE: happstack-hamlet: compile-time HTML templates for the Haskell application server stack
Very cool Jeremy, great work! Please everyone, give me any feedback you have, *especially* the negative kind. Michael On Wed, May 5, 2010 at 12:46 AM, Jeremy Shaw wrote: > Hello, > > I am pleased to announce the availability of happstack-hamlet: > > http://hackage.haskell.org/package/happstack-hamlet > > > http://patch-tag.com/r/mae/happstack/snapshot/current/content/pretty/happstack-hamlet > > Happstack is a web application development framework. > Hamlet provides HTML templates which are checked for correctness at compile > time. > This package add support for using Hamlet templates with Happstack. > > A simple demo is available here: > > http://patch-tag.com/r/mae/happstack/snapshot/current/content/pretty/happstack-hamlet/demo.hs > > Please report any issues with the happstack-hamlet package itself to the > happs mailing list (You will need to be subscribed): > http://groups.google.com/group/happs > > Big thanks to Michael Snoyman for writing Hamlet! > > Hamlet homepage: http://docs.yesodweb.com/hamlet/ > Happstack homepage: http://www.happstack.com/ > > happy hacking! > - jeremy > > p.s. Reply-to is set to haskell-cafe > > -- > You received this message because you are subscribed to the Google Groups > "HAppS" group. > To post to this group, send email to ha...@googlegroups.com. > To unsubscribe from this group, send email to > happs+unsubscr...@googlegroups.com . > For more options, visit this group at > http://groups.google.com/group/happs?hl=en. > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: Error instaling Happstack on Windows - cabal bug?
On 5 May 2010 08:29, Flavio Botelho wrote: > A Windows prompt shows problems (Application not properly initialized) > with a "perl.exe" program. > Does cabal use perl (that's completely unexpected for me)? GHC does if you use -fvia-C (which is not the default even on Windows AFAIK). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why cabal forces reinstallation of happstack-utils?
On Wednesday 05 May 2010 01:45:29, Maciej Piechotka wrote: > > I updated local copy, as shown, but cabal wants to rebuild it anyway. My > question was rather why the repo is considered at all when the package > is installed. > > Regards Okay, I didn't quite understand your question, sorry. So, what's the situation? You unpacked happstack-util, edited the cabal file to allow parsec-3.1, cd'ed to the unpacked directory and ran cabal install there, so you had happstack-util installed. Then you ran cabal install --dry-run and it said Resolving dependencies... cabal: cannot configure happstack-util-0.5.0. Is that correct? I don't know why cabal does that. As a guess: it looks at the .cabal file in the package index to find out what's needed, compares with the output of ghc-pkg list, finds a missing dependency (parsec-2.*) and decides to reinstall. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Installing ghc in an OpenSolaris Zone
On Tue, May 04, 2010 at 01:36:27PM +0200, Günther Schmidt wrote: > Hello Lars, > > did you happen to manage ghc-6.10.4 in a zone? > > I suspect there are some packages I failed to install into the zone, but > I'm not certain. No, I've never used zones, I just read up about them in the past. -- Lars Viklund | z...@acc.umu.se ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why cabal forces reinstallation of happstack-utils?
On Wed, 2010-05-05 at 01:09 +0200, Daniel Fischer wrote: > On Mittwoch 05 Mai 2010 00:55:38, Maciej Piechotka wrote: > > I try to configure happstack with parsec 3.1. It seems to fail due to > > cabal: > > > > happstack-util.cabal says parsec < 3, so --constraint="parsec > 3" and the > given dependencies are incompatible, hence it can't be configured. > > Probably parsec < 3 was specified because parsec-3.0 was significantly > slower than parsec-2.*. I updated local copy, as shown, but cabal wants to rebuild it anyway. My question was rather why the repo is considered at all when the package is installed. Regards signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why cabal forces reinstallation of happstack-utils?
Hello, Seems that happstack-util had an artificially low upper bounds. I just uploaded happstack-util 0.5.0.1 which bumps it to parsec < 4. Make sure that your version of the 'network' library is compiled against parsec 3, since happstack-server depends on both network and parsec. Thanks for your report! - jeremy On May 4, 2010, at 5:55 PM, Maciej Piechotka wrote: I try to configure happstack with parsec 3.1. It seems to fail due to cabal: I installed happstack-util editing happstack-util.cabal by hand: % grep parsec ~/.ghc/x86_64-linux-6.12.2/package.conf.d/happstack- util-0.5.0-6e27d5d3ba1c07f259d463ee3036c92b.conf parsec-3.1.0-5842597f447f82b210228391f371cff1 % cabal install --constraint 'parsec > 3' --dry-run happstack Resolving dependencies... cabal: cannot configure happstack-util-0.5.0. It requires parsec <3 For the dependency on parsec <3 there are these packages: parsec-2.0, parsec-2.1.0.0 and parsec-2.1.0.1. However none of them are available. parsec-2.0 was excluded because of the top level dependency parsec >3 parsec-2.1.0.0 was excluded because of the top level dependency parsec 3 parsec-2.1.0.1 was excluded because of the top level dependency parsec 3 % ghc-pkg list | grep happstack-util happstack-util-0.5.0 Regards ___ 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] Why cabal forces reinstallation of happstack-utils?
On Mittwoch 05 Mai 2010 00:55:38, Maciej Piechotka wrote: > I try to configure happstack with parsec 3.1. It seems to fail due to > cabal: > happstack-util.cabal says parsec < 3, so --constraint="parsec > 3" and the given dependencies are incompatible, hence it can't be configured. Probably parsec < 3 was specified because parsec-3.0 was significantly slower than parsec-2.*. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Why cabal forces reinstallation of happstack-utils?
I try to configure happstack with parsec 3.1. It seems to fail due to cabal: I installed happstack-util editing happstack-util.cabal by hand: % grep parsec ~/.ghc/x86_64-linux-6.12.2/package.conf.d/happstack-util-0.5.0-6e27d5d3ba1c07f259d463ee3036c92b.conf parsec-3.1.0-5842597f447f82b210228391f371cff1 % cabal install --constraint 'parsec > 3' --dry-run happstack Resolving dependencies... cabal: cannot configure happstack-util-0.5.0. It requires parsec <3 For the dependency on parsec <3 there are these packages: parsec-2.0, parsec-2.1.0.0 and parsec-2.1.0.1. However none of them are available. parsec-2.0 was excluded because of the top level dependency parsec >3 parsec-2.1.0.0 was excluded because of the top level dependency parsec >3 parsec-2.1.0.1 was excluded because of the top level dependency parsec >3 % ghc-pkg list | grep happstack-util happstack-util-0.5.0 Regards signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Fwd: Error instaling Happstack on Windows - cabal bug?
Trying to install on Windows, i am having a strange problem (may actually be some cabal bug?), More specifically trying to install happstack-util [13 of 19] Compiling Happstack.Crypto.MD5 ( src\Happstack\Crypto\MD5.hs, dist\bu ild\Happstack\Crypto\MD5.o ) cabal: Error: some packages failed to install: happstack-util-0.5.0 failed during the building phase. The exception was: ExitFailure (-1073741819) A Windows prompt shows problems (Application not properly initialized) with a "perl.exe" program. Does cabal use perl (that's completely unexpected for me)? I did install perl and put it on the path and that didn't solve it (maybe there is a configuration parameter to point to perl's executable?) Thanks, Flavio ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: happstack-hamlet: compile-time HTML templates for the Haskell application server stack
Hello, I am pleased to announce the availability of happstack-hamlet: http://hackage.haskell.org/package/happstack-hamlet http://patch-tag.com/r/mae/happstack/snapshot/current/content/pretty/happstack-hamlet Happstack is a web application development framework. Hamlet provides HTML templates which are checked for correctness at compile time. This package add support for using Hamlet templates with Happstack. A simple demo is available here: http://patch-tag.com/r/mae/happstack/snapshot/current/content/pretty/happstack-hamlet/demo.hs Please report any issues with the happstack-hamlet package itself to the happs mailing list (You will need to be subscribed): http://groups.google.com/group/happs Big thanks to Michael Snoyman for writing Hamlet! Hamlet homepage: http://docs.yesodweb.com/hamlet/ Happstack homepage: http://www.happstack.com/ happy hacking! - jeremy p.s. Reply-to is set to haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Is anyone using Haddock's support for frames?
On Tue, May 4, 2010 at 1:23 PM, David Waern wrote: > 2010/5/4 Sean Leather : >> Somewhat OT, but is there a place where we can request/review features in >> the new HTML presentation of Haddock. Are there any mockups of what the >> pages might look like? I've had some ideas pop around my head every time I >> look at documentation. ;) > > http://trac.haskell.org/haddock/ticket/108 > > Or feel free to open a discussion on hadd...@projects.haskell.org. I haven't been able to find information on this list anywhere. http://www.haskell.org/haddock/ doesn't mention it, and neither does the haddock wiki nor http://haskell.org/haskellwiki/Mailing_lists. Am I missing something obvious? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell and the Software design process
This is awesome! GHC-devs , please mainline the CONTRACT pragma.
-deech
On 5/4/10, Edward Kmett wrote:
> The papers are available here: http://gallium.inria.fr/~naxu/pub.html
>
> But in general you can say things like the following:
>
> (Dana Xu uses a slightly different notation that I can never remember).
>
> sorted :: Ord a => [a] -> Bool
>> sorted [] = True
>> sorted [x] = True
>> sorted (x:xs) = x < head xs && sorted xs
>>
>> sort :: Ord a => [a] -> { xs : [a] | sorted xs }
>> sort [] = []
>> sort (x:xs) = insert x (sort xs)
>>
>> insert :: Ord a => a -> { xs : [a] | sorted xs } -> { ys : [a] | sorted xs
>> }
>> -- insert :: Ord a => a -> { xs : [a] } -> { ys : [a] | sorted xs ==>
>> sorted ys }
>> insert x [] = [x]
>> insert x yys@(y:ys)
>> | x < y = x:yys
>> | otherwise = y:insert x ys
>>
>
>
>
> And with that an abstract interpreter runs checking the partial correctness
> of the code. The predicates can be specified in Haskell itself,
> non-termination (even in the predicate) is covered by the fact that you only
> check partial correctness.
>
> In the above, the abstract interpretation for sort can use the fact that
> insert returns a sorted list. In fact the only non-trivial clause to prove
> in the whole thing is the second branch of insert, which may rely on the
> transitivity of (<=), and so may have to be handed off to an external
> theorem prover.
>
> Static contract checking/ESC yields either success, a warning that it can't
> prove something, with a stack trace to the condition it can't prove, or an
> error with a counter example and a stack trace of what goes wrong.
> Unannotated code is effectively inlined rather than assumed to be total, so
> you can mix and match this style with traditional code.
>
> The fact that you get compile time stack traces is what made me fall in love
> with the approach. Dana used to have (most of) a port of ghc to support SCC
> on darcs.haskell.org, but I don't know what happened to it.
>
> -Edward Kmett
>
>
>
> On Tue, May 4, 2010 at 2:43 PM, Gregory Crosswhite <
> gcr...@phys.washington.edu> wrote:
>
>> I definitely like that idea. :-) Is this similar to the notion of
>> dependent types?
>>
>> Cheers,
>> Greg
>>
>>
>>
>> On May 4, 2010, at 11:21 AM, Kyle Murphy wrote:
>>
>> This whole thing seems to be touching on something I saw recently and was
>> quite interested in. I found a site talking about static contract checking
>> in Haskell, unfortunately I can't seem to find it now, but this paper (
>> http://research.microsoft.com/en-us/um/people/simonpj/papers/verify/haskellcontract.ps)
>> by Simon Peyton Jones among others seems to be about the same thing the
>> site I found was talking about. The idea is to provide enough extra
>> information to the type system to actually be able to verify that for
>> instance, secondElement is always called with at least two items. If there
>> exists in your code any situation in which the contract of a function
>> could
>> be violated (and therefore the possibility of blowing up at runtime), it
>> no
>> longer passes static type checking. The paper doesn't go much into the
>> impact something like that would have on for instance GHCi, but if it was
>> smart enough to inherit contracts from functions used and display these
>> derived contracts this would be a very simple way to find all the edge
>> cases
>> of your code.
>>
>> -R. Kyle Murphy
>> --
>> Curiosity was framed, Ignorance killed the cat.
>>
>>
>> On Tue, May 4, 2010 at 12:56, John Lato wrote:
>>
>>> On Tue, May 4, 2010 at 5:31 PM, Gregory Crosswhite
>>> wrote:
>>> >
>>> > Yes, but I think that it is also important to distinguish between cases
>>> where an error is expected to be able to occur at runtime, and cases
>>> where
>>> an error could only occur at runtime *if the programmer screwed up*. If
>>> you
>>> structure your code to preserve and rely on the invariant that a given
>>> list
>>> has at least two elements, then it makes sense to call secondElement
>>> because
>>> if the list doesn't have two elements then you screwed up. Furthermore,
>>> there is no way to recover from such an error because you don't
>>> necessarily
>>> know where the invariant was broken because if you did you would have
>>> expected the possibility and already fixed it.
>>> >
>>> > But hypothetically, suppose that you decided to use safeSecondElement
>>> anyway; now you have to deal with a Nothing in your code. Since, again,
>>> you don't know how to recover from this (as if you did, you wouldn't have
>>> gotten a Nothing in the first place), the only thing you can do is
>>> propagate
>>> it through the calculation, until it reaches someone who can recover from
>>> it, which means that now your whole calculation has to be muddled up with
>>> Maybe types wrapping every result purely to capture the possibility of a
>>> bug
>>> (or hardware fault, I suppose). If your program relied on this
>>> calculation,
>>> then it *still* has no choice but to terminate, and it
Re: [Haskell-cafe] ANN: has-0.4 Entity based records
I think I missed your point in my last post, and there are more
necessary extensions need to be enabled than I wrote before.
TypeFamilies, TypeOperator and FlexibleContexts extensions are
necessary. So you need to write this at top of the code if you don't
choose OPTIONS_GHC pragma.
> {-# LANGUAGE TypeFamilies,TypeOperators,FlexibleContexts #-}
Sorry for incorrect information.
-nwn
On 5 May 2010 02:33, HASHIMOTO, Yusaku wrote:
> I uploaded new version (0.4.0.1) of this package with proper pragmas.
>
> On 5 May 2010 02:00, HASHIMOTO, Yusaku wrote:
>> Hello
>>
I'm pleased to announce the release of my new library, named "has",
written to aim to ease pain at inconvinience of Haskell's build-in
records.
>>>
>>> Hmm, nice work, looks interesting.
>>
>> Thanks!
>>
You can use the has in three steps (without counting installation).
1. Write {-# OPTIONS_GHC -fglasgow-exts #-} top of your code,
>>>
>>> This is going out of style. It would be nice to know specifically
>>> what LANGUAGE extensions are necessary.
>>
>> Ah, yes. {-# LANGUAGE TypeFamilies #-} is enough for that literate
>> haskell file, But the has depends GHC's language extensions such as
>> UndecidableInstances, OverlappingInstances and TypeFamilies. But I'll
>> remove OPTIONS_GHC pragma from library codes. Thank you for your
>> suggestion.
>>
>> -nwn
>>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Is anyone using Haddock's support for frames?
2010/5/4 Sean Leather : > Somewhat OT, but is there a place where we can request/review features in > the new HTML presentation of Haddock. Are there any mockups of what the > pages might look like? I've had some ideas pop around my head every time I > look at documentation. ;) http://trac.haskell.org/haddock/ticket/108 Or feel free to open a discussion on hadd...@projects.haskell.org. Ideas very welcomed! David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Is anyone using Haddock's support for frames?
> * We probably want to replace the frames with something more modern > (like a sidebar on the same page) in the future > > * We are rewriting the HTML backend and it would be nice to avoid > unnecessary work > > So if you're using this feature and want to keep it, please speak up! > Somewhat OT, but is there a place where we can request/review features in the new HTML presentation of Haddock. Are there any mockups of what the pages might look like? I've had some ideas pop around my head every time I look at documentation. ;) Thanks, Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell and the Software design process
The papers are available here: http://gallium.inria.fr/~naxu/pub.html
But in general you can say things like the following:
(Dana Xu uses a slightly different notation that I can never remember).
sorted :: Ord a => [a] -> Bool
> sorted [] = True
> sorted [x] = True
> sorted (x:xs) = x < head xs && sorted xs
>
> sort :: Ord a => [a] -> { xs : [a] | sorted xs }
> sort [] = []
> sort (x:xs) = insert x (sort xs)
>
> insert :: Ord a => a -> { xs : [a] | sorted xs } -> { ys : [a] | sorted xs
> }
> -- insert :: Ord a => a -> { xs : [a] } -> { ys : [a] | sorted xs ==>
> sorted ys }
> insert x [] = [x]
> insert x yys@(y:ys)
> | x < y = x:yys
> | otherwise = y:insert x ys
>
And with that an abstract interpreter runs checking the partial correctness
of the code. The predicates can be specified in Haskell itself,
non-termination (even in the predicate) is covered by the fact that you only
check partial correctness.
In the above, the abstract interpretation for sort can use the fact that
insert returns a sorted list. In fact the only non-trivial clause to prove
in the whole thing is the second branch of insert, which may rely on the
transitivity of (<=), and so may have to be handed off to an external
theorem prover.
Static contract checking/ESC yields either success, a warning that it can't
prove something, with a stack trace to the condition it can't prove, or an
error with a counter example and a stack trace of what goes wrong.
Unannotated code is effectively inlined rather than assumed to be total, so
you can mix and match this style with traditional code.
The fact that you get compile time stack traces is what made me fall in love
with the approach. Dana used to have (most of) a port of ghc to support SCC
on darcs.haskell.org, but I don't know what happened to it.
-Edward Kmett
On Tue, May 4, 2010 at 2:43 PM, Gregory Crosswhite <
gcr...@phys.washington.edu> wrote:
> I definitely like that idea. :-) Is this similar to the notion of
> dependent types?
>
> Cheers,
> Greg
>
>
>
> On May 4, 2010, at 11:21 AM, Kyle Murphy wrote:
>
> This whole thing seems to be touching on something I saw recently and was
> quite interested in. I found a site talking about static contract checking
> in Haskell, unfortunately I can't seem to find it now, but this paper (
> http://research.microsoft.com/en-us/um/people/simonpj/papers/verify/haskellcontract.ps)
> by Simon Peyton Jones among others seems to be about the same thing the
> site I found was talking about. The idea is to provide enough extra
> information to the type system to actually be able to verify that for
> instance, secondElement is always called with at least two items. If there
> exists in your code any situation in which the contract of a function could
> be violated (and therefore the possibility of blowing up at runtime), it no
> longer passes static type checking. The paper doesn't go much into the
> impact something like that would have on for instance GHCi, but if it was
> smart enough to inherit contracts from functions used and display these
> derived contracts this would be a very simple way to find all the edge cases
> of your code.
>
> -R. Kyle Murphy
> --
> Curiosity was framed, Ignorance killed the cat.
>
>
> On Tue, May 4, 2010 at 12:56, John Lato wrote:
>
>> On Tue, May 4, 2010 at 5:31 PM, Gregory Crosswhite
>> wrote:
>> >
>> > Yes, but I think that it is also important to distinguish between cases
>> where an error is expected to be able to occur at runtime, and cases where
>> an error could only occur at runtime *if the programmer screwed up*. If you
>> structure your code to preserve and rely on the invariant that a given list
>> has at least two elements, then it makes sense to call secondElement because
>> if the list doesn't have two elements then you screwed up. Furthermore,
>> there is no way to recover from such an error because you don't necessarily
>> know where the invariant was broken because if you did you would have
>> expected the possibility and already fixed it.
>> >
>> > But hypothetically, suppose that you decided to use safeSecondElement
>> anyway; now you have to deal with a Nothing in your code. Since, again,
>> you don't know how to recover from this (as if you did, you wouldn't have
>> gotten a Nothing in the first place), the only thing you can do is propagate
>> it through the calculation, until it reaches someone who can recover from
>> it, which means that now your whole calculation has to be muddled up with
>> Maybe types wrapping every result purely to capture the possibility of a bug
>> (or hardware fault, I suppose). If your program relied on this calculation,
>> then it *still* has no choice but to terminate, and it *still* doesn't know
>> where the error occurred --- although if you use something like ErrorT, you
>> might at least know what the nature of the error was. So basically, you
>> still end up with having to terminate your program and printing out an error
>> message reporting t
Re: [Haskell-cafe] Haskell and the Software design process
On Tue, May 4, 2010 at 2:43 PM, Gregory Crosswhite wrote: > I definitely like that idea. :-) Is this similar to the notion of > dependent types? That's where things tend to wind up eventually, yes. Although, with Haskell as it stands, a great deal of unused information is already present outside the type system, sufficient to automatically prove a range of "easy" properties of code. For instance, consider Neil Mitchell's Catch tool[0], which seems to handle things like the "secondElement" function discussed. Of course, actually writing such a checker is not so easy, and encoding the results of something like Catch in the type system leads to either convoluted type metaprogramming hacks or to new extensions creeping slowly toward full dependent types. - C. [0] http://community.haskell.org/~ndm/catch/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Is anyone using Haddock's support for frames?
I think it will no longer be needed once Haddock outputs table-less layout code. Frames caused problems with the back-button, so they weren't really an improvement. A simple CSS float:right + smaller font on the div containing the index would be a lot better. I think it would be best to keep the headings in the index, though. Haddock's current long list of things is often not very helpful, because the organisation by categories is gone (and the headings alone are often not sufficient). On 4 May 2010 19:19, David Waern wrote: > Hi > > Since version 2.4.0 Haddock has generated HTML output that uses frames > (index-frames.html) in addition to the normal output. We'd like to > deprecate this feature unless there is a significant amount of users. > The reason is two-fold: > > * We probably want to replace the frames with something more modern > (like a sidebar on the same page) in the future > > * We are rewriting the HTML backend and it would be nice to avoid > unnecessary work > > So if you're using this feature and want to keep it, please speak up! > > cc:ing cvs-ghc@ in case they have any users of the frames due to the > size of the GHC code base. (This might have been the the original > motivation for the feature). > > Thanks, > David > -- Push the envelope. Watch it bend. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell and the Software design process
I definitely like that idea. :-) Is this similar to the notion of dependent types? Cheers, Greg On May 4, 2010, at 11:21 AM, Kyle Murphy wrote: > This whole thing seems to be touching on something I saw recently and was > quite interested in. I found a site talking about static contract checking in > Haskell, unfortunately I can't seem to find it now, but this paper ( > http://research.microsoft.com/en-us/um/people/simonpj/papers/verify/haskellcontract.ps > ) by Simon Peyton Jones among others seems to be about the same thing the > site I found was talking about. The idea is to provide enough extra > information to the type system to actually be able to verify that for > instance, secondElement is always called with at least two items. If there > exists in your code any situation in which the contract of a function could > be violated (and therefore the possibility of blowing up at runtime), it no > longer passes static type checking. The paper doesn't go much into the impact > something like that would have on for instance GHCi, but if it was smart > enough to inherit contracts from functions used and display these derived > contracts this would be a very simple way to find all the edge cases of your > code. > > -R. Kyle Murphy > -- > Curiosity was framed, Ignorance killed the cat. > > > On Tue, May 4, 2010 at 12:56, John Lato wrote: > On Tue, May 4, 2010 at 5:31 PM, Gregory Crosswhite > wrote: > > > > Yes, but I think that it is also important to distinguish between cases > > where an error is expected to be able to occur at runtime, and cases where > > an error could only occur at runtime *if the programmer screwed up*. If > > you structure your code to preserve and rely on the invariant that a given > > list has at least two elements, then it makes sense to call secondElement > > because if the list doesn't have two elements then you screwed up. > > Furthermore, there is no way to recover from such an error because you > > don't necessarily know where the invariant was broken because if you did > > you would have expected the possibility and already fixed it. > > > > But hypothetically, suppose that you decided to use safeSecondElement > > anyway; now you have to deal with a Nothing in your code. Since, again, > > you don't know how to recover from this (as if you did, you wouldn't have > > gotten a Nothing in the first place), the only thing you can do is > > propagate it through the calculation, until it reaches someone who can > > recover from it, which means that now your whole calculation has to be > > muddled up with Maybe types wrapping every result purely to capture the > > possibility of a bug (or hardware fault, I suppose). If your program > > relied on this calculation, then it *still* has no choice but to terminate, > > and it *still* doesn't know where the error occurred --- although if you > > use something like ErrorT, you might at least know what the nature of the > > error was. So basically, you still end up with having to terminate your > > program and printing out an error message reporting the existence of a bug, > > but now you had to add error-propagating infrastructure to your entire > > program to do this that makes every function more complicated, rather than > > relying on the built-in infrastructure supplied by Haskell in the form of > > undefined, error, and throwing exceptions from pure code. > > > > If you want to make your program fault tolerant against bugs --- which is > > reasonable in programs such as, say, a text editor, where inability to > > complete one task doesn't necessarily mean that the whole program has to > > stop --- then you are probably working in the IO monad and so have access > > to means of catching exceptions, which means that you might as well use > > them. > > > > Thus, if you are dealing with invariants which only fail if you, the > > programmer, screwed something up, I don't really see the benefit of using > > functions like safeSecondElement over secondElement. Of course, situations > > in which you are *expecting* subcomputations to be able to fail at runtime > > if, say, the input is ill-formed, are a different matter. > > I agree completely, although I'm not the first to point out that > catching exceptions thrown from pure code can be tricky because they > might not appear where you expect them to. Of course this can also > indicate your architecture needs help. > > John > ___ > 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] Haskell and the Software design process
This whole thing seems to be touching on something I saw recently and was quite interested in. I found a site talking about static contract checking in Haskell, unfortunately I can't seem to find it now, but this paper ( http://research.microsoft.com/en-us/um/people/simonpj/papers/verify/haskellcontract.ps) by Simon Peyton Jones among others seems to be about the same thing the site I found was talking about. The idea is to provide enough extra information to the type system to actually be able to verify that for instance, secondElement is always called with at least two items. If there exists in your code any situation in which the contract of a function could be violated (and therefore the possibility of blowing up at runtime), it no longer passes static type checking. The paper doesn't go much into the impact something like that would have on for instance GHCi, but if it was smart enough to inherit contracts from functions used and display these derived contracts this would be a very simple way to find all the edge cases of your code. -R. Kyle Murphy -- Curiosity was framed, Ignorance killed the cat. On Tue, May 4, 2010 at 12:56, John Lato wrote: > On Tue, May 4, 2010 at 5:31 PM, Gregory Crosswhite > wrote: > > > > Yes, but I think that it is also important to distinguish between cases > where an error is expected to be able to occur at runtime, and cases where > an error could only occur at runtime *if the programmer screwed up*. If you > structure your code to preserve and rely on the invariant that a given list > has at least two elements, then it makes sense to call secondElement because > if the list doesn't have two elements then you screwed up. Furthermore, > there is no way to recover from such an error because you don't necessarily > know where the invariant was broken because if you did you would have > expected the possibility and already fixed it. > > > > But hypothetically, suppose that you decided to use safeSecondElement > anyway; now you have to deal with a Nothing in your code. Since, again, > you don't know how to recover from this (as if you did, you wouldn't have > gotten a Nothing in the first place), the only thing you can do is propagate > it through the calculation, until it reaches someone who can recover from > it, which means that now your whole calculation has to be muddled up with > Maybe types wrapping every result purely to capture the possibility of a bug > (or hardware fault, I suppose). If your program relied on this calculation, > then it *still* has no choice but to terminate, and it *still* doesn't know > where the error occurred --- although if you use something like ErrorT, you > might at least know what the nature of the error was. So basically, you > still end up with having to terminate your program and printing out an error > message reporting the existence of a bug, but now you had to add > error-propagating infrastructure to your entire program to do this that > makes every function more complicated, rather than relying on the built-in > infrastructure supplied by Haskell in the form of undefined, error, and > throwing exceptions from pure code. > > > > If you want to make your program fault tolerant against bugs --- which is > reasonable in programs such as, say, a text editor, where inability to > complete one task doesn't necessarily mean that the whole program has to > stop --- then you are probably working in the IO monad and so have access to > means of catching exceptions, which means that you might as well use them. > > > > Thus, if you are dealing with invariants which only fail if you, the > programmer, screwed something up, I don't really see the benefit of using > functions like safeSecondElement over secondElement. Of course, situations > in which you are *expecting* subcomputations to be able to fail at runtime > if, say, the input is ill-formed, are a different matter. > > I agree completely, although I'm not the first to point out that > catching exceptions thrown from pure code can be tricky because they > might not appear where you expect them to. Of course this can also > indicate your architecture needs help. > > John > ___ > 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] Is anyone using Haddock's support for frames?
Hi Since version 2.4.0 Haddock has generated HTML output that uses frames (index-frames.html) in addition to the normal output. We'd like to deprecate this feature unless there is a significant amount of users. The reason is two-fold: * We probably want to replace the frames with something more modern (like a sidebar on the same page) in the future * We are rewriting the HTML backend and it would be nice to avoid unnecessary work So if you're using this feature and want to keep it, please speak up! cc:ing cvs-ghc@ in case they have any users of the frames due to the size of the GHC code base. (This might have been the the original motivation for the feature). Thanks, David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: has-0.4 Entity based records
I uploaded new version (0.4.0.1) of this package with proper pragmas.
On 5 May 2010 02:00, HASHIMOTO, Yusaku wrote:
> Hello
>
>>> I'm pleased to announce the release of my new library, named "has",
>>> written to aim to ease pain at inconvinience of Haskell's build-in
>>> records.
>>
>> Hmm, nice work, looks interesting.
>
> Thanks!
>
>>> You can use the has in three steps (without counting installation).
>>>
>>> 1. Write {-# OPTIONS_GHC -fglasgow-exts #-} top of your code,
>>
>> This is going out of style. It would be nice to know specifically
>> what LANGUAGE extensions are necessary.
>
> Ah, yes. {-# LANGUAGE TypeFamilies #-} is enough for that literate
> haskell file, But the has depends GHC's language extensions such as
> UndecidableInstances, OverlappingInstances and TypeFamilies. But I'll
> remove OPTIONS_GHC pragma from library codes. Thank you for your
> suggestion.
>
> -nwn
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: has-0.4 Entity based records
Hello
>> I'm pleased to announce the release of my new library, named "has",
>> written to aim to ease pain at inconvinience of Haskell's build-in
>> records.
>
> Hmm, nice work, looks interesting.
Thanks!
>> You can use the has in three steps (without counting installation).
>>
>> 1. Write {-# OPTIONS_GHC -fglasgow-exts #-} top of your code,
>
> This is going out of style. It would be nice to know specifically
> what LANGUAGE extensions are necessary.
Ah, yes. {-# LANGUAGE TypeFamilies #-} is enough for that literate
haskell file, But the has depends GHC's language extensions such as
UndecidableInstances, OverlappingInstances and TypeFamilies. But I'll
remove OPTIONS_GHC pragma from library codes. Thank you for your
suggestion.
-nwn
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell and the Software design process
On Tue, May 4, 2010 at 5:31 PM, Gregory Crosswhite wrote: > > Yes, but I think that it is also important to distinguish between cases where > an error is expected to be able to occur at runtime, and cases where an error > could only occur at runtime *if the programmer screwed up*. If you structure > your code to preserve and rely on the invariant that a given list has at > least two elements, then it makes sense to call secondElement because if the > list doesn't have two elements then you screwed up. Furthermore, there is no > way to recover from such an error because you don't necessarily know where > the invariant was broken because if you did you would have expected the > possibility and already fixed it. > > But hypothetically, suppose that you decided to use safeSecondElement anyway; > now you have to deal with a Nothing in your code. Since, again, you don't > know how to recover from this (as if you did, you wouldn't have gotten a > Nothing in the first place), the only thing you can do is propagate it > through the calculation, until it reaches someone who can recover from it, > which means that now your whole calculation has to be muddled up with Maybe > types wrapping every result purely to capture the possibility of a bug (or > hardware fault, I suppose). If your program relied on this calculation, then > it *still* has no choice but to terminate, and it *still* doesn't know where > the error occurred --- although if you use something like ErrorT, you might > at least know what the nature of the error was. So basically, you still end > up with having to terminate your program and printing out an error message > reporting the existence of a bug, but now you had to add error-propagating > infrastructure to your entire program to do this that makes every function > more complicated, rather than relying on the built-in infrastructure supplied > by Haskell in the form of undefined, error, and throwing exceptions from pure > code. > > If you want to make your program fault tolerant against bugs --- which is > reasonable in programs such as, say, a text editor, where inability to > complete one task doesn't necessarily mean that the whole program has to stop > --- then you are probably working in the IO monad and so have access to means > of catching exceptions, which means that you might as well use them. > > Thus, if you are dealing with invariants which only fail if you, the > programmer, screwed something up, I don't really see the benefit of using > functions like safeSecondElement over secondElement. Of course, situations > in which you are *expecting* subcomputations to be able to fail at runtime > if, say, the input is ill-formed, are a different matter. I agree completely, although I'm not the first to point out that catching exceptions thrown from pure code can be tricky because they might not appear where you expect them to. Of course this can also indicate your architecture needs help. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: has-0.4 Entity based records
On Tue, May 4, 2010 at 10:18 AM, HASHIMOTO, Yusaku wrote:
> Hello,
>
> I'm pleased to announce the release of my new library, named "has",
> written to aim to ease pain at inconvinience of Haskell's build-in
> records.
Hmm, nice work, looks interesting.
> With the has, You can reuse accessors over records to write generic
> function, combine records with another.
>
> Repository is at GitHub: http://github.com/nonowarn/has
> Uploaded on Hackage: http://hackage.haskell.org/package/has
>
> So you can install this by "cabal install has"
>
> You can use the has in three steps (without counting installation).
>
> 1. Write {-# OPTIONS_GHC -fglasgow-exts #-} top of your code,
This is going out of style. It would be nice to know specifically
what LANGUAGE extensions are necessary.
Luke
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell and the Software design process
On May 4, 2010, at 5:22 AM, John Lato wrote: > The reason people argue for safeSecondElement over secondElement is > exactly the reason you argue against it. Calling safeSecondElement on > a list with < 2 elements forces the programmer to handle the result > immediately by returning a Maybe, which requires the programmer to > handle the Nothing case, corresponding to invalid input for this > function. This is better than the program crashing because the > programmer has to fix it before it's even released. This is exactly > how to use the type system to your advantage; the error condition is > indicated by the return type of the function. > > "Crashing at the point of the error" isn't necessarily useful in > Haskell due to lazy evaluation. The code will crash when the result > of the partial function is evaluated, which may be quite far away (in > terms of function calls) from where the programmer would expect. Yes, but I think that it is also important to distinguish between cases where an error is expected to be able to occur at runtime, and cases where an error could only occur at runtime *if the programmer screwed up*. If you structure your code to preserve and rely on the invariant that a given list has at least two elements, then it makes sense to call secondElement because if the list doesn't have two elements then you screwed up. Furthermore, there is no way to recover from such an error because you don't necessarily know where the invariant was broken because if you did you would have expected the possibility and already fixed it. But hypothetically, suppose that you decided to use safeSecondElement anyway; now you have to deal with a Nothing in your code. Since, again, you don't know how to recover from this (as if you did, you wouldn't have gotten a Nothing in the first place), the only thing you can do is propagate it through the calculation, until it reaches someone who can recover from it, which means that now your whole calculation has to be muddled up with Maybe types wrapping every result purely to capture the possibility of a bug (or hardware fault, I suppose). If your program relied on this calculation, then it *still* has no choice but to terminate, and it *still* doesn't know where the error occurred --- although if you use something like ErrorT, you might at least know what the nature of the error was. So basically, you still end up with having to terminate your program and printing out an error message reporting the existence of a bug, but now you had to add error-propagating infrastructure to your entire program to do this that makes every function more complicated, rather than relying on the built-in infrastructure supplied by Haskell in the form of undefined, error, and throwing exceptions from pure code. If you want to make your program fault tolerant against bugs --- which is reasonable in programs such as, say, a text editor, where inability to complete one task doesn't necessarily mean that the whole program has to stop --- then you are probably working in the IO monad and so have access to means of catching exceptions, which means that you might as well use them. Thus, if you are dealing with invariants which only fail if you, the programmer, screwed something up, I don't really see the benefit of using functions like safeSecondElement over secondElement. Of course, situations in which you are *expecting* subcomputations to be able to fail at runtime if, say, the input is ill-formed, are a different matter. Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: has-0.4 Entity based records
Hello,
I'm pleased to announce the release of my new library, named "has",
written to aim to ease pain at inconvinience of Haskell's build-in
records.
With the has, You can reuse accessors over records to write generic
function, combine records with another.
Repository is at GitHub: http://github.com/nonowarn/has
Uploaded on Hackage: http://hackage.haskell.org/package/has
So you can install this by "cabal install has"
You can use the has in three steps (without counting installation).
1. Write {-# OPTIONS_GHC -fglasgow-exts #-} top of your code,
import Data.Has module.
> {-# OPTIONS_GHC -fglasgow-exts #-}
> import Data.Has
2. Define entities. "Entity" is data to index field in records.
You can define an entity in one line.
> data Foo = Foo; type instance TypeOf Foo = Int
(I lied) Before semicolon, declares entity. After semicolon,
specifies the type to which the entity points.
Define some entities for later examples.
> data Bar = Bar; type instance TypeOf Bar = Double
> data Baz = Baz; type instance TypeOf Baz = String
> data Quux = Quux; type instance TypeOf Quux = Bool
3. Define Records by concatinating fields of entities.
> type MyRecord = FieldOf Foo :&: FieldOf Bar :&: FieldOf Baz
This is almost same as writing
< data MyRecord = MyRecord { foo :: Int
< , bar :: Double
< , baz :: String
< }
To construct a value of record, remove colons and replace entities
in record with values, and uncapitalize some words.
> aRecord :: MyRecord
> aRecord = fieldOf 42 & fieldOf 3.14 & fieldOf "string"
And you can play with it.
To read/write/modify a value of field in records, you can use
functions with names stealed from data-accessor. But uses value-level
entities instead of accessors.
< Foo ^. aRecord -- Reading
< Foo ^= 4649 $ aRecord-- Writing
< Foo ^: (*2) $ aRecord-- Modifying
If we have another record type contains Foo field, You can still
access the field in the same way.
> type AnotherRecord = FieldOf Bar :&: FieldOf Foo
> anotherRecord :: AnotherRecord
> anotherRecord = fieldOf 2.71 & fieldOf 31
< Foo ^. anotherRecord -- And this also works
Using these functions and Has constraint, You can write generic
functions over records.
> fooIsGreaterThan :: (Has Foo r) => r -> Int -> Bool
> fooIsGreaterThan r x = (Foo ^. r) > x
< aRecord `fooIsGreaterThan` 40 -- evaluated to True
< anotherRecord `fooIsGreaterThan` 40 -- evaluated To False
Even if you defined another record by combining records by (:&:), you
can still access the field, and apply to generic functions.
> type MoreRecord = FieldOf Baz :&: FieldOf Quux
> type CombinedRecord = AnotherRecord :&: MoreRecord
> combinedRecord :: CombinedRecord
> combinedRecord = (fieldOf 1.618 & fieldOf 39) & (fieldOf "sowaka" & fieldOf
> True)
>-- We can omit parentheses
>-- (even place parens anyware in record)
< combinedRecord `fooIsGreaterThan` 40 -- This yet works
The Has constraint provides not only genericity but also safety. If
the record doesn't satisfy the constraint, the type checker rejects
it.
> predicateOnRecords :: (Has Foo r, Has Quux r) => r -> Bool
> predicateOnRecords r = fooIsGreaterThan r 30 && (Quux ^. r)
< predicateOnRecords combinedRecord -- This is OK
< predicateOnRecords aRecord-- This yields compile error
More examples included in package[1]
[1]: http://github.com/nonowarn/has/tree/master/examples/
This library is inspired by HList[2], and interfaces are stealed from
data-accessors[3]. And lenses[4], fclabels[5], and records[6] devote
themselves to similar purposes.
[2]: http://hackage.haskell.org/package/HList
[3]: http://hackage.haskell.org/package/data-accessor
[4]: http://hackage.haskell.org/package/lenses
[5]: http://hackage.haskell.org/package/fclabels
[6]: http://hackage.haskell.org/package/records
Enjoy!
-nwn
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Interest in a Mathematics & AI strike force ?
This is a very interesting idea. I consider it to be a long shot compared to "just" writing haskell code to perform these tasks, so I don't think it's a priority, except if someone is willing to work on this. But I'd already be quite satisfied with a more complete and uniform "framework" for mathematics in haskell. On Tue, May 4, 2010 at 4:58 PM, John Creighton wrote: > I know that someone has created a Haskell interpreter for lisp. > Perhaps this could server as a starting pointing to creating a > translator between lisp and haskell. This is relevant with regards to > computer algebra because the computer algebra system Maxima is written > is lisp. Their is also a repository of AI programs which are written > in lisp. No doubt starting from scratch with haskell would create new > possibility but it would be nice to also be able to utilize existing > work. > > On May 3, 7:59 pm, Alp Mestanogullari wrote: > > Hello -cafe, > > > > When I started learning Haskell, I saw the AI page [1] which aimed at > > creating a sound, uniform and handy framework for AI programming in > Haskell. > > I added my name on it and thought a bit about it. I even wrote a first > > version of HNN [2], a neural network library, quite early in my Haskell > > days. > > > > I found that idea to be great but did not see any actual effort around > this. > > So, I'm now thinking again about that and even enlarging it to > mathematics & > > AI. Thus, I would like to have an idea of the number of people interested > in > > being involved in such an effort. There are several tools out there on > > hackage but they aren't that much uniform and neither play nicely > together. > > I'm pretty convinced this could be improved and as a Mathematics student > I'm > > highly interested in that. If enough people are interested, we could for > > example set up a mailing list and a trac to organize the effort and then > > people could just discuss and write Haskell modules when time permits. > > > > Any comment, idea, reaction, interest ? > > > > [1]http://www.haskell.org/haskellwiki/AI > > [2]http://www.haskell.org/haskellwiki/HNN > > > > -- > > Alp Mestanogullarihttp:// > alpmestan.wordpress.com/http://alp.developpez.com/ > > > > ___ > > Haskell-Cafe mailing list > > haskell-c...@haskell.orghttp:// > www.haskell.org/mailman/listinfo/haskell-cafe > > > > -- > > You received this message because you are subscribed to the Google Groups > "Haskell-cafe" group. > > To post to this group, send email to haskell-c...@googlegroups.com. > > To unsubscribe from this group, send email to > haskell-cafe+unsubscr...@googlegroups.com > . > > For more options, visit this group athttp:// > groups.google.com/group/haskell-cafe?hl=en. > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Alp Mestanogullari http://alpmestan.wordpress.com/ http://alp.developpez.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Set Operations In Haskell's Type System
hello, 2010/5/4 John Creighton : > I will continue to try to solve the problem on my own but at the > moment I'm able to get IsSuperSet to work but not the classes Isa, > Child and IsSubSet to work. Unlike set theory IsSubSet is not the same > as switching the order arguments in IsSuperSet because the searching > is done in the opposite direction. In one case we are searching the > parents and each child only has one parent. In the other Case we are > searching the children and each parent could have multiple children). Since Subset is the opposite of Superset, you can search in the "easier" (up) direction, so it really is as easy as reversing the order of arguments. It's not possible to write class/type-level function Child a b | a -> b, because functions (classes with fun-deps) must be deterministic. If you want to enumerate all children (based on Parent class instances), it's also impossible in this setup, it's probably possible with Oleg's second-order typeclass programming[1]. [1] http://okmij.org/ftp/Haskell/types.html#poly2 But what are you actually trying to achieve? I can't thing of anything useful that would require walking down the hierarchy tree (and backtracking) and it has to be done at the type level. Please use more descriptive type-variable names, type-level code should also be easy to read:) regards, Bartek Ćwikłowski ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell and the Software design process
On Tue, May 4, 2010 at 2:09 PM, Limestraël wrote: > 2010/5/4 John Lato >> >> "Crashing at the point of the error" isn't necessarily useful in >> Haskell due to lazy evaluation. The code will crash when the result >> of the partial function is evaluated, which may be quite far away (in >> terms of function calls) from where the programmer would expect. > > Is that why Haskell can't provide a traceback when exceptions are raised? I'm not really the right person to answer this, but I believe this is roughly true. > Are there other methods than Maybe or exceptions to handle the errors in > Haskell? Is the monad Error(T) useful? There are many other ways of handling errors/exceptional conditions. Maybe, Either, ErrorT, abuse of monad fail, explicit-exception [1] and attempt [2] are some of them; there are others. Which is appropriate depends upon the use case. The difficulty is gluing together libraries that use different mechanisms (attempt addresses this to some extent). And of course exceptions, which are unavoidable but often neglected because they're invisible at the type level. [1] http://hackage.haskell.org/package/explicit-exception [2] http://hackage.haskell.org/package/attempt John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Interest in a Mathematics & AI strike force ?
I know that someone has created a Haskell interpreter for lisp. Perhaps this could server as a starting pointing to creating a translator between lisp and haskell. This is relevant with regards to computer algebra because the computer algebra system Maxima is written is lisp. Their is also a repository of AI programs which are written in lisp. No doubt starting from scratch with haskell would create new possibility but it would be nice to also be able to utilize existing work. On May 3, 7:59 pm, Alp Mestanogullari wrote: > Hello -cafe, > > When I started learning Haskell, I saw the AI page [1] which aimed at > creating a sound, uniform and handy framework for AI programming in Haskell. > I added my name on it and thought a bit about it. I even wrote a first > version of HNN [2], a neural network library, quite early in my Haskell > days. > > I found that idea to be great but did not see any actual effort around this. > So, I'm now thinking again about that and even enlarging it to mathematics & > AI. Thus, I would like to have an idea of the number of people interested in > being involved in such an effort. There are several tools out there on > hackage but they aren't that much uniform and neither play nicely together. > I'm pretty convinced this could be improved and as a Mathematics student I'm > highly interested in that. If enough people are interested, we could for > example set up a mailing list and a trac to organize the effort and then > people could just discuss and write Haskell modules when time permits. > > Any comment, idea, reaction, interest ? > > [1]http://www.haskell.org/haskellwiki/AI > [2]http://www.haskell.org/haskellwiki/HNN > > -- > Alp Mestanogullarihttp://alpmestan.wordpress.com/http://alp.developpez.com/ > > ___ > Haskell-Cafe mailing list > haskell-c...@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe > > -- > You received this message because you are subscribed to the Google Groups > "Haskell-cafe" group. > To post to this group, send email to haskell-c...@googlegroups.com. > To unsubscribe from this group, send email to > haskell-cafe+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/haskell-cafe?hl=en. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Set Operations In Haskell's Type System
This is partly a continuation from:
http://groups.google.ca/group/haskell-cafe/browse_thread/thread/4ee2ca1f5eb88e7a?hl=en#
and
http://hpaste.org/fastcgi/hpaste.fcgi/view?id=25265
Also of relevance:
http://groups.google.ca/group/haskell-cafe/browse_thread/thread/9cc8858a2e51a995?hl=en#
http://www.haskell.org/haskellwiki/GHC/AdvancedOverlap
http://homepages.cwi.nl/~ralf/HList/paper.pdf
http://okmij.org/ftp/Haskell/typecast.html
http://www.haskell.org/haskellwiki/User:ConradParker/InstantInsanity
http://okmij.org/ftp/Haskell/types.html (haven't looked at this link
yet)
I will continue to try to solve the problem on my own but at the
moment I'm able to get IsSuperSet to work but not the classes Isa,
Child and IsSubSet to work. Unlike set theory IsSubSet is not the same
as switching the order arguments in IsSuperSet because the searching
is done in the opposite direction. In one case we are searching the
parents and each child only has one parent. In the other Case we are
searching the children and each parent could have multiple children).
Bellow is my current code:
{-# LANGUAGE EmptyDataDecls,
MultiParamTypeClasses,
ScopedTypeVariables,
FunctionalDependencies,
OverlappingInstances,
FlexibleInstances,
UndecidableInstances,
TypeFamilies #-}
{-# LANGUAGE TypeOperators #-} --10
{-# LANGUAGE FlexibleContexts #-}
--{-# LANGUAGE IncoherentInstances #-}
--IsSubSet ---
data ItsNotAParrent
class IsSubSet a b c | a b -> c where -- General Definition
isSubSet :: a->b->c
class Child a b|b->a where {}
instance (
Parrent b a2,
TypeEq a2 a itsAParrent, --
Child' itsAParrent a b
) => Child a b
class Child' itsAParrent a b where {}
instance (TypeCast b ItsNotAParrent)=>Child' F a b --No Childern
instance (TypeCast b c, Parrent c b)=>Child' T a b
instance (TypeCast b M)=>Child' itsAParrent a b --- Fail Case
instance (
TypeEq ItsNotAParrent a itsNotAParrent,
TypeEq a b iseq,
IsSubSet' itsNotAParrent iseq a b c3 --
) =>
IsSubSet a b c3 where --
isSubSet a b = undefined::c3
class IsSubSet' itsNotAParrent iseq a b c| itsNotAParrent iseq a b ->
c where {}
instance (TypeCast c T)=>IsSubSet' F T a b c where {}
instance (TypeCast c F)=>IsSubSet' T iseq a b c where {} --Not sure
which logic value is best for this case.
instance (TypeCast c M)=>IsSubSet' itsNotAParrent iseq a b c where {}
--Fail Case
instance (
Child a d,
IsSubSet d b c
)=>
IsSubSet' F F a b c where {}
--bla11=isSubSet Cat Animal
---Isa
-
class Isa' a b c|a b->c where {} --Direct Relationship
class Isa a b c|a b->c where
isa::a->b->c
instance (
Isa' a1 b1 c1, --Direct Relationship
IsSuperSet a1 a c2, --Check --20
IsSuperSet b b1 c3, --
Isa'' c1 c2 c3 a1 b1 c4 -- Decesion function --
)=>Isa a b c4 where
isa a b = undefined::c4
class Isa'' c1 c2 c3 a b c4|c1 c2 c3 a b->c4 where {}
-- isa :: c1->c2->c3->a->b->c4
instance Isa'' T T T a1 b1 T where {}
-- isa'' c1 c2 c3 a b = T --30
instance Isa'' F c2 c3 a1 b1 F where {} --
-- isa'' c1 c2 c3 a b = F
instance Isa'' c1 F c3 a1 b1 F where {}
-- isa'' c1 c2 c3 a b = F
instance Isa'' c1 c2 F a1 b1 F where {}
-- isa'' c1 c2 c3 a b = F
Instance Isa Relations
--
instance Isa' Animal Noun T
instance (TypeCast F result) => Isa' a b result
-Test Relationships
--40
--bla6 = isa Cat Noun --
--bla4 = isa Cat Verb
---Basic Type Declarations
---
data Noun = Noun deriving (Show) --15
data Verb = Verb deriving (Show) --
data Adjactive = Adjactive deriving (Show)
data Animal=Animal deriving (Show)
data Feline=Feline deriving (Show) --50
data Cat = Cat deriving (Show)
data Taby_Cat=Taby_Cat deriving (Show)
---Instance SubType Relations
data ItsAnOrphan = ItsAnOrphan
instance Show ItsAnOrphan where
show _ = "ItsAnOrphan" --60
class Parrent a b| a->b where -- Specific Cases
parrent :: a->b --
instance Parrent Cat Feline where --
parrent a = Feline --40
instance Parrent Feline Animal where --
parrent a = Animal --
instance (TypeCast result ItsAnOrphan) => Parrent anyChild result
where
parrent a = undefined::result
--- Generic subType Relations
--
class IsSuperSet a b c | a b -> c where -- General Definition
isSuperSet :: a->b->c
--instance (TypeEq b Animal T,TypeEq c F T)=>IsSuperSet a b c where
--85
-- isSuperSet a b = F --
u=undefined
instance (
TypeEq ItsAnOrphan b isOrphan,
TypeEq a b iseq,
IsSuperSet' isOr
Re: [Haskell-cafe] Haskell and the Software design process
On Tue, May 4, 2010 at 9:09 AM, Limestraël wrote: > Are there other methods than Maybe or exceptions to handle the errors in > Haskell? Is the monad Error(T) useful? I believe the usual Error monad is just (Either e), with Left indicating failure. It's the same idea as Maybe, only returning information about the error instead of simply Nothing. At any rate, earlier you said: > The Maybe method is the simplest but it also comes with a little overhead, > since you always have to unpack the Maybe a value return ...which sounds odd to me. If you have a complex computation, in which many subcomputations can fail, it makes perfect sense to lift the whole thing into an error-handling monad. Particularly at points where nothing sensible can be done with a Left or Nothing, unpacking the result is unnecessary; instead, leave it as is and continue the computation inside the monad. Then, unpack the value at whatever point that you actually need the result, or can handle errors gracefully. I'd actually argue that error handling with Maybe/Either is the single best, most persuasive use for monadic structure in code--it's certainly the thing I miss most in other languages. For something so simple (the entire implementation of Maybe with instances is shorter than this message!) it's amazingly useful, letting you simplify code while simultaneously having static assurance that you won't get runtime errors because of not checking for failure somewhere. Using "fromJust" or "maybe (error foo) ..." seems bizarre, as if trying to recreate in Haskell the mind-numbing experience of dealing with unexpectedly null pointers being dereferenced. For that matter, null references tend to be frustrating to debug for exactly the same reason that Haskell errors can be: Crashing only when and if the value is actually needed, not when the null pointer or _|_ is first introduced. - C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Haskell and scripting
Hello minh, Tuesday, May 4, 2010, 11:15:03 AM, you wrote: > Numerous games include for instance a complete Lua interpreter, that's just one 100 kb dll :) -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell and the Software design process
2010/5/4 John Lato > "Crashing at the point of the error" isn't necessarily useful in > Haskell due to lazy evaluation. The code will crash when the result > of the partial function is evaluated, which may be quite far away (in > terms of function calls) from where the programmer would expect. > Is that why Haskell can't provide a traceback when exceptions are raised? Are there other methods than Maybe or exceptions to handle the errors in Haskell? Is the monad Error(T) useful? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell and the Software design process
> From: Rafael Cunha de Almeida > > Ivan Miljenovic disse: >> On 3 May 2010 14:17, aditya siram wrote: >>> I'm a little confused about this too. I've seen many functions defined like: >>> f x = (\s -> ...) >>> which is a partial function because it returns a function and is the same >>> as: >>> f x s = ... >> >> No, that's a partially applied function. >> >> A partial function is one such as: >> >> secondElement (_:x:_) = x >> >> Note that it is only defined for lists with at least two elements, for >> any other list (i.e. singleton or empty) it will throw an error; >> -fwarn-incomplete-patterns (which is included in -Wall) tells you >> about these. >> >> You can also argue that functions such as head are partial, as they >> explicitly throw an error if the input data isn't correct. >> >> Partial functions are bad because if you accidentally use one the >> wrong way, your entire program crashes in a flaming wreck. It's much >> better to do something like this: >> >> safeSecondElement (_:x:_) = Just x >> safeSecondElement _ = Nothing >> >> This will work with all possible input types. > > I don't think that safeSecondElement is worse than secondElement. I think it's > better for the program to crash right away when you try to do something that > doesn't make sense. > > Getting the secondElement of a list with one or less elements doesn't make > sense, so you are definetely doing something wrong if you expected the list to > have two elements, but it doesn't. It's best that the program crashes there, > than propagate the error and crash somewhere else or, worse, not crash at all > and give a wrong answer. Stepping in on the tail end of this discussion, however... The reason people argue for safeSecondElement over secondElement is exactly the reason you argue against it. Calling safeSecondElement on a list with < 2 elements forces the programmer to handle the result immediately by returning a Maybe, which requires the programmer to handle the Nothing case, corresponding to invalid input for this function. This is better than the program crashing because the programmer has to fix it before it's even released. This is exactly how to use the type system to your advantage; the error condition is indicated by the return type of the function. "Crashing at the point of the error" isn't necessarily useful in Haskell due to lazy evaluation. The code will crash when the result of the partial function is evaluated, which may be quite far away (in terms of function calls) from where the programmer would expect. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Installing ghc in an OpenSolaris Zone
Hello Lars, did you happen to manage ghc-6.10.4 in a zone? I suspect there are some packages I failed to install into the zone, but I'm not certain. Günther Am 29.04.10 23:19, schrieb Lars Viklund: On Thu, Apr 29, 2010 at 09:14:50AM +0200, Christian Maeder wrote: Günther Schmidt schrieb: Have you managed to install it into a zone yourself? What do you mean by "zone"? I managed to install this ghc into an other location than /usr/local by giving a prefix to configure: A Solaris zone is a mechanism similar to FreeBSD jails and (somewhat like) a chroot. It's a separate virtual world, with its own network interfaces, filesystem, etc. [1] http://en.wikipedia.org/wiki/Solaris_Containers ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal-install: bus error
On 5/3/10 23:46, Jason Dagit wrote: This happened to a co-worker on her mac. We used gdb to track the bus errors to the network library. Once we tracked it down to there, we did some combination of deleting $HOME/.cabal, building/installing the latest version of Network and then relinking cabal-install. I've also seen these errors with some versions of zlib (but, I think that was on an old Solaris box that had lots of issues). I just updated to the newest version and had problems with zlib: ld: warning: in /opt/local/lib/libz.dylib, file is not of required architecture (full error below) The solution was: # port install zlib +universal I hope this is of use to someone. :-) Martijn. Full error: (...) [39 of 40] Compiling Distribution.Client.Install ( Distribution/Client/Install.hs, dist/build/cabal/cabal-tmp/Distribution/Client/Install.o ) [40 of 40] Compiling Main ( Main.hs, dist/build/cabal/cabal-tmp/Main.o ) Linking dist/build/cabal/cabal ... ld: warning: in /opt/local/lib/libz.dylib, file is not of required architecture Undefined symbols: "_deflateEnd", referenced from: _deflateEnd$non_lazy_ptr in libHSzlib-0.5.2.0.a(Stream.o) "_inflateEnd", referenced from: _inflateEnd$non_lazy_ptr in libHSzlib-0.5.2.0.a(Stream.o) "_inflateInit2_", referenced from: _s4ug_info in libHSzlib-0.5.2.0.a(Stream.o) "_deflate", referenced from: _s4lq_info in libHSzlib-0.5.2.0.a(Stream.o) "_deflateInit2_", referenced from: _s4z5_info in libHSzlib-0.5.2.0.a(Stream.o) "_zlibVersion", referenced from: _r336_info in libHSzlib-0.5.2.0.a(Stream.o) "_inflate", referenced from: _s4om_info in libHSzlib-0.5.2.0.a(Stream.o) ld: symbol(s) not found collect2: ld returned 1 exit status cabal: Error: some packages failed to install: cabal-install-0.8.2 failed during the building phase. The exception was: exit: ExitFailure 1 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Learning about Programming Languages (specifically Haskell)
Here is my attempt. I tried to avoid higher concepts like folds and
things like the ($) operator. Most recursions are written explicitly.
{ BEGIN CODE }
module Main where
-- Data type representing a door which is either Open or Closed.
data Door = Open | Closed deriving Show
toggle :: Door -> Door
toggle Open = Closed
toggle Closed = Open
-- Applies the function f to every n'th element of a list.
skipMap :: (a -> a) -> Int -> [a] -> [a]
skipMap f n | n < 1 = error "skipMap: step < 1"
| otherwise = go (n - 1)
where
-- Apply the function 'f' to an element of the list when the
-- counter reaches 0, otherwise leave the element untouched.
go _ [] = []
go 0 (x:xs) = f x : go (n - 1) xs
go c (x:xs) = x : go (c - 1) xs
-- Calculate the final answer.
run :: Int -> [Door]
run n = go 1 initialDoors -- Start by toggling every door.
where
-- Initial list of closed doors
initialDoors :: [Door]
initialDoors = replicate n Closed
-- Toggle every c doors, then proceed by toggling every c+1 doors
-- of the result, etcetera... Stops after toggling the n'th door.
go :: Int -> [Door] -> [Door]
go c doors
| c > n = doors
| otherwise = go (c + 1) (skipMap toggle c doors)
-- Print information about a single door.
printDoor :: (Int, Door) -> IO ()
printDoor (n, door) = putStrLn ("Door #" ++ show n ++ " is " ++ show door)
printRun :: Int -> IO ()
printRun n = mapM_ printDoor (zip [1..n] (run n))
-- The program entry point.
main :: IO ()
main = printRun 100
{ END CODE }
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell and scripting
> A complete language needs a complete implementation. No, Minh, I was not talking about re-implementing a whole Lisp/Scheme language interpreter in Haskell. (I know there is BTW a Scheme interpreter made in Haskell : http://jonathan.tang.name/files/scheme_in_48/tutorial/overview.html). But what I really wanted to know is how usually haskellers do to script their applications. For instance (as you say), many games made in C/C++ use Lua (for AI or for configuration). That is the kind of scripting I'm talking about : a compiled program (in Haskell) reading an interpreting a script (in some already existing interpreted language (*) or some DSL especially made for this purpose). (*) functional language, because I want to keep the benefit of functional programming for scripting. So no Lua, no Python... > I may have misunderstood your goals and what you mean by "scripting". Our DSEL is intended to be used for expressing all kinds of scripting tasks. Martin, I did not understand your meaning of "scripting". IMO, a program can be scripted if it provides a way to alter (a part of) its configuration without having to recompile it entirely. If need be it recompiles the configuration files, but I think it's better if those files are interpreted (speeds up the program lauching, since it doesn't have to compile and link again (*)) (*) Yi, for instance, takes a little time to recompile its configuration, and when it re-links its executable, it weighs 38Mo! (and dynamic linking is still not perfect in Haskell) Plus, end-users have to install the compiler (GHC, which is not lightweight), even if they have the statically-linked executable of the application. 2010/5/4 minh thu > 2010/5/4 Limestraël : > > ... > > > > Minh, Kyle, Gwern, the dyre approach seems to be very interesting too. > > But if I understood well, we also have to recompile at run-time the > > configuration haskell script? > > So the final application (Yi, for instance) will need GHC to be installed > to > > run? Or did I miss something? > > By the way, I had never heard of Yi, but can I deduce from its name its a > > Vi(m)-like (which I am a big fan of)? Moreover, the idea of scripting my > > editor in Haskell appeals me. > > Yes GHC is needed. But if your goal is to produce something with the > benefits of a complete language for configuration, I think it's fine. > Numerous games include for instance a complete Lua interpreter, > SketchUp includes a ruby interpreter (or maybe it is python), Blender > uses python, Common Lisp programs can use Common Lisp, and so on. > > A complete language needs a complete implementation. > > If you want to make your own (non-embedded) DSL, you will either > provide less than a "complete" language or have to implement a lot of > stuff. > > Cheers, > Thu > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strict type system allows for a maximum number of programming errors to be caught at compile time.
On 04/05/2010, at 13:30, Luke Palmer wrote: > On Mon, May 3, 2010 at 11:07 AM, Kyle Murphy wrote: > >> The fact that it doesn't is proof enough that there's a problem >> with it even if that problem is simply that the types you're using aren't >> exactly correct. Further, I'd argue that in the first instance with a >> non-strict type system, the instance of wrong code that compiles would be >> higher. The only argument to support non-strict typing would be if you could >> show that it takes less time to track down runtime bugs than it does to fix >> compile time type errors, and any such claim I'd be highly skeptical of. > > Clearly. But many people believe in this methodology, and use test > suites and code coverage instead of types. Indeed, such practices are > essentially "empirical type checking", and they afford the advantage > that their verification is much more expressive (however less > reliable) than our static type system, because they may use arbitrary > code to express their predicates. I don't think it's a question of types vs. testing. Rather, it's types + testing vs. just testing. How is the latter more expressive than the former for defining properties of programs? Also, testing loses a lot of appeal once you start dealing with concurrent programs. Testing for "this program doesn't have race conditions" isn't exactly easy. You want as many static guarantees as possible. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Learning about Programming Languages (specifically Haskell)
Alright, here's my attempt to add comments, although once again it seems
like the choice of algorithm in this example is a little wierd. By checking
the output I was able to determine that it results in True for values of
n*n-1, but why exactly that is I can't really figure out at the moment. If I
actually sat down with a sheet of paper and walked through the recursion I
might be able to make sense out of it.
--- Begin Code ---
{- This function takes an Int, and passes it to doh twice returning the
result. -}
doorOpen :: Int -> Bool
doorOpen door = doh door door
{- This function takes two Ints, returning True when the second Int is 0. If
the second Int isn't 0, it checks to see if the first Int modulus the second
Int plus one, is equal to the second Int. This condition will only be true
when the first number has the following relationship to the second one:
n*i+i. E. G. given 10 as the second number, this would be true for 10, 21,
32, 43, etc. If the condition is true it calls itself recursively while
decrementing the second Int by one, and inverting the return value. If the
condition is false it calls itself recursively while decrementing the second
Int by one, and returns the result unmodified. -}
doh :: Int -> Int -> Bool
doh door 0 = True
doh door pass =
if (door `rem` (pass+1)) == pass
then not (doh door (pass-1))
else doh door (pass-1)
{- This produces an infinite list created by calling doorOpen with the
numbers 0 to infinity -}
doors :: [Bool]
doors = [doorOpen n | n <- [0..]]
{- Utility function to print a tuple with some explanation text. Note that
this is inside the IO monad and therefore impure. -}
printDoor :: (Int,Bool) -> IO ()
printDoor (door,open) =
putStrLn ("Door #" ++ (show door) ++ " is " ++
if open then "open." else "closed.")
{- Given an Int this prints the first n elements from the doors list. This
works because zip only produces a list as long as the shortest of its two
arguments. mapM_ is a varient of map that functions on monads and that
discards its result. Ordinarily this would be pointless and might as well be
a no-op, but because printDoor executes inside the IO monad it can have side
effects from executing, and therefore must be evaluated every time. -}
printUpTo :: Int -> IO ()
printUpTo n =
mapM_ printDoor (zip [0..(n-1)] doors)
{- The main entry point to the program, calls printUpTo with 100 -}
main :: IO ()
main = printUpTo 100
--- End Code ---
-R. Kyle Murphy
--
Curiosity was framed, Ignorance killed the cat.
On Mon, May 3, 2010 at 13:15, Samuel Williams <
space.ship.travel...@gmail.com> wrote:
> Dear Kyle,
>
> I've recevied the following program. You did a fantastic job of explaining
> the other one, but as you said it wasn't a great approach, if you have a
> moment could you explain this one?
>
> doorOpen :: Int -> Bool
> doorOpen door = doh door door
>
> doh :: Int -> Int -> Bool
> doh door 0 = True
> doh door pass =
>if (door `rem` (pass+1)) == pass
>then not (doh door (pass-1))
>else doh door (pass-1)
>
> doors :: [Bool]
> doors = [doorOpen n | n <- [0..]]
>
> printDoor :: (Int,Bool) -> IO ()
> printDoor (door,open) =
>putStrLn ("Door #" ++ (show door) ++ " is " ++
>if open then "open." else "closed.")
>
> printUpTo :: Int -> IO ()
> printUpTo n =
>mapM_ printDoor (zip [0..(n-1)] doors)
>
> printUpTo 100
>
> Kind regards,
> Samuel
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interest in a Mathematics & AI strike force ?
I'd be quite interested in this sort of project . Please keep me in the loop, -Carter On Mon, May 3, 2010 at 11:06 PM, Alp Mestanogullari wrote: > Ok guys, Ivan takes care of graphs =) > > Note that it's more about computational mathematics, for things one would > do for example with Mathematica or similar softwares. > > Maybe interested people could come and discuss that on IRC, as a beginning, > on a #haskell-math channel for example ? > > On Tue, May 4, 2010 at 4:17 AM, Ivan Miljenovic > wrote: > >> On 4 May 2010 11:59, Alp Mestanogullari wrote: >> > I found that idea to be great but did not see any actual effort around >> this. >> > So, I'm now thinking again about that and even enlarging it to >> mathematics & >> > AI. Thus, I would like to have an idea of the number of people >> interested in >> > being involved in such an effort. There are several tools out there on >> > hackage but they aren't that much uniform and neither play nicely >> together. >> > I'm pretty convinced this could be improved and as a Mathematics student >> I'm >> > highly interested in that. If enough people are interested, we could for >> > example set up a mailing list and a trac to organize the effort and then >> > people could just discuss and write Haskell modules when time permits. >> > Any comment, idea, reaction, interest ? >> >> Well, Dons seems to think I'm a one-man graph strikeforce :p >> http://www.mail-archive.com/haskell-cafe@haskell.org/msg74763.html >> >> -- >> Ivan Lazar Miljenovic >> ivan.miljeno...@gmail.com >> IvanMiljenovic.wordpress.com >> > > > > -- > Alp Mestanogullari > http://alpmestan.wordpress.com/ > http://alp.developpez.com/ > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell and scripting
2010/5/4 Limestraël : > ... > > Minh, Kyle, Gwern, the dyre approach seems to be very interesting too. > But if I understood well, we also have to recompile at run-time the > configuration haskell script? > So the final application (Yi, for instance) will need GHC to be installed to > run? Or did I miss something? > By the way, I had never heard of Yi, but can I deduce from its name its a > Vi(m)-like (which I am a big fan of)? Moreover, the idea of scripting my > editor in Haskell appeals me. Yes GHC is needed. But if your goal is to produce something with the benefits of a complete language for configuration, I think it's fine. Numerous games include for instance a complete Lua interpreter, SketchUp includes a ruby interpreter (or maybe it is python), Blender uses python, Common Lisp programs can use Common Lisp, and so on. A complete language needs a complete implementation. If you want to make your own (non-embedded) DSL, you will either provide less than a "complete" language or have to implement a lot of stuff. Cheers, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
