Re: [Haskell-cafe] [ANN] Haskell-Paris meetup
I'm afraid I won't attend the event, but I have to say that you have one of the very best Haskell logos I've ever seen :) 2013/6/4 lucas di cioccio > Dear all, > > I'm happy to announce that the Haskell-Paris group will meet on June 25th > in Paris. Please register (free) at > http://www.meetup.com/haskell-paris/events/122515522/ . > Program is not decided yet (contributions are welcome). We'll update once > we know the lineup. > > I don't like to send spammy emails but I would like to take advantage of > this announcement to invite any non-Parisian Haskellers to get in touch > with us (email, twitter, or meetup page) if you are in town. We may an > event scheduled close in time and we can anyway propose a get-together in a > restaurant so that visitors can taste our great food&drink and everyone can > chat about her favorite programming language. I did this type of > semi-planned dinners a few times with some Ruby folks and it's a good way > to build ties :). > > Regards, > --Lucas DiCioccio > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The state of binary (de)serialization
Hey guys, I didn't see this thread at first, thanks to Johan for bringing it to my attention. cereal is a fork of binary, and provided a incremental interface before binary did. It also has a few additional combinators like "isolate" and "label", which is the reason why safecopy uses cereal instead of binary (at least I know it uses "label"). As an experiment, I've wrapped the api of Data.ByteString.Builder and and re-exported it as Data.Binary.Builder, but it turned out that performance got worse. I have yet to look into why. Once it all seems ok, binary will just wrap and re-export bytestrings builder. If you use binary or builder doesn't really matter, the basic APIs are very similar. builder can offer some more options if you want to spend more time in tuning for speed. binary is also already in the HP, since it is bundled with GHC (GHC depends on binary). In other words, depending on binary should be future-proof. On another note, binary-0.7 is out, get it while it's hot! :) Lennart 2013/2/26 Johan Tibell > On Mon, Feb 25, 2013 at 4:51 PM, Alexander Solla wrote: > >> On Mon, Feb 25, 2013 at 11:59 AM, Johan Tibell wrote: >> >>> >>> There are some blog posts and comments out there about merging cereal >>>> and binary, is this what's the goal/going on (cfr runGetIncremental)? >>>> >>> >>> It's most definitely the goal and it's basically done. The only thing I >>> don't think we'll adopt from cereal is the instances from container types. >>> >> >> Why not? Those instances are useful. Without instances defined in >> binary/cereal, pretty much every Happstack (or, better said, every >> ixset/acidstate/safecopy stack) user will have to have orphan instances. >> > > I will have to give a bit more context to answer this one. After the > binary package was created we've realized that it should really have been > two packages: > > * One package for serialization and deserialization of basic types, that > have a well-defined serialization format even outside the package e.g. > little and big endian integers, IEEE floats, etc. This package would > correspond to Data.Binary.Get, Data.Binary.Builder, and Data.Binary.Put. > > * One package that defines a particular binary format useful for > serializing arbitrary Haskell values. This package would correspond to > Data.Binary. > > For the latter we need to decide what guarantees we make. For example, is > the format stable between releases? Is the format public (such that other > libraries can parse the output of binary)? Right now these two questions > are left unanswered in both binary and cereal, making those packages less > useful. > > Before we answer those questions we don't want to 1) add > more dependencies to binary and 2) define serialization formats that we > might break in the next release. > > So perhaps once we've settled these issues we'll include instances for > containers. > > Also, cereal has a generic instance. Will the new binary? >> > > That sounds reasonable. If someone sends a pull request Lennart or I will > review and merge it. > > -- Johan > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Happstack 7
On Friday, 30 March 2012 00:53:48 UTC+4, Jeremy Shaw wrote: > > We are pleased to announce the release of Happstack 7! > > Happstack is a fast, modern, web application framework written in Haskell. > Please check out the brand new happstack.com website to read about what > is new in Happstack 7, and what we are planning for Happstack 8, and what > makes Happstack great! > > http://www.happstack.com/ > > - jeremy > Congratulations to the new release, and may I say that the homepage looks smashing! :D With the work of Antoine Latter's happstack-wai (https://github.com/aslatter/happstack-wai), it's likely possible to serve happstack applications through my (still in development) SPDY WAI server ( https://github.com/kolmodin/spdy) although I have not tested this combination yet. Before I saw happstack-wai I had a quick look at the happstack API and saw that the Request keeps the request body as a (lazy?) String. I'm curious to the rationale for this, as one could expect a lazy bytestring would be more efficient, and some kind of stream would better support error handling (given that the String is indeed lazy). Sorry if this has been discussed before, I searched the mailing list without finding anything. Feels like Happstack has been reborn, thanks again! Cheers, Lennart ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] mapM is supralinear?
You seem to ignore garbage collection. On Sat, Sep 24, 2011 at 6:40 AM, Arseniy Alekseyev < arseniy.alekse...@gmail.com> wrote: > > Apparently it doesn't, and it seems to be fixed now. > > Does anyone know what exactly the bug was? Because this seems like a > serious bug to me. I've run into it myself today and wasn't happy. > Linear algorithms should work in linear time however much memory they > allocate (modulo cache thrashing of course). Existence of people > claiming otherwise surprises me! > > > On 22 September 2011 01:05, John Lato wrote: > > On Wed, Sep 21, 2011 at 1:57 PM, Tim Docker wrote: > >> > >> On 09/09/2011, at 8:19 PM, John Lato wrote: > >> > >>> Agreed. Whenever I'd like to use mapM (or any other function for > >>> which a *M_ is available), I've found the following rules helpful: > >>> > >>> 1. If I can guarantee the list is short (~ n<=20), go ahead and use > mapM > >>> 2. Otherwise use mapM_, foldM_, or foldM if a real reduction is > >>> possible (i.e. not "foldM snocM []"). > >>> > >>> Step 2 sometimes requires changing my design, but it's always been for > >>> the better. `mapM_` tends to require more pipeline composition, so > >>> it's leveraging the language's strengths. > >> > >> This thread is really interesting - it relates directly to problems I am > >> currently > >> having with mapM over large lists (see the thread "stack overflow > pain"). > >> > >> Can you explain what you mean by "mapM_ tends to require more pipeline > >> composition"? > >> In what way is it leveraging the language strengths? > > > > Hmm, that is suitably cryptic. One way to think of it is an inversion > > of control. Instead of operating on whole collections of things in a > > monad, you specify monadic actions (pipelines) which are applied > > sequentially to each input. > > > > Here's a simple example. Suppose you have a bunch of data serialized > > to files, and you want to read each file into a data structure, apply > > some process based upon the last file's data, and write out the output > > to new files. One way to do that would look like: > > > > do > >dats <- mapM readMyData files > >let pairs = zip (mempty:dats) dats > >zipWithM_ (\(last, this) fname -> writeMyData (update last this) > > fname) pairs newFiles > > > > However, you could also put everything into a single monadic > > operation, like this > > > > do > >foldM_ (\last (infile, outfile) -> do > >this <- readMyData > infile > >writeMyData > > (update last this) outfile > >return this > > ) > > mempty > > (zip files newFiles) > > > > The first interleaves control (mapM, zipWIthM_) with monadic actions > > (file IO), whereas the second only has one control function (foldM_) > > which completely processes one input. I say this is more pipeline > > composition because you have to create an entire pipeline from input > > to output, which is then sequentially fed inputs by the control > > function. > > > > I say this leverages Haskell's strengths because it's quite easy to > > compose functions and monadic actions in Haskell. It also tends to be > > garbage-collector friendly. I also find it much easier to reason > > about space usage. You don't need to worry if part of a list is being > > retained, because the full list of data doesn't appear anywhere. If > > you need to access prior elements they're specified explicitly so you > > know exactly how much data you're holding on to. > > > > My perspective might be warped by my work on iteratees, but I find > > this a very natural approach. > > > > John L. > > > > ___ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] instance Enum Double considered not entirely great?
I totally agree with you. Haskell is very broken when it comes to [x..y] for floating point. It's an attempt to make it more "friendly" for naive users, but there is no way FP can be made friendly. Any such attempts will fail, so make it usable for people who understand FP instead. -- Lennart On Mon, Sep 26, 2011 at 10:02 AM, Richard O'Keefe wrote: > > On 23/09/2011, at 4:06 PM, Chris Smith wrote: > > > On Fri, 2011-09-23 at 11:02 +1200, Richard O'Keefe wrote: > >> I do think that '..' syntax for Float and Double could be useful, > >> but the actual definition is such that, well, words fail me. > >> [1.0..3.5] => [1.0,2.0,3.0,4.0] Why did anyone ever think > >> _that_ was a good idea? > > > > In case you meant that as a question, the reason is this: > > > >Prelude> [0.1, 0.2 .. 0.3] > >[0.1,0.2,0.30004] > > That shows why it is a *BAD* idea. > 0.3 comes out as 0.29998890 > so the final value is clearly and unambiguously > *outside* the requested range. > > > Because of rounding error, an implementation that meets your proposed > > law would have left out 0.3 from that sequence, when of course it was > > intended to be there. > > But the output shown does NOT include 0.3 in the sequence. > > 0.3 `elem` [0.1, 0.2 .. 0.3] > > is False. > > > This is messy for the properties you want to > > state, but it's almost surely the right thing to do in practice. > > I flatly deny that. I have access to several programming languages > that offer 'REAL DO', including Fortran, R, and Smalltalk. They all > do the same thing; NONE of them overshoots the mark. > > If I *wanted* the range to be enlarged a little bit, > I would enlarge it myself: [0.1, 0.2 .. 0.3+0.001] perhaps. > > > If the > > list is longer, then the most likely way to get it right is to follow > > the behavior as currently specified. > > I don't see the length of the list as having much relevance; if the > bug shows up in a list of length 3, it is clearly not likely to be > any better for longer lists. This is NOT by any stretch of the > imagination, it is a BUG. If you have used REAL DO in almost any other > programming language, you will be shocked and dismayed by its behaviour > in Haskell. > > Programming constructs that are implemented to do what would probably > meant if you were an idiot instead of what you *asked* for are > dangerous. > > > If you can clear this up with a better explanation of the properties, > > great! But if you can't, then we ought to reject the kind of thinking > > that would remove useful behavior when it doesn't fit some theoretical > > properties that looked nice until you consider the edge cases. > > I don't see any useful behaviour here. > I see an implausibly motivated bug and while I _have_ written REAL DO > in the past (because some languages offer only one numeric type), I > cannot imagine wishing to do so in Haskell, thanks to this bug. What > I want now is a compiler option, on by default, to assure me that I am > *not* using floating point numeration in Haskell. > > > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] instance Enum Double considered not entirely great?
If you do [0.1, 0.2 .. 0.3] it should leave out 0.3. This is floating point numbers and if you don't understand them, then don't use them. The current behaviour of .. for floating point is totally broken, IMO. -- Lennart On Fri, Sep 23, 2011 at 6:06 AM, Chris Smith wrote: > On Fri, 2011-09-23 at 11:02 +1200, Richard O'Keefe wrote: > > I do think that '..' syntax for Float and Double could be useful, > > but the actual definition is such that, well, words fail me. > > [1.0..3.5] => [1.0,2.0,3.0,4.0] Why did anyone ever think > > _that_ was a good idea? > > In case you meant that as a question, the reason is this: > >Prelude> [0.1, 0.2 .. 0.3] >[0.1,0.2,0.30004] > > Because of rounding error, an implementation that meets your proposed > law would have left out 0.3 from that sequence, when of course it was > intended to be there. This is messy for the properties you want to > state, but it's almost surely the right thing to do in practice. If the > list is longer, then the most likely way to get it right is to follow > the behavior as currently specified. Of course it's messy, but the > world is a messy place, especially when it comes to floating point > arithmetic. > > If you can clear this up with a better explanation of the properties, > great! But if you can't, then we ought to reject the kind of thinking > that would remove useful behavior when it doesn't fit some theoretical > properties that looked nice until you consider the edge cases. > > -- > Chris > > > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary.IncrementalGet remake
Hi,
On Wed, Apr 20, 2011 at 8:35 PM, Antoine Latter wrote:
> On Wed, Apr 20, 2011 at 1:03 PM, Sergey Mironov wrote:
> > Hello cafe.
> >
> > Haskell wiki told me about continuation-based parser
> > Data.Binary.IncrementalGet [1] from binary-strict package. I found the
> > idea very useful and tried to use it. Original library by Lennart
> > Kolmodin raises some questions. The lib's main data structures are:
> >
>
> Lennart Kolmodin has a branch of Binary with incremental get which
> supports lookAhead:
>
> https://github.com/kolmodin/binary/tree/cps
Thanks Antonine for noting this.
> I don't have performance measurements, but if you look-ahead too far
> it obviously isn't good for memory consumption.
Indeed you trade off memory consumption if you're not careful with
lookAhead, as you would do with any depth-first parser allowing choice.
Although I haven't benchmarked, I think it has a more memory efficient
implementation than the increasingly popular text parsing library attoparsec
(foundation of haskell's fastest json library, aeson).
> Antoine
>
> > data IResult a = IFailed S String
> > | IFinished S a
> > | IPartial (B.ByteString -> IResult a)
> >
> > newtype Get r a = Get { unGet :: S -> (a -> S -> IResult r) -> IResult r
> }
> >
> > instance Monad (Get r) where
> > return a = Get (\s -> \k -> k a s)
> > m >>= k = Get (\s -> \cont -> unGet m s (\a -> \s' -> unGet (k a) s'
> cont))
> > fail err = Get (\s -> const $ IFailed s err)
> >
> > Here, "S" is parser's state. It works well, but currently doesn't
> > support lookAhead. I tried to add such function and gave up to do it
> > having current implementation, but write simpler one instead. Please
> > see IncrementalGet2.hs (link [2] below). Remake is briefly tested, has
> > no ghc-specific optimizations, but allows user to peek data from
> > stream.
> >
> > What bothering me is the fact that I could actually miss idea (or part
> > of idea) of the original. If it is so, please let me know :) For
> > example, what is the point of using separate result type r in original
> > Get r a?
>
In the case of parsing with binary, I don't think there are any serious
limitations with not being able to specify your own "r" in "Get r a". I ran
into something during the implementation, but I'm afraid it wasn't
noteworthy enough to remember :) Possibly it had to do something with saving
continuations for later use, and how flexible you could be when using them?
Hmm.. Anyway, not a problem in binary.
Work has been done lately by Johan Tibell to make the builder (part of the
Put monad) efficient, and with very good progress. I've worked on the CPS
based parsing.
Our aim is to provide the easiest to use, and at the same time, the fastest,
binary parsing library out there.
Expect much internal change, yet backwards compatibility, with the next
release :)
Unfortunately I've been extremely busy lately, so don't expect a release for
a few more months. I invite everybody to try out the new code and try to
benchmark and break it :)
Cheers,
Lennart Kolmodin
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is SHE (the Strathclyde Haskell Enhancement) portable?
It probably is portable, but I'd think only GHC has all the necessary extensions. On Sun, Jan 23, 2011 at 12:27 PM, Maciej Piechotka wrote: > It may be strange question but: > > - Is SHE portable (assuming that the compiler have the extensions)? > - If yes why there is only information how to use it with GHC? > > Regards > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Set monad
That looks like it looses the efficiency of the underlying representation.
On Sun, Jan 9, 2011 at 6:45 AM, Sebastian Fischer wrote:
> On Sun, Jan 9, 2011 at 6:53 AM, Lennart Augustsson > wrote:
>
>> It so happens that you can make a set data type that is a Monad, but it's
>> not exactly the best possible sets.
>>
>> module SetMonad where
>>
>> newtype Set a = Set { unSet :: [a] }
>>
>
> Here is a version that also does not require restricted monads but works
> with an arbitrary underlying Set data type (e.g. from Data.Set). It uses
> continuations with a Rank2Type.
>
> import qualified Data.Set as S
>
> newtype Set a = Set { (>>-) :: forall b . Ord b => (a -> S.Set b) ->
> S.Set b }
>
> instance Monad Set where
> return x = Set ($x)
> a >>= f = Set (\k -> a >>- \x -> f x >>- k)
>
> Only conversion to the underlying Set type requires an Ord constraint.
>
> getSet :: Ord a => Set a -> S.Set a
> getSet a = a >>- S.singleton
>
> A `MonadPlus` instance can lift `empty` and `union`.
>
> instance MonadPlus Set where
> mzero = Set (const S.empty)
> mplus a b = Set (\k -> S.union (a >>- k) (b >>- k))
>
> Maybe, Heinrich Apfelmus's operational package [1] can be used to do the
> same without continuations.
>
> [1]: http://projects.haskell.org/operational/
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Set monad
It so happens that you can make a set data type that is a Monad, but it's
not exactly the best possible sets.
module SetMonad where
newtype Set a = Set { unSet :: [a] }
singleton :: a -> Set a
singleton x = Set [x]
unions :: [Set a] -> Set a
unions ss = Set $ concatMap unSet ss
member :: (Eq a) => a -> Set a -> Bool
member x s = x `elem` unSet s
instance Monad Set where
return = singleton
x >>= f = unions (map f (unSet x))
On Sat, Jan 8, 2011 at 9:28 PM, Peter Padawitz wrote:
> Hi,
>
> is there any way to instantiate m in Monad m with a set datatype in order
> to implement the usual powerset monad?
>
> My straightforward attempt failed because the bind operator of this
> instance requires the Eq constraint on the argument types of m.
>
> Peter
>
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Incorrectly inferring type [t]
First, what type would such a function have? Certainly not [a]->[b], because that type say that it can take a list of any type and turn it into a list of any other type, e.g., [Int]->[Bool]. On Thu, Dec 30, 2010 at 4:05 AM, william murphy wrote: > Hi All, > > I've spent a lot of time trying to write a version of concat, which > concatenates lists of any "depth": > So: > concat'' [[[1,2],[3,4]],[[5]]] would return: [1,2,3,4,5] > > > The code is: > concat'' :: [a] -> [b] > concat'' ((y:ys):xs) = (concat'' (y:ys)) ++ (concat'' xs) > concat'' [] = [] > concat'' (x:xs) = (x:xs) > > > And the inevitable error is: > test.hs:298:12: > Couldn't match expected type `a' against inferred type `[t]' > `a' is a rigid type variable bound by > the type signature for `concat''' at test.hs:297:13 > In the pattern: y : ys > In the pattern: (y : ys) : xs > In the definition of `concat''': > concat'' ((y : ys) : xs) = (concat'' (y : ys)) ++ (concat'' xs) > > test.hs:300:24: > Couldn't match expected type `b' against inferred type `[t]' > `b' is a rigid type variable bound by > the type signature for `concat''' at test.hs:297:20 > In the first argument of `(:)', namely `x' > In the expression: (x : xs) > In the definition of `concat''': concat'' (x : xs) = (x : xs) > Failed, modules loaded: none. > > > Any help or advice would be appreciated. > Will > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] how to write a loop in haskell way
Recursion replaces loops. If it needs to be monadic or not depends on what you want to do. On Sun, Dec 19, 2010 at 10:53 AM, ender wrote: > 2010/12/19 Henning Thielemann : > > > > On Sun, 19 Dec 2010, ender wrote: > > > >>> do > >>> alloca $ \value -> do > >>> poke value (50::Int) > >>> allocaArray 4 $ \part_stack -> do > >>> alloca $ \part_ptr -> do > >>> poke part_ptr part_stack > >>> let loop = do > >>> val <- peek value > >>> if val == 0 then return () else do > >>> p <- peek part_ptr > >>> poke p (val `rem` 1) > >>> poke part_ptr (p `plusPtr` 1) > >>> poke value (val `quot` 1) > >>> loop > >>> loop > >> > >> and I really think that's not a "haskell way", it's just translate c > >> code into haskell code byte by byte > >> My question is: how to translate above c code into haskell in "haskell > >> way" > > > > If the count of loop runs does not depend on results of the loop body, > then > > 'mapM' and 'mapM_' applied to the list of increasing pointers are your > > friends. In your case, the loop aborts when 'val' becomes zero. I'm > > certainly thinking too complicated, but you might use MaybeT IO () (e.g. > > from transformers package) and abort 'mapM_' with 'mzero' when 'val' > becomes > > zero. (MaybeT IO a) is like an IO monad with an early exit (somehow an > > exception) option. > > > Hi Henning: > Thanks for your quick reply. So recursive and monad is the proper > way to simulate loop,right? > > Thanks and BR > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [URGENT] DNS problems at haskell.org?
I bet they did try to contact the owner. But when the contact email no longer works nobody will get the messages. On Sat, Dec 18, 2010 at 3:35 PM, Ketil Malde wrote: > Karel Gardas writes: > > > > http://www.reddit.com/r/haskell/comments/encrv/whats_happened_to_haskellorg_did_someone_forget/c19guw1 > > Quoth dons: > > | The domain name was seized by Network Solutions (it wasn't due to > | expire until this time next year). The confusion seems to be that > | while Yale was the nominated owner, it was administered by Galois. > > | We've contacted Network Solutions and resolve their confusion. > > Would it be impertinent to question the wisdom of using a domain > provider that just breaks a paid-for and working site without contacting > the owner? How about contacting another, more professional registrar > instead of Network Solution? > > http://www.host-shopper.com/web-hosts-reviews.html?sortBy=rating > > -k > -- > If I haven't seen further, it is by standing in the footprints of giants > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] Functor => Applicative => Monad
IO On Thu, Dec 16, 2010 at 6:03 PM, John Smith wrote: > On 15/12/2010 14:31, Lennart Augustsson wrote: > >> Yes, I think there should be a MonadFail distinct from MonadPlus. >> Some types, like IO, are not in MonadPlus, but have a special >> implementation of the fail method. >> >> Personally, I think fail should just be removed, but that would break >> existing code. >> The fail method was introduced for the wrong reasons (better error >> messages was the excuse). >> > > Which other monads (other than MonadPlus subclasses) define fail? > > > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] Functor => Applicative => Monad
Yes, I think there should be a MonadFail distinct from MonadPlus. Some types, like IO, are not in MonadPlus, but have a special implementation of the fail method. Personally, I think fail should just be removed, but that would break existing code. The fail method was introduced for the wrong reasons (better error messages was the excuse). -- Lennart On Wed, Dec 15, 2010 at 11:51 AM, John Smith wrote: > On 15/12/2010 11:39, Lennart Augustsson wrote: > >> Any refutable pattern match in do would force MonadFail (or MonadPlus if >> you prefer). So >> 1. (MonadFail m) => a -> m a, \ a -> return a >> 2. (MonadFail m) => m a, mfail "..." >> 3. (MonadFail m) => Maybe a -> m a, \ a -> case a of Nothing -> mfail >> "..."; Just x -> return x >> 4. (Monad m) => a -> b -> m a, \ a b -> return a >> 5. (Monad m) => (a, b) -> m a, \ (a, b) -> return a >> >> As far as type inference and desugaring goes, it seems very little would >> have to be changed in an implementation. >> > > Is there a need for a MonadFail, as distinct from mzero? fail always seems > to be defined as error in ordinary monads, and as mzero in MonadPlus (or > left at the default error). > > > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] Functor => Applicative => Monad
Any refutable pattern match in do would force MonadFail (or MonadPlus if you
prefer). So
1. (MonadFail m) => a -> m a, \ a -> return a
2. (MonadFail m) => m a, mfail "..."
3. (MonadFail m) => Maybe a -> m a, \ a -> case a of Nothing -> mfail
"..."; Just x -> return x
4. (Monad m) => a -> b -> m a, \ a b -> return a
5. (Monad m) => (a, b) -> m a, \ (a, b) -> return a
As far as type inference and desugaring goes, it seems very little would
have to be changed in an implementation.
-- Lennart
2010/12/15 Tillmann Rendel
> Hi John,
>
>
> John Smith wrote:
>
>> Perhaps pattern match failures in a MonadPlus should bind to mzero - I
>> believe that this is what your example and similar wish to achieve.
>>
>
> You updated the proposal to say:
>
>> a failed pattern match should error in the same way as is does for pure
>> code, while in
>> MonadPlus, the current behaviour could be maintained with mzero
>>
>
> Can you be more specific as to how that would interact with polymorphism
> and type inference? What does it mean to be "in MonadPlus"? How does the
> compiler know?
>
> For example, what would be the static types and dynamic semantics of the
> following expressions:
>
> 1. \a -> do {Just x <- return (Just a); return x}
>
> 2. do {Just x <- return Nothing; return x}
>
> 3. \a -> do {Just x <- a; return x}
>
> 4. \a b -> do {(x, _) <- return (a, b); return x}
>
> 5. \a -> do {(x, _) <- return a; return x}
>
>Tillmann
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: "Haskell is a scripting language inspired by Python."
It happened at various universities around the world. Look at the original Haskell committee and you'll get a good idea where. The smallest Haskell I know of is Gofer/Hugs; it originally ran on a 640k PCs. Before that languages like SASL and KRC ran on PDP-11 with 64k memory. None of these had a compiler that was bootstrapped, but I had a simple functional language that compiled itself and ran in 64K. The smallest bootstrapped Haskell compiler is NHC which (I think) runs in a few MB. -- Lennart On Thu, Nov 4, 2010 at 8:54 PM, Andrew Coppin wrote: > Where the heck did all this > stuff happen?! Can you actually run something like Haskell with mere > kilobytes of RAM? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: "Haskell is a scripting language inspired by Python."
KRC, Miranda, and LML all predate Haskell and have list comprehensions. On Thu, Nov 4, 2010 at 3:16 PM, Jonathan Geddes wrote: > Regardless of which languages got which features for which other > languages, Haskell is surely NOT a "scripting language inspired by > python"... > > Also, it was my understanding that Python got list comprehensions > straight from Haskell. Unless, of course, some of the pre-Haskells > also had this feature. > > Haskell: [f x | x <- xs, x <= 15] > Python: [f(x) for x in xs if x <= 15] > > The Python version reads the way I would speak the Haskell one if I > were reading code aloud, though I might say "such that" rather than > "for" > > --Jonathan Geddes > > On Thu, Nov 4, 2010 at 6:05 AM, Stephen Tetley > wrote: >> On 4 November 2010 12:03, Stephen Tetley wrote: >>> Python is approximately as old as Python and most likely got >>> indentation from ABC. >> >> Apologies that should read - "as old as Haskell" >> >> Obviously IDSWIM - (I _don't_ say what I mean). >> ___ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Mysterious fact
Jon, you beat me to it. I was going to mention Ponder.
But Ponder did have a builtin type, it had the function type built in. :)
-- Lennart
On Tue, Nov 2, 2010 at 9:47 PM, Jon Fairbairn
wrote:
> Andrew Coppin writes:
>
>> The other day, I accidentally came up with this:
>>
>> |{-# LANGUAGE RankNTypes #-}
>>
>> type Either x y= forall r. (x -> r) -> (y -> r) -> r
>>
>> left :: x -> Either x y
>> left x f g= f x
>>
>> right :: y -> Either x y
>> right y f g= g y
>>
>> |
>>
>> This is one example; it seems that just about any algebraic
>> type can be encoded this way. I presume that somebody else
>> has thought of this before. Does it have a name?
>
> You could try reading my PhD thesis!
> <http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-75.html>
> contains a link to the full text scanned to a pdf. (That -- 1985
> -- was a long time ago. One thing I really regret about it is
> that there should have been a comma between "simple" and "typed"
> in the title. I suspect people think "simply typed" when they
> see it). It isn't hard to read (one of my examiners said it made
> good bed-time reading).
>
> Anyway, the relevant part is that Ponder was a programming
> language (Stuart Wray even wrote a GUI programme in it) that had
> (in principle) no built-in types, relying on the type system
> being powerful enough to express anything and the optimiser
> being good enough to convert them to something more sensible.
> In practice neither was /quite/ true, but it got quite close.
>
> --
> Jón Fairbairn jon.fairba...@cl.cam.ac.uk
> http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2010-09-14)
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is simplest extension language to implement?
I don't understand. Why don't you use Haskell as the scripting language? On Tue, Nov 2, 2010 at 7:04 AM, Permjacov Evgeniy wrote: > Let us think, that we need some scripting language for our pure haskell > project and configure-compile-run is not a way. In such a case a > reasonably simple, yet standartized and wide known language should be > implemented. What such language may be? > R(4/5/6)RS ? > EcmaScript ? > Some other ? > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] who's in charge?
It's working just fine. I've never wanted a mail client library. :) -- Lennart 2010/10/27 Günther Schmidt : > Dear Malcolm, > > since there is no mail client library even after 10+ years I suggest to > rethink the approach, because frankly, it's not working. > > Günther > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Static computation/inlining
I would not worry about doing that at runtime. The only reliable way to make sure it happens at compile time that I can think of would be some Template Haskell. (Or some really deep magic with dictionaries.) -- Lennart On Mon, Oct 11, 2010 at 3:51 AM, Alexander Solla wrote: > Hi everybody, > I'm working on a module that encodes "static" facts about "the real world". > For now, I'm working on an ISO 3166 compliant list of countries, country > names, and country codes. I've run into a bit of an optimization issue. > There is a static bijective correspondence between countries and their > codes. In order to keep one just one "large" data structure representation > as Haskell code, I encoded this bijection using a list. I'm looking to > write queries against this list, but it is rather tedious. I figured I > could make some Data.Maps to handle it for me. > > > -- Country and ISOCountryCodes derive (Data, Eq, Ord, Show, Typeable) > countries_and_iso_country_codes :: [ (Country, ISOCountryCode) ] > countries_and_iso_country_codes = > > [ ( Afghanistan , ISOCountryCode AF > AFG (isoNumericCode 004) ) > , ( AlandIslands , ISOCountryCode AX ALA > (isoNumericCode 248) ) > , ( Albania , ISOCountryCode AL ALB > (isoNumericCode 008) ) > ... > , ( Zimbabwe , ISOCountryCode ZW ZWE (isoNumericCode 716) ) ] > map_country_to_country_code :: Map Country ISOCountryCode > map_country_to_country_code = fromList countries_and_iso_country_codes > map_country_code_to_country :: Map ISOCountryCode Country > map_country_code_to_country = fromList . fmap (\(a,b) -> (b, a)) $ > countries_and_iso_country_codes > Is there anyway to instruct GHC (and maybe other compilers) to compute these > maps statically? Are GHC and the other compilers smart enough to do it > automatically? Although the list isn't huge, I would still rather get rid of > the O(2*n) operation of turning it into maps at run-time. (Especially since > some later list encodings like these might be enormous) What should I be > looking into? > Thanks > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re-order type
You can use Djinn to generate the glue. Note that in the example you give there are many possible ways to make the glue just looking at the types. Changing the output types of f so they can't be confused with the input types we get: Djinn> ? compose :: (c1 -> a1 -> d) -> (a-> b -> c -> (b1,c1,a1)) -> (a -> b -> c -> d) compose :: (c1 -> a1 -> d) -> (a -> b -> c -> (b1, c1, a1)) -> a -> b -> c -> d compose a b c d e = case b c d e of (_, f, g) -> a f g -- Lennart 2010/10/9 André Batista Martins : > Hello, > exists any algorithm to determine how terms can be changed to safisty the > type of one function? > > > example: > > f:: a-> b -> c -> (b,c,a) > > f1 :: c -> a -> d > > In my first function "f" i want assign the output "c" and "a" for to input > of function "f1". > I searched for any solution, but i didn't find any anything. > > One clue i have found is "minimal edit distance algorithm" for 2 strings. > Perhaps if i convert de output type of "f" to one string, and de input of > "f1" to another string and then use this algorithm , i will get one "dirty" > solution... > > I'm open to any sugestion. > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Desired behaviour of rounding etc.
That code is incorrect. You can't assume that the base for floating point numbers is 2, that's something you have to check. (POWER6 and z9 has hardware support for base 10 floating point.) -- Lennart On Fri, Oct 8, 2010 at 2:08 PM, Daniel Fischer wrote: > The methods of the RealFrac class produce garbage when the value lies > outside the range of the target type, e.g. > > Prelude GHC.Float> truncate 1.234e11 :: Int -- 32-bits > -1154051584 > > and, in the case of truncate, different garbage when the rewrite rule > fires: > > Prelude GHC.Float> double2Int 1.234e11 > -2147483648 > > I'm currently working on faster implementations of properFraction, > truncate, round, ceiling and floor for Float and Double, so I'd like to > know > > - does it matter at all what garbage is returned in the above case? > - if it does, what is the desired behaviour (at least for Int, I can't > cater for all possibilities)? > > > On a related note, in my benchmarks, > > truncFloatGen :: Integral a => Float -> a > truncFloatGen = fromInteger . truncFloatInteger > > truncFloatInteger :: Float -> Integer > truncFloatInteger x = > case decodeFloat x of > (m,e) | e == 0 -> m > | e < 0 -> > let s = -e > in if m < 0 > then - ((-m) `shiftR` s) > else m `shiftR` s > | otherwise -> m `shiftL` e > > is more than twice as fast as GHC.Float.float2Int, the corresponding for > Double almost twice as fast as double2Int. > > Can anybody confirm that the above is faster than float2Int on other > machines/architectures? > > Cheers, > Daniel > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: A GHC error message puzzle
So it's a bug in the garbage collector. It's closing a handle that clearly is still reachable, otherwise this would not have happened. On Fri, Aug 13, 2010 at 10:53 AM, Simon Marlow wrote: > On 12/08/2010 21:59, Yitzchak Gale wrote: >> >> Wei Hu wrote: >>> >>> nonTermination _ = blackhole where blackhole = blackhole >> >> My original example was actually: >> >> process :: String -> String >> process = let x = x in x > > Ah yes, that works too. But other similar versions don't, like this one: > > process :: String -> String > process _ = let x = x in x > > Hence why I added the "tail" in my version. > > So what happens is this: > > - the recursive definition causes the main thread to block on itself > (known as a "black hole") > > - the program is deadlocked (no threads to run), so the runtime > invokes the GC to see if any threads are unreachable > > - the GC finds that > (a) the main thread is unreachable and blocked on a blackhole, so it > gets a NonTermination exception > (b) the Handle is unreachable, so its finalizer is started > > - the finalizer runs first, and closes the Handle > > - the main thread runs next, and the exception handler for writeFile > tries to close the Handle, which has already been finalized > > Really hClose shouldn't complain about a finalized handle, I'll see if I can > fix that. > > Cheers, > Simon > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell in Industry
The former. On Tue, Aug 10, 2010 at 2:59 PM, Ivan Lazar Miljenovic wrote: > Lennart Augustsson writes: > >> Rather than high turnover it indicates (in my experience) that it's >> difficult to fill positions in finance. >> That's one reason they are advertised repeatedly. > > Because you can't find people that are good enough (in terms of required > skill sets, etc.) or because no-one wants the job? > > -- > Ivan Lazar Miljenovic > ivan.miljeno...@gmail.com > IvanMiljenovic.wordpress.com > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell in Industry
Rather than high turnover it indicates (in my experience) that it's difficult to fill positions in finance. That's one reason they are advertised repeatedly. On Tue, Aug 10, 2010 at 12:27 PM, Ivan Lazar Miljenovic wrote: > Malcolm Wallace writes: > It's disproportionate. 95% of the job offerings in functional programming are with investment firms. >> >> I'm not sure that is really true. You might see more adverts for >> financial jobs, but often those jobs may be advertised multiple times, >> because different headhunters see an opportunity to earn a slice of >> the pie. By contrast, non-financial FP jobs are likely to be >> advertised only once, or not at all, because candidates are easily >> found. > > It could also indicate high turn-over for investment firm > jobs... (i.e. people get sick of it). > > -- > Ivan Lazar Miljenovic > ivan.miljeno...@gmail.com > IvanMiljenovic.wordpress.com > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell in Industry
But do you think there would be more Haskell jobs offered (in absolute terms), if no investment firms offered jobs? Is there some kind of quota of job offers that gets used up? There seems to be more job applicants that job offers at the moment, so I'm not sure what the problem is. On Mon, Aug 9, 2010 at 6:59 PM, Tom Hawkins wrote: > It's disproportionate. 95% of the job offerings in functional > programming are with investment firms. I believe investment banking > is important, but does it really need to dominate a large percentage > of the world's top tier programmers? Is computing the risk of > derivative contracts more important than pursuing sustainable energy, > new drug discovery, improving crop yields, etc. Some will argue > investment banking enables all of these things -- and I'm sure many > people in the industry go to work everyday feeling proud of their > contributions. But I just think most of this talent is going in to > improve the bottom line and little else. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell in Industry
Out of 10 people trained only 2 should do programming anyway. :) On Fri, Aug 6, 2010 at 4:58 AM, Tom Hawkins wrote: > Hi Eil, >> Have you had any trouble training people to use Haskell? > > Yes. I find that out of 10 people I train, only about 2 pick it up > and run with it. I'm starting to believe you are either wired for > functional programming, or you're not. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is toRational a method of Real?
Yes, for instance to be able to use functions as number. Or to be able to use constructive real numbers as numbers, since equality is not computable. -- Lennart On Thu, Aug 5, 2010 at 4:17 AM, Ivan Lazar Miljenovic wrote: > On 5 August 2010 10:15, Lennart Augustsson wrote: >> You're right. It's bad to have toRational in Real. It's also bad to >> have Show and Eq as superclasses to Num. > > I understand why it's bad to have Show as a superclass, but why Eq? > Because it stops you from using functions as numbers, etc. ? > > > -- > Ivan Lazar Miljenovic > ivan.miljeno...@gmail.com > IvanMiljenovic.wordpress.com > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is toRational a method of Real?
You're right. It's bad to have toRational in Real. It's also bad to have Show and Eq as superclasses to Num. On Wed, Aug 4, 2010 at 8:30 PM, Omari Norman wrote: > Why is toRational a method of Real? I thought that real numbers need not > be rational, such as the square root of two. Wouldn't it make more sense > to have some sort of Rational typeclass with this method? Thanks. > --Omari > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Instances for Set of Functor, Traversable?
But that's not really a solution, since it doesn't make a Functor
instance for Set; it makes a Functor' instance for Set.
If you are willing to not be upwards compatible then, yes, there are solutions.
I think the best bet for an upwards compatible solutions is the
associated constraints,
www.cs.kuleuven.be/~toms/Research/papers/constraint_families.pdf
On Tue, Jul 27, 2010 at 10:17 AM, wrote:
>
> Lennart Augustsson wrote:
>> Try to make Set an instance of Functor and you'll see why it isn't.
>> It's very annoying.
>
> And yet the very simple, and old solution works.
>
> http://okmij.org/ftp/Haskell/types.html#restricted-datatypes
>
> We just properly generalize Functor, so that all old functors are new
> functors. In addition, many more functors become possible, including
> Set. In general, we can have functors
> fmap' :: (C1 a, C2 b) => (a -> b) -> f a -> f b
> Incidentally, even an Integer may be considered a functor:
> we can define the fmap' operation fitting the above signature, where
> the constraint C1 a is a ~ Integer.
>
> Although the use of OverlappingInstances is not required, the
> extension leads to the nicest code; all old functors just work.
>
>
> {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-}
> {-# LANGUAGE OverlappingInstances #-}
>
> module FunctorEx where
>
> import Control.Monad
> import Data.Set as S
>
> class Functor' f a b where
> fmap' :: (a -> b) -> f a -> f b
>
> -- The default instance:
> -- All ordinary Functors are also extended functors
>
> instance Functor f => Functor' f a b where
> fmap' = fmap
>
> -- Now define a functor for a set
> instance (Ord a, Ord b) => Functor' S.Set a b where
> fmap' = S.map
>
>
> -- Define a degenerate functor, for an integer
> newtype I a = I Integer deriving Show
>
> instance Functor' I Integer Integer where
> fmap' f (I x) = I $ f x
>
> -- tests
>
> -- Lists as functors
> test_l = fmap' (+10) [1,2,3,4]
> -- [11,12,13,14]
>
> -- Sets as functors
> test_s = fmap' (\x -> x `mod` 3) $ S.fromList [1,2,3,4]
> -- fromList [0,1,2]
>
> -- Integer as functor
> test_i = fmap' (* (6::Integer)) $ I 7
> -- I 42
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Instances for Set of Functor, Traversable?
Try to make Set an instance of Functor and you'll see why it isn't. It's very annoying. On Mon, Jul 26, 2010 at 11:55 PM, Gregory Crosswhite wrote: > Is there a specific reason why Set doesn't have instances for Functor > and Traversable? Or have they just not been written yet? :-) > > Cheers, > Greg > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Using the ContT monads for early exits of IO ?
I would not use the continuation monad just for early exit. Sounds like the error monad to me. 2010/6/10 Günther Schmidt : > Hi everyone, > > I'm about to write a rather lengthy piece of IO code. Depending on the > results of some of the IO actions I'd like the computation to stop right > there and then. > > Now I know in general how to write this but I'm wondering if this is one of > those occasions where I should make use of the Cont monad to make an early > exit. > > Günther > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] currying combinators
Yes, of course you have to trust Djinn to believe its proof. That's no different from having to trust me if I had done the proof by hand. Our you would have to trust yourself if you did the proof. BTW, Djinn does not do an exhaustive search, since there are infinitely many proofs. (Even if you just consider cut free proofs there's usually infinitely many.) On Fri, May 28, 2010 at 8:14 AM, wren ng thornton wrote: > Lennart Augustsson wrote: >> >> So what would you consider a proof that there are no total Haskell >> functions of that type? >> Or, using Curry-Howard, a proof that the corresponding logical formula >> is unprovable in intuitionistic logic? > > > It depends on what kind of proof I'm looking for. If I'm looking for an > informal proof to convince myself, then I'd probably trust Djinn. If I'm > trying to convince others, am deeply skeptical, or want to understand the > reasoning behind the result, then I'd be looking for a more rigorous proof. > In general, that rigorous proof would require metatheory (as you say)--- > either my own, or understanding the metatheory behind some tool I'm using to > develop the proof. For example, I'd only trust Djinn for a rigorous proof > after fully understanding the algorithms it's using and the metatheory used > to prove its correctness (and a code inspection, if I didn't trust the > developers). > > >> If Djinn correctly implements the decision procedure that have been >> proven to be total (using meta theory), then I would regard Djinn >> saying no as a proof that there is no function of that type. > > So would I. However, that's adding prerequisites for trusting Djinn--- which > was my original point: that Djinn says there isn't one is not sufficient > justification for some folks, they'd also want justification for why we > should believe Djinn actually does exhaust every possibility. > > -- > Live well, > ~wren > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] currying combinators
So what would you consider a proof that there are no total Haskell functions of that type? Or, using Curry-Howard, a proof that the corresponding logical formula is unprovable in intuitionistic logic? As I understand, in general this can only be proven using meta theory rather than the logic itself (it could happen that the given formula implies absurdity, and then we'd know it can't be proven, given that the logic is consistent). If Djinn correctly implements the decision procedure that have been proven to be total (using meta theory), then I would regard Djinn saying no as a proof that there is no function of that type. -- Lennart On Thu, May 27, 2010 at 7:49 PM, wren ng thornton wrote: > Dan Doel wrote: >> >> On Thursday 27 May 2010 3:27:58 am wren ng thornton wrote: >>> >>> By parametricty, presumably. >> >> Actually, I imagine the way he proved it was to use djinn, which uses a >> complete decision procedure for intuitionistic propositional logic. The >> proofs of theorems for that logic correspond to total functions for the >> analogous type. Since djinn is complete, it will either find a total >> function with the right type, or not, in which case there is no such >> function. >> >> At that point, all you have left to do is show that djinn is in fact >> complete. For that, you can probably look to the paper it's based on: >> Contraction-Free Sequent Calculi for Intuitionistic Logic* (if I'm not >> mistaken) by Roy Dyckhoff. > > Sure, that's another option. But the failure of exhaustive search isn't a > constructive/intuitionistic technique, so not everyone would accept the > proof. Djinn is essentially an implementation of reasoning by parametricity, > IIRC, so it comes down to the same first principles. > > > (Sorry, just finished writing a philosophy paper on intuitionism :) > > -- > Live well, > ~wren > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] currying combinators
There are no interesting (i.e. total) functions of that type. 2010/5/25 Yitzchak Gale : > Günther Schmidt wrote: >> http://www.hpaste.org/fastcgi/hpaste.fcgi/view?id=25694 >> in which I attempt to develop a "currying combinator" library. >> I'm stuck at some point and would appreciate any help. > > How about this: > > keep :: ((t -> b) -> u -> b) -> ((t1 -> t) -> b) -> (t1 -> u) -> b > > so then > > nameZip = keep (drop' . drop') names > > Regards, > Yitz > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Proof question -- (==) over Bool
That's totally false. You don't evaluate 'undefined' before calling 'id'. (Or if you, it's because you've made a transformation that is valid because 'id' is strict.) On Mon, May 24, 2010 at 9:05 AM, Alexander Solla wrote: > Yes, but only because it doesn't work at all. Consider that calling > >> id undefined > > requires evaluating undefined before you can call id. The program will > "crash" before you ever call id. Of course, the identity function "should" > have produced a value that crashed in exactly the same way. But we never > got there. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Clean proof -- correction
Actually, I didn't notice the typo. It's still not a true statement.
(h . either (f, g)) undefined /= (either (h . f, h . g)) undefined
Also, it's not exactly the function either from the Prelude.
-- Lennart
2010/5/23 R J :
> Correction: the theorem is
> h . either (f, g) = either (h . f, h . g)
>
> (Thanks to Lennart for pointing out the typo.)
>
> From: rj248...@hotmail.com
> To: haskell-cafe@haskell.org
> Subject: Clean proof?
> Date: Sun, 23 May 2010 15:41:20 +
>
> Given the following definition of "either", from the prelude:
> either :: (a -> c, b -> c) -> Either a b -> c
> either (f, g) (Left x) = f x
> either (f, g) (Right x) = g x
> what's a clean proof that:
> h . either (f, g) = either (h . f, g . h)?
> The only proof I can think of requires the introduction of an anonymous
> function of z, with case analysis on z (Case 1: z = Left x, Case 2: z =
> Right y), but the use of anonymous functions and case analysis is ugly, and
> I'm not sure how to tie up the two cases neatly at the end. For example
> here's the "Left" case:
> h . either (f, g)
> = {definition of "\"}
> \z -> (h . either (f, g)) z
> = {definition of "."}
> \z -> (h (either (f, g) z)
> = {definition of "either" in case z = Left x}
> \z -> (h (f x))
> = {definition of "."}
> \z -> (h . f) x
> = {definition of "."}
> h . f
>
> Thanks.
>
> The New Busy is not the too busy. Combine all your e-mail accounts with
> Hotmail. Get busy.
>
> The New Busy is not the old busy. Search, chat and e-mail from your inbox.
> Get started.
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Clean proof?
There is no clean proof of that statement because it is false.
(Consider the argument 'undefined'.)
2010/5/23 R J :
> Given the following definition of "either", from the prelude:
> either :: (a -> c, b -> c) -> Either a b -> c
> either (f, g) (Left x) = f x
> either (f, g) (Right x) = g x
> what's a clean proof that:
> h . either (f, g) = either (h . f, g . h)?
> The only proof I can think of requires the introduction of an anonymous
> function of z, with case analysis on z (Case 1: z = Left x, Case 2: z =
> Right y), but the use of anonymous functions and case analysis is ugly, and
> I'm not sure how to tie up the two cases neatly at the end. For example
> here's the "Left" case:
> h . either (f, g)
> = {definition of "\"}
> \z -> (h . either (f, g)) z
> = {definition of "."}
> \z -> (h (either (f, g) z)
> = {definition of "either" in case z = Left x}
> \z -> (h (f x))
> = {definition of "."}
> \z -> (h . f) x
> = {definition of "."}
> h . f
>
> Thanks.
>
> The New Busy is not the too busy. Combine all your e-mail accounts with
> Hotmail. Get busy.
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Proof question -- (==) over Bool
For Bool, I'm not sure, but for, e.g., () it's certainly true. Take this definition of == () == _ = True Using case analysis of just the constructors, ignoring the value bottom, you can easily prove symmetry. But '() == undefined' terminates, whereas 'undefined == ()' does not. Ignore bottom at your own peril. BTW, the id function works fine on bottom, both from a semantic and implementation point of view. -- Lennart On Sun, May 23, 2010 at 11:23 AM, Alexander Solla wrote: > > On May 23, 2010, at 1:35 AM, Jon Fairbairn wrote: > >> It seems to me relevant here, because one of the uses to which >> one might put the symmetry rule is to replace an expression “e1 >> == e2” with “e2 == e1”, which can turn a programme that >> terminates into a programme that does not. > > I don't see how that can be (but if you have a counter example, please show > us). Even if we extend == to apply to equivalence classes of bottom values, > we would have to evaluate both e1 and e2 to determine the value of e1 == e2 > or e2 == e1. > > Prelude> undefined == True > *** Exception: Prelude.undefined > Prelude> True == undefined > *** Exception: Prelude.undefined > Prelude> undefined == undefined > *** Exception: Prelude.undefined > > That is, if one case is exceptional, so is the other. > > You can't really even quantify over bottoms in Haskell, as a language. The > language runtime is able to do some evaluation and sometimes figure out that > a bottom is undefined. Sometimes. But the runtime isn't a part of the > language. The runtime is an implementation of the language's interpetation > function. Bottoms are equivalent by conceptual fiat (in other words, > vacuously) since not even the id :: a -> a function applies to > them.___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ShowList magic
Your question is actually deeper than some of the people answering you
seem to realize.
How does ghci decide what to do when you say
show []
?
The expression [] has type [a], which means it could be a list of any
type 'a', including Char.
Normally, when Haskell can't determine the type in this kind of
context it will complain.
You can try compiling the program
main = putStrLn (show [])
and you'll see the error message.
But in ghci there is a special defaulting rule that will use the type
() ambiguous types.
So ghci will use the 'Show ()' instance, which uses the default
implementation for showList.
-- Lennart
On Mon, May 17, 2010 at 4:56 AM, Abby Henríquez Tejera
wrote:
> Hi.
>
> I'm a Haskell newbie and there's a bit of Haskell code that I don't
> understand how it works. In the prelude, defining the class Show, the
> function showList is implemented twice, one for String and another one
> for other lists:
>
> showList cs = showChar '"' . showl cs
> where showl "" = showChar '"'
> showl ('"':cs) = showString "\\\"" . showl cs
> showl (c:cs) = showLitChar c . showl cs
>
> and
>
>
>
> showList [] = showString "[]"
> showList (x:xs) = showChar '[' . shows x . showl xs
> where showl [] = showChar ']'
> showl (x:xs) = showChar ',' . shows x .
> showl xs
>
> The thing is... how does Haskell «know» which to execute? It works
> even for the blank string:
> Prelude> show ""
> "\"\""
> Prelude> show []
> "[]"
>
> Salud,
> Abby
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Integers v ints
The cost factor of Integer vs Int is far, far smaller than the factor between computable reals vs Double. On Thu, Apr 1, 2010 at 6:33 PM, Jens Blanck wrote: > Yes, the cost for computable reals will be an order of magnitude or possibly > two for well-behaved computations. For not well-behaved problems it will be > much worse, but it won't return nonsense either. Also consider that the > difference between Integers and unboxed Ints is also quite big. I'll happily > to take the hit. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: data-category, restricted categories
Of course Haskell' should have an empty case. As soon as empty data declarations are allowed then empty case must be allowed just by using common sense. On Tue, Mar 30, 2010 at 11:03 PM, Ashley Yakeley wrote: > wagne...@seas.upenn.edu wrote: >> >> I believe I was claiming that, in the absence of undefined, Nothing and >> Nothing2 *aren't* isomorphic (in the CT sense). > > Well, this is only due to Haskell's difficulty with empty case expressions. > If that were fixed, they would be isomorphic even without undefined. > > -- > Ashley Yakeley > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Where are the haskell elders?
What Don said. 2010/3/29 Don Stewart : > gue.schmidt: >> Hi all, >> >> I notice that posts from the Haskell elders are pretty rare now. Only >> every now and then we hear from them. >> >> How come? > > Because there is too much noise on this list, Günther > > -- Don > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC vs GCC vs JHC
Does anything change if you swap the first two rhss? On Sun, Mar 28, 2010 at 1:28 AM, Roman Leshchinskiy wrote: > On 28/03/2010, at 09:47, Lennart Augustsson wrote: > >> It's important to switch from mod to rem. This can be done by a >> simple abstract interpretation. > > Also, changing the definition of rem from > > a `rem` b > | b == 0 = divZeroError > | a == minBound && b == (-1) = overflowError > | otherwise = a `remInt` b > > to > > a `rem` b > | b == 0 = divZeroError > | b == (-1) && a == minBound = overflowError > | otherwise = a `remInt` b > > speeds up the GHC version by about 20%. Figuring out why is left as an > exercise to the reader :-) > > Roman > > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC vs GCC vs JHC
It's important to switch from mod to rem. This can be done by a simple abstract interpretation. I'm nore sure if it's jhc or gcc that does this for jhc. -- Lennart On Sat, Mar 27, 2010 at 10:30 PM, Rafael Cunha de Almeida wrote: > John Meacham wrote: >> Here are jhc's timings for the same programs on my machine. gcc and ghc >> both used -O3 and jhc had its full standard optimizations turned on. >> >> jhc: >> ./hs.out 5.12s user 0.07s system 96% cpu 5.380 total >> >> gcc: >> ./a.out 5.58s user 0.00s system 97% cpu 5.710 total >> >> ghc: >> ./try 31.11s user 0.00s system 96% cpu 32.200 total >> >> >> As you can see, jhc shines at this example, actually beating gcc -O3. It >> isn't too surprising, this is exactly the sort of haskell code that jhc >> excels at. > > What's the property of that code which makes jhc excels in it? What > makes ghc perform so poorly in comparison? > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bytestrings and [Char]
Turn on OverloadedStrings and you can pattern match on any type you like that is in the IsString class. Which means that Data.Text can use string literals just like regular strings (but you can't use Char literals in the match). On Mon, Mar 22, 2010 at 1:15 PM, Ivan Miljenovic wrote: > On 23 March 2010 00:10, Johan Tibell wrote: >> A sequence of bytes is not the same thing as a sequence of Unicode >> code points. If you want to replace String by something more efficient >> have a look at Data.Text. > > Though Data.Text still has the disadvantage of not being as nice to > deal with as String, since you can't pattern match on it, etc. > > Whilst it may degrade performance, treating String as a list of > characters rather than an array provides you with greater flexibility > of how to deal with it. > > -- > Ivan Lazar Miljenovic > ivan.miljeno...@gmail.com > IvanMiljenovic.wordpress.com > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proper round-trip HughesPJ/Parsec for Doubles?
If you use read (reads) and show for the actual conversion it will round trip. It appears to be non-trivial since most languages and libraries get it wrong. :) -- Lennart On Tue, Feb 23, 2010 at 1:44 PM, Andy Gimblett wrote: > Hi all, > > Short version: How can I pretty print and parse values of type Double such > that those operations are each other's inverse? > > Long version: I'm writing and QuickCheck-testing a parser using the approach > set out here: > > http://lstephen.wordpress.com/2007/07/29/parsec-parser-testing-with-quickcheck/ > > That is, each syntactic category gets a pretty-printer and a parser and an > Arbitrary instance, and QuickCheck checks that (parse . prettyPrint) == id, > basically. Somewhat unsurprisingly, this sometimes fails for floating point > values (I'm using Doubles). > > Now, I know that floats are in some sense imprecise, and comparing for > equality is fraught with peril, but it seems that if x==x then it ought to > be at least _possible_ to arrange matters such that (parse . prettyPrint x) > == x as well. At worst, pretty-printing the underlying binary > representation!? So my feeling is that my parser could be improved. > > At the moment I'm working around it by defining a type class which checks > for equality within some margin of error, and using that instead of Eq - but > it's messier than I'd like, so I wondered if there was something obvious I'm > missing. > > As hpaste.org seems to be down, I'll attach a code example here instead. > > Thanks! > > -Andy > > -- > Andy Gimblett > http://gimbo.org.uk/ > > > > > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC RTS question
Supply a fix for the problem, and it will probably get included. There has probably been little demand for this feature so far. -- Lennart On Sun, Feb 21, 2010 at 10:21 PM, Ben Millwood wrote: > On Sun, Feb 21, 2010 at 7:10 PM, Max Bolingbroke > wrote: >> >> You might be able to get somewhere by writing a custom "main" function >> in C and linking it in. According to >> http://haskell.org/ghc/docs/latest/html/users_guide/options-phases.html >> if a lib specified with the -l option during compilation contains a >> "main", that will be used in preference to the one from HSrts. >> > > I think the neater way of doing this would be to use the FFI, with a > foreign export declaration making your haskell main available to a > wrapper C file, which would then initialise the RTS with a > slightly-modified argc and argv. > See http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html > for details on how to do that. > > I also think it's strange, though, that adding RTS hooks is not > optional. GHC should support some method of disabling them, in my > opinion. > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell-src type inference algorithm?
Well, something like such a tool exists, but I can't give it away. On Fri, Feb 12, 2010 at 12:13 AM, Niklas Broberg wrote: >> Anyone know of a type inference utility that can run right on haskell-src >> types? or one that could be easily adapted? > > This is very high on my wish-list for haskell-src-exts, and I'm hoping > the stuff Lennart will contribute will go a long way towards making it > feasible. I believe I can safely say that no such tool exists (and if > it does, why haven't you told me?? ;-)), but if you implement (parts > of) one yourself I'd be more than interested to see, and incorporate, > the results. > > Cheers, > > /Niklas > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell-src type inference algorithm?
It does type inference, it's just not engineered to be part of a real compiler. On Thu, Feb 11, 2010 at 6:41 PM, Stephen Tetley wrote: > http://web.cecs.pdx.edu/~mpj/thih/ > > Looks like its a type _checker_ though... > > > On 11 February 2010 17:39, Stephen Tetley wrote: >> Hello Job >> >> For Haskell 98 would the code from 'Typing Haskell in Haskell' paper suffice? >> >> A web search should find the code... >> >> Best wishes >> >> Stephen >> > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell-src type inference algorithm?
To do anything interesting you also to process modules, something which I hope to contribute soon to haskell-src-exts. On Thu, Feb 11, 2010 at 6:35 PM, Job Vranish wrote: > Anyone know of a type inference utility that can run right on haskell-src > types? or one that could be easily adapted? > I want to be able to pass in an HsExp and get back an HsQualType. It doesn't > have to be fancy, plain Haskell98 types would do. > > It wouldn't be to hard to make one myself, but I figured there might be one > floating around already and it'd be a shame to write it twice :) > > Thanks, > > - Job > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: could we get a Data instance for Data.Text.Text?
> The only safe rule is: if you don't control the class, C, or you don't > control the type constructor, T, don't make instance C T. I agree in principle, but in the real world you can't live by this rule. Example, I want to use Uniplate to traverse the tree built by haskell-src-exts, Using Data.Data is too slow, so I need to make my own instances. HSE provides like 50 types that need instances, and it has to be exactly those types. Also, Uniplate requires instances of a particular class it has. I don't own either of these packages. Including the HSE instances in Uniplate would just be plain idiotic. Including the Uniplate instances with HSE would make some sense, but would make HSE artificially depend on Uniplate for those who don't want the instances. So, what's left is to make orphan instances (that I own). It's not ideal, but I don't see any alternative to it. -- Lennart ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Language simplicity
PL/I has keywords, they're just not reserved words. With as many keywords as PL/I has, there something to say for not making them reserved. :) On Wed, Jan 13, 2010 at 11:50 AM, Brandon S. Allbery KF8NH wrote: > On Jan 13, 2010, at 05:45 , Ketil Malde wrote: >> >> "Brandon S. Allbery KF8NH" writes: >>> >>> If we're going to go that far, FORTRAN and PL/1 have none. FORTRAN is >>> somewhat infamous for this: >> >> There's also the option (perhaps this was PL/1?) of writing constructs >> like: IF THEN THEN IF ELSE THEN etc. Having few reserved words isn't >> necessarily a benefit. :-) > > That'd be PL/I, and a prime example of why languages use keywords these days > (as if FORTRAN weren't enough). :) > > -- > brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com > system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu > electrical and computer engineering, carnegie mellon university KF8NH > > > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to get a list of constructors for a type?
I've put some of Oleg's code on hackage, named polytypeable. > import Data.PolyTypeable > main = print [polyTypeOf Nothing, polyTypeOf Just] This prints [Maybe a1,a1 -> Maybe a1] To get a list of the actual constructors you need to derive Data.Data.Data and use that. -- Lennart On Wed, Dec 30, 2009 at 8:46 PM, Claude Heiland-Allen wrote: > Gregory Propf wrote: >> >> Say I have something like >> >> data DT a = Foo a | Bar a | Boo a >> >> I want something like a list of the constructors of DT, perhaps as >> [TypeRep]. I'm using Data.Typeable but can't seem to find what I need in >> there. Everything there operates over constructors, not types. > > The approach below won't work in general because the constructors may have > different (argument) types, but for the above: > > [Foo, Bar, Boo] :: [a -> DT a] > > And you could manually build a list of constructor types, as a try: > > [typeOf Nothing, typeOf Just] :: [TypeRep] > > which doesn't work, due to polymorphic ambiguity, so you'd have to: > > [typeOf (Nothing :: Maybe Int), typeOf (Just :: Int -> Maybe Int)] > > In general, maybe Data.Dynamic is what you need, but I don't think that can > handle polymorphic values yet either. > > What do you want to do with the list of constructors once you have them? > > Where are they defined? > > > Claude > -- > http://claudiusmaximus.goto10.org > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: repr-0.3.2
Did you consider using the traced package? 2009/12/24 Bas van Dijk : > On Thu, Dec 24, 2009 at 1:00 AM, Andrey Sisoyev > wrote: >> Where do you make use of it? :) > > A few months ago I was working on 'levmar'[1] a Levenberg-Marquardt > data fitting library in Haskell. If you want your data fitting to be > really fast you need to supply a Jacobian of the model function you > want to fit. A Jacobian describes the partial derivatives of the > parameters of the model function. I used Conal Elliott's > vector-space[2] library to automatically derive a Jacobian from the > model function. > > I was interested in the derivatives vector-space would come up with. A > derivative however, is just a function so the only thing you can do > with it is apply it to a value. This then yields a result which is > usually just a Double. I wasn't really interested in this actual > numeric result but more in the underlying numeric expressing that > generated that result. > > So I wrote repr to visualize this numeric expression. However, after I > wrote repr, the work on levmar stalled a bit and I did not actually > get around to applying repr to the derivatives. I plan to make a new > release of levmar in the coming weeks or so and I think I will use > repr then. > > regards, > > Bas > > [1] http://hackage.haskell.org/package/levmar > [2] http://hackage.haskell.org/package/vector-space > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Zumkeller numbers
And if you use quotRem it's faster (unless you're running on some exotic hardware like NS32K). On Tue, Dec 8, 2009 at 10:19 PM, Richard O'Keefe wrote: > > On Dec 9, 2009, at 1:15 AM, Daniel Fischer wrote: > >> Am Dienstag 08 Dezember 2009 08:44:52 schrieb Ketil Malde: >>> >>> "Richard O'Keefe" writes: factors n = [m | m <- [1..n], mod n m == 0] >>> >>> -- saves about 10% time, seems to give the same result: >>> factors n = [m | m <- [1..n `div` 2], mod n m == 0]++[n] >> >> Even faster (for large enough n): >> >> factors n = >> mergeAll [if q == d then [d] else [d, q] | d <- [1 .. isqrt n] >> , let (q,r) = n `divMod` d, r >> == 0] > > We can improve on that somewhat: > > factors 1 = [1] > factors n = 1 : candidates 2 4 n [n] > where candidates d d2 n hi = > if d2 < n then > let (q,r) = divMod n d in > if r == 0 then d : candidates (d+1) (d2+d+d+1) n (q:hi) > else candidates (d+1) (d2+d+d+1) n hi > else if d2 == n then d:hi else hi > > This never constructs a cons cell it doesn't mean to keep. > >> > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimization with Strings ?
Thank you Sir for giving me a good laugh! On Thu, Dec 3, 2009 at 5:25 PM, John D. Earle wrote: > Dear Emmanuel Chantréau, > > You may want to look into Objective CAML http://caml.inria.fr/ which is a > French product as you can see from the Internet address. It is likely better > suited to the task than Haskell and has a reputation for speed. For those > who prefer object oriented programming it has facilities for that which may > ease your transition from C++. The Microsoft F# language is based on > Objective CAML. > > Haskell has a problem with its type system and is not rigorous. Haskell is > not a suitable language for proof assistants and so I would advise you to > stay clear of Haskell. Standard ML was engineered with the needs of proof > assistants in mind and so you may want to look into Standard ML, but you > should be very happy with Objective CAML. It has an excellent reputation. > The Coq proof assistant which is another French product is based on > Objective CAML. > > If you do decide that Haskell is the way, it will help ease your transition > to Haskell. There is nothing that says you can't keep your fingers in > several pies at once. > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Coercing numeric and string constants
Try with -XExtendedDefaulingRules.
On Mon, Nov 16, 2009 at 6:33 AM, Mark Lentczner wrote:
> I'm looking for a good way to handle a library interface that accepts both
> strings and numbers in particular argument positions:
>
> Start with the following definitions. I've defined ResourceTree as a class
> here since the details don't matter.
>
>> data Segment = Key String | Index Int
>> deriving (Eq, Show)
>>
>> type Path = [Segment]
>>
>> class ResourceTree a where
>> lookupPath :: Path -> a -> Maybe String
>
> What I'm after is to make the following code, representative of intended
> client usage to work:
>
>> examples :: (ResourceTree a) => a -> [Maybe String]
>> examples r = [
>> r `at` "status",
>> r `at` 7,
>> r `at` "part" ./ "sku",
>> r `at` "items" ./ 2,
>> r `at` 7 ./ "name",
>> r `at` 7 ./ 9
>> ]
>
> The first way I thought to do this was with type classes:
>
>> class Segmentable a where { toSegment :: a -> Segment }
>> instance Segmentable Segment where { toSegment = id }
>> instance Segmentable String where { toSegment = Key }
>> instance Segmentable Int where { toSegment = Index }
>>
>> class Pathable a where { toPath :: a -> Path }
>> instance Pathable Path where { toPath = id }
>> instance Pathable String where { toPath s = [ Key s ] }
>> instance Pathable Int where { toPath i = [ Index i ] }
>>
>> (./) :: (Segmentable a, Pathable b) => a -> b -> Path
>> a ./ b = toSegment a : toPath b
>> infixr 4 ./
>>
>> at :: (ResourceTree a, Pathable b) => a -> b -> Maybe String
>> a `at` b = lookupPath (toPath b) a
>> infix 2 `at`
>
> This works great for all uses in the client code where the type of the
> numeric arguments are known or otherwise forced to be Int. However, when used
> with numeric constants (as in the function example above), it fails due to
> the way that numeric constants are defined in Haskell. For example, the
> constant 9 in example results in this error:
>
> Ambiguous type variable `t4' in the constraints:
> `Pathable t4' arising from a use of `./' at Test.hs:48:15-20
> `Num t4' arising from the literal `9' at Test.hs:48:20
> Probable fix: add a type signature that fixes these type variable(s)
>
> I suppose that even though there is only one type that is both an instance of
> Num and of Pathable (Int), that can't be deduced with certainty.
>
> In the client code, one could fix this by typing the constants thus:
>
>> r `at` (7::Int) ./ (9::Int)
>
> But to me that makes a hash out of the concise syntax I was trying to achieve.
>
> Also, this code requires both FlexibleInstances and TypeSynonymInstances
> pragmas (though the later requirement could be worked around.), though I'm
> lead to understand that those are common enough. I think also that, these are
> only needed in the library, not the client code.
>
> The other way I thought to do this is by making Path and Segment instances of
> Num and IsString:
>
>> instance Num Segment where { fromInteger = Index . fromInteger }
>> instance IsString Segment where { fromString = Key . fromString }
>> instance Num Path where { fromInteger i = [ Index $ fromInteger i ] }
>> instance IsString Path where { fromString s = [ Key $ fromString s ] }
>>
>> (./) :: Segment -> Path -> Path
>> a ./ b = a : b
>> infixr 4 ./
>>
>> at :: (ResourceTree a) => a -> Path -> Maybe String
>> a `at` b = lookupPath b a
>> infix 2 `at`
>
> This works but has two downsides: 1) Segment and Path are poor instances of
> Num, eliciting errors for missing methods and resulting in run-time errors
> should any client code accidentally use them as such. 2) It requires the
> OverloadedStrings pragma in every client module.
>
> Any comments on these two approaches would be appreciated, How to improve
> them? Which is the lesser of two evils?
>
> On the other hand, I realize that many may object that intended interface
> isn't very Haskell like. The data object I need to represent (ResourceTree)
> comes from external input and really does have the strange "paths of strings
> or integers" construction, I can't change that. And it is expected that much
> client code will use constant paths to access and manipulate various parts of
> such objects, hence the desire for a concise operator set that works with
> constants. Given that there are actually several operations on ResourceTree
> involving paths (where the operation requires the whole Path as a single
> value), any thoughts on a more Haskell like construction?
>
> Thanks,
> - MtnViewMark
>
>
> Mark Lentczner
> http://www.ozonehouse.com/mark/
> m...@glyphic.com
>
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-
Re: [Haskell-cafe] Little errors in number calculations
Hugs is wrong, as you can easily see by evaluating let x = 123.35503 * 10.0 in x == read (show x) With ghc it comes out as True and with Hugs as False. -- Lennart On Sat, Nov 14, 2009 at 9:00 PM, Abby Henríquez Tejera wrote: > Hi. > > I've seen that in GHC sometimes there are little errors in some basic > number calculations: > > *Prelude> 123.35503 * 10.0 > 1233.55029 > > *Prelude> properFraction 123.35503 > (123,0.35502993) > > whereas in Hugs no such errors seem to occur (that I have found, at > least): > > *Hugs> 123.35503 * 10.0 > 1233.5503 > > (but:) > > *Hugs> properFraction 123.35503 > (123,0.3550299) > > I understand that error may (and will) happen in floating point, but > it surprises me that they do so easily, and, above all, the difference > between GHC and Hugs. Does someone know why does this difference > occur? > > (Thanks in advance, by the way :) ). > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What does the `forall` mean ?
Of the two declarations >data Fizzle a = Fizzle (b -> (a, b)) a >data Fizzle a = forall b. Fizzle (b -> (a, b)) a only the second one is allowed (with some suitable extension). Personally I think the first one should be allowed as well, with the same meaning as the second one. Some people thought it was to error prone not to have any indication when an existential type is introduced, so instead we are now stuck with a somewhat confusing keyword. -- Lennart On Sat, Nov 14, 2009 at 4:55 PM, Mark Lentczner wrote: > On Nov 12, 2009, at 2:59 PM, Sean Leather wrote: >> foo :: forall x y. (x -> x) -> y >> bar :: forall y. (forall x . x -> x) -> y >> >> While neither function is seemingly useful, the second says that the >> higher-order argument must be polymorphic. I see two options: > > AHA! This is the bit of insight I needed! My confusion over forall was I > thought that I understood that all Haskell types were as if there was a > forall for all free type variables in front of the expression. For example, I > think the following are the same: > > fizz :: a -> String -> [a] > fizz :: forall a. a -> String -> [a] > > So why would you need forall? The example Sean explained is that if you want > to control the scope of the existential quantification. And you can only > "push the scope inward", since the outer most scope basically "forall"s all > the free type variables (after type inference, I suppose.) > > I also think I understand that the implicit 'forall' inherent in Haskell > falls at different places in various constructs, which also had me confused. > For example, while the above two function type declarations are equivalent, > these two data declarations aren't: > > data Fizzle a = Fizzle (b -> (a, b)) a > data Fizzle a = forall b. Fizzle (b -> (a, b)) a > > This would be because the implicit 'forall' is essentially to the left of the > 'data Fizzle a' section. I'm guessing that the same holds true for type and > newtype constructs. > > Have I got this all correct? > > Would I be correct in thinking: The difference between these two is that the > type b can be "fixed" upon application of amy to the first two arguments > (given context), whereas bob applied to two arguments MUST return a function > that is applicable to every type. > > amy :: Int -> a -> b -> [Either a b] > bob :: Int -> a -> (forall b. b) -> [Either a b] > > Thanks for helping me understand... > - Mark > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Opinion about JHC
Thanks Neil, That was indeed my point. Since a compiler is a substantial program I would have more confidence it a compiler that is self-hosting. Surely you must have tried? -- Lennart On Fri, Nov 13, 2009 at 8:08 PM, Neil Mitchell wrote: > Hi John, > >>> Do you use jhc when you develop jhc? I.e., does it compile itself. >>> For me, this is the litmus test of when a compiler has become usable. >>> I mean, if even the developers of a compiler don't use it themselves, >>> why should anyone else? :) >> >> Well, this touches on another issue, and that is that jhc is a native >> cross-compiler. It never behaves differently if compiled by another >> haskell compiler or is compiled on an alternate platform. There is never >> a need to 'bootstrap' it, once you have jhc running anywhere then it is >> as good as it would be if it is running everywhere. So to me, >> self-hosting has never been a big issue as it doesn't provide any direct >> "material" benefit. My time is better spent implementing more extensions >> or improving the back end. > > I think you might have missed Lennart's point. It's fair to say you do > a lot of Haskell development work while writing a Haskell compiler. If > you aren't using your compiler for your development work (in > particular for your compiler) then anyone trying to use it is likely > to bump in to problems. It's not that there are technical advantages > of self-compilation, but it is a good statement of faith from the > compiler author. > > Anyway, I think the Haskell community needs more compilers, so I wish > you lots of luck with JHC! > > Thanks, Neil > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Opinion about JHC
If by minority platform you mean platforms that are resource starved, like some embedded systems, then I would have to agree. -- Lennart On Wed, Nov 11, 2009 at 2:12 PM, Donn Cave wrote: > Quoth Lennart Augustsson , > >> Do you use jhc when you develop jhc? I.e., does it compile itself. >> For me, this is the litmus test of when a compiler has become usable. >> I mean, if even the developers of a compiler don't use it themselves, >> why should anyone else? :) > > Though that's exactly backwards for minority platforms, where the > compilers that compile themselves tend to be no use whatever. > > Donn Cave, d...@avvanta.com > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Opinion about JHC
John, Do you use jhc when you develop jhc? I.e., does it compile itself. For me, this is the litmus test of when a compiler has become usable. I mean, if even the developers of a compiler don't use it themselves, why should anyone else? :) -- Lennart On Wed, Nov 11, 2009 at 3:37 AM, John Meacham wrote: > On Tue, Nov 10, 2009 at 07:41:54PM -0800, Philippos Apolinarius wrote: >> I discovered a Haskell compiler that generates very small and fast >> code. In fact, it beats Clean. It has the following properties: > > Excellent. that was my goal ;) > >> 1 --- One can cross-compile programs easily. For instance, here is how I >> generated code for Windows: >> >> jhc --cross -mwin32 genetic.hs -o genetic > > Yup. This was a major goal. compiling for iPhones and embedded arches is > just as easy assuming you have a gcc toolchain set up. (at least with > the hacked iPhone SDK.. I have never tried it with the official one) > >> >> 2 -- It seems to be quite complete. >> >> 3 -- However, it often compiles a file, but the program fails to run. >> >> I have the following questions about it: >> >> 1 -- How active is the team who is writing the JHC compiler? > > Hi, I am the main contributor, but others are welcome and several have > made signifigant contributions. Development tends to be spurty. A lot of > work will get done in a short amount of time, this generally corresponds > to when an external contributor gets involved and the back and forth > helps stimulate patches on my part to complement theirs. > > Although I have not been able to devote a lot of my time to jhc in the > past, hopefully this will change in the not to distant future and I will > be able to work on it full time. > > >> 2 -- Is it complete Haskell? The author claims that it is; it compiled >> all programs that I wrote, but that does not mean much, because my >> programs are quite simple. > > It does Haskell 98 and several extensions, which is pretty much what GHC > does. However, it does not implement the same set of extensions as GHC > so this causes issues as a lot of people use GHC extensions extensively. > > I plan on supporting all of Haskell' of course, and the popular GHC > extensions to help compatibility. Not all are implemented. > >> 3 -- Why the Haskell community almost never talks about JHC? > > Part of it is that I am not very good at advocacy. I don't always > post announcements on the main haskell lists figuring the interested > parties are on the jhc list already. I do try to make jhc good, fast, > and usable, I always hoped someone better at advocacy than me would join > the project :) In truth, I think the spurty nature of development also > affects this, the list will be quite for a long time with a flurry of > development lasting a few weeks occasionally inspiring some discussion > in the other groups. > > In any case, I am glad you liked what you found! please join the mailing > list for jhc if you are interested in its development or using it. > > John > > > > -- > John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/ > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pretty printing with comments
It's not an easy problem to pretty print (i.e. change indentation) and
preserve the comments. And always get it right.
On Tue, Oct 20, 2009 at 1:28 PM, Pasqualino "Titto" Assini
wrote:
> Thanks Niklas,
>
> in fact this produced a source with comments:
>
>
> import Language.Haskell.Exts.Annotated
>
> main = do
> (ParseOk (mod,comments)) <- parseFileWithComments defaultParseMode "Test.hs"
> let pretty = exactPrint mod comments
> writeFile "Test_PRETTY.hs" pretty
>
>
>
> However:
> - The source code produced was incorrect:
>
>
> class Dir d where
>
> was rewritten as:
>
> class Dir dwhere{
>
>
> And:
>
> instance Dir Directory where
> localDir (Local f) = return f
>
> type URL= String
>
>
> was rewritten as:
>
>
> instance Dir Directory where
> localDir (Local f) = return f
>
> typeURL= String
>
>
> Are these known bugs?
>
>
> - Also, the printing is a bit too exact :-), I would like to keep my
> comments AND get the code nicely reformatted.
>
>
> Is there a way?
>
> What people use to keep their haskell source files in tip-top shape?
>
> Thanks
>
> titto
>
>
>
>
>
>
> 2009/10/20 Niklas Broberg :
>> Hi Pasqualino,
>>
>>> I am looking at the haskell-src-ext library.
>>>
>>> It can parse files with comments and it can pretty print but, for what
>>> I can see it cannot do both :-) (prettyPrint won't work on the
>>> structure returned by parseFileWithComments).
>>
>> What you want is exactPrint, defined in
>> Language.Haskell.Exts.Annotated.ExactPrint. :-)
>>
>> Cheers,
>>
>> /Niklas
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Exponential complexity of type checking (Was: Type-level naturals & multiplication)
Yes, there are simple H-M examples that are exponential. x0 = undefined x1 = (x1,x1) x2 = (x2,x2) x3 = (x3,x3) ... xn will have a type with 2^n type variables so it has size 2^n. -- Lennart On Tue, Oct 13, 2009 at 6:04 PM, Brad Larsen wrote: > On Tue, Oct 13, 2009 at 3:37 AM, Simon Peyton-Jones > wrote: >> | > Is there any way to define type-level multiplication without requiring >> | > undecidable instances? >> | >> | No, not at the moment. The reasons are explained in the paper "Type >> | Checking with Open Type Functions" (ICFP'08): >> | >> | http://www.cse.unsw.edu.au/~chak/papers/tc-tfs.pdf >> | >> | We want to eventually add closed *type families* to the system (ie, >> | families where you can't add new instances in other modules). For >> | such closed families, we should be able to admit more complex >> | instances without requiring undecidable instances. >> >> It's also worth noting that while "undecidable" instances sound scary, but >> all it means is that the type checker can't prove that type inference will >> terminate. We accept this lack-of-guarantee for the programs we *run*, and >> type inference can (worst case) take exponential time which is not so >> different from failing to terminate; so risking non-termination in type >> inference is arguably not so bad. >> >> Simon >> > > I have written code that makes heavy use of multi-parameter type > classes in the ``finally tagless'' tradition, which takes several > seconds and many megabytes of memory for GHCI to infer its type. > However, that example is rather complicated, and I am not sure its > type inference complexity is exponential---it is at least very bad. > > Are there any simple, well-known examples where Haskell type inference > has exponential complexity? Or Hindley-Milner type inference, for > that matter? (Haskell 98 is not quite Hindley-Milner?) > > Sincerely, > Brad Larsen > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] type inference question
Indeed, the types foo :: forall a . (Num a) => a -> (Int, Float) and foo :: (forall a . (Num a) => a) -> (Int, Float) are quite different. The first one say, I (foo) can handle any kind of numeric 'a' you (the caller) can pick. You (the caller) get to choose exactly what type you give me. The second one says, I (foo) require you (the caller) to give me an numeric 'a' that I can use any way I want. You (the caller) don't get to choose what type you give me, you have to give me a polymorphic one. -- Lennart On Thu, Oct 8, 2009 at 5:35 PM, Bulat Ziganshin wrote: > Hello Cristiano, > > Thursday, October 8, 2009, 7:14:20 PM, you wrote: > >> Could you explain why, under NoMonomorphismRestriction, this typechecks: > >> let a = 1 in (a + (1 :: Int),a + (1 :: Float)) > >> while this not: > >> foo :: Num a => a -> (Int,Float) >> foo k = (k + (1 :: Int), k + (1.0 :: Float)) > > i think it's because type is different: > > foo :: (forall a. (Num a) => a) -> (Int,Float) > > in first equation it probably inferred correctly > > > > -- > Best regards, > Bulat mailto:bulat.zigans...@gmail.com > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] type inference question
The reason a gets a single type is the monomorphism restriction (read
the report).
Using NoMonomorphismRestriction your example with a works fine.
On Thu, Oct 8, 2009 at 12:29 PM, Cristiano Paris wrote:
> On Thu, Oct 8, 2009 at 11:04 AM, minh thu wrote:
>> Hi,
>>
>> I'd like to know what are the typing rules used in Haskell (98 is ok).
>>
>> Specifically, I'd like to know what makes
>>
>> let i = \x -> x in (i True, i 1)
>>
>> legal, and not
>>
>> let a = 1 in (a + (1 :: Int), a + (1.0 :: Float))
>>
>> Is it correct that polymorphic functions can be used polymorphically
>> (in multiple places) while non-functions receive a monomorphic type ?
>
> First, "1" IS a constant function so it's in no way special and is a
> value like any other.
>
> That said, the type of 1 is (Num t) => t, hence polymorphic. But, when
> used in the first element of the tuple, a is assigned a more concrete
> type (Int) which mismatches with the second element of the tuple,
> which is a Float.
>
> If you swap the tuple, you'll find that the error reported by ghci is
> the very same as before, except that the two types are swapped.
>
> Is it possible to rewrite the expression so as to work? The answer is
> yes, using existential quantification (and Rank2 polymorphism).
>
> Here you are:
> {-# LANGUAGE ExistentialQuantification, Rank2Types #-}
> foo :: (forall a. (Num a) => a) -> (Int,Float)
> foo = \x -> (x + (1 :: Int), x + (1 :: Float))
>
> Hence:
>
> foo 1 --> (2,2.0)
>
> Bye,
>
> Cristiano
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is a number. (Was: Num instances for 2-dimensional types)
OK, "just pairs" have no arithmetic, but one way of defining arithmetic is to treat the pairs as complex numbers. Or as mantissa and exponent. Or as something else. So there's nothing wrong, IMO, to make pairs an instance of Num if you so desire. (Though I'd probably introduce a new type.) On Mon, Oct 5, 2009 at 6:46 PM, Miguel Mitrofanov wrote: >> "Just pairs" have no natural arithmetic upon them. > > Exactly my point. > >> BTW. the missing term of M.M. is DUAL NUMBERS. > > Remembered this already. Thanks anyway. > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Num instances for 2-dimensional types
Complex numbers are just pairs of numbers, and then the various operations on them are defined in a specific way. There may be other ways to define the operations on pairs of numbers that makes sense too. You can also view complex numbers as polynomials if you wish. Or two element lists of numbers. My real point is that you shouldn't tell others what they should regard as numbers and what not. Being a number is in the eye of the beholder. :) On Mon, Oct 5, 2009 at 4:55 PM, Miguel Mitrofanov wrote: > No, they aren't. They are polynomials in one variable "i" modulo i^2+1. > > Seriously, if you say complex numbers are just pairs of real numbers - you > have to agree that double numbers (sorry, don't know the exact English > term), defined by > > (a,b)+(c,d) = (a+c,b+d) > (a,b)(c,d) = (ac, ad+bc) > > are just pairs of real numbers too. After that, you have two choices: a) > admit that complex numbers and double numbers are the same - and most > mathematicians would agree they aren't - or b) admit that the relation "be > the same" is not transitive - which is simply bizarre. > > > Lennart Augustsson wrote: >> >> But complex numbers are just pairs of numbers. So pairs of numbers >> can obviously be numbers then. >> >> On Mon, Oct 5, 2009 at 4:40 PM, Miguel Mitrofanov >> wrote: >>> >>> Lennart Augustsson wrote: >>>> >>>> And what is a number? >>> >>> Can't say. You know, it's kinda funny to ask a biologist what it means to >>> be >>> alive. >>> >>>> Are complex numbers numbers? >>> >>> Beyond any reasonable doubt. Just like you and me are most certainly >>> alive. >>> >> ___ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Num instances for 2-dimensional types
Everyone agrees that the Haskell numeric hierarchy is flawed, but I've yet to see a good replacement. On Mon, Oct 5, 2009 at 4:51 PM, Brad Larsen wrote: > On Mon, Oct 5, 2009 at 10:36 AM, Miguel Mitrofanov > wrote: > [...] >> Of course, it's OK to call anything "numbers" provided that you stated >> explicitly what exactly you would mean by that. But then you have to drop >> all kind of stuff mathematicians developed for the usual notion of numbers. >> In the same way, you shouldn't use the "Num" class for your "numbers". >> >> On the other hand, people can (ab)use the "Num" class as they wish, and it's >> their business until they ask a question about it somewhere outside - which >> makes the business not only theirs. > [...] > > The Num class has `negate' as part of its definition. Natural numbers > are numbers, but I don't believe there is any sensible definition of > `negate' for them. > > Haskell 98's numeric hierarchy combines many operations which should > be separate. As further evidence, every bit of Haskell I have seen > that does symbolic manipulation of numeric expressions either leaves > out instances that would make the syntax more convenient, or else > defines partial instances because certain class functions have no > sensible definition for symbolic expressions. > > Sincerely, > Brad > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Num instances for 2-dimensional types
But complex numbers are just pairs of numbers. So pairs of numbers can obviously be numbers then. On Mon, Oct 5, 2009 at 4:40 PM, Miguel Mitrofanov wrote: > Lennart Augustsson wrote: >> >> And what is a number? > > Can't say. You know, it's kinda funny to ask a biologist what it means to be > alive. > >> Are complex numbers numbers? > > Beyond any reasonable doubt. Just like you and me are most certainly alive. > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Num instances for 2-dimensional types
And what is a number? Are complex numbers numbers? On Mon, Oct 5, 2009 at 3:12 PM, Miguel Mitrofanov wrote: > > > Sönke Hahn wrote: > >> I used to implement >> >> fromInteger n = (r, r) where r = fromInteger n >> >> , but thinking about it, >> fromInteger n = (fromInteger n, 0) >> >> seems very reasonable, too. > > Stop pretending something is a number when it's not. > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Is logBase right?
Prelude> toRational 697.04157958259998 3065621287177675 % 4398046511104 Prelude> toRational 697.0415795826 3065621287177675 % 4398046511104 As you can see, both numbers are represented by the same Double. Haskell prints a Double with the simplest number that converts back to the same bit pattern. So there's no "keep more decimals", just a matter of string conversion. -- Lennart On Tue, Aug 25, 2009 at 7:11 PM, Ketil Malde wrote: > Steve writes: > >> Also, I had a problem using floating point in Python where >>>>> round(697.04157958254996, 10) >> gave >> 697.04157958259998 > >> Its been fixed in the latest versions of Python: >>>>> round(697.04157958254996, 10) >> 697.0415795825 > >> ghci> roundN 697.04157958254996 10 >> 697.0415795826 > > Is there something special with this number? > > Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) > [GCC 4.3.3] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> 697.04157958259998 > 697.04157958259998 > >>> 12345.678901234567890 > 12345.678901234567 > > GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help > Loading package base ... linking ... done. > Prelude> 697.04157958259998 > 697.0415795826 > Prelude> 12345.678901234567890 > 12345.678901234567 > > So, Python manages to keep more decimals than GHC for your number, but > for other numbers, the precision appears to be the same. > > -k > -- > If I haven't seen further, it is by standing in the footprints of giants > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Is logBase right?
I don't really care much one way or the other, but since C (math.h) provides functions for base 2 and base 10 with some additional accuracy, I wouldn't mind using them. For a constant base I'd expect the extra comparison to be constant folded, so that's ok. For a non-constant base there would be a small penalty. -- Lennart On Tue, Aug 25, 2009 at 3:20 PM, Henning Thielemann wrote: > > On Sun, 23 Aug 2009, Lennart Augustsson wrote: > >> You're absolutely right. It would be easy to change logBase to have >> special cases for, say, base 2 and base 10, and call the C library >> functions for those. In fact, I think it's a worth while change, >> since it's easy and get's better results for some cases. > > I think, the current implementation should left as it is. For fractional > bases, no one would easily detect such imprecise results and report them as > problem. So, it seems like people need a logarithm of integers, so they > should be supplied with a special logarithm function for integers. For the > other use cases, where 10 as base is one choice amongst a continuous set of > rational numbers it would not be a problem to give the imprecise result. In > the general case I would not accept a speed loss due to a check against 2 > and 10 as base. > > In dynamically typed languages like Python this might be different, because > their users might not care much about types. It may not be important for > them, whether a number is an integer or a floating point number that is > accidentally integral. However, Python distinguishes between these two kinds > of integers, but only dynamically. > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Is logBase right?
You're absolutely right. It would be easy to change logBase to have special cases for, say, base 2 and base 10, and call the C library functions for those. In fact, I think it's a worth while change, since it's easy and get's better results for some cases. -- Lennart On Sun, Aug 23, 2009 at 12:41 PM, Steve wrote: > On Sat, 2009-08-22 at 13:03 -0400, haskell-cafe-requ...@haskell.org > wrote: >> Message: 10 >> Date: Sat, 22 Aug 2009 11:24:21 +0200 >> From: Roberto L?pez >> Subject: [Haskell-cafe] Re: Is logBase right? >> To: haskell-cafe@haskell.org >> Message-ID: >> Content-Type: text/plain; charset="ISO-8859-1" >> >> If 4.0 / 2.0 was 1.98, it would be ok? >> >> The real value of log10 1000 is 3 (3.0). It can be represented with >> accuracy >> and it should be. >> >> You get the accuracy value in Perl, but there is the same problem in >> Python. >> It's a bit discouraging. >> > > There is *not* the same problem in Python: > $ python > Python 2.6.2 (r262:71600, Jul 9 2009, 23:16:53) > [GCC 4.4.0 20090506 (Red Hat 4.4.0-4)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. >>>> import math >>>> math.log10(1000) > 3.0 > > Recent work in Python 3 (and Python 2.6) has improved the handling of > floating point numbers, and addresses exactly the problem that Roberto > has raised. > > I see no reason why Haskell could not improve its handling of floating > point numbers by using similar techniques. > > Steve > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unifcation and matching in Abelian groups
Even if you are only slightly irritated by offset syntax, why are you using it?
{;} works fine.
On Sat, Aug 22, 2009 at 3:51 AM, John D. Ramsdell wrote:
> Let me put all my cards on the table. You see, I really am only
> slightly irrigated by offset syntax. In contrast, I am a strong
> proponent of functional programming for parallel programming. In my
> opinion, it has to be the "new way" for multiprocessor machines. Just
> think about it and if other paradym could possibly work. We've tried
> many on them. Many years ago, I wrote SISAl programs. There were
> many good ideas in SISAL, but it did not catch on. Perhaps Data
> Parallel Haskell will catch on. In my opinion, something like it is
> the ``answer.'' Even though the code I submitted is not parallel,
> I've thought about how to make it so. And isn't thinking parallelism
> iour future? I think so.
>
> John
>
> On Thu, Aug 20, 2009 at 10:04 AM, Jules Bean wrote:
>> John D. Ramsdell wrote:
>>>
>>> On Thu, Aug 20, 2009 at 9:08 AM, Jules Bean wrote:
>>>
I don't find layout a problem, with good editor support. I agree it's a
problem, with poor editor support. That's all I meant.
>>>
>>> Let's put this issue in perspective. For those few Haskell
>>> programmers that do find layout irritating, I'm sure we would all
>>> agree it's but a minor irritation. The real downside of layout is if
>>> non-Haskell programmers use it as an excuse to dismiss the language.
>>> I happen to think that Data Parallel Haskell has great potential for
>>> use in high performance computations. I'd hate to see a bunch of
>>> Fortraners not try DPH because of Haskell syntax.
>>
>> Well that's a reasonable point.
>>
>> They can still use the non-layout form if it bothers them that much?
>>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] Re: Where do I put the seq?
The IO in hbc was (is) the old request-response model, on top of which there was also a continuation layer, as well as the monadic IO (once that was invented). It involved a lot more C code handling the requests than I really liked. BTW, unsafePerformIO is pretty ugly to implement in the request-response model. I take that as a sign that unsafePerformIO is bad. :) -- Lennart On Fri, Aug 21, 2009 at 3:14 PM, Derek Elkins wrote: > On Fri, Aug 21, 2009 at 5:04 AM, Lennart > Augustsson wrote: >>> On Fri, Aug 21, 2009 at 10:52 AM, Bayley, Alistair >>> wrote: >>>> >>>> > From: haskell-cafe-boun...@haskell.org >>>> > [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Bulat Ziganshin >>>> > To: Peter Verswyvelen >>>> > >>>> > > But how does GHC implement the RealWorld internally? I guess >>>> > >>>> > look the "base" library sources for "RealWorld" >>>> >>>> http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/GHC-IOBas >>>> e.html#IO >>>> >> On Fri, Aug 21, 2009 at 11:04 AM, Peter Verswyvelen wrote: >>> IO also seems to use unboxed (hence strict?) tuples >>> >>> newtype IO a = IO (State# RealWorld -> (# State# RealWorld, a #)) >>> >>> Not sure if this is just for performance, but if the strictness is required, >>> here we have the horrible hack again then (would behave different without >>> it?). I guess it works because when applying primitive function likes >>> putChar#, these could be considered as fully strict, since putChar# c really >>> does force evaluation of c strictly and puts in the screen. This is >>> different from the lazy IO situation, where a string is concatenated lazily, >>> and put on the screen by the consumer as soon as it's available. Ah I'm >>> having troubles to explain myself formally, never mind :) >>> Actually RealWorld is not defined in that file, it is defined here, but >>> hidden >>> file:///C:/app/ghp/doc/libraries/ghc-prim/GHC-Prim.html#t%3ARealWorld >>> But I don't understand the comment >>> data RealWorld Source >>> RealWorld is deeply magical. It is primitive, but it is >>> not unlifted (hence ptrArg). We never manipulate values of type RealWorld; >>> it's only used in the type system, to parameterise State#. >>> Maybe I should reread the papers, but it seems lots of magic is needed to >>> get IO right (such as the existential types to make sure different state >>> threads are kept separate) >> >> You need a lot of magic to make the IO monad efficient. >> You don't really want to pass around (and pattern match on) a >> RealWorld token, that would be inefficient. > > I've always preferred the continuation based implementation of IO as > used in Hugs and I believe in HBC. GHC's handling of it has always > seemed hack-y to me. I don't recall any special treatment of IO by > HBC, though Lennart will definitely be able to verify or deny that. > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] Re: Where do I put the seq?
You need a lot of magic to make the IO monad efficient. You don't really want to pass around (and pattern match on) a RealWorld token, that would be inefficient. On Fri, Aug 21, 2009 at 11:04 AM, Peter Verswyvelen wrote: > IO also seems to use unboxed (hence strict?) tuples > > newtype IO a = IO (State# RealWorld -> (# State# RealWorld, a #)) > > Not sure if this is just for performance, but if the strictness is required, > here we have the horrible hack again then (would behave different without > it?). I guess it works because when applying primitive function likes > putChar#, these could be considered as fully strict, since putChar# c really > does force evaluation of c strictly and puts in the screen. This is > different from the lazy IO situation, where a string is concatenated lazily, > and put on the screen by the consumer as soon as it's available. Ah I'm > having troubles to explain myself formally, never mind :) > Actually RealWorld is not defined in that file, it is defined here, but > hidden > file:///C:/app/ghp/doc/libraries/ghc-prim/GHC-Prim.html#t%3ARealWorld > But I don't understand the comment > data RealWorld Source > RealWorld is deeply magical. It is primitive, but it is > not unlifted (hence ptrArg). We never manipulate values of type RealWorld; > it's only used in the type system, to parameterise State#. > Maybe I should reread the papers, but it seems lots of magic is needed to > get IO right (such as the existential types to make sure different state > threads are kept separate) > On Fri, Aug 21, 2009 at 10:52 AM, Bayley, Alistair > wrote: >> >> > From: haskell-cafe-boun...@haskell.org >> > [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Bulat Ziganshin >> > To: Peter Verswyvelen >> > >> > > But how does GHC implement the RealWorld internally? I guess >> > >> > look the "base" library sources for "RealWorld" >> >> http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/GHC-IOBas >> e.html#IO >> * >> Confidentiality Note: The information contained in this message, >> and any attachments, may contain confidential and/or privileged >> material. It is intended solely for the person(s) or entity to >> which it is addressed. Any review, retransmission, dissemination, >> or taking of any action in reliance upon this information by >> persons or entities other than the intended recipient(s) is >> prohibited. If you received this in error, please contact the >> sender and delete the material from any computer. >> * >> > > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Where do I put the seq?
Internally GHC does have to enforce the ordering on IO operations somehow.
If there actually was a RealWorld value being passed around you could
use some version of seq the guarantees sequential evaluation.
But GHC doesn't even pass a RealWorld around, the sequencing is
enforced by different means.
It's uninteresting for this discussion how GHC enforces the sequencing
internally, the important part is that it is part the sequencing is
part of the IO monad semantics and this is what should be used to
guarantee the sequencing of IO operations in a program.
-- Lennart
On Thu, Aug 20, 2009 at 10:41 PM, Peter Verswyvelen wrote:
> But how does GHC implement the RealWorld internally? I guess this can't be
> done using standard Haskell stuff? It feels to me that if I would implement
> it, I would need seq again, or a strict field, or some incrementing "time"
> value that is a strict argument of each of the IO primitives. In any case, I
> would need strictness to control the dependencies no? I might be wrong
> (again) but this is all very interesting ;-)
>
> On Thu, Aug 20, 2009 at 10:25 PM, David Menendez wrote:
>>
>> On Thu, Aug 20, 2009 at 3:43 PM, Peter Verswyvelen
>> wrote:
>> >
>> > Also doesn't Haskell's IO system uses a hidden RealWorld type that has
>> > no
>> > value but which is passed from between monadics binds in a strict way to
>> > make the ordering work?
>>
>> Haskell only describes how the IO monad behaves. GHC's implementation
>> uses a RealWorld type, but other implementations are possible.
>>
>> A quick sketch of an alternative implementation,
>>
>> data Trace = Done | Get (Char -> Trace) | Put Char Trace
>>
>> newtype IO a = IO { unIO :: (a -> Trace) -> Trace }
>>
>> instance Monad IO where
>> return a = IO (\k -> k a)
>> m >>= f = IO (\k -> unIO m (\a -> unIO (f a) k))
>>
>> getChar :: IO Char
>> getChar = IO Get
>>
>> putChar :: Char -> IO ()
>> putChar c = IO (\k -> Put c (k ()))
>>
>> The run-time system is responsible for interpreting the Trace and
>> inputting/outputting characters as needed. All of IO can be
>> implemented in this manner.
>>
>> > So IO in Haskell is a horrible hack then? :-) If it
>> > would be done nicely, in the FRP way, then RealWorld IO would need time
>> > stamps to get rid of the hack?
>>
>> Again, no. GHC's IO type uses the RealWorld value to create data
>> dependencies. For example, putChar 'x' >> getChar, the getChar depends
>> on the RealWorld returned by putChar 'x'.
>>
>> This is why it's dangerous to open up GHC's IO type unless you know
>> what you're doing. If you aren't careful, you may accidentally
>> duplicate or destroy the RealWorld, at which point you risk losing
>> purity and referential transparency.
>>
>> I suppose you could consider the fact that GHC's IO is implemented
>> using impure primitive operations a hack, but the whole point of the
>> IO monad is to hide that impurity from the rest of the program.
>>
>> --
>> Dave Menendez
>> <http://www.eyrie.org/~zednenem/>
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Where do I put the seq?
Using seq to control a program's semantics (as in, input-output behaviour) is a horrible hack. The seq operation there to control space and time aspects of your program. (The specification of seq doesn't even say that the first argument is evaluated before the second one.) You should use data dependencies to control your program's semantics. On Thu, Aug 20, 2009 at 4:34 PM, David Leimbach wrote: > > > On Thu, Aug 20, 2009 at 2:52 AM, Jules Bean wrote: >> >> Peter Verswyvelen wrote: >>> >>> Not at all, use it for whatever you want to :-) >>> >>> I'm writing this code because I'm preparing to write a bunch of tutorials >>> on FRP, and I first wanted to start with simple console based FRP, e.g. >>> making a little text adventure game, where the input/choices of the user >>> might be parsed ala parsec, using monadic style, applicative style, and >>> arrows, and then doing the same with FRP frameworks like >> >> >> This is a really bad place to start a FRP tutorial IMO. >> >> The interface for 'interact' does not make any promises about the relative >> evaluation order of the input list / production order of the output list. >> >> That's why you are having to play horrible tricks with seq to try to force >> the order to be what you want. >> >> I don't think this is the basis of a robust system or a sensible tutorial. >> >> Just my 2c. > > Interesting feedback, but I don't get the reason really. How is using seq a > "horrible trick"? It's there for strict evaluation when you need it, and in > this case it was warranted. > And as far as saying it's not a good basis for a robust system, I'm also not > sure I agree, but a "sensible tutorial", that I could believe as I think > it's actually quite difficult to explain these topics to people in a way > they're going to understand right away. > Could we perhaps bother you to suggest an alternative along with your > criticism? It would feel a little more constructive at least (not that I > think you were being terribly harsh) > Dave > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] unsafeDestructiveAssign?
No, there's no way you can change the value of 'a' after the fact. Since 'a' is a constant the compiler has most likely inlined it wherever it has been used, the done constant folding etc. If you need an updateable variable, you need to tell the compiler, otherwise it will assume your code is pure. -- Lennart On Tue, Aug 11, 2009 at 5:48 PM, Job Vranish wrote: > Does anybody know if there is some unsafe IO function that would let me do > destructive assignment? > Something like: > > a = 5 > main = do > veryUnsafeAndYouShouldNeverEveryCallThisFunction_DestructiveAssign a 8 > print a >> 8 > > and yes I am in fact insane... > > I'm also looking for a way to make actual copies of data. > so I could do something like this: > > a = Node 5 [Node 2 [], Node 5 [a]] > main = do > b <- makeCopy a > veryUnsafeAndYouShouldNeverEveryCallThisFunction_DestructiveAssign b (Node > 0 []) > -- 'a' is unchanged > > It would be even more fantastic, if the copy function was lazy. > I think the traverse function might actually make a copy, but I would be > happier with something more general (doesn't require membership in > traversable), and more explicit (was actually designed for making real > copies). > > Any ideas? > > Thanks, > > - Job > > > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] generalize RecordPuns and RecordWildCards to work with qualified names?
At a minimum I think the error message should be better.
I also think it would be natural to use the DisambiguateRecordFields
for the places where RecordWildcards are used.
I mean, if I change from unqualified import to a qualified one, and
then change all visible names to be qualified I would expect things to
still work.
For RecordPuns I don't have an opinion on what to do.
-- Lennart
On Sun, Aug 9, 2009 at 9:42 PM, Simon Peyton-Jones wrote:
> Oh, now I get it, thanks. This message concerns design choices for
> record-syntax-related GHC extensions. Lennart, pls tune in. You don’t need
> to have read the thread to understand this message.
>
> | I think that Even refers to an example like this:
> |
> | module A where
> | data A = A { a :: Int }
> |
> | The following works:
> |
> | {-# LANGUAGE NamedFieldPuns #-}
> | module B where
> | import A
> | f (A { a }) = a
> |
> | However, if we import "A" qualified, then punning does not seem to work:
> |
> | {-# LANGUAGE NamedFieldPuns #-}
> | module B where
> | import qualified A
> | f (A.A { a }) = a
> |
> | This results in: Not in scope: `a'
>
> Right. What is happening is that GHC looks up the first 'a' (the one on the
> LHS) and finds it not in scope. If you add -XDisambiguateRecordFields, it
> works fine. But admittedly, the error message is unhelpful. I could improve
> that.
>
> Now on to the suggested change:
>
> | {-# LANGUAGE NamedFieldPuns #-}
> | module B where
> | import qualified A
> |
> | f (A.A { A.a }) = a
> |
> | This results in: Qualified variable in pattern: A.a
> |
> | Even is suggesting that instead of reporting an error, in the second
> | case we could use the translation:
> |
> | f (A.A { A.a }) = a --> f (A.A { A.a = a })
> |
> | (i.e., when punning occurs with a qualified name, use just the
> | unqualified part of the name in the pattern)
>
> Yes, that'd be possible. But it seems debatable -- it doesn't *look* as if
> the pattern (A.A { A.a }) binds 'a' -- and it seems even less desirable in
> record construction and update. To be concrete, would you expect these to
> work too?
>
> g a = A.A { A.a } --> g a = A.A { A.a = a }
> h x a = x { A.a } --> h x a = a { A.a = a }
>
> In these cases, I think the abbreviated code looks too confusing.
>
> With -XDisambiguateRecordFields you could say
>
> g a = A.A { a }
>
> which seems better. (But there's no help for record update, since we don’t
> know which data constructor is involved.)
>
>
> So my current conclusion is: improve the error message, perhaps suggesting
> the flag -XDismabiguateRecordFields, but don't add the change you suggest.
>
> Comments?
>
> Simon
>
>
> ___
> Glasgow-haskell-users mailing list
> glasgow-haskell-us...@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Complex numbers and (**)
A2: Yes, this seem unfortunate, so perhaps a different definition for
Complex is warranted.
Or maybe the default implementation for (**) should be changed so that
0**x is 0, except if x is 0 (in which case I think it should be
undefined).
-- Lennart
On Sat, Aug 8, 2009 at 2:55 PM, Paul Sargent wrote:
> Hi,
>
> First post to the cafe, so "Hello everybody!".
> Hope this is reasonable subject matter and not too long.
>
> I've been working on some algorithms that involved taking the n-th root of
> complex numbers. In my code I've implemented this as raising the complex
> number ('z') to 1/n using the (**) operator. Obviously, there are n roots,
> but I only need one of them so this is fine.
>
> Q1) Have I missed a method that's a little less general than 'raising to a
> Complex'? We have integer powers, but not integer roots?
>
> All seems to work fine, except I have a little wrapper function to prefer
> real roots of real numbers, until I started seeing NaNs appearing. This
> happened when I tried to take the root of 0+0i. In fact raising 0+0i to any
> power with (**) causes NaNs to appear. (^) and (^^) have no problem,
> assuming the calculation is one that can be represented with those
> operators. Neither is there a problem when the values being raised are not
> in complex form.
>
> Prelude Data.Complex> let xs = [0.0 :+ 0.0, 1.0 :+ 0.0, 2.0 :+ 0.0, 3.0 :+
> 0.0]
>
> Prelude Data.Complex> [x ^ 2 | x <- xs]
> [0.0 :+ 0.0,1.0 :+ 0.0,4.0 :+ 0.0,9.0 :+ 0.0]
>
> Prelude Data.Complex> [x ^^ 2 | x <- xs]
> [0.0 :+ 0.0,1.0 :+ 0.0,4.0 :+ 0.0,9.0 :+ 0.0]
>
> Prelude Data.Complex> [x ** 2 | x <- xs]
> [NaN :+ NaN,1.0 :+ 0.0,4.0 :+ 0.0,9.002 :+ 0.0]
>
> Prelude Data.Complex> let xs = [0.0,1.0,2.0,3.0]
> Prelude Data.Complex> [x ** 2 | x <- xs]
> [0.0,1.0,4.0,9.0]
>
> Digging deeper I've discovered this is because Complex inherits it's
> definition of (**) as "x ** y = exp (log x * y)". Well... the log of 0+0i is
> -Inf+0i. Multiply this by a real number in complex form and you end up with
> -Infinity * 0.0 as one of the terms. According to the IEEE floating point
> spec, this is NaN. That NaN propagates through exp, and you end up with NaN
> :+ NaN as the result.
>
> Q2) Do people agree this is a bug in the definition of Data.Complex?
>
> Seems like the thing to do to fix this is have an instance of (**) for
> Data.Complex that special cases (0 :+ 0) ** _ to always return (0 :+ 0). An
> alternative would be to use the underlying non-complex (**) operator for
> arguments with no imaginary parts. One downside is that this would change
> the output of Complex (**) so that raising a real argument to a real power
> always produced a real result (which is actually what I want, but may not be
> what others expect / have got used to)
>
> Q3) Do people agree with these options? Any opinions? How would I submit a
> patch?
>
> I did send a mail to the glasgow-haskell-bugs list, but it doesn't appear to
> shown up in the archives, so I assume it didn't make it. It also didn't seem
> quite the right place as this is in the libraries. Apologies if anybody
> reading this is getting deja-vu.
>
> Paul
>
>
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Simple quirk in behavior of `mod`
That how I was taught to round in school, so it doesn't seem at all unusual to me. 2009/7/23 Matthias Görgens : >> Round-to-even means x.5 gets rounded to x if x is even and x+1 if x is >> odd. This is sometimes known as banker's rounding. > > OK. That's slightly unusual indeed. > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Adding a field to a data record
With the RecordWildCard extension you should be able to write
newFoo Old.Foo{..} = New.Foo { .., z=1 }
On Tue, Jul 28, 2009 at 3:47 PM, Henry Laxen wrote:
> Malcolm Wallace cs.york.ac.uk> writes:
>
>>
>> > and perhaps use emacs to
>> > query-replace all the Foo1's back to Foo's
>>
>> At least this bit can be avoided easily enough, by using
>> module qualification during the conversion process.
>>
>> module Original (Foo(..)) where
>> data Foo = Foo { ... y :: Int } deriving ...
>>
>> module New (Foo(..)) where
>> data Foo = Foo { ... y, z :: Int } deriving ...
>>
>> module Convert where
>> import Original as Old
>> import New as New
>> newFoo :: Old.Foo -> New.Foo
>> newFoo old{..} = New.Foo { a=a, b=b, ... z=1 }
>>
>> Finally rename module New.
>>
>> Regards,
>> Malcolm
>>
>
> Thanks Malcolm, yes, that keeps me out of emacs, but the part I would really
> like to avoid is writing the New.Foo { a=a, b=b, ... z=1 } part, where the
> field
> names are many, long, and varied. Yes, I could cut and paste, but I'm hoping
> for a "better way." Thanks.
> Best wishes,
> Henry Laxen
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Slightly off-topic: Lambda calculus
Actually, keeping all names distinct is not de Bruijn numbering, it's called the Barendregt convention. On Sun, Jun 21, 2009 at 7:05 PM, Deniz Dogan wrote: > 2009/6/21 Andrew Coppin : >> OK, so I'm guessing there might be one or two (!) people around here who >> know something about the Lambda calculus. >> >> I've written a simple interpretter that takes any valid Lambda expression >> and performs as many beta reductions as possible. When the input is first >> received, all the variables are renamed to be unique. >> >> Question: Does this guarantee that the reduction sequence will never contain >> name collisions? >> >> I have a sinking feeling that it does not. However, I can find no >> counter-example as yet. If somebody here can provide either a proof or a >> counter-example, that would be helpful. > > I'm no expert, but it sounds to me like you're doing the equivalent of > "de Bruijn indexing", which is a method to avoid alpha conversion, > which is basically what you're worried about. Therefore, I'm guessing > that there will be no name collisions. > > -- > Deniz Dogan > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Slightly off-topic: Lambda calculus
As others have pointed out, it is not enough to rename before reduction. It should be pretty obvious since when you do substitution and copy a lambda expression into more than once place you will introduce variables with the same name. You can keep unique variables by "cloning" during substitution, i.e., renaming the bound variables. -- Lennart On Sun, Jun 21, 2009 at 6:53 PM, Andrew Coppin wrote: > OK, so I'm guessing there might be one or two (!) people around here who > know something about the Lambda calculus. > > I've written a simple interpretter that takes any valid Lambda expression > and performs as many beta reductions as possible. When the input is first > received, all the variables are renamed to be unique. > > Question: Does this guarantee that the reduction sequence will never contain > name collisions? > > I have a sinking feeling that it does not. However, I can find no > counter-example as yet. If somebody here can provide either a proof or a > counter-example, that would be helpful. > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Obscure weirdness
Did you try running it in some debugger, like windbg or VS? 2009/6/20 Andrew Coppin : > Marcin Kosiba wrote: >> >> On Saturday 20 June 2009, Andrew Coppin wrote: >> >>> >>> OK, so here's an interesting problem... >>> >>> I've been coding away all day, but now my program is doing something >>> slightly weird. For a specific input, it summarily terminates. The >>> registered exception handler does not fire. There is no output to stdout >>> or stderr indicating what the problem is. It just *stops* half way >>> through the printout. >>> >>> Weirder: If I run it in GHCi, then GHCi itself terminates. (I didn't >>> think you could *do* that!) >>> >> >> Hi, >> With the information you've provided it's hard to even guess. At >> least take a look at your app's RAM usage -- it just may be that its >> allocating too much memory and the OOM killer is killing it (if you're >> running linux, that is). >> You may also want to try the GHCi debugger [1] to find out where >> the program crashes. The last thing I'd do is blame it on ghc/ghci, but as >> always -- such a possibility exists. >> > > It's Windows. And while it's possible (indeed even probable) that my code > has an infinite loop in it somewhere, usually that makes the program slow to > a crawl and start thrashing the HD as it hits virtual memory. But this > program just dies. Instantly. > > And I already tried the GHCi debugger. When I run the program, GHCi just > quits. I suppose if I can track down exactly *where* in the program it's > dying, I could try single-stepping through it... > > If I was doing something tricky like FFI or unsafe coersions, I'd assume I'd > got it wrong somewhere. But I'm just doing plain ordinary Haskell stuff - > traversing trees, pattern matching, etc. I'm a bit perplexed that it can > fail this way. > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] unique identity and name shadowing during type inference
Use 1. You'll probably need a monad in the type checker soon or later anyway, e.g., for handling errors. On Sat, Jun 20, 2009 at 7:57 PM, Geoffrey Irving wrote: > Hello, > > I am designing a type inference algorithm for a language with > arbitrary function overloading. For various reasons (beyond the scope > of this email), it's impossible to know the full type of an overloaded > function, so each function is assigned a unique primitive type and the > inference algorithm gradually learns more information about the > primitive. For example, if we declare an identity function > > f x = x > > the algorithm will create a primitive type F, and record f :: F. If > we use the function a few times, > > f 1 > f "blah" > > the algorithm will infer > > F Int = Int > F String = String > > My question is: what's the best way to represent these unique > primitive types in Haskell? A new type primitive needs to be created > whenever we process a function declaration. Nested function > declarations produce a different primitive each time the parent is > invoked with different argument types. These separate primitives can > escape if local functions are returned, so the inference algorithm > must be able to keep them separate and learn more about them after > their parent function is forgotten. > > Here are a few ways I know of: > > 1. Thread a uniqueness generator monad through the whole algorithm. > I'd prefer to avoid this extra plumbing if possible. > 2. Label primitives with the full context of how they were created. > If function f declares a nested function g, and f is called with Int > and Char, the primitives for g would be labeled with "f Int" and "f > Char" to keep them separate. This is similar to lambda lifting. > 3. Scary hacks involving makeStableName and unsafePerformIO. Some > sort of context would have to be thrown around here to make sure GHC > doesn't merge the different makeStableName calls. > > Unfortunately, method (2) is complicated by the fact that variable > names are not unique even in the internal representation (I'm using > the trick from [1]), so I'm not sure what the minimal unique "context" > would be. > > Does anyone know other methods outside of (1), (2), or (3), or clean > ways of structuring (2) or (3)? > > Thanks! > Geoffrey > > [1]: http://www.haskell.org/~simonmar/bib/ghcinliner02_abstract.html > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
The creators of Haskell didn't pick any particular representation for numbers. (Well, literals are kind of Integers.) You can pick what types you make instances of Num. Some of them are lazy, some of them are strict. On Wed, Jun 17, 2009 at 11:05 PM, Keith Sheppard wrote: > In lambda calculus numbers are just functions and you evaluate them > just like any other function. Haskell could have chosen the same > representation for numbers and all evaluation on numbers would be lazy > (assuming normal order evaluation). I think that would have been the > "Purist Lazy" way to go. That is not the way the creators of Haskell > designed language though... am i missing something? > > On Wed, Jun 17, 2009 at 4:05 PM, Lennart > Augustsson wrote: >> What do you mean by "literals are strict"? Strictness is a semantic >> property of functions, and while literals can be overloaded to be >> functions I don't know what you mean. >> >> On Wed, Jun 17, 2009 at 9:50 PM, Keith Sheppard wrote: >>> Haskell's numeric literals are strict. You wouldn't want that to >>> change right? It seems to me that having sum and product be strict is >>> consistent with this. >>> >>> -Keith >>> >>> On Wed, Jun 17, 2009 at 11:15 AM, Thomas Davie wrote: >>>> >>>> On 17 Jun 2009, at 13:32, Yitzchak Gale wrote: >>>> >>>>> Henk-Jan van Tuyl wrote: >>>>>> >>>>>> reverse >>>>>> maximum >>>>>> minimum >>>>> >>>>> Oh yes, please fix those also! >>>> >>>> import Prelude.Strict? >>>> >>>> Honestly, these functions are ones that I've *deffinately* used lazy >>>> versions of, in fact, in the cases of minimum/maximum I've even used ones >>>> that are super-lazy and parallel using unamb. >>>> >>>> It would be extremely odd to randomly decide "most people would want this >>>> to >>>> be strict" based on no knowledge of what they're actually doing. Instead, >>>> why don't we stand by the fact that haskell is a lazy language, and that >>>> the >>>> functions we get by default are lazy, and then write a strict prelude as I >>>> suggest above to complement the lazy version. >>>> >>>> Bob >>>> ___ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe@haskell.org >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>> >>> >>> >>> >>> -- >>> keithsheppard.name >>> ___ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> > > > > -- > keithsheppard.name > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
What do you mean by "literals are strict"? Strictness is a semantic property of functions, and while literals can be overloaded to be functions I don't know what you mean. On Wed, Jun 17, 2009 at 9:50 PM, Keith Sheppard wrote: > Haskell's numeric literals are strict. You wouldn't want that to > change right? It seems to me that having sum and product be strict is > consistent with this. > > -Keith > > On Wed, Jun 17, 2009 at 11:15 AM, Thomas Davie wrote: >> >> On 17 Jun 2009, at 13:32, Yitzchak Gale wrote: >> >>> Henk-Jan van Tuyl wrote: reverse maximum minimum >>> >>> Oh yes, please fix those also! >> >> import Prelude.Strict? >> >> Honestly, these functions are ones that I've *deffinately* used lazy >> versions of, in fact, in the cases of minimum/maximum I've even used ones >> that are super-lazy and parallel using unamb. >> >> It would be extremely odd to randomly decide "most people would want this to >> be strict" based on no knowledge of what they're actually doing. Instead, >> why don't we stand by the fact that haskell is a lazy language, and that the >> functions we get by default are lazy, and then write a strict prelude as I >> suggest above to complement the lazy version. >> >> Bob >> ___ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > > -- > keithsheppard.name > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance of functional priority queues
I wasn't contradicting you, just clarifying that this is indeed the optimal asymtotic complexity. On Mon, Jun 15, 2009 at 3:43 PM, Sebastian Sylvan wrote: > Is that not what I said? > > On Mon, Jun 15, 2009 at 2:12 PM, Lennart Augustsson > wrote: >> >> A priority queue can't have all operations being O(1), because then >> you would be able to sort in O(n) time. So O(log n) deleteMin and >> O(1) for the rest is as good as it gets. >> >> On Mon, Jun 15, 2009 at 10:40 AM, Sebastian >> Sylvan wrote: >> > >> > >> > On Mon, Jun 15, 2009 at 4:18 AM, Richard O'Keefe >> > wrote: >> >> >> >> There's a current thread in the Erlang mailing list about >> >> priority queues. I'm aware of, for example, the Brodal/Okasaki >> >> paper and the David King paper. I'm also aware of James Cook's >> >> priority queue package in Hackage, have my own copy of Okasaki's >> >> book, and have just spent an hour searching the web. >> >> >> >> One of the correspondents in that thread claims that it is >> >> provably impossible to have an efficient priority queue implementation >> > >> > >> > A priority queue based on skewed binomial heaps is asymptotically >> > optimal >> > (O(1) for everything except deleteMin which is O(log n)), so if that's >> > what >> > he means by "efficient" then he's most definitely wrong. If he's talking >> > about "small constant factors" then it's harder to understand what he's >> > referring to more precisely, and therefore what he means by "provably". >> > >> > -- >> > Sebastian Sylvan >> > +44(0)7857-300802 >> > UIN: 44640862 >> > >> > ___ >> > Haskell-Cafe mailing list >> > Haskell-Cafe@haskell.org >> > http://www.haskell.org/mailman/listinfo/haskell-cafe >> > >> > > > > > -- > Sebastian Sylvan > +44(0)7857-300802 > UIN: 44640862 > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance of functional priority queues
A priority queue can't have all operations being O(1), because then you would be able to sort in O(n) time. So O(log n) deleteMin and O(1) for the rest is as good as it gets. On Mon, Jun 15, 2009 at 10:40 AM, Sebastian Sylvan wrote: > > > On Mon, Jun 15, 2009 at 4:18 AM, Richard O'Keefe wrote: >> >> There's a current thread in the Erlang mailing list about >> priority queues. I'm aware of, for example, the Brodal/Okasaki >> paper and the David King paper. I'm also aware of James Cook's >> priority queue package in Hackage, have my own copy of Okasaki's >> book, and have just spent an hour searching the web. >> >> One of the correspondents in that thread claims that it is >> provably impossible to have an efficient priority queue implementation > > > A priority queue based on skewed binomial heaps is asymptotically optimal > (O(1) for everything except deleteMin which is O(log n)), so if that's what > he means by "efficient" then he's most definitely wrong. If he's talking > about "small constant factors" then it's harder to understand what he's > referring to more precisely, and therefore what he means by "provably". > > -- > Sebastian Sylvan > +44(0)7857-300802 > UIN: 44640862 > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bool as type class to serve EDSLs.
Here's what I usually use. As Simon points out, ambiguity is lurking
as soon as you use conditional. You can avoid it a fundep, but that's
not necessarily what you want either.
-- | Generalization of the 'Bool' type. Used by the generalized 'Eq' and 'Ord'.
class Boolean bool where
(&&) :: bool -> bool -> bool -- ^Logical conjunction.
(||) :: bool -> bool -> bool -- ^Logical disjunction.
not :: bool -> bool -- ^Locical negation.
false :: bool -- ^Truth.
true :: bool -- ^Falsity.
fromBool :: Bool -> bool-- ^Convert a 'Bool' to the
generalized Boolean type.
fromBool b = if b then true else false
-- | Generalization of the @if@ construct.
class (Boolean bool) => Conditional bool a where
conditional :: bool -> a -> a -> a -- ^Pick the first argument if
the 'Boolean' value is true, otherwise the second argument.
class (Boolean bool) => Eq a bool {- x | a -> bool -} where
(==) :: a -> a -> bool
(/=) :: a -> a -> bool
x /= y = not (x == y)
x == y = not (x /= y)
On Thu, May 28, 2009 at 8:14 AM, Simon Peyton-Jones
wrote:
> You are absolutely right about the tantalising opportunity. I know that
> Lennart has thought quite a bit about this very point when designing his
> Paradise system. Likewise Conal for Pan.
>
> One difficulty is, I think, that it's easy to get ambiguity. Eg
> ifthenelse (a > b) e1 e2
> The (a>b) produces a boolean-thing, and ifthenelse consumes it; but which
> type of boolean? The Expr type? Real Bools? Or what?
>
> If there was a nice design, then GHC's existing -fno-implicit-prelude flag
> could be extended (again) to desugar if-then-else to the new thing. But the
> design is unclear, to me anyway.
>
> Simon
>
> | -Original Message-
> | From: haskell-cafe-boun...@haskell.org
> [mailto:haskell-cafe-boun...@haskell.org] On
> | Behalf Of Sebastiaan Visser
> | Sent: 27 May 2009 13:32
> | To: Haskell Cafe
> | Subject: [Haskell-cafe] Bool as type class to serve EDSLs.
> |
> | Hello,
> |
> | While playing with embedded domain specific languages in Haskell I
> | discovered the Num type class is a really neat tool. Take this simple
> | example embedded language that can embed primitives from the output
> | language and can do function application.
> |
> | >data Expr :: * -> * where
> | > Prim :: String -> Expr a
> | > App :: Expr (a -> b) -> Expr a -> Expr b
> |
> | Take these two dummy types to represent things in the output language.
> |
> | >data MyNum
> | >data MyBool
> |
> | Now it is very easy to create an Num instance for this language:
> |
> | >primPlus :: Expr (MyNum -> MyNum -> MyNum)
> | >primPlus = Prim "prim+"
> |
> | >instance Num (Epxr MyNum) where
> | > a + b = primPlus `App` a `App` b
> | > fromInteger = Prim . show
> | > ...
> |
> | Which allows you to create very beautiful expression for your language
> | embedded inside Haskell. The Haskell expression `10 * 5 + 2' produces
> | a nice and well typed expression in your embedded domain.
> |
> | But unfortunately, not everyone in the Prelude is as tolerant as the
> | Num instance. Take the Eq and the Ord type classes for example, they
> | require you to deliver real Haskell `Bool's. This makes it impossible
> | make your DSL an instance of these two, because there are no `Bool's
> | only `Expr Bool's.
> |
> | Which brings me to the point that, for the sake of embedding other
> | languages, Haskell's Prelude (or an alternative) can greatly benefit
> | from (at least) a Boolean type class like this:
> |
> | class Boolean a where
> | ifthenelse :: a -> b -> b -> b -- Not sure about this
> | representation.
> | ...
> |
> | And one instance:
> |
> | >instance Boolean (Expr MyBool) where
> | > ifthenelse c a b = Prim "if-then-else" `App` c `App` a `App` b
> |
> | Now we can change (for example) the Eq type class to this:
> |
> | >class Eq a where
> | > (==) :: Boolean b => a -> a -> b
> | > (/=) :: Boolean b => a -> a -> b
> |
> | For which we can give an implementation for our domain:
> |
> | >primEq :: Epxr (a -> a -> MyBool)
> | >primEq = Prim "=="
> |
> | >instance Eq (Expr a) where
> | > a == b = primEq `App` a `App` b
> |
> | And now we get all functionality from the Prelude that is based on Eq
> | (like not, &&, ||, etc) for free in our domain specific language!
Re: [Haskell-cafe] Haskell type system and the lambda cube
Type checking is decidable for all of the lambda cube, but not type inference. Haskell 98 is a subset of Fw, Haskell with extensions is an superset of Fw. -- Lennart On Mon, May 25, 2009 at 12:59 PM, Brent Yorgey wrote: > On Sun, May 24, 2009 at 10:39:50AM +0200, Petr Pudlak wrote: >> On Sun, May 24, 2009 at 12:18:40PM +0400, Eugene Kirpichov wrote: >> > Haskell has terms depending on types (polymorphic terms) and types >> > depending on types (type families?), but no dependent types. >> >> But how about undecidability? I'd say that lambda2 or lambda-omega have >> undecidable type checking, > > I don't think that's true. Unless I am mistaken, type checking is > decidable for all the vertices of the lambda cube. > >> (BWT, will some future version of Haskell consider including some kind of >> dependent types?) > > I doubt it. But there is a lot of current research into bringing as > much of the power of dependent types into the language (e.g. type > families) without actually bringing in all the headaches of > full-spectrum dependent types. > > -Brent > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] conflicting variable definitions in pattern
Simplicity of pattern matching semantics, not of implementation (we all knew how to implement it). Miranda had non-linear patterns, but nobody really argued for them in Haskell. If Haskell had them, I'd not argue to have them removed, but nor will I argue to add them. -- Lennart On Fri, May 15, 2009 at 1:19 PM, Conor McBride wrote: > > On 15 May 2009, at 12:07, Lennart Augustsson wrote: > >> In the original language design the Haskell committee considered >> allowing multiple occurrences of the same variable in a pattern (with >> the suggested equality tests), but it was rejected in favour of >> simplicity. > > Simplicity for whom, is the question? My point is > only that there's no technical horror to the proposal. > It's just that, given guards, the benefit (in simplicity > of program comprehension) of nonlinear patterns over > explicit == is noticeable but hardly spectacular. > > Rumblings about funny termination behaviour, equality > for functions, and the complexity of unification (which > isn't the proposal anyway) are wide of the mark. This > is just an ordinary cost-versus-benefit issue. My guess > is that if this feature were already in, few would be > campaigning to remove it. (By all means step up and say > why!) As it's not in, it has to compete with other > priorities: I'm mildly positive about nonlinear > patterns, but there are more important concerns. > > Frankly, the worst consequence I've had from Haskell's > pattern linearity was just my father's derision. He > quite naturally complained that his programs had lost > some of their simplicity. > > All the best > > Conor > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] conflicting variable definitions in pattern
In the original language design the Haskell committee considered allowing multiple occurrences of the same variable in a pattern (with the suggested equality tests), but it was rejected in favour of simplicity. -- Lennart On Fri, May 15, 2009 at 11:30 AM, Sittampalam, Ganesh wrote: > Conor McBride wrote: >> On 15 May 2009, at 09:11, Sittampalam, Ganesh wrote: >>> >>> but then pattern matching can introduce Eq constraints which some >>> might see as a bit odd. >> >> Doesn't seem that odd to me. Plenty of other language features come >> with constraints attached. > > It's the introduction of a constraint from tweaking a pattern that is > odd, I think. By way of precedent H98 rejected this kind of idea in > favour of putting 'fail' into Monad. > > Ganesh > > === > Please access the attached hyperlink for an important electronic > communications disclaimer: > http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html > === > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] is value evaluated?
But testing for something being evaluated has to be in the IO monad, or else you're going to break the semantics. On Fri, May 8, 2009 at 4:14 PM, Don Stewart wrote: > Andy Gill has been advocating programmatic access to the 'is evaluated' > status bit for years now. 'seq' becomes cheaper, and we can write > operational properties/assertions about strictness. > > -- Don > > > jochem: >> Nikhil Patil wrote: >> > Hi, >> > >> > I am curious to know if there is a function in Haskell to find if a >> certain >> > value has already been evaluated. The function I need would have the type: >> > >> >> (?!) :: a -> Bool >> >> I will call this function `evaluated', since it is not a binary operator. >> >> The existence of such a function would violate referential transparency. >> >> What would the value of >> ( evaluated (fibs !! 100), evaluated (fibs !! 100) ) >> be ? Suppose that I first print the `fst' of this tuple, then print the >> 101st Fibonacci nummber, and then print the `snd' of this tuple. By lazy >> evaluation, one would expect that this yields >> >> False >> >> True >> >> but this violates referential transparency. >> >> Cheers, >> -- >> Jochem Berndsen | joc...@functor.nl >> GPG: 0xE6FABFAB >> ___ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
