data EShow = forall a. Show a = EShow a
data E t = forall a. E (a-t) a
smallPrint_ t = concatMap (\f- f t) [show . foo, show . bar, show . baz]
Yeah, I am aware of these solutions, but like Dan says:
but first-class existentials are still desirable because introducing a new
type for
I was wandering if it would be possible to optimize
unambhttp://hackage.haskell.org/packages/archive/unamb/0.1.9/doc/html/Data-Unamb.html#v%3Aunamb
by
checking if a value is already evaluated to head normal form.
So
f `unamb` g
would then be extremely fast if either f or g is already evaluated
On 20 Apr 2009, at 09:41, Peter Verswyvelen wrote:
I was wandering if it would be possible to optimize unamb by
checking if a value is already evaluated to head normal form.
So
f `unamb` g
would then be extremely fast if either f or g is already evaluated
to head normal form.
Maybe
On Mon, Apr 20, 2009 at 10:23 AM, Thomas Davie tom.da...@gmail.com wrote:
Really? Is it any less referentially transparent than unamb already is -
i.e. it's referentially transparent, as long as the two values really are
equal.
I think it is. Suppose we call the function hnf :: a - Bool.
On 20 Apr 2009, at 10:57, Peter Verswyvelen wrote:
On Mon, Apr 20, 2009 at 10:23 AM, Thomas Davie tom.da...@gmail.com
wrote:
Really? Is it any less referentially transparent than unamb already
is - i.e. it's referentially transparent, as long as the two values
really are equal.
I think
I disagree. First of all, UHC states explicitly that some features are not supported (and probably never would be). Secondly, it seems like
almost nobody uses (n+k)-patterns, and when they are used, they make the code less readable; so it's good NOT to support them, in order to make
programmers
Miguel Mitrofanov wrote:
Jon Fairbairn wrote on 20.04.2009 13:59:
Achim Schneider bars...@web.de writes:
Jon Fairbairn jon.fairba...@cl.cam.ac.uk wrote:
a...@cs.uu.nl writes:
Utrecht Haskell Compiler -- first release, version 1.0.0
Achim Schneider bars...@web.de writes:
Jon Fairbairn jon.fairba...@cl.cam.ac.uk wrote:
a...@cs.uu.nl writes:
Utrecht Haskell Compiler -- first release, version 1.0.0
The UHC team is happy to announce the first
Achim Schneider wrote:
Don Stewart d...@galois.com wrote:
This means that 'cabal
install' works out of the box on every system, without needing
admin/root privs (esp. important for students).
...and people who were bitten by sanity and thus never, ever touch /usr
manually, only through their
I agree in principle; you should really implement the full Haskell98
if you claim to be a Haskell implementation.
In the particular case of n+k I don't care, since I never use them and
they are slated for removal in Hakell'.
-- Lennart
On Mon, Apr 20, 2009 at 11:59 AM, Jon Fairbairn
Hello Jon,
Monday, April 20, 2009, 1:59:07 PM, you wrote:
It's not an implementor's place to make such decisions --
they can legitimately say this feature sucks and tell the
next Haskell committee so. If they care enough about it,
they can lobby or get on that next committee, but the
If every implementor got to choose what subset of the standard to
implement that all code would have have to written in the implemented
intersection. I think that's a terrible idea.
The Haskell98 standard was set so there would be a baseline that
people could rely on.
When I implemented Haskell
Well, the problem is that every implementor does choose a subset of standart to
implement.
It's much worse in JavaScript - essential features working differently in Internet Explorer, Firefox, Opera, and Safari, and sometimes they even
differ between versions; Web programmers still manage.
I don't think that other languages failing should be an excuse for
Haskell to be equally bad.
On Mon, Apr 20, 2009 at 1:23 PM, Miguel Mitrofanov
miguelim...@yandex.ru wrote:
Well, the problem is that every implementor does choose a subset of standart
to implement.
It's much worse in
On Apr 18, 2009, at 2:48 AM, Sjoerd Visscher wrote:
using Matt Hellige's pointless fun
http://matt.immute.net/content/pointless-fun
diag = foldr1 (zipWith (++) $. id ~ ([]:) ~ id)
$. map (++ repeat []) ~ takeWhile (not.null)
$. (map.map) (:[]) ~ concat
pretty! Those seem to be
Me neither; there were actually two points:
1) It's not bad; at least, it's not bad for reasons you provide.
2) It would be here whether we like it or not.
Lennart Augustsson wrote on 20.04.2009 15:31:
I don't think that other languages failing should be an excuse for
Haskell to be equally
Hi,
according the several style guides, lines shouldn't be too long
(longer than 78 characters).
http://www.cs.caltech.edu/courses/cs11/material/haskell/misc/haskell_style_guide.html
http://www.haskell.org/haskellwiki/Programming_guidelines
However, I miss hints how to break lines best.
This is one with functional lists:
diag = foldr1 (zipWith (.) $. id ~ (id:) ~ id)
$. map (++ repeat id) ~ takeWhile (not.null.($[]))
$. (map.map) (:) ~ ($[]) . mconcat
On Apr 20, 2009, at 1:48 PM, Sebastian Fischer wrote:
On Apr 18, 2009, at 2:48 AM, Sjoerd Visscher wrote:
using
I've been looking at CPS in Haskell and wondering how many multiplications the
product function performs if it encounters a zero somewhere in the input list.
Zero?
Does anyone know the definition of the product function?
Michael
___
Check that by experiment in ghci or by looking at the source:
Prelude* product [0..]
Or search product at http://holumbus.fh-wedel.de/hayoo/hayoo.html
and click on one of the Source links.
2009/4/20 michael rice nowg...@yahoo.com:
I've been looking at CPS in Haskell and wondering how many
Sure, so hnf would give us a non-determined result, but I don't think
that makes unamb any less referentially transparent – the same value is
always returned, and always reduced at least to hnf.
I think it is hnf that Peter was talking about needing to be in IO, not
unamb.
- Jake
Yes indeed.
On Mon, Apr 20, 2009 at 3:42 PM, Jake McArthur jake.mcart...@gmail.comwrote:
Sure, so hnf would give us a non-determined result, but I don't think that
makes unamb any less referentially transparent – the same value is always
returned, and always reduced at least to hnf.
I
A solution with enums would severely suffer from the expression problem...
One would need to extent the enums every time one needs to support a new
function. Maybe could be solved with type classes, don't know.
On Mon, Apr 20, 2009 at 3:57 PM, Achim Schneider bars...@web.de wrote:
Lennart
Lennart Augustsson lenn...@augustsson.net wrote:
On Sun, Apr 19, 2009 at 10:43 PM, Peter Verswyvelen
bugf...@gmail.com wrote:
For example, suppose you have a predicate a - Bool, and a list of
these predicates [a - Bool], but you want to remove all functions
that are obviously equal in the
Hi Eugene,
Clever solution.
It didn't come right back so I interrupted it. Guess it would do all those
multiplies by zero.
Does anyone know how to define it to avoid that?
Thanks.
Michael
--- On Mon, 4/20/09, Eugene Kirpichov ekirpic...@gmail.com wrote:
From: Eugene Kirpichov
Christian Maeder christian.mae...@dfki.de wrote:
[...]
All very fine, but what about simply moving code into a top-level
binding or a function-level let/where?
--
(c) this sig last receiving data processing entity. Inspect headers
for copyright history. All rights reserved. Copying, hiring,
On Apr 20, 2009, at 4:32 PM, michael rice wrote:
Hi Eugene,
Clever solution.
It didn't come right back so I interrupted it. Guess it would do all
those multiplies by zero.
Does anyone know how to define it to avoid that?
Thanks.
Michael
--- On Mon, 4/20/09, Eugene Kirpichov
Christian Maeder wrote:
I've nothing against long names, but one shouldn't try to put blocks
to the right of them.
This is very important from my point of view. Indention should not
depend on identifier length. However, I make an exception to that rule
sometimes for definitions which look
Just refuse to use UHC until it conforms. One can refuse to use GHC
libraries that use extensions as well for similar reasons. I always think
twice when I see something that isn't Haskell 98 in my stack.
Anything that doesn't conform completely to Haskell 98 can effectively be
considered not
Hello michael,
Monday, April 20, 2009, 6:32:47 PM, you wrote:
something like
0*_ = 0
x*y = x *# y
or vice versa
_*0 = 0
x*y = x *# y
where *# is original (*) definition. current ghc definiton just
performs cpu-level operation w/o checking for 0 since this is rarely
useful and need some time
michael rice wrote:
I've been looking at CPS in Haskell and wondering how many multiplications the
product function performs if it encounters a zero somewhere in the input list.
Zero?
Does anyone know the definition of the product function?
You can use Hoogle [1] to search for product [2].
David Leimbach wrote:
Just refuse to use UHC until it conforms. One can refuse to use GHC
libraries that use extensions as well for similar reasons. I always
think twice when I see something that isn't Haskell 98 in my stack.
Do you not use Hugs for the same reason?
This also seems to work:
myprod l = prod l id
where
prod [] k = k 1
prod (x:xs) k = if x == 0 then 0 else prod xs (\ z - k (x * z))
*Main Data.List :load prod
[1 of 1] Compiling Main ( prod.hs, interpreted )
Ok, modules loaded: Main.
*Main Data.List myprod
On Mon, Apr 20, 2009 at 7:57 AM, Achim Schneider bars...@web.de wrote:
Lennart Augustsson lenn...@augustsson.net wrote:
On Sun, Apr 19, 2009 at 10:43 PM, Peter Verswyvelen
bugf...@gmail.com wrote:
For example, suppose you have a predicate a - Bool, and a list of
these predicates [a -
Just refuse to use UHC until it conforms.
Do you not use Hugs for the same reason?
Not to mention that GHC does not comply with the H'98 standard either:
http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs-and-infelicities.html#vs-Haskell-defn
Regards,
Malcolm
On Mon, Apr 20, 2009 at 8:19 AM, Martijn van Steenbergen
mart...@van.steenbergen.nl wrote:
David Leimbach wrote:
Just refuse to use UHC until it conforms. One can refuse to use GHC
libraries that use extensions as well for similar reasons. I always think
twice when I see something that
On Mon, Apr 20, 2009 at 8:38 AM, Malcolm Wallace
malcolm.wall...@cs.york.ac.uk wrote:
Just refuse to use UHC until it conforms.
Do you not use Hugs for the same reason?
Not to mention that GHC does not comply with the H'98 standard either:
Simplest app should look like this
module Main where
import Hack
import Hack.Handler.Kibro
hello :: Application
hello = \env - return $ Response
{ status = 200
, headers = [ (Content-Type, text/plain) ]
, body= Hello World
}
main =
Can you stick this on Hackage? I'd love to play with it...
On Mon, Apr 20, 2009 at 11:46 AM, Jinjing Wang nfjinj...@gmail.com wrote:
Simplest app should look like this
module Main where
import Hack
import Hack.Handler.Kibro
hello :: Application
hello = \env - return $
Oh look:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hack-2009.4.20
*slinks away*
On Mon, Apr 20, 2009 at 11:48 AM, John Van Enk vane...@gmail.com wrote:
Can you stick this on Hackage? I'd love to play with it...
On Mon, Apr 20, 2009 at 11:46 AM, Jinjing Wang
On Apr 20, 2009, at 5:44 PM, David Leimbach wrote:
On Mon, Apr 20, 2009 at 8:38 AM, Malcolm Wallace malcolm.wall...@cs.york.ac.uk
wrote:
Just refuse to use UHC until it conforms.
Do you not use Hugs for the same reason?
Not to mention that GHC does not comply with the H'98 standard either:
We need to start referring to more haskell packages as sexy
/Joe
Jinjing Wang wrote:
Simplest app should look like this
module Main where
import Hack
import Hack.Handler.Kibro
hello :: Application
hello = \env - return $ Response
{ status = 200
, headers
Err, is there some reason you don't have simpler interfaces like:plaintext
:: String - Application
plaintext text = \env - return $ Response
{ status = 200
, headers = [ (Content-Type, text/plain) ]
, body= text
}
On Mon, Apr 20, 2009 at 12:30 PM, Joe Fredette
2009/4/20 Alberto G. Corona agocor...@gmail.com:
Interesting. It seems similar to TCache.
It is indeed. I particularly like the feature of TCache that
you can fill partially initialized values from the cache
so I've added a similar high-level interface for TMap
(module TStorage).
Cheers,
Peter
Joe Fredette wrote:
We need to start referring to more haskell packages as sexy
Would *you* want to copulate with it? ;-)
Hmm, no documentation... GHC log is complaining that mps is missing.
Pitty.
___
Haskell-Cafe mailing list
I'm sort of backtracking from your opinion that this hnf would need to be
in IO. Are you imagining something like?
data (NFData a) = OnceNFData n = OnceNFData { the_data :: a, is_normal_form ::
(IORef Bool) }
I think GHC generally prevents parallel evaluation of the same unevaluated
That last definition multiplied zeros coming out of the recursion, but I
believe this one is good:
myprod l = prod l id id
where
prod [] k b = k 1
prod (x:xs) k b = if x == 0 then b 0 else prod xs (\ z - k (x * z)) b
My goal was to use CPS to do it. Did I succeed?
Also, is there
Christopher Lane Hinson wrote:
What we'd like to avoid is duplicate verification that a thunk is hnf.
Do we have evidence that this verification ever actually consumes a lot
of resources?
I think the OP is trying to avoid spawning unnecessary threads at the
cost of duplicate checks for HNF.
f `unamb` g just needs f or g to be in weak head normal form I think. This
should be much easier to test for I guess.
I always confuse weak head normal form with reduced head normal form, but
the documentation of GHC does not help here:
E.g.:
-- | Reduces its argument to weak head normal
Andrew Coppin wrote:
Joe Fredette wrote:
We need to start referring to more haskell packages as sexy
Would *you* want to copulate with it? ;-)
Hey, it's a safe and pure language, right? ;-)
Hmm, no documentation... GHC log is complaining that mps is missing.
Pitty.
In a post in the *Elerea, another FRP library *thread*,* Peter Verswyvelen
wrote:
*I think it would be nice if we could make a reactive benchmark or
something: some tiny examples that capture the essence of reactive systems,
and a way to compare each solution's pros and cons.* *
*
*For example
It would also be nice if you could plug it into the hierarchical
module system somewhere, perhaps renaming the module to
Data.Algorithm.RungeKutta or Numeric.RungeKutta or
Math.RungeKutta. This is pretty much the standard practice now, I
think.
Alex
On Sun, Apr 19, 2009 at 4:04 PM, Uwe
Hello,
On Thursday 16 April 2009 17:22, Sebastian Fischer wrote:
...
Thanks! Feel free to incorporate ideas from NaurPrimes.hs. I don't
understand them yet.
NaurPrimes.hs is derived from the EratoS.hs that you get from unpacking
thorkilnaur.dk/~tn/Haskell/EratoS/T64_20070303_1819.tar.gz.
Hi everybody,
I'm pleased to announce that Petr Ročkai's project on optimising darcs
has been accepted for Google Summer of Code.
More details can be found here:
http://socghop.appspot.com/org/home/google/gsoc2009/haskell
Petr's project fits into an ongoing effort by the darcs community to
On 20 Apr 2009, at 10:12 pm, Miguel Mitrofanov wrote:
I disagree. First of all, UHC states explicitly that some features
are not supported (and probably never would be). Secondly, it seems
like almost nobody uses (n+k)-patterns,
How can you possibly know that?
and when they are used,
On 20 Apr 2009, at 10:27 pm, Jules Bean wrote:
This is good advice (/usr/local is fine though).
Actually, no, it isn't.
To start with, these days it's chock full of stuff
which is hardly less critical for system operation
than anything you'll find in /bin.
More importantly, it's not a place
On Apr 20, 2009, at 10:46 , David Leimbach wrote:
Just refuse to use UHC until it conforms. One can refuse to use GHC
libraries that use extensions as well for similar reasons. I
always think twice when I see something that isn't Haskell 98 in my
stack.
So you don't use hierarchical
Richard O'Keefe wrote:
On 20 Apr 2009, at 10:27 pm, Jules Bean wrote:
However, the point here is surely that the de-facto default for all
other downloaded programs - standard makefile setups, automake,
autoconf, perl package, python packages, graphic installers like
firefox - is do to what
Brandon S. Allbery KF8NH allb...@ece.cmu.edu writes:
On Apr 20, 2009, at 10:46 , David Leimbach wrote:
Just refuse to use UHC until it conforms. One can refuse to use GHC
libraries that use extensions as well for similar reasons. I always think
twice when I see something that
Edward Middleton emiddle...@bebear.net writes:
Richard O'Keefe wrote:
On 20 Apr 2009, at 10:27 pm, Jules Bean wrote:
However, the point here is surely that the de-facto default for all
other downloaded programs - standard makefile setups, automake,
autoconf, perl package, python packages,
Hi,
a refresh release of the Haskell (lib)curl package has been uploaded to
Hackage,
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/curl
It enables 6.10.2 use, taking into account the updated story on how to
register
Haskell-based finalizers. Thanks to Carl Howells for
Trying to give different semantics to the same declarative definition based
on whether it's recursively defined or not seems rather hack-ish, although
I can understand what you are coming from from an implementation angle.
Mathematically an integral operator has only one semantics regardless
of
On 21 Apr 2009, at 04:59, Richard O'Keefe wrote:
On 20 Apr 2009, at 10:12 pm, Miguel Mitrofanov wrote:
I disagree. First of all, UHC states explicitly that some features
are not supported (and probably never would be). Secondly, it seems
like almost nobody uses (n+k)-patterns,
How can
Richard O'Keefe wrote:
However, the point here is surely that the de-facto default for all
other downloaded programs - standard makefile setups, automake,
autoconf, perl package, python packages, graphic installers like
firefox - is do to what cabal calls a 'global' install by default.
The
On 21 Apr 2009, at 4:52 pm, Jules Bean wrote:
The point I was making, which is scarcely important enough to bother
explaining again, is that having the same *default* as other
software is a virtue.
That point is mistaken.
I have no idea how many people are unable to use that default,
On Mon, Apr 20, 2009 at 9:45 PM, Miguel Mitrofanov
miguelim...@yandex.ru wrote:
On 21 Apr 2009, at 04:59, Richard O'Keefe wrote:
On 20 Apr 2009, at 10:12 pm, Miguel Mitrofanov wrote:
I disagree. First of all, UHC states explicitly that some features are
not supported (and probably never
On 21 Apr 2009, at 2:10 pm, Edward Middleton wrote:
Richard O'Keefe wrote:
The assumption here seems to be that everyone owns their own machine
or has a system adminstrator with large amounts of free time on their
hands. Just because a lot of other people are doing something crazy
doesn't
On 21 Apr 2009, at 5:10 pm, Jason Dagit wrote:
Plus, there was a movement to ban them:
And somehow this means people don't?
BUT, here is the real point of my reply:
To end this debate as to whether people really use them. We have this
huge collection of source code called Hackage. I bet
68 matches
Mail list logo
