Re: [Haskell] Announcing Djinn, version 2004-12-11, a coding wizard
Djinn takes a type, what you have written does not appear to be a type. -- Lennart On Thu, Apr 7, 2011 at 3:35 PM, Martin wrote: > > After reading this post, i can only see a -> b > > how to define more specific such as > > flow 0 y = y > flow z flow x, y = flow z+x, y > > could you demonstrate using djinn to do above mapping definition > to generate a function? > > > > ___ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Marketing Haskell
Koalas are slow and lazy animals. I think the choice is highly appropriate. -- Lennart On Wed, Apr 1, 2009 at 8:22 AM, Colin Paul Adams wrote: >> "Simon" == Simon Peyton-Jones writes: > > Simon> So I hereby declare the official Haskell mascot to be the > Simon> koala, in the form of the image attached below. > > Could you please explain the logic that caused you to choose a koala? > > I have hitherto been unaware of any connection between this creature > and the entity concerned. > > I would have thought a fish be more appropriate (at least across the channel). > -- > Colin Adams > Preston Lancashire > ___ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: [Haskell-cafe] ANN: cmonad 0.1.1
Well, yes and no. GHC actually does a decent job when given very imperative code with references and mutable arrays. Now the type I use to wrap the references to get type safe l-values and r-values makes it tricker, and ghc lacks a crucial optimization for specialization of constructor returns. With that in place I think the code could be quite performant. -- Lennart On Sun, Mar 29, 2009 at 3:13 PM, Jason Dusek wrote: > 2009/03/29 Lennart Augustsson : >> ...GHC lacks certain optimizations to make efficient code when >> using CMonad, so instead of C speed you get low speed. > > Is this surprising to anyone? > > -- > Jason Dusek > ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANN: cmonad 0.1.1
I've uploaded my CMonad package to Hackage. It allows you to write
Haskell code in a C style.
Unfortunately, GHC lacks certain optimizations to make efficient code
when using CMonad,
so instead of C speed you get low speed.
Example: Computing some Fibonacci numbers:
fib = do {
a <- arrayU[40];
i <- auto 0;
a[0] =: 1;
a[1] =: 1;
for (i =: 2, (i :: EIO Int) < 40, i += 1) $ do {
a[i] =: a[i-1] + a[i-2];
};
retrn (a[39]);
}
Example: Copying stdin to stdout:
cat = do {
c <- auto 0;
while ((c =: getchar()) >= 0) $ do {
putchar(c);
};
return ();
}
-- Lennart
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: [Haskell-cafe] Haskell Weekly News: Issue 111 - March 28, 2009
The quote has been around since at least the early 80s, but I don't know who it's from. 2009/3/28 Krzysztof Skrzętnicki : > This paper from 1994: > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.36.5611 > begins point 1.1 with exactly that sentence. It doesn't seem to be > quoted there, so one can assume this is the original source of that > sentence. I'm not sure dough. > > Regards > > Christopher Skrzętnicki > > 2009/3/28 Conal Elliott : >>> conal: Recursion is the goto of functional programming >> >> BTW, I certainly did not mean to take credit for this wonderful quote. I >> don't know the origin. I first heard it from Erik Meijer. >> >> - Conal >> >> >> ___ >> Haskell-Cafe mailing list >> haskell-c...@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > ___ > Haskell-Cafe mailing list > haskell-c...@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Lazy IO breaks purity
I don't see any breaking of referential transparence in your code.
Every time you do an IO operation the result is basically
non-deterministic since you are talking to the outside world.
You're assuming the IO has some kind of semantics that Haskell makes
no promises about.
I'm not saying that this isn't a problem, because it is.
But it doesn't break referential transparency, it just makes the
semantics of IO even more complicated.
(I don't have a formal proof that unsafeInterleaveIO cannot break RT,
but I've not seen an example where it does yet.)
-- Lennart
On Thu, Mar 5, 2009 at 2:12 AM, wrote:
>
>
> We demonstrate how lazy IO breaks referential transparency. A pure
> function of the type Int->Int->Int gives different integers depending
> on the order of evaluation of its arguments. Our Haskell98 code uses
> nothing but the standard input. We conclude that extolling the purity
> of Haskell and advertising lazy IO is inconsistent.
>
> Henning Thielemann wrote on Haskell-Cafe:
>> Say I have a chain of functions: read a file, ... write that to a file,
>> all of these functions are written in a lazy way, which is currently
>> considered good style
>
> Lazy IO should not be considered good style. One of the common
> definitions of purity is that pure expressions should evaluate to the
> same results regardless of evaluation order, or that equals can be
> substituted for equals. If an expression of the type Int evaluates to
> 1, we should be able to replace every occurrence of the expression with
> 1 without changing the results and other observables.
>
> The expression (read s) where s is the result of the (hGetContents h1)
> action has the pure type, e.g., Int. Yet its evaluation does more than
> just producing an integer: it may also close a file associated with
> the handle h1. Closing the file has an observable effect: the file
> descriptor, which is a scarce resource, is freed. Some OS lock the
> open file, or prevent operations such as renaming and deletion on the
> open file. A file system whose file is open cannot be
> unmounted. Suppose I use an Haskell application such as an editor to
> process data from a removable drive. I mount the drive, tell the
> application the file name. The (still running) application finished
> with the file and displayed the result. And yet I can't unplug the
> removable drive, because it turns out that the final result was
> produced without needing to read all the data from the file, and the
> file remains unclosed.
>
> Some people say: the programmer should have used seq. That is the
> admission of guilt! An expression (read s)::Int that evaluates to 1 is
> equal to 1. So, one should be able substitute (read s) with 1. If the
> result of evaluating 1 turns out not needed for the final outcome,
> then not evaluating (read s) should not affect the outcome. And yet it
> does. One uses seq to force evaluation of an expression even if the
> result may be unused. Thus the expression of a pure type
> has *side-effect*.
>
> The advice about using seq reminds me of advice given to C programmers
> that they should not free a malloc'ed pointer twice, dereference a
> zero pointer and write past the boundary of an array. If lazy IO is
> considered good style given the proper use of seq, then C should be
> considered safe given the proper use of pointers and arrays.
>
> Side affects like closing a file are observable in the external
> world. A program may observe these effects, in an IO monad. One can
> argue there are no guarantees at all about what happens in the IO
> monad. Can side-effects of lazy IO be observable in _pure_ Haskell
> code, in functions with pure type? Yes, they can. The examples are
> depressingly easy to write, once one realizes that reading does have
> side effects, POSIX provides for file descriptor aliasing, and sharing
> becomes observable with side effects. Here is a simple Haskell98 code.
>
>
>> {- Haskell98! -}
>>
>> module Main where
>>
>> import System.IO
>> import System.Posix.IO (fdToHandle, stdInput)
>>
>> -- f1 and f2 are both pure functions, with the pure type.
>> -- Both compute the result of the subtraction e1 - e2.
>> -- The only difference between them is the sequence of
>> -- evaluating their arguments, e1 `seq` e2 vs. e2 `seq` e1
>> -- For really pure functions, that difference should not be observable
>>
>> f1, f2:: Int -> Int -> Int
>>
>> f1 e1 e2 = e1 `seq` e2 `seq` e1 - e2
>> f2 e1 e2 = e2 `seq` e1 `seq` e1 - e2
>>
>> read_int s = read . head . words $ s
>>
>> main = do
>> let h1 = stdin
>> h2 <- fdToHandle stdInput
>> s1 <- hGetContents h1
>> s2 <- hGetContents h2
>> print $ f1 (read_int s1) (read_int s2)
>> -- print $ f2 (read_int s1) (read_int s2)
>
>
> One can compile it with GHC (I used 6.8.2, with and without -O2) and
> run like this
> ~> /tmp/a.out
> 1
> 2
> -1
> That is, we run the program and type 1 and 2 as the inputs. The
> program prints out the result, -1. If we co
[Haskell] Re: [Haskell-cafe] Gtk2HS 0.10.0 Released
Does this version work from ghci? -- Lennart On Wed, Feb 11, 2009 at 5:40 AM, Peter Gavin wrote: > Hi everyone, > > Oh, dear... it seems I've forgotten how to spell "cafe", and sent this > message to haskell-c...@haskell.org the first time around. I resent it to > all the lists again (just to make sure everyone interested receives it), so > I apologize for any duplicated messages you might have received. In any > case... > > I'd like to release the announcement of Gtk2HS 0.10.0. A lot of new stuff > has gone into this release, including: > > - Support for GHC 6.10 > - Bindings to GIO and GtkSourceView-2.0 > - Full switch to the new model-view implementation using a Haskell model > - Support for many more model-based widgets such as IconView and an updated > binding for ComboBox > - Full Drag-and-Drop support > - Better support for Attributes in Pango > - Replaced Event for EventM monad, thereby improving efficiency and > convenience > - Functions for interaction between Cairo and Pixbuf drawing > - Lots of bug fixes, code cleanups, and portability improvements > > With this release, the bindings to GnomeVFS and GtkSourceView-1.0 have been > deprecated. The TreeList modules have been deprecated from the Gtk+ > bindings. > > Source and Win32 binaries are available at: > > > https://sourceforge.net/project/showfiles.php?group_id=49207package_id=42440&release_id=659598 > > Thanks to everyone who submitted bug fixes and features this time around! > > Thanks, > Peter Gavin > Gtk2HS Release Manager > > ___ > Haskell-Cafe mailing list > haskell-c...@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] type inference & instance extensions
A loop without turning on a flag to allow it must be a bug.
-- Lennart
On Mon, Jan 19, 2009 at 2:04 PM, Sittampalam, Ganesh
wrote:
> Doug McIlroy wrote:
>> A fragment of an attempt to make pairs serve as complex numbers,
>> using ghc/hugs extensions:
>>
>> instance Num a => Num (a,a) where
>> (x,y) * (u,v) = (x*u-y*v, x*v+y*u)
>>
>> Unfortunately, type inference isn't strong enough to cope with
>>
>> (1,1)*(1,1)
>>
>> Why shouldn't it be strengthened to do so?
>
> The problem is that type classes are an "open" system. Although
> it's obvious that your instance is the only one in this code
> that can be used to type-check (1,1), that doesn't preclude new
> code adding an instance that could make it behave differently.
>
> I had hoped that the code below (GHC 6.10+) would work, but it
> just sends GHC into a loop when you actually try to typecheck
> (1,1). I don't know if that's a bug in GHC or a misunderstanding
> on my part of how the typechecking should work.
>
> {-# LANGUAGE FlexibleInstances, TypeFamilies #-}
>
> instance (a~b, Num a) => Num (a, b) where
> fromInteger k = (fromInteger k, fromInteger 0)
> (x,y) * (u,v) = (x*u-y*v, x*v+y*u)
>
> Ganesh
>
> ==
> Please access the attached hyperlink for an important electronic
> communications disclaimer:
>
> http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
> ==
>
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANN: llvm-0.4.0.1
We have now released version 0.4.0.1 of the Haskell LLVM bindings.
(This release that is quite incompatible with the old 0.0.2 release.)
LLVM is a virtual machine and the bindings allow you to generate code
for this virtual machine. This code can then be executed by a JIT
or written to a file for further processing by the LLVM tools.
The LLVM bindings has two layers. You can either use the low level
bindings that is just the same as the C bindings for the LLVM. This
level is quite unsafe as there is very little type checking.
The recommended way is a high level binding (somewhat less complete)
which eliminates many errors by leveraging the Haskell type system.
A simple example, generating code for a function that adds two
numbers and then calling it from Haskell:
import Data.Int
import LLVM.Core
import LLVM.ExecutionEngine
cgplus :: CodeGenModule (Function (Int32 -> Int32 -> IO Int32))
cgplus =
createFunction InternalLinkage $ \ x y -> do
r <- add x y
ret r
main = do
ioplus <- simpleFunction cgplus
let plus = unsafePurify ioplus
print $ plus 20 22
Enjoy!
Bryan O'Sullivan
Lennart Augustsson
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANN: HLint 1.0
Another parse error: newtype CodeGenModule a = CGM (StateT CGMState IO a) deriving (Monad, MonadState CGMState, MonadIO) On Sat, Dec 20, 2008 at 9:55 AM, Neil Mitchell wrote: > Hi, > > I am pleased to announce HLint, a tool for making suggestions to > improve your Haskell code. Previously this tool was called Dr Haskell > and depended on a working installation of Yhc - both of those have now > changed. HLint requires GHC 6.10*, and to install simply type: > > cabal update && cabal install hlint > > If you haven't yet installed the cabal command, instructions are here: > http://ghcmutterings.wordpress.com/2008/11/10/bootstrapping-cabal-install/ > > As an example of what HLint does, running "hlint darcs-2.1.2" over the > latest stable release of darcs gives 385 suggestions, including: > > darcs-2.1.2\src\CommandLine.lhs:46:1: Use a string literal > Found: > [' ', '\t', '"', '%'] > Why not: > " \t\"%" > > darcs-2.1.2\src\CommandLine.lhs:49:1: Eta reduce > Found: > quotedArg ftable >= between (char '"') (char '"') $ quoteContent ftable > Why not: > quotedArg = between (char '"') (char '"') . quoteContent > > darcs-2.1.2\src\CommandLine.lhs:94:1: Use concatMap > Found: > concat $ map escapeC s > Why not: > concatMap escapeC s > > To see all the hints in a nice interactive document visit > http://www-users.cs.york.ac.uk/~ndm/hlint/hlint-report.htm > (recommended if you are thinking of trying out hlint) > > All necessary links, including a manual, hackage links, bug tracker > and source code can be found from the tool website: > http://www-users.cs.york.ac.uk/~ndm/hlint/ > > Acknowledgements: Niklas Broberg and the haskell-src-exts package have > both been very helpful. The darcs users mailing list gave many good > suggestions which I've incorportated. > > Please direct any follow up conversations to haskell-cafe@ > > Thanks > > Neil > > * Why GHC 6.10? View patterns. > ___ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANN: HLint 1.0
It would be nice if HLint didn't suggest things that it will object to in the next round. Like LLVM/Core/CodeGen.hs:176:1: Eta reduce Found: applyArgs f g = apArgs 0 f g Why not: applyArgs f = apArgs 0 f BTW, great tool! -- Lennart ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANN: typehash version 1.3
The typehash library allows you to produce a unique identifier (a cryptographic hash) for a type. This is useful if you save values of some type to a file (text, binary, whatever format you wish) and then when you read it back in again you want to verify that the type you want to read is the one you actually wrote. The type hash takes into account both the actual name of the type and the structure of the type. The type hash is a compact value that only allows comparing for equality. The library also supports type codes. A type code encodes the complete structure of a type and can be used for finer comparison than just equality, e.g., will the read function be able to read what show produced (in this case renaming types and adding constructors is allowed). The library is on hackage, of course. -- Lennart ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] IVars
Before we can talk about what right and wrong we need to know what the semantics of IVars should be. On Dec 8, 2007 7:12 PM, Marc A. Ziegert <[EMAIL PROTECTED]> wrote: > many many answers, many guesses... > let's compare these semantics: > > readIVar :: IVar a -> IO a > readIVar' :: IVar a -> a > readIVar' = unsafePerformIO . readIVar > > so, we do not need readIVar'. it could be a nice addition to the > libraries, maybe as "unsafeReadIVar" or "unsafeReadMVar". > but the other way: > > readIVar v = return $ readIVar' v > > does not work. with this definition, readIVar itself does not block > anymore. it's like hGetContents. > and... > > readIVar v = return $! readIVar' v > > evaluates too much: > it wont work if the stored value evaluates to 1) undefined or 2) _|_. > it may even cause a 3) deadlock: > > do > writeIVar v (readIVar' w) > x<-readIVar v > writeIVar w "cat" > return x :: IO String > > readIVar should only return the 'reference'(internal pointer) to the read > object without evaluating it. in other words: > readIVar should wait to receive but not look into the received "box"; it > may contain a nasty undead werecat of some type. (Schrödinger's Law.) > > - marc > > > > > > Am Freitag, 7. Dezember 2007 schrieb Paul Johnson: > > Conal Elliott wrote: > > > Oh. Simple enough. Thanks. > > > > > > Another question: why the IO in readIVar :: IVar a -> IO a, instead > > > of just readIVar :: IVar a -> a? After all, won't readIVar iv yield > > > the same result (eventually) every time it's called? > > Because it won't necessarily yield the same result the next time you run > > it. This is the same reason the stuff in System.Environment returns > > values in IO. > > > > Paul. > > ___ > > Haskell mailing list > > Haskell@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell > > > > > > ___ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > > ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] IVars
That argument doesn't totally fly since non-termination isn't considered an effect in Haskell. Bottom doesn't commute with a IO operations normally either. But not having readIVar return 'IO a' does make me a little quesy. :) -- Lennart On Dec 4, 2007 8:25 AM, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote: > But since the read may block, it matters **when** you perform it. For > example if you print "Hello" and then read the IVar, you'll block after > printing; but if you read the IVar and then print, the print won't come > out. If the operation was pure (no IO) then you'd have a lot less control > over when it happened. > > > > Simon > > > > *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On > Behalf Of *Lennart Augustsson > *Sent:* 04 December 2007 08:19 > *To:* Conal Elliott > *Cc:* haskell@haskell.org > *Subject:* Re: [Haskell] IVars > > > > Good question. That must be a matter of taste, because as you say the > read will always produce the same result. But it sill is a bit of a strange > operation. > > -- Lennart > > On Dec 4, 2007 6:25 AM, Conal Elliott < [EMAIL PROTECTED]> wrote: > > Oh. Simple enough. Thanks. > > Another question: why the IO in readIVar :: IVar a -> IO a, instead of > just readIVar :: IVar a -> a? After all, won't readIVar iv yield the same > result (eventually) every time it's called? > > > > On Dec 3, 2007 12:29 AM, Lennart Augustsson <[EMAIL PROTECTED]> > wrote: > > You can make them from MVars. > > On Dec 2, 2007 8:03 PM, Conal Elliott <[EMAIL PROTECTED]> wrote: > > what became of (assign-once) IVars? afaict, they were in concurrent > haskell and now aren't. > > ___ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > > > > > > > ___ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > > > > ___ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > > ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] IVars
Good question. That must be a matter of taste, because as you say the read will always produce the same result. But it sill is a bit of a strange operation. -- Lennart On Dec 4, 2007 6:25 AM, Conal Elliott <[EMAIL PROTECTED]> wrote: > Oh. Simple enough. Thanks. > > Another question: why the IO in readIVar :: IVar a -> IO a, instead of > just readIVar :: IVar a -> a? After all, won't readIVar iv yield the same > result (eventually) every time it's called? > > > On Dec 3, 2007 12:29 AM, Lennart Augustsson <[EMAIL PROTECTED]> > wrote: > > > You can make them from MVars. > > > > On Dec 2, 2007 8:03 PM, Conal Elliott <[EMAIL PROTECTED]> wrote: > > > > > what became of (assign-once) IVars? afaict, they were in concurrent > > > haskell and now aren't. > > > > > > ___ > > > Haskell mailing list > > > Haskell@haskell.org > > > http://www.haskell.org/mailman/listinfo/haskell > > > > > > > > > > ___ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > > ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] IVars
You can make them from MVars. On Dec 2, 2007 8:03 PM, Conal Elliott <[EMAIL PROTECTED]> wrote: > what became of (assign-once) IVars? afaict, they were in concurrent > haskell and now aren't. > > ___ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > > ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Bang patterns and declaration order
I totally agree with Derek. Which exception you get can vary with compiler version, compiler flags, time of day, phase of the moon, ... It will be one in a set of exceptions, but you don't know which one. -- Lennart On Nov 18, 2007 8:34 PM, Derek Elkins <[EMAIL PROTECTED]> wrote: > On Sun, 2007-11-18 at 12:11 -0800, Iavor Diatchki wrote: > > Hello, > > > > I was playing around with "bang patterns" and I noticed that > > when combined with asynchronous exceptions they can lead to > > programs where the order of the declarations in a binding > > group is important! Here is an example: > > > > > import Control.Exception > > > import Prelude hiding (catch) > > > > > > main = putStrLn =<< eval_order > > > > > > test = "no exception" > > > where !_ = error "top down" > > > !_ = error "bottom up" > > > > > > eval_order = evaluate test `catch` \e -> > > >case e of > > > ErrorCall txt -> return txt > > > _ -> throw e > > > > Of course, this is a contrived exampled but, as far as I know, > > this was not possible in Haskell before (if anyone has an example > > to the contrary please send it to the list). > > > > By the way, with GHC 6.8.1 the above program prints "bottom up". > > This means that when there are multiple "banged" bindings they > > are evaluated starting with the last one in the text. I imagine > > than in most programs this is not particularly important, but > > it seems to me that it would be a bit nicer if we were to adjust > > the translation so that bindings were evaluated top to bottom > > (e.g., like in ML). > > The whole point of the "imprecise exceptions" paper was that any > exception may be returned when multiple ones could be. There is no > reason why the bindings should be evaluated top-down. If you are > relying on the order the bindings are evaluated you are doing something > very, very wrong. Should we also specify what exception should be > thrown for error "left-right" + error "right-left" ? > > ___ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] boilerplate boilerplate
Oh, so you want the original behaviour of type declarations back. :)
In Haskell 1.0, if you didn't specify any deriving, you got as much
derived as possible. I quite liked it, but it was changed.
-- Lennart
On Tue, 22 May 2007, Alex Jacobson wrote:
Date: Tue, 22 May 2007 19:07:26 -0400
From: Alex Jacobson <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [Haskell] boilerplate boilerplate
Consider this module for a blog entry that I will want to put in various
generic collections that require Ord
{-# OPTIONS -fglasgow-exts #-}
module Blog.Types where
import Data.Typeable
import Data.Generics
data BlogEntry = Entry EpochSeconds Name Email Title Body
deriving (Eq,Ord,Read,Show,Typeable)
newtype Name = Name String deriving (Eq,Ord,Read,Show,Typeable)
newtype Title = Title String deriving (Eq,Ord,Read,Show,Typeable)
newtype Body = Body String deriving (Eq,Ord,Read,Show,Typeable)
It seems really unnecessarily verbose. Having to add the OPTION header AND
import Data.Typeable and Data.Generics just to derive Typeable is a
beat-down. It is even more of a beat-down to have to add a deriving clause
for every newtype to make this all work nicely. Is there a way to make all
types automatically derive everything unless there is an explicit instance
declaration otherwise?
{-# OPTIONS -fglasgow-exts -fgenerics -fderiving#-}
module Blog.Types where
data BlogEntry = Entry EpochSeconds Name Email Title Body
newtype Name = Name String newtype Title = Title String newtype Body =
Body String
Isn't that much nicer?
-Alex-
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
-- Lennart
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Haskell job
Hi all, Credit Suisse has started using Haskell within GMAG, the group that provides financial analytics for the bank. The main use of Haskell is for a Domain Specific Embedded Language that is being used by the people writing the financial analytics (these people typically have a PhD in mathematics or physics). We are looking to extend our Haskell group (which currently is me and Ganesh Sittampalam), so if you're an experienced Haskell person take the chance! Here's a URL to the Credit Suisse job ad: https://creditsuisse.taleo.net/servlets/CareerSection? art_ip_action=FlowDispatcher&flowTypeNo=13&pageSeq=2&reqNo=53820&art_ser vlet_language=en&selected_language=en&csNo=10020#topOfCsPage If you have any questions email Howard Mansell, [EMAIL PROTECTED] suisse.com, or me. -- Lennart ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] haskell communities worthy of academic study?
Excellent! It's good too see that the GHC complexities will be appreciated by someone. Yet Dr Tuldoso has much left to discover. Like the near hopeless task of trying to keep a local GHC version with a few patches up to date with darcs without getting totally entangled in conflicts, access to non-existing files, internal errors etc. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Num is such a fat and greedy class
On Dec 11, 2006, at 03:50 , Johannes Waldmann wrote: let data Bar = ... in ... If you allow this you need to be very careful about type equality. When is Bar equal to Bar? If it's inside a recursive function, does each invocation get its own Bar? (In SML the answer is yes.) If you decide the answer is no, then is the beta rule still valid? E.g., let x = (let Bar = ... in ...) in ... x ... x ... expand x (which has always been semantically valid in Haskell) ... (let Bar = ... in ...) ... (let Bar = ... in ...) ... Are those two Bar types equal? In Cayenne I allowed all these things, but the price is that Cayenne has structural equality on types rather than nominal. Switching to nominal to structural would be a major change in Haskell. So this change may look innocuous, but it has big ramifications. -- Lennart ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Num is such a fat and greedy class
Oh, come on. It's not that bad. Just start every module with import Prelude() import MyPrelude that's what I do. There's nothing sacred about the Prelude (except a few things used for special syntax). It just happens to be in scope. -- Lennart On Dec 8, 2006, at 15:04 , Dan Weston wrote: The following observations are not new, insightful, or gracious, but I was lusting after the innocent +,-,* operators for my own evil ends and was mildly curious why... Num is such a fat and greedy class. If you want to marry Cinderella, you have to take her ugly stepsisters too. 1) Groups may only want to define addition. Why can't they use + (instead of <+>, >?&**+>, or other such perversion)? 2) Affine spaces have a (-) but no (+). Worse, the signature might be (-) :: Point -> Point -> Vector, which doesn't unify with (a -> a - > a). Wouldn't the following be more useful/general? class Subtraction a b | a -> b where (-) :: a -> a -> b Or would this require needless type annotation for the common subset of (a -> a -> a) instances? 3) Quaternions have no signum, unit quaternions have (*), (/) but no (+) or (-), abs would have a different signatures (Quaternion - > Double) which doesn't unify with (a -> a), and fields cannot be scaled with (*) as in (*) :: (Field f) => Double -> f -> f Would it not make sense to put each of these operators (division too) into their own individual superclasses that Num inherits? My (obviously naive) philosophy about type classes is that operations should be bundled only when they are mutually recursive (i.e. there is more than one useful minimal definition). If there is just one minimal set of operations, they can be in their own parent class too. Then again, I should get over my lust and stick with my own operators <+>, <-->, and <***>. Not too pretty, but they have a wonderful personality all their own! Dan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: Visual Haskell prerelease 0.2
That's great! Thanks for the hard work, Krasimir. One question, where can I find the source? I didn't see anything about that on the download page. -- Lennart On Nov 28, 2006, at 02:30 , Krasimir Angelov wrote: Hello Haskellers, I am happy to announce that there is a prerelease version of Visual Haskell on: http://www.haskell.org/visualhaskell This is the first version that is: - available for both VStudio 2003 and VStudio 2005 - distributed with a stable GHC version (6.6) This is still prerelease version but if there aren't any bug reports in the next few days I will just rename it to release. Many thanks to Simon Marlow, Brian Smith, Wayne Vucenic, Jared Updike and Pepe Iborra that helped me with the preparation of this new release. Cheers, Krasimir ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] GADT: call for proper terminology
Well, Kent Petersson and I proposed them as an addition to Haskell in 1994, so they are not that new. :) -- Lennart http://web.cecs.pdx.edu/~sheard/papers/silly.pdf On Oct 11, 2006, at 09:47 , Paul Hudak wrote: Lennart Augustsson wrote: Well, I think the GADT type definition syntax is the syntax data type definitions should have had from the start. Too bad we didn't realize it 15 years ago. -- Lennart I agree! In my experience teaching Haskell, the current syntax is a bit confusing for newbies, and for years I've been telling students, "It really means this: ..." and then I write out a syntax more like GADT's. I also think that if we had adopted this syntax from the beginning, GADT's would have been "discovered" far sooner than now. -Paul ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] GADT: call for proper terminology
On Oct 11, 2006, at 03:58 , Bulat Ziganshin wrote: Hello oleg, Wednesday, October 11, 2006, 6:12:23 AM, you wrote: Annotate the data type using a GADT: data MyData a where MyCon :: MyData a It helps to reduce confusion about the merits of various features and additions to Haskell if we use the term GADT exclusively for truly _generalized_ algebraic data types. imho, the error was inventing new syntax for GADTs instead of just adding type guards to the old one Well, I think the GADT type definition syntax is the syntax data type definitions should have had from the start. Too bad we didn't realize it 15 years ago. -- Lennart ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] How to define Y combinator in Haskell
Well, you can do it with the existing recursion in Haskell let yc f = f (yc f) Or you can encode it with type level recursion and no value recursion by using a recursive data type. -- Lennart On Sep 15, 2006, at 08:11 , Haihua Lin wrote: Hi, Writing yc = \f -> (\x -> f(x x)) (\x -> f(x x)) causes type error. Is there a way to define it in Haskell? Thanks, Haihua ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] The GHC typechecker is Turing-complete
Just a somewhat related fact: A standard Hindley-Milner type checker (deducer) has the same power as a Turing machine with a finite tape. I.e., the same power as a computer, since they have finite memory. :) -- Lennart On Aug 10, 2006, at 22:04 , Robert Dockins wrote: ... ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] (.) . (.)
Why not ask the computer? -- Lennart bamse% ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.4.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base-1.0 ... linking ... done. Prelude> :t (.) . (.) (.) . (.) :: (b -> c) -> (a -> a1 -> b) -> a -> a1 -> c Prelude> Leaving GHCi. bamse% djinn Welcome to Djinn version 2005-12-12. Type :h to get help. Djinn> f ? (b -> c) -> (a -> a1 -> b) -> a -> a1 -> c f :: (b -> c) -> (a -> a1 -> b) -> a -> a1 -> c f x1 x2 x3 x4 = x1 (x2 x3 x4) Djinn> :q Bye. Brian Hulley wrote: Taral wrote: On 5/28/06, Dominic Steinitz <[EMAIL PROTECTED]> wrote: Is this defined in some library? Thanks, Dominic. Don't think so. I use: \a b -> f (g a b) I don't see how (.) . (.) translates into something so simple. Using c for (.) to make things easier to write, I get: (.) . (.) === c c c === \x -> (c c c x) === \x -> (c (c x)) === \x -> (\y z -> c (c x) y z) === \x -> (\y z -> (c x) (y z)) === \x -> (\y z -> (\p q -> c x q p) (y z)) === \x -> (\y z -> (\p q -> x (q p) (y z)) === \x -> (\y z -> (\q -> x (q (y z === \x y z q -> x (q (y z)) Have I made an error somewhere above? Thanks, Brian. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Platform-dependent behaviour with functions on NaN
Yeah, I think it boils down to different representations of NaN on different platform. I guess I forgot to test for NaN when I wrote (the C code for) decodeFloat. It should generate some consistent result. On the other hand, if you have code that possible divides by 0 and don't check for it, well... It would be nice if Haskell allowed you to turn on signalling NaNs. -- Lennart Geisler, Tim (EXT) wrote: In Haskell, the behaviour of functions on floating-point values which are NaN can be platform dependent. On "SunOS sun 5.9 Generic_118558-09 sun4u sparc SUNW,Sun-Blade-1500": Prelude> ceiling (0/0) 359538626972463141629054847463408713596141135051689993197834953606314521560057077521179117265533756343080917907028764928468642653778928365536935093407075033972099821153102564152490980180778657888151737016910267884609166473806445896331617118664246696549595652408289446337476354361838599762500808052368249716736 On Windows: Prelude> ceiling (0/0) -269653970229347386159395778618353710042696546841345985910145121736599013708251444699062715983611304031680170819807090036488184653221624933739271145959211186566651840137298227914453329401869141179179624428127508653257226023513694322210869665811240855745025766026879447359920868907719574457253034494436336205824 Both machines use the binary distributions of GHC 6.4.1. In our production code, this error (which is actually an error in our program) occured inside a quite complex expression which can be simplified to max 0 (ceiling (0/0)). On Windows, we did not recognize the error in the program, because the complex expression just returned 0. On Solaris, the complex expression returned this large number (which represents in the application "the number of CPUs needed in a certain device" ;-) We develop Haskell programs on Windows and run them in production on Sparc with Solaris. It seems that we have to run special regression tests testing for differences between Sparc Solaris and Windows. The Haskell 98 report http://www.haskell.org/onlinereport/basic.html#sect6.4 states: "The results of exceptional conditions (such as overflow or underflow) on the fixed-precision numeric types are undefined; an implementation may choose error (/_|_/, semantically), a truncated value, or a special value such as infinity, indefinite, etc." There has been some discussion six years ago and nearly two years ago: http://blog.gmane.org/gmane.comp.lang.haskell.glasgow.user/month=20040801 Is there a chance to - properly define the behaviour of functions depending on the function properFraction for values like NaN, Infinity, ...? - get an implementation of this in GHC which computes the same results for all platforms? Perhaps the function properFraction could raise an exception in case of isNaN and isInfinity? Other languages are more portable. E.g., for Java, these cases are defined. http://java.sun.com/docs/books/jls/second_edition/html/typesValues.doc.html#9249 states: "All numeric operations with NaN as an operand produce NaN as a result." Tim ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Boxing (Day) Question
Ashley Yakeley wrote: In article <[EMAIL PROTECTED]>, Lennart Augustsson <[EMAIL PROTECTED]> wrote: On the whole it looks like you want type variables with kind #. There are very good implementation reasons for not allowing this. If you had type variables of kind # you could have polymorphic functions over unboxed values. But since the values are unboxed they don't have a uniform representation (e.g., a Double# is probably twice the size of a Float#). So polymorphic functions over unboxed values are not easy to implement. (You can imagine implementations of them, but none of them are pleasent.) Oh, I hadn't thought of that. One solution might be to have a kind for each kind of storage: * for boxed values #4 for 4-byte values #8 for 8-byte values #P for pointers to things that need to be GC'd (or whatever) etc. Do you think this would work? Yes, I think it would work. But I'd think it would be awkward. Now you need to know the size of each unboxed type to make polymorphic functions (and that's not even portable). -- Lennart ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Boxing (Day) Question
Niklas Sorensson wrote: That's what I thought. But I'm still curious when it is used, and why it isn't a suitable solution for unboxed polymorhic functions in most cases. But getting most cases right isn't enough, you have to get all cases right. So if you want to have unboxed polymorphic functions you need to handle the general case. And that's the ugly part. -- Lennart ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Boxing (Day) Question
On the whole it looks like you want type variables with kind #. There are very good implementation reasons for not allowing this. If you had type variables of kind # you could have polymorphic functions over unboxed values. But since the values are unboxed they don't have a uniform representation (e.g., a Double# is probably twice the size of a Float#). So polymorphic functions over unboxed values are not easy to implement. (You can imagine implementations of them, but none of them are pleasent.) -- Lennart Ashley Yakeley wrote: As I understand it, with unboxing switched on (->) actually has this kind: (->) :: ? -> ? -> * Reading the Core specification, GHC has a particular kind of "polykindism" which introduces kind "?", and defines specialisation such that "?" may be replaced by "*" or "#" inside any kind. Accordingly, (->) may be specialised: (->) :: * -> * -> * (->) :: # -> * -> * (->) :: * -> # -> * (->) :: # -> # -> * Examples: module Boxing where import GHC.Exts fooSS :: (->) Int Int fooSS 3 = 5 fooSS _ = 2 fooHS :: (->) Int# Int fooHS 3# = 5 fooHS _ = 2 fooSH :: (->) Int Int# fooSH 3 = 5# fooSH _ = 2# fooHH :: (->) Int# Int# fooHH 3# = 5# fooHH _ = 2# type Fun = (->) fooHH' :: Fun Int# Int# fooHH' 3# = 5# fooHH' _ = 2# Do any other type constructors or symbols have a kind with "?" in it? I like the "kind" approach to unboxed types. It automatically rules out "[Int#]" by kind mismatch, for instance. But I was disappointed I couldn't do this with GHC 6.4.1: data MyC s = MkMyC (s Int# Int) or class C s where c :: s Int# Int (in either case: "Kind error: Expecting kind `k_a19o', but `Int#' has kind `#' In the class declaration for `C'") There's no kind mismatch here, merely a restriction that the kinds of arguments to classes be #-free. I can't do this, either: newtype MyD (u :: #) = MkMyD (u -> Bool) GHC actually complains about parsing the kind signature. Would Bad Things Happen if this restriction were lifted? I don't have a pressing need for it actually, though this might be useful: class Boxed (b :: *) (u :: #) | b -> u, u -> b where box :: u -> b unbox :: b -> u In case you're worried, lifting the restriction would NOT allow uncompilable things such as newtype MyE (u :: #) = MkMyE u ...simply because there's already a straightforward restriction that values in type constructors have types of kind "*". It is merely the notion of "#-freeness" that seems unnecessary. It would, however, allow this: newtype Box (u :: #) = MkBox (() -> u) ...and quite possibly this: newtype Value (x :: ?) = MkValue (() -> x) I believe these can be compiled safely? ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Djinn and the inverse of a typechecker
[EMAIL PROTECTED] wrote: In the following example we will be using a simplified (and perhaps, more elegant) system than the one used in the class. The typechecker uses only conjunctions and disjunctions. The evaluator of the logic system is complete: if there is a solution, the evaluator will always find it in finite time. Is it also terminating? So if there is no solution it will tell you so. -- Lennart ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Cabal support for djinn
Thanks! It's in the next version. I'll also make the license less restrictive. (With no explicit copyright information in the files the default copyright applies, i.e., I have all rights.) -- Lennart Henning Günther wrote: Hi Lennart, I really like djinn and decided to write a quick darcs patch for it so one can use cabal (http://haskell.org/cabal/) for building it. As I couldn't find any license informations, I inserted "AllRightsReserved" as the license field. Feel free to change that! I'd love to see it being released under a GPL or BSD style license, but that's just my opinion. Henning ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Announcing Djinn, new version 2004-12-13
Well, the proof search is terminating (and complete) so it has to stop somewhere. That happens to be result with this particular search strategy. -- Lennart Chung-chieh Shan wrote: Lennart Augustsson <[EMAIL PROTECTED]> wrote in article <[EMAIL PROTECTED]> in gmane.comp.lang.haskell.general: There is a new version of Djinn available, with two notable new features: Haskell data types can be defined and the found functions are sorted (heuristically) to present the best one first. Hello, I wonder why the only Church numerals Djinn found were 0 and 1? Djinn> :set +m Djinn> num ? (a -> a) -> (a -> a) num :: (a -> a) -> a -> a num x1 x2 = x1 x2 -- or num _ x2 = x2 Very cool, in any case. Ken ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Announcing Djinn, new version 2004-12-13
There is a new version of Djinn available, with two notable new features: Haskell data types can be defined and the found functions are sorted (heuristically) to present the best one first. To play with Djinn do a darcs get http://darcs.augustsson.net/Darcs/Djinn or get http://darcs.augustsson.net/Darcs/Djinn/Djinn.tar.gz Then just type make. (You need a Haskell 98 implementation and some libraries.) And then start djinn. `-- Lennart ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Announcing Djinn, version 2004-12-11, a coding wizard
Howdy, y'all! I've written a small program that takes a (Haskell) type and gives you back a function of that type if one exists. It's kind of fun, so I thought I'd share it. It's probably best explained with a sample session. calvin% djinn Welcome to Djinn version 2005-12-11. Type :h to get help. # Djinn is interactive if not given any arguments. # Let's see if it can find the identity function. Djinn> f ? a->a f :: a -> a f x1 = x1 # Yes, that was easy. Let's try some tuple munging. Djinn> sel ? ((a,b),(c,d)) -> (b,c) sel :: ((a, b), (c, d)) -> (b, c) sel ((_, v5), (v6, _)) = (v5, v6) # We can ask for the impossible, but then we get what we # deserve. Djinn> cast ? a->b -- cast cannot be realized. # OK, let's be bold and try some functions that are tricky to write: # return, bind, and callCC in the continuation monad Djinn> type C a = (a -> r) -> r Djinn> returnC ? a -> C a returnC :: a -> C a returnC x1 x2 = x2 x1 Djinn> bindC ? C a -> (a -> C b) -> C b bindC :: C a -> (a -> C b) -> C b bindC x1 x2 x3 = x1 (\ c15 -> x2 c15 (\ c17 -> x3 c17)) Djinn> callCC ? ((a -> C b) -> C a) -> C a callCC :: ((a -> C b) -> C a) -> C a callCC x1 x2 = x1 (\ c15 _ -> x2 c15) (\ c11 -> x2 c11) # Well, poor Djinn has a sweaty brow after deducing the code # for callCC so we had better quit. Djinn> :q Bye. To play with Djinn do a darcs get http://darcs.augustsson.net/Darcs/Djinn or get http://darcs.augustsson.net/Darcs/Djinn/Djinn.tar.gz Then just type make. (You need a Haskell 98 implementation and some libraries.) And then start djinn. For the curious, Djinn uses a decision procedure for intuitionistic propositional calculus due to Roy Dyckhoff. It's a variation of Gentzen's LJ system. This means that (in theory) Djinn will always find a function if one exists, and if one doesn't exist Djinn will terminate telling you so. This is the very first version, so expect bugs. :) Share and enjoy. -- Lennart ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] [ANNOUNCE] yhc - York Haskell Compiler
Simon Peyton-Jones wrote: | I am aware of some experiments with alternative back-ends for ghc, but I | don't know of any work on a ghc back-end generating portable bytecode. | A few years ago some work was done towards a ghc-hugs fusion, but in the | end hugs remained separate and the ghc people developed ghci. Perhaps | ghc and/or hugs developers can comment further? GHCi does indeed generate byte code, but we have never gotten around to trying to dump it into files and reload it. That might be an interesting project -- but it only gives a constant performance factor over loading the source files in the first place, so it's not clear that it's a major win. The major win with having the byte code in a file is that you could have a stand alone byte code interpreter (and runtime system). That would make bootstrapping GHC a much less daunting task. -- Lennart ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] specification of sum
Simon Marlow wrote: On 02 November 2005 00:20, Lennart Augustsson wrote: Furthermore, ghc has a WRONG definition of sum. Surely not... sum is defined by Haskell 98 as: sum = foldl (+) 0 and this is exactly what GHC provides. Furthermore we have specialised strict versions for Int and Integer. Also, we shouldn't be turning overloaded functions into class methods purely for the purposes of providing optimised versions; that's what the SPECIALISE pragma is for. You are absolutly right, sum is defined with foldl. I wonder why my hbc prelude had it defined with foldr? (This should teach me not to look at bit rotted code.) -- Lennart ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] specification of sum
Cale Gibbard wrote: On 01/11/05, Sebastian Sylvan <[EMAIL PROTECTED]> wrote: On 11/1/05, Scherrer, Chad <[EMAIL PROTECTED]> wrote: I was wondering... In my experience, it's worked much better to use sum' = foldl' (+) 0 than the built-in "sum" function, which leaks memory like crazy for large input lists. I'm guessing the built-in definition is sum = foldr (+) 0 But as far as I know, (+) is always strict, so foldl' seems much more natural to me. Is there a case where the build-in definition is preferable? The library definition in ghc actually uses foldl. It's conceivable that you may not want (+) to be non-strict for certain data types. The question then becomes, is there a case where you want _sum_ to be non-strict? I'd argue that the likely answer is no, given that (+) is an operation in an Abelian group and not a monoid. Regardless of whether (+) is strict, when you compute a sum you will always have to consume the entire list. (+) is not an operation in an Abelian group. (+) is a function with type a->a->a for some particular a. Haskell makes no mention about (+) having any other properties. Furthermore, ghc has a WRONG definition of sum. You cannot change a foldr into a foldl, unless the operator is associative, and (+) does not have to be. -- Lennart PS. I think additional properties of class methods would be great, but since Haskell cannot enforce them we should not rely on them. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] strictness of putChar: report incomplete?
Simon Marlow wrote: I agree with you. And that is how it used to be, but then some people didn't think that was convenient enough so now we are stuck with a seq that (IMHO) stinks. :) Having a seq that works on anything is occasionally very useful for fixing space leaks, and the type class version was kind of ugly and unwieldy. The type class pops up when you use ! in a data declaration, which looks strange. But I agree that polymorphic seq does have some painful side effects. Polymorphic seq is not lambda definable, which I dislike. -- Lennart ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] strictness of putChar: report incomplete?
Wolfgang Jeltsch wrote: Am Mittwoch, 5. Oktober 2005 16:22 schrieb Simon Marlow: [...] Also, GHC's optimiser currently treats (_|_ :: IO a) and (do _|_; return ()) as interchangeable, which is naughty, and people have occasionally noticed, but the benefits can sometimes be huge. It is this distinction that makes it hard to optimise IO code in a Haskell compiler, though. I think, seq should be a method of a type class. Then we could forbid applying seq to a function, we could forbid applying seq to an IO expression and we could forbid applying seq to expressions of any type with hidden implementation for which we don't want to provide bottom tests. I agree with you. And that is how it used to be, but then some people didn't think that was convenient enough so now we are stuck with a seq that (IMHO) stinks. :) -- Lennart ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Literal for Infinity
Not all FP representations have infinity, and even if they do, they might only have one infinity. -- Lennart Frederik Eaton wrote: I've previously mentioned that I would like to see an 'instance Bounded Double' etc., as part of the standard, which would use 1/0 for maxBound, or the largest possible value (there must be one!) for platforms where that is not possible. I don't see a problem with looking at Double values as if they were bounded by -infinity and +infinity. On Thu, Sep 29, 2005 at 09:11:25PM +0300, Yitzchak Gale wrote: Hi Jacques, Thanks also to you for a most interesting reply. This same discussion has taken place on the discussion list of every modern general-purpose programming language. The same points are always raised and argued, and the conclusion is always the same: floating point exceptions should raise exceptions. Programs that are so sensitive that the tiny overhead makes a difference should use numeric libraries, unboxed types, FFI, and the like. In Haskell also, it looks like the infrastructure was already laid in the Control.Exception module. I hope we will soon be using it. I personally would like also to see alternative functions that return values in the Error monad. Regards, Yitz On Thu, Sep 29, 2005 at 03:13:27PM +0300, Jacques Carette wrote: The IEEE 754 standard says (fairly clearly) that +1.0 / +0.0 is one of the most 'stable' definitions of Infinity (in Float at least). Throwing an exception is also regarded as a possibility in IEEE 754, but it is expected that that is not the default, as experience shows that that is a sub-optimal default. Mathematical software (Maple, Mathematica, Matlab) have generally moved in that direction. Almost all hardware implementations of float arithmetic now default to IEEE 754 arithmetic. Having the arithmetic do 'something else' involves more CPU cycles, so users should generally complain if their system's arithmetic differs from IEEE 754 arithmetic without some deep reason to do so [there are some; read and understand William Kahan's papers for these]. Jacques ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Literal for Infinity
The RealFloat class has a number of methods for testing various properties of a FP number: isNaN :: a -> Bool isInfinite :: a -> Bool isDenormalized :: a -> Bool isNegativeZero :: a -> Bool isIEEE :: a -> Bool If you really want to create an Infinity, I suggest 1/0, but not all FP formats support it (IEEE754 does). -- Lennart Yitzchak Gale wrote: While checking for floating-point overflow and underflow conditions, I tried to create a somewhat reliable cross-platform Infinity with the literal "1e10". When GHC 6.4.1 reads this literal, it goes into a deep trance and consumes huge amounts of memory. Shouldn't it immediately recognize such a thing as Infinity? Is there a better way to check for Infinity? I have not yet figured out how to check for NaN at all - because it is not equal to itself. Any suggestions? BTW, I notice that Simon PJ proposed literals for Infinity and Nan several years ago: http://www.haskell.org/pipermail/haskell/2001-August/007753.html Did anything ever come out of this? Regards, Yitzchak ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell SOE Question
But who said you should remove the import of word32ToInt? It was only fromIntegral that was discussed. -- Lennart Alex Edelsburg wrote: Thanks for your suggestion. --import Word (fromIntegral) --import Word (word32ToInt) I removed both import statements from the code and tried to run again. This time HUGS generated the following error. ERROR "Animation.hs":57 - Undefined variable "word32ToInt" ~Alex ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] offside rule question
The offside rule is patronizing. :)
It tries to force you to lay out your program in a certain way.
If you like that way, good. If you don't like that way, you can
use {;} as you say.
-- Lennart
Frederik Eaton wrote:
Huh, that seems patronizing. Well at least I can override it with {}.
Thanks,
Frederik
On Thu, Jul 14, 2005 at 02:42:53AM +0200, Lennart Augustsson wrote:
That's how it is defined in the Haskell definition.
But there is a reason. The offside rule (or whatever yoy want to
call it) is there to give visual cues. If you were allowed to override
these easily just because it's parsable in principle then your code
would no longer have these visual cues that make Haskell code fairly
easy to read.
-- Lennart
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] offside rule question
That's how it is defined in the Haskell definition. But there is a reason. The offside rule (or whatever yoy want to call it) is there to give visual cues. If you were allowed to override these easily just because it's parsable in principle then your code would no longer have these visual cues that make Haskell code fairly easy to read. -- Lennart Frederik Eaton wrote: Compiling the following module (with ghc) fails with error message "parse error (possibly incorrect indentation)", pointing to the let statement. The error goes away when I indent the lines marked "--*". But I don't understand how what I've written could be ambiguous. If I am inside a parenthesized expression, then I can't possibly start another let-clause. The fact that the compiler won't acknowledge this fact ends up causing a lot of my code to be squished up against the right margin when it seems like it shouldn't have to be. module Main where main :: IO () main = do let a = (map (\x-> x+1) --* [0..9]) --* print a return () Is there a reason for this behavior or is it just a shortcoming of the compiler? Frederik ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Dynamic binding
Yes, a) is a weakness, but usually I don't find it too restrictive. I agree that extensible data types would be a very interesting addition to Haskell, and I'd like to have it. But the original question was how to do it in Haskell, and when I hear Haskell i think Haskell-98 since it's the only standardized version of Haskell. So I tried to answer the question. I wish Haskell-98 had existentials, but people didn't dare in those days. :) (Even though hbc had it implemented.) -- Lennart Ralf Lammel wrote: Lennart, from a textbook perspective I agree that this solution should be mentioned to make it easy for non-Haskellers to get into the subject. However (as you of course know, but I just don't understand why you don't dare to mention the limitations a) and b) ...) a) Your constructor-based approach is not extensible. (Adding another form of shape requires touching existing code and recompilation.) I reckon that the (normal implied OO) point of the Shapes example, to a considerable extent, is also about the potential addition of new shapes. Saying we can take a snapshot of shape "types" and burn them into constructors of an algebraic type does not give me the impression of Haskell being ahead in type system and programming language arena. b) This "burn subtypes into constructors" leads me to a second weakness. By doing so, we have lost the precision of the original type dichotomy circle vs rectangle vs square since these guys are now all represented as terms of type. Of course, you might say that we could define dedicated types for circle, rectangle and square so that we would use the shape type merely as a *sum* type. (So constructors only serve for embedding.) This way we could at least recover the typing precision of OO. So I am willing to give in on b) but I maintain a) and I really miss extensible datatypes :-) Ralf (doing too much C# these days I guess) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lennart Augustsson Sent: Thursday, June 23, 2005 7:30 AM To: Andrew Ward Cc: haskell@haskell.org Subject: Re: [Haskell] Dynamic binding Andrew Ward wrote: Hi All, In Simon Thompson's The Craft of Functional Programming Second Edition, page 226, it is mentioned that Laufer (1996) describes a Haskell extension to allow dynamic binding. I was wondering if this has been implemented as an extension in any of the haskell compilers, or variants? I am a c++ programmer by trade, only dabbling in Haskell when I was at university, so it seems a disadvantage to me to not have dynamic binding in Haskell 98. What would be the normal way for a Haskell programmer to handle the typical shape example in beginner OO tutorials? Unlike previous posters that have shown various ways to simulate object oriented programming I'm going to try and answer the question. :) Here is what I would do: -- data Shape = Circle Point Radius | Square Point Size draw :: Shape -> Pict draw (Circle p r) = drawCircle p r draw (Square p s) = drawRectangle p s s moveTo :: Shape -> Point -> Shape moveTo (Circle _ r) p = Circle p r moveTo (Square _ s) p = Square p s shapes :: [Shape] shapes = [Circle (0,0) 1, Square (1,1) 2] shapes' :: [Shape] shapes' = map (moveTo (2,2)) shapes -- This is in rather stark contrast to the object oriented way of doing the same things. For reference, here's how you could do it : -- class IsShape shape where draw :: shape -> Pict moveTo :: Point -> shape -> shape data Shape = forall a . (IsShape a) => Shape a data Circle = Circle Point Radius instance IsShape Circle where draw (Circle p r) = drawCircle p r moveTo p (Circle _ r) = Circle p r data Square = Square Point Size instance IsShape Square where draw (Square p s) = drawRectangle p s s moveTo p (Square _ s) = Square p s shapes :: [Shape] shapes = [Shape (Circle (0,0) 10), Shape (Square (1,1) 2)] shapes' :: [Shape] shapes' = map (moveShapeTo (2,2)) shapes where moveShapeTo p (Shape s) = Shape (moveTo p s) -- Both ways of doing it contains the same information, it's just that it's organized in different ways. The "functional way" centers around the type Shape. You can find out all about what shapes exist by looking at the type definition. For each operation on shapes (draw & moveTo) you describe what they do for the different shapes. The object oriented way centers more around the objects (surprise, surprise). For each kind of object you say that it's a shape and how the shape operations work. So, which is better? I don't think you can say one is better than the other. They have different strengths. With the object oriented way it is easy to answer questions like "What is
Re: [Haskell] Dynamic binding
Andrew Ward wrote: Hi All, In Simon Thompson's The Craft of Functional Programming Second Edition, page 226, it is mentioned that Laufer (1996) describes a Haskell extension to allow dynamic binding. I was wondering if this has been implemented as an extension in any of the haskell compilers, or variants? I am a c++ programmer by trade, only dabbling in Haskell when I was at university, so it seems a disadvantage to me to not have dynamic binding in Haskell 98. What would be the normal way for a Haskell programmer to handle the typical shape example in beginner OO tutorials? Unlike previous posters that have shown various ways to simulate object oriented programming I'm going to try and answer the question. :) Here is what I would do: -- data Shape = Circle Point Radius | Square Point Size draw :: Shape -> Pict draw (Circle p r) = drawCircle p r draw (Square p s) = drawRectangle p s s moveTo :: Shape -> Point -> Shape moveTo (Circle _ r) p = Circle p r moveTo (Square _ s) p = Square p s shapes :: [Shape] shapes = [Circle (0,0) 1, Square (1,1) 2] shapes' :: [Shape] shapes' = map (moveTo (2,2)) shapes -- This is in rather stark contrast to the object oriented way of doing the same things. For reference, here's how you could do it : -- class IsShape shape where draw :: shape -> Pict moveTo :: Point -> shape -> shape data Shape = forall a . (IsShape a) => Shape a data Circle = Circle Point Radius instance IsShape Circle where draw (Circle p r) = drawCircle p r moveTo p (Circle _ r) = Circle p r data Square = Square Point Size instance IsShape Square where draw (Square p s) = drawRectangle p s s moveTo p (Square _ s) = Square p s shapes :: [Shape] shapes = [Shape (Circle (0,0) 10), Shape (Square (1,1) 2)] shapes' :: [Shape] shapes' = map (moveShapeTo (2,2)) shapes where moveShapeTo p (Shape s) = Shape (moveTo p s) -- Both ways of doing it contains the same information, it's just that it's organized in different ways. The "functional way" centers around the type Shape. You can find out all about what shapes exist by looking at the type definition. For each operation on shapes (draw & moveTo) you describe what they do for the different shapes. The object oriented way centers more around the objects (surprise, surprise). For each kind of object you say that it's a shape and how the shape operations work. So, which is better? I don't think you can say one is better than the other. They have different strengths. With the object oriented way it is easy to answer questions like "What is a Circle?", whereas with the functional way it is easy to answer "How do you draw a Shape"? Likewise, with the object oriented way it's easier to add a new kind of shape and with the functional way it's easier to add a new operation. To me it's a matter of taste. I like the functional taste; my brain has been warped over many years. -- Lennart ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] instance Bounded Double
I agree with all of that. :) -- Lennart Thomas Davie wrote: I may be barking up the wrong tree here, but I think the key to this discussion is that real numbers are not bounded, while doubles are bounded. One cannot say what the smallest or largest real number are, but one can say what the smallest or largest double are (and it is unfortunately implementation specific, and probably pretty messy to set up). We could define maxBound as (2^(mantisa_space))^(2^(exponent_space)) and min bound pretty similarly... But I'm sure that everyone will agree that this is a horrible hack. One may even question whether Doubles should be bounded, in that they are an attempt to represent real numbers, and as such should come as close as is possible to being real numbers (meaning not having bounds). Sorry for a possibly irrelevant ramble. Bob On Mar 13, 2005, at 11:02 PM, Lennart Augustsson wrote: And what would you have minBound and maxBound be? I guess you could use +/- the maximum value representable. Going for infinity is rather dodgy, and assumes an FP representation that has infinity. -- Lennart Frederik Eaton wrote: Interesting. In that case, I would agree that portability seems like another reason to define a Bounded instance for Double. That way users could call 'maxBound' and 'minBound' rather than 1/0 and -(1/0)... Frederik On Fri, Mar 11, 2005 at 11:10:33AM +0100, Lennart Augustsson wrote: Haskell does not guarantee that 1/0 is well defined, nor that -(1/0) is different from 1/0. While the former is true for IEEE floating point numbers, the latter is only true when using affine infinities. -- Lennart Frederik Eaton wrote: Shouldn't Double, Float, etc. be instances of Bounded? I've declared e.g. instance Bounded Double where minBound = -(1/0) maxBound = 1/0 in a module where I needed it and there doesn't seem to be any issue with the definition... Frederik ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] instance Bounded Double
And what would you have minBound and maxBound be? I guess you could use +/- the maximum value representable. Going for infinity is rather dodgy, and assumes an FP representation that has infinity. -- Lennart Frederik Eaton wrote: Interesting. In that case, I would agree that portability seems like another reason to define a Bounded instance for Double. That way users could call 'maxBound' and 'minBound' rather than 1/0 and -(1/0)... Frederik On Fri, Mar 11, 2005 at 11:10:33AM +0100, Lennart Augustsson wrote: Haskell does not guarantee that 1/0 is well defined, nor that -(1/0) is different from 1/0. While the former is true for IEEE floating point numbers, the latter is only true when using affine infinities. -- Lennart Frederik Eaton wrote: Shouldn't Double, Float, etc. be instances of Bounded? I've declared e.g. instance Bounded Double where minBound = -(1/0) maxBound = 1/0 in a module where I needed it and there doesn't seem to be any issue with the definition... Frederik ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] instance Bounded Double
Haskell does not guarantee that 1/0 is well defined, nor that -(1/0) is different from 1/0. While the former is true for IEEE floating point numbers, the latter is only true when using affine infinities. -- Lennart Frederik Eaton wrote: Shouldn't Double, Float, etc. be instances of Bounded? I've declared e.g. instance Bounded Double where minBound = -(1/0) maxBound = 1/0 in a module where I needed it and there doesn't seem to be any issue with the definition... Frederik ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Typing in haskell and mathematics
Cale Gibbard wrote:
Another common thing which is done whenever convenient is to treat
Cartesian product as associative, and naturally identify the spaces (A
x A) x A and A x (A x A), along with perhaps A^3 which might be
functions f: {0,1,2} -> A,
It's fine to identify (A x A) x A with A x (A x A) in set theory where
they are isomorphic. But in a language like Haskell this is simply not
true. Bottom wreaks havoc with many things. :(
-- Lennart
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Newbie : How come that cyclic recursive lists are efficient ?
It doesn't have to be a top level definition, it works anyway. -- Lennart Bruno Abdon wrote: 'hamming', in your code, is a top-level definition. When used three times inside its own definition, it's the same variable being used three times. You don't recompute a variable value in order to reuse it. As an example, if you do foo :: [Integer] foo = [1,2,3] + [4,5] bar = foo ++ foo ++ foo the concatenation used to produce foo will not be done three times in order to calculate the value of bar. That would be true for any function would foo be defined upon, not only concatenation. Bruno Abdon On Mon, 24 Jan 2005 10:38:35 +0100, Francis Girard <[EMAIL PROTECTED]> wrote: Hi, The classical Hamming problem have the following solution in Haskell : *** BEGIN SNAP -- hamming.hs -- Merges two infinite lists merge :: (Ord a) => [a] -> [a] -> [a] merge (x:xs)(y:ys) | x == y= x : merge xs ys | x < y= x : merge xs (y:ys) | otherwise = y : merge (x:xs) ys -- Lazily produce the hamming sequence hamming :: [Integer] hamming = 1 : merge (map (2*) hamming) (merge (map (3*) hamming) (map (5*) hamming)) *** END SNAP I just love these algorithms that run after their tail (they make my brain melt) but I don't know how is it that they are efficient. Here, the hamming recursively calls itself three times. For this algorithm to be efficient, the Haskell system, somehow, has to "remember" the already generated sequence THROUGH RECURSION (i.e. not only intermediate "local" results) otherwise it would end up regenerating the beginning of the sequence over and over again. Obviously, Haskell does remember what had already been generated THROUGH RECURSION since executing the program with GHCI runs quite smoothly and responsively. That Haskell manages to do that is for me "magnifique". But I need to know (if only a little) about how it achieves this in order to know what I, as a lambda programmer, can do, and how to compute the Big-Oh complexity of the algorithm. Thank you, Francis Girard FRANCE ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: "Never" GADT Function?
Well, this compiles: data T a where BoolT :: T Bool IntT :: T Int neverT' :: T a -> x neverT' BoolT = error "Bool" neverT' IntT = error "Int" neverT :: T Char -> x neverT = neverT' But it uses error for the unreachable cases, maybe not what you want. -- Lennart Ashley Yakeley wrote: In article <[EMAIL PROTECTED]>, Martin Sulzmann <[EMAIL PROTECTED]> wrote: You should be able to even write neverT (BoolT x) = x neverT (IntT x) = False Actually I didn't put in any arguments to my constructors. Apart from that I agree: this should compile, but doesn't: data T a where BoolT :: T Bool IntT :: T Int neverT :: T Char -> x neverT BoolT = "hello" neverT IntT = 37 Pick.hs:11:9: Inaccessible case alternative: Can't match types `Bool' and `Char' When checking the pattern: BoolT In the definition of `neverT': neverT BoolT = "hello" ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Real life examples
But surely any device driver is parametrized on the exact IO addresses? How would you be able to handle multiple devices otherwise? Adrian Hey wrote: On Friday 26 Nov 2004 11:39 am, Keean Schupke wrote: Adrian Hey wrote: Well it can be written in Haskell, but not using a module that was specifically designed to prevent this. Well, It can be written in Haskell as it stands at the moment... No it can't. If I have a device driver that's accessing real hardware (peeking and poking specific memory locations say), how are you going to emulate that? You need to make peek and poke parameters of the module. That is certainly possible, but if the author of the driver module didn't anticipate your emulation needs, you'd be stuck I think. Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Better Exception Handling
Tomasz Zielonka wrote: On Thu, Nov 25, 2004 at 07:52:43PM +0100, Lennart Augustsson wrote: As I'm sure you have gathered from all the answers you can't have the latter and keep Haskell pure. But there is an interesting alternative (at least theoretically). You could have a function like mkCatchJust :: IO ((Exception -> Maybe b) -> (c -> a) -> c -> (b -> a) -> a) How is that different from this? mkReadFile :: IO (FilePath -> String) This is wrong. Even if I get a function as a result of an IO computation, I expect that function to be pure. BTW, I couldn't stop myself. Here's (a simple version of) mkReadFile: mkReadFile :: IO (FilePath -> String) mkReadFile = do names <- traverse "/" files <- mapM readFile names let find name = case lookup name (zip names files) of Just file -> file Nothing -> error "file not found" return find traverse :: FilePath -> IO [FilePath] traverse d = do fs <- getDirectoryContents d let fs' = map ((d ++ "/") ++) (fs \\ [".", ".."]) fss <- mapM traverse fs' return (concat fss) `catch` \ e -> return [d] I don't really recommend it being used. :) -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] A puzzle and an annoying feature
Keean Schupke wrote: Daan Leijen wrote: You are right, I feel like that too: one should expect that the type checker can figure this out, and perhaps it is even really useful. On the other hand, suppose you decide later to export the class, and suddenly your code would no longer type check. I must have missed a mail... how could adding an export change the code? If you export the class you can add another instance to it. And now my type variable would really be ambiguous. -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] A puzzle and an annoying feature
Daan Leijen wrote: You are right, I feel like that too: one should expect that the type checker can figure this out, and perhaps it is even really useful. On the other hand, suppose you decide later to export the class, and suddenly your code would no longer type check. The fact that adding an export defintion would lead to a type error somewhere else in the code might be rather confusing. (worse! it might be considered inelegant :-) Yes, that is somewhat strange, I agree. :) Personally, I feel that this problem might be better solved by making a lot of the implicit assumptions (and semantics) of type classes more explicit, and bring them under user control. Of course, I do have not have any idea of how this should be done concretely ;-) (although type class directives might be a step in the right direction?) Yes, I think the type class directives is a step forwards. :) -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Better Exception Handling
Jules Bean wrote: By the same token, you can just stick the function strangeReadFile :: FilePath -> String into the language. As long as it is memoized, always returning the same value, it doesn't break beta-reduction. I call it 'strange' because the time that the file is actually read is not guaranteed, so if you read more than one file in your program, you have no guarantee that you are reading a constant total state that actually existed at any point in time. (Before you think this sounds unbearably horrible, there is at least one commercially sold RDBMS which has this semantics on its select statements ;P) It is also strange by the fact that strangeReadFile can very well be different functions at different runs of the program. That's why I think such a function should be generated by the IO monad. (If you want it at all!) -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Better Exception Handling
Tomasz Zielonka wrote: On Thu, Nov 25, 2004 at 07:52:43PM +0100, Lennart Augustsson wrote: As I'm sure you have gathered from all the answers you can't have the latter and keep Haskell pure. But there is an interesting alternative (at least theoretically). You could have a function like mkCatchJust :: IO ((Exception -> Maybe b) -> (c -> a) -> c -> (b -> a) -> a) How is that different from this? mkReadFile :: IO (FilePath -> String) This is wrong. Why is this wrong? Even if I get a function as a result of an IO computation, I expect that function to be pure. Yes, so do I. The function returned will have to be pure. Pure in the sense that given the same argument it always has to return the same result. In the case of mkReadFile this is not too hard to implement. I admit that it is rather awkward, but it can be pure. -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Better Exception Handling
John Goerzen wrote: So why do we have: catchJust :: (Exception -> Maybe b) -> IO a -> (b -> IO a) -> IO a instead of: catchJust :: (Exception -> Maybe b) -> (c -> a) -> c -> (b -> a) -> a As I'm sure you have gathered from all the answers you can't have the latter and keep Haskell pure. But there is an interesting alternative (at least theoretically). You could have a function like mkCatchJust :: IO ((Exception -> Maybe b) -> (c -> a) -> c -> (b -> a) -> a) And you would use it by do cj <- mkCatchJust cj The cj function can be used in non-IO code and will behave just as you want. But you have to create it in the IO monad, since it's behaviour is not deterministic (especially not in the face of async exceptions). The tricky thing is to implement it, because cj should really only be used once. Why? Because it has to behave the same way for the same arguments every time. This is not easily implemented. :( -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] A puzzle and an annoying feature
Graham Klyne wrote: I have a concern with this, if I understand the issue correctly. Suppose I have a source module that compiles and runs correctly. Now suppose I add a restricted (selective) import statement to the file, explicitly introducing a name that I know does not clash with anything in my module. I expect the module to continue to compile and run correctly. If I understand Lennart's proposal correctly, adding such an import could cause the compilation to fail, by adding new instance options that then needs to be disambiguated. Not in my particular case. The class is local to the module. Any instance declaration would have to be in that module. -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] A puzzle and an annoying feature
Of course it can. I might do it myself. :) -- Lennart Keean Schupke wrote: I have already asked Simon PJ if this can be implemented in GHC... So if more people ask for it, it might get done! Keean Lennart Augustsson wrote: Here is a small puzzle. -- The following generates a type error: f :: Char -> Char f c = let x = g c in h x -- But this definition does not: f :: Char -> Char f c = let x :: Bool x = g c in h x ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] A puzzle and an annoying feature
Daan Leijen wrote: Keean Schupke wrote: No, closed classes are different, here we are talking about lazy overlap resolution, so if at _call_ time only one instance fits we choose it. Closing a class is different. A "closed class" directive however is an explicit specification that makes the intention of the designer explicit in the program. Since it would solve the puzzle in a rather elegant and explicit way, I thought that it was interesting to mention. Indeed, a closed directive would have been fine. But it's not really necessary, the class is obviously closed because of not being exported. But the type checker doesn't use this fact. I find it somewhat anomalous that there is one unique way to give types to my program, but that the type checker refuses to do it. :) -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Real life examples
No, with exactly the type signatures they have I don't think you can. But the untyped version of them can be implemented. And that is good enough to convince me that the beta rule is still valid. -- Lennart Josef Svenningsson wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marcin 'Qrczak' Kowalczyk Sent: den 25 november 2004 11:49 To: [EMAIL PROTECTED] Subject: Re: [Haskell] Real life examples Lennart Augustsson <[EMAIL PROTECTED]> writes: An "easy" way to prove it is to provide an equivalent implementation that uses only pure functions. As far as I remember Control.Monad.ST can be written purely. And I think the same is true for Data.Dynamic. I think neither of them can. I agree with Marcin. I challenge you (Lennart) to write Control.Monad.ST in Haskell98. I (and many others) have tried and failed. An interesting summary by Koen can be found here: http://www.haskell.org/pipermail/haskell/2001-September/007922.html Cheers, /Josef ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Real life examples
I don't necessarily agree that you can do this trick in all implementations of Dynamic and Typable. You're relying on more things than the interface to Dynamic promises. Your fromDynamic could very well return Nothing. And should! But that doesn't matter. The unsafeCast function doesn't really worry my much. It's unsafePerformIO that worries me. Using unsafe casts just makes us program in the untyped lambda calculus, where the beta rule still holds, so no worries. Whereas unsafePerformIO opens an entirely different can of worms. -- Lennart George Russell wrote: Lennart wrote (snipped): > An "easy" way to > prove it is to provide an equivalent implementation that uses only > pure functions. As far as I remember Control.Monad.ST can be written > purely. And I think the same is true for Data.Dynamic. I don't see how it can be, since you can use Data.Dynamic to provide an unsafe function cast : a -> b newtype UnsafeCast a = UnsafeCast a instance Typeable (UnsafeCast a) where typeOf _ = mkAppTy (mkTyCon "") [] cast :: a -> b cast a = let Just (UnsafeCast b) = fromDynamic (toDyn (UnsafeCast a)) in b ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] A puzzle and an annoying feature
[EMAIL PROTECTED] wrote: G'day all. Quoting Lennart Augustsson <[EMAIL PROTECTED]>: Here is a small puzzle. You can understand this one because the closed world hypothesis doesn't apply to type context inference. I have no problem understanding the technical reason for this. But I now think it's a poor design. -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Real life examples
Ben Rudiak-Gould wrote: Lennart Augustsson wrote: > What do you mean when you say the interface is pure? > > If your module is really pure then there should be an implemenation > of it (which could have really bad complexity) with the same observable > behaviour that uses only pure Haskell. Is this possible? Really? I agree with the converse of that statement, but I don't think it goes both ways. To me a function or module is pure when you can use it without compromising the equational properties of the language. I don't think Data.Dynamic or Control.Monad.ST satisfy your criterion for purity, but I would call them pure (after discarding the functions marked unsafe in the latter). Agreed, there can pure functions that cannot be written with the pure primitives, but then you have a proof obligation. An "easy" way to prove it is to provide an equivalent implementation that uses only pure functions. As far as I remember Control.Monad.ST can be written purely. And I think the same is true for Data.Dynamic. -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Real life examples
Ben Rudiak-Gould wrote: Yes it does. :-) If each Haskell environment ships with a correct implementation of the library, then its interface is the only part that matters. If the unsafePerformIO hack doesn't work in your new Haskell compiler, you can replace it with some other magic that does work. It's fine for the Haskell environment to hide impure magic behind a pure interface -- that's what the language is all about. What do you mean when you say the interface is pure? If your module is really pure then there should be an implemenation of it (which could have really bad complexity) with the same observable behaviour that uses only pure Haskell. Is this possible? If it's not possible I don't understand what you mean by pure. -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] A puzzle and an annoying feature
Here is a small puzzle. -- The following generates a type error: f :: Char -> Char f c = let x = g c in h x -- But this definition does not: f :: Char -> Char f c = let x :: Bool x = g c in h x Furthermore, replacing Bool by any other type in the latter definition will always give a type error. How is this possible? Scroll down for the answer. Here is the module: module Puzzle(f) where f :: Char -> Char f c = let x = g c in h x class C a where g :: Char -> a h :: a -> Char instance C Bool where g c = c == 'T' h b = if b then 'T' else 'F' The error message from ghc is Puzzle.hs:5:12: Ambiguous type variable `a' in the top-level constraint: `C a' arising from use of `g' at Puzzle.hs:5:12 I know the technical reason why this is happening. But it's hard for me to motivate why this is reasonable. The type variable `a' is not ambiguous at all, the only type it can possibly have is Bool; any other type is an error. Furthermore, there can never be any other instance of the class C added to any program using the module Puzzle since the class C is not exported. So in what sense is this really ambiguous? I think it would be quite reasonable to allow the Puzzle module to compile, resolving `a' to be Bool. I.e., if there is only one instance that can satisfy a constraint and there is no possibility of adding instances outside the compiled module, I think resolving the overloading makes sense. -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Real life examples
George Russell wrote: I think their disadvantages are overstated. Glasgow Haskell uses them lots, And I bet the implementors wish they hadn't used them as much. ;) Now we have some weird division of flags into static and dynamic, for instance. Global (top level) variables can be very convenient, but they often come back to bite you. -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Top Level TWI's again was Re: [Haskell] Re: Parameterized Show
Adrian Hey wrote: On Tuesday 23 Nov 2004 9:29 am, Keean Schupke wrote: myDriver :: (Chan in,Chan out) -> State -> IO State myDriver (in,out) state = do -- read commands from in -- process commands -- reply on out myDriver (in,out) new_state How does this solve the problem we're talking about (namely preventing the accidental creation of multiple processes all of which believe they are "the" device driver for a particular unique resource)? So do you agree with me that the protection against two drivers "opening" the same device does not belong in the driver code? (Because if it sits there I could mistakenly have another driver open the same device.) -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Top Level TWI's again was Re: [Haskell] Re: Parameterized Show
Adrian Hey wrote: On Tuesday 23 Nov 2004 9:39 am, Lennart Augustsson wrote: I find it hard to argue these things in the abstract. Could you post us a (simplified) signature for a module where you are using top level variables? Maybe that way I can be convinced that you need them. Or vice versa. :) Nope, sorry, been down this route once before and I'm sick of these arguments. Fortunately (having just had time for a quick scan of John Meachams post) it seems JM has done an excellent job of this already. (So argue with him, I'm taking the day off :-) Enjoy your day off! I guess we will both remain unconvinced. :) -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Real life examples
Tomasz Zielonka wrote: On Tue, Nov 23, 2004 at 08:50:45PM -0800, John Meacham wrote: Atom.hs from ginsu.. This is perhaps the best example, and an incredibly useful piece of code for anyone struggling with space problems out there. it provides data Atom = ... (abstract) instance Ord Atom instance Eq Atom toAtom :: String -> Atom fromAtom :: Atom -> String [...] internally, Atom has a global hash table of strings -> atoms, note that externally, Atom is truly purely functional. toAtom and fromAtom although using internal state inside are real functions. the same argument always returns the same (externally visible) result. This is because the actual integer chosen is hidden, there is no way to get at it outside the module. Just a nitpick: will this code always yield the same results? map fromAtom $ sort $ map toAtom $ words "Just a nitpick" This is one of the very few cases where I've used unsafePerformIO (because I too have implemented something like Atom :). To make this work properly you need to actually compare the strings for Ord, but you can compare "pointers" for Eq. Doing that, you don't break Haskell semantics (but proving it seems tricky). -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Global Variables and IO initializers
[EMAIL PROTECTED] wrote: No. I mean by the "Haskell language" what is described in the Haskell 98 Report. unsafePerformIO is not part of the language, it is a value defined by one of the standard hierarchical libraries. unsafePerformIO is part of the FFI addendum to the H98 report. So I think it counts as being part of "the Haskell language" by any reasonable sense of that phrase. Well, I don't. unsafePerformIO is an extension that is very much against the spirit of Haskell. Haskell with it does not have the properties I want. So I don't use it. :) I think any addition that breaks the semantics of the language should be very clearly labelled as such. -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Global Variables and IO initializers
George Russell wrote: (3) It needs no extensions to the Haskell language, and only fairly standard hierarchical libraries like Data.IORef. It uses unsafePerformIO which is very much an extension to Haskell. :) -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Top Level TWI's again was Re: [Haskell] Re: Parameterized Show
Adrian Hey wrote: As for openDevice, if a device should only allow a single open I would assume this is part of the device driver in the operating system? (I know this is shifting blame. But I think it shifts it to where it belongs. In the OS there will be an "open" flag per device.) IOW there is no possible sound solution in Haskell. I think that's a problem for a "general purpose" programming language. What if there is no OS or device driver? Shouldn't people reasonably expect to be able to write their own device driver in a general purpose programming language? I find it hard to argue these things in the abstract. Could you post us a (simplified) signature for a module where you are using top level variables? Maybe that way I can be convinced that you need them. Or vice versa. :) If there's no OS nor driver you are free to do what you like, so I claim you can do without top level variables. I've written plenty of device drivers in C for NetBSD. They (almost) never use top level mutable variables (except to control debugging level). If you use top level variables it always bites you in the end. On some occasions I started with using top level mutables (like keeping a free list of transfer descriptors), but in the end I always had to change them to be local to some other piece of state. (I didn't change because of purity reasons, but out of necessity.) So my aversion for top level mutables does not stem from Haskell alone. -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Top Level TWI's again was Re: [Haskell] Re: Parameterized Show
Adrian Hey wrote: But toplevel things with identity (TWI) are evil as well, *especially* if they are easy to use. Just repeating this again and again doesn't make it any more true. Neither you or any of the other nay-sayers have provided any evidence or credible justification for this assertion, nor have any of you provided any workable alternative for even the simplest example. Lennart has yet to explain how he proposes to implement his supposedly safer "openDevice". You have yet to explain how you propose to deal with stdout etc.. Personally, I can't believe I hear people arguing for global variables. I thought that went away 30 years ago. It has nothing to do with functional programming. As for openDevice, if a device should only allow a single open I would assume this is part of the device driver in the operating system? (I know this is shifting blame. But I think it shifts it to where it belongs. In the OS there will be an "open" flag per device.) I admit there are proper uses of global variables, but they are very rare. You have not convinced me you have one. -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Parameterized Show
George Russell wrote: Since it hasn't been mentioned yet I should also point people once again to "Functional Pearl: Implicit Configurations" by Oleg and Chung-chieh Shan, which ingeniously uses polymorphic recursion to construct type class instances at run time. If there's a safe and sane way to add local dictionaries to the language, it's probably along those lines. It is very ingenious to encode complex configuration information by chains of types, but it is something I recoil from in horror. Yes, but I think the point is that local instances make sense since you can encode them like this. And if they make sense it might be a good idea to add them to make life less encoded. :) -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Re: [Haskell] Re: Global Variables and IO initializers
Jules Bean wrote: Yes... a lot of the example we have seen here are 'just' handles. newIORef creates handles. Something many programmers would like is the ability to create fresh handles at the toplevel... Yes, I hear what they want. That doesn't mean I think it's a good idea. Top level things with identity are evil. :) -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Re: [Haskell] Re: Global Variables and IO initializers
Keean Schupke wrote: Adrian Hey wrote: The first step to solving a problem is to at least recognise that it exists. What is "bizarre" is that so many folk seem to be in denial over this. Perhaps you would like to show me your solution to the "oneShot" problem. Why are you unable to give a concrete real world example of why this is necessary then. Even your example of real world hardware that must be initialised once fails! (What if I start two copies of the program?) Indeed. With hardware the solution is to do hdl <- openDevice which will succeed the first time and then return "busy" until closed. Any access to the device must use the hdl. Trying to do without the handle is just shooting yourself in the foot. It might look good at first, but it doesn't scale. -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Re: [Haskell] Re: Global Variables and IO initializers
Adrian Hey wrote: 4- They already exist (stdin,stout,stderr) and I don't recall anybody ever complaining about this. stdin, stdout, and stderr are not global variables. They are just handles. One possible implementation of handles is as an Int. So stdin is no more a global variable than 0. Of course you need some state associated with the handle, but that state does not have to be a unique global things. You are passing that state around via the IO monad, and there could be multiple versions of it. GHC chooses to implement it differently, but that's a choice. -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Global Variables and IO initializers
Adrian Hey wrote: Why are top level IORefs any worse than other IORefs (for example)? Because global variables are just BAD. They have been considered bad a long time, it's not a Haskell thing. If you really grok the functional way of doing things there should be *very*, *very* few times you need a global variable. I incredibly suspicious about code that "needs" it. Having a global variable almost always you have a single copy of some data structure; there is no way to create two of them. I claim that the right way is to have a handle to your "object" and pass that around. (But I can also be persuaded that there might be exceptions. (I've written a few lines of Haskell and I have used a global variable once, I think.)) -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Correct interpretation of the curry-howard isomorphism
JP Bernardy wrote: I'd say, check what any primitive 'proves' before using it. Besides that, calling other functions is ok. Except for general recursion. coerce :: a -> b coerce = coerce -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Data.Set whishes
I think it's because of tradition. Originally Haskell didn't have qualified names, only renaming. (Which, IMHO, was a wrong decision in the original Haskell design.) -- Lennart Koen Claessen wrote: | http://www.haskell.org/hierarchical-modules/libraries/library-design.html I have always wondered why the module system is not used at all in these conventions. I mean, the function names seem to come straight from the Haskell 1.2 days when there was no module system! What I mean is, instead of: newIORef, writeIORef, readIORef We could have: IORef.new, IORef.write, IORef.read (Or: new, write, read if all we use are IORefs.) And instead of: mapSet, emptySet, ... We have: Set.map, Set.empty, ... This is how Chris does it in Edison. Why isn't this used more? /Koen -- Koen Claessenhttp://www.cs.chalmers.se/~koen/ Chalmers University of Technology, Gothenburg, Sweden ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: getting the path to the executing program
Hal Daume III wrote: is there a function, related to getProgName, which returns the (absolute) path to the current program? Well, the absolute path name is not necessarily unique, nor is it guaranteed to exist. :) -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: no continuations
I'm not sure what your question means. You can make your own continuations, so in that sense Haskell has them. But perhaps you're asking why Haskell lacks something like call/cc in Scheme which allows you to grab the current continuation? This doesn't play very well with graph reduction (which most Haskell implementations use), since with graph reduction you will update application nodes with the result of the computation. If you have call/cc available you can "jump back in time" and have a function call return something different, which would contradict the "cached" result from the previous call. It's not an insurmountable problem, but it's pretty hairy. -- Lennart Scott wrote: Why does Haskell have no continuations? (http://www.haskell.org/hawiki/CoMonad) If continuations are incompatible with non-strict semantics, I'd appreciate an explanation. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Haskell naming conventions
Sean L. Palmer wrote: class Eq a where (==) :: a -> a -> Bool That actually declares a /type class/, not a class. So why the use of the keyword class? Is it done merely to confuse C++ and Java programmers? The concept of type class in Haskell apparently roughly corresponds to the concept of "interface" in Java. So why not call it interface? According to dictionary.com one of the definitions of the word class is: A set, collection, group, or configuration containing members regarded as having certain attributes or traits in common; a kind or category. And what the members of class Eq have in common is that they have a function (==). So to me it seems that the word "class" is very well chosen; it describes what's going on. Now, I admit that if you think you can take concepts with similar names from other programming languages and apply them to Haskell you might get confused. You might come across what is called "false friends" in natural language, i.e., words that look the same but mean different things. -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Why are strings linked lists?
Glynn Clements wrote: What Unicode support? Simply claiming that values of type Char are Unicode characters doesn't make it so. Just because some implementations lack toUpper etc. doesn't mean they all do. Hbc has had those implemented for maybe 10 years. -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: a type question
rui yang wrote: Suppose I have a function: funcmap :: a->b->c can I use type synonyms to describe a new type like this: Type Funcmap = a->b>c ? First, it's 'type' not 'Type'. Second, you want '->' not '>'. Third, all type variables in the RHS must be on the LHS. So, we get type Funcmap a b c = a->b->c ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Enum on Float/Double
I think you need to be careful when you reach the smallest number that can be normalized. Let's face it, Haskell just doesn't provide the right functions for this. :) -- Lennart Hal Daume III wrote: This works great for when x/=0...is there a good (Haskell) solution for the smallest positive float? On Tue, 21 Oct 2003, Lennart Augustsson wrote: So this has been a while, but i think that decodeFloat, incrementing the mantissa, encodeFloat might work. But then again, it might not. :) -- Lennart Hal Daume III wrote: My preference would be for succ (+-0) to return the smallest positive real, since then you could define succ x to be the unique y with x < y and forall z . z < y => not (x < z), where such a y exists, and I'm not sure if the Haskell standard knows about signed zeros. Is this really useful? Why would you need this number? Peano artithmetic on reals? :-) Is there any way to do this (yet)? I found a case where I really need: f :: Float -> Float where f x is the least y such that x < y even if i have to FFI to C, I'd really like a solution. any help would be appreciated. - Hal ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Enum on Float/Double
So this has been a while, but i think that decodeFloat, incrementing the mantissa, encodeFloat might work. But then again, it might not. :) -- Lennart Hal Daume III wrote: My preference would be for succ (+-0) to return the smallest positive real, since then you could define succ x to be the unique y with x < y and forall z . z < y => not (x < z), where such a y exists, and I'm not sure if the Haskell standard knows about signed zeros. Is this really useful? Why would you need this number? Peano artithmetic on reals? :-) Is there any way to do this (yet)? I found a case where I really need: f :: Float -> Float where f x is the least y such that x < y even if i have to FFI to C, I'd really like a solution. any help would be appreciated. - Hal ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: IO behaves oddly if used nested
Derek Elkins wrote: If I'm not mistaken, the Report restricts main's type to be, at least, IO a. Anyways, it's perfectly sensible to return anything. The RTS simply discards it. The above example as an entire program is an IO action that returns an IO action that is discarded by the RTS. You're right, the report says that the value of the IO is discarded (nd it can be of any type. While I don't think this is the best choice of type for main, it does make the described behaviour perfectly sensible. -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: IO behaves oddly if used nested
Alastair Reid wrote: Another question with a trivial answer, what is the result of: main :: IO (IO ()) main = return (putStr "Hello World!") It is a computation which, if executed, will print "Hello World" Clearly it also shows the relation between IO and chosen evaluation strategy. This isn't clear to me at all - can you explain further? Is it even type correct with main :: IO (IO ()) If it is, it shouldn't be. It makes no sense. The value computed by the top level IO action should have some consumer. Sensible types for the consumer (which in some sense is the OS) are () or some exit code. -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: loop through the list...
This really sounds a lot like home work. :) -- Lennart Fredrik Petersson wrote: hi again... :) Ok assume i got this list of tuples [(10,1),(20,2),(30,3)] where i in (i,j) is a index, i want to go through the list and add a number witch matches the best index. Like 18 should give me [(10,1),(20,3),(30,3)] since 18 are over 10 and under 20... aky? something like [if (thenumber < index) then (index,int+1) \and break\ else (index,int) | (index,int) <- [thelist]] My problem is that i dont know how to do the break thing! next time the value gonna be smaller than the 30 and ++ the int. Can i use some help-boolean to set it false when we have counted up once? and include that one in the if-stmt?? How do i do that? I guess your laughing your pants wet right now coz there are of-corz some smart built-in functions in haskell to do this kind of silly ting, so please tell me! :) Respect the rock! //Fredde ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Typesafe MRef with a regular monad
Simon Marlow wrote: Simon P.J. writes: ... So it's reasonable that there should be some language extension. I'm just looking for the minimal such extension. unsafeCoerce# is quite a minimal extension :-) It's a minimal extension, but it's not an extension that provides any insight. :) -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: int to float problem
Use the Prelude function realToFrac. -- Lennart Mike T. Machenry wrote: Hello, I am having a problem. I recently desided I wanted a bunch function to return float instead of Int. I changed their type and wrote a new function that returned a float. I figured it'd be okay if all the others still returned Int since it's trivial to convert Int to Float. Sadly Haskell won't let me do this. What should I do? I attempted to cast all of the values in the functions that returned Int to Float, but I found no way to do this. I found fromInteger but it didn't seem to work on the return value of the cardinality function for instance. I guess cardinality much return Int. This is one of my functions. smallestSet :: GameState -> Float smallestSet s = (-1 * cardinality (fLocations s)) This function is an error because it infer's an Int. Thanks, -mike ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: ANNOUNCE: 0th International Obfuscated Haskell Code Contest
Shae Matijs Erisson wrote: The following message is a courtesy copy of an article that has been posted to comp.lang.functional as well. In the spirit of http://ioccc.org/ Bring us your poor, weary, downtrodden, and unreadable source code. Come to the 0th INTERNATIONAL OBFUSCATED HASKELL CODE CONTEST! This not the 1st (nor do you claimso :) Obfuscated Haskell contest. There was one many moons ago. -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Time library underspecified
Yes, I totally agree. The current time library is pretty broken. -- Lennart John Meacham wrote: yes! I was just wrestling with this yesterday. I finally gave up and looked inside ghc's (TOD Integer Integer) directly because the Time library as it currently stands is somewhat less than useful. This is probably a pretty serious bug in Haskell 98 as there is no good way to work with times other than roll your own. how about: toRawTime :: ClockTime -> (Integer,Integer) where they are # of seconds and picoseconds since epoch. (and an 'epoch' constant ClockTime) another useful thing would be endOfTime and beginningOfTime constants, representing the minimum and maximum values representable by ClockTime. John On Thu, Nov 14, 2002 at 10:22:46AM -0800, Christopher Milton wrote: Hmm, this has come up before: http://www.haskell.org/pipermail/glasgow-haskell-bugs/2001-September/001810.html http://www.haskell.org/pipermail/haskell/2002-January/008678.html --- Peter Thiemann <[EMAIL PROTECTED]> wrote: Did anyone try to use the standard Time library that comes with Haskell for a serious purpose? I wanted to, but came across the problem that the TimeDiff data type is underspecified. For example, what is the official way to convert a TimeDiff value into seconds? The problematic parts are: * how many days for one tdYear (365, 366) * how many days for one tdMonth (28,29,30,31) * how many seconds for one tdMin (given the presence of leap seconds)^(1) Actually, once the absolute reference of the TimeDiff is lost, then it is impossible to recover leap years and leap seconds, so TimeDiff better had to account for them somehow. I suppose, the best would be to just have diffClockTimes return the number of seconds as an Integer. Since Simon PJ has finished editing the library report, who's now in charge of keeping track of problems with it and perhaps writing a commentary in cases such as this? Cheers -Peter (1) for this one, there is reasonable consensus. for example the ISO 8601 standard (representation of dates and times) defines minute=60 seconds, hour=60 minutes, day=24 hours. However, this leads to the strange(?) situation that the difference between 1998-12-31T12:00:00 and 1999-01-01T12:00:00 is 1 day and one second. (There was a leap second on that night 1998 December 31 23h 59m 59s 1998 December 31 23h 59m 60s 1999 January 010h0m0s see http://tycho.usno.navy.mil/leap.html) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell = Christopher Milton [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site http://webhosting.yahoo.com ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
