Re: [Haskell-cafe] ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
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 every existential is annoying. It's comparable to having to write a new class for every combination of argument and result types to mimic first class functions in Java (aside from first class functions being more ubiquitous in their usefulness, although perhaps it only appears that way because we don't have easy use of existential types). I've personally always looked at the extra data type or repeated functions as ugly hacks around the fact that GHC doesn't have real existential typing. Since Haskell is otherwise virtually free of ugly hacks (at least at the level I work at, which doesn't require things like unsafePerformIO and unboxed arrays) this has always annoyed me a bit. So I figured that since we now have a working implementation it would be worth a shot to ask if this language wart can be removed from GHC. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Optimizing unamb by determining the state of a thunk?
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 to head normal form. Maybe using some vacuum tricks? This function would need to be in IO since it is of course not referentially transparent. Although threads are lightweight in Haskell, forking/waiting/killing surely must have more overhead than just checking the thunk of an expression? Of course one could also make unamb a primitive :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimizing unamb by determining the state of a thunk?
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 using some vacuum tricks? This function would need to be in IO since it is of course not referentially transparent. 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. Although threads are lightweight in Haskell, forking/waiting/killing surely must have more overhead than just checking the thunk of an expression? Of course one could also make unamb a primitive :-) That would be a lovely solution for me. Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimizing unamb by determining the state of a thunk?
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. hnf might return a different result for the same argument, since the evaluation of the argument might be happening on a different thread, so the result of hnf depends on the time when it is evaluated. Or am I missing something here? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimizing unamb by determining the state of a thunk?
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 it is. Suppose we call the function hnf :: a - Bool. hnf might return a different result for the same argument, since the evaluation of the argument might be happening on a different thread, so the result of hnf depends on the time when it is evaluated. Or am I missing something here? 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. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
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 avoid them as much as possible. I don't think #ifdef's would be really all over the place; it's more likely that a minor refactoring would take place so that (n+k)-patterns would disappear. 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 The UHC team is happy to announce the first public release of the Utrecht Haskell Compiler (UHC). UHC supports almost all Haskell98 features Why? Is there something about Haskell 98 that's hard to implement? Insanity. I doubt anyone is going to miss n+k patterns: That (taken with the followup from Richard O'Keefe saying he does use them) underlines my point, really. What follows is specific to Haskell, but the general point applies to most languages I've encountered. I have no love for n+k patterns, but they are part of Haskell98 -- and were the subject of protracted arguments for and against them before the Report was finished (I was against them, if I remember correctly). Any implementation claiming to be of Haskell98 should have them, whether or not the implementor likes them, because otherwise someone will come along with a valid Haskell98 programme and it won't compile, so they'll have to hack it around. This sort of thing (and resulting #ifdef all over the place) wastes far more programmer time in the end (assuming the compiler becomes popular) than it would take to implement the feature. 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 arguments for n+k patterns /in Haskell98/ were done long ago. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) --first release
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 The UHC team is happy to announce the first public release of the Utrecht Haskell Compiler (UHC). UHC supports almost all Haskell98 features Why? Is there something about Haskell 98 that's hard to implement? Insanity. I doubt anyone is going to miss n+k patterns: That (taken with the followup from Richard O'Keefe saying he does use them) underlines my point, really. What follows is specific to Haskell, but the general point applies to most languages I've encountered. I have no love for n+k patterns, but they are part of Haskell98 -- and were the subject of protracted arguments for and against them before the Report was finished (I was against them, if I remember correctly). Any implementation claiming to be of Haskell98 should have them, whether or not the implementor likes them, because otherwise someone will come along with a valid Haskell98 programme and it won't compile, so they'll have to hack it around. This sort of thing (and resulting #ifdef all over the place) wastes far more programmer time in the end (assuming the compiler becomes popular) than it would take to implement the feature. 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 arguments for n+k patterns /in Haskell98/ were done long ago. 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 avoid them as much as possible. I don't think #ifdef's would be really all over the place; it's more likely that a minor refactoring would take place so that (n+k)-patterns would disappear. In addition, (n+k) patterns will be removed from the standard as soon as the Haskell prime process produces a new one, so people who want to make their code support that new standard should be removing them right now. 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] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
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 public release of the Utrecht Haskell Compiler (UHC). UHC supports almost all Haskell98 features Why? Is there something about Haskell 98 that's hard to implement? Insanity. I doubt anyone is going to miss n+k patterns: That (taken with the followup from Richard O'Keefe saying he does use them) underlines my point, really. What follows is specific to Haskell, but the general point applies to most languages I've encountered. I have no love for n+k patterns, but they are part of Haskell98 -- and were the subject of protracted arguments for and against them before the Report was finished (I was against them, if I remember correctly). Any implementation claiming to be of Haskell98 should have them, whether or not the implementor likes them, because otherwise someone will come along with a valid Haskell98 programme and it won't compile, so they'll have to hack it around. This sort of thing (and resulting #ifdef all over the place) wastes far more programmer time in the end (assuming the compiler becomes popular) than it would take to implement the feature. 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 arguments for n+k patterns /in Haskell98/ were done long ago. -- Jón Fairbairn jon.fairba...@cl.cam.ac.uk http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2009-01-31) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
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 distribution's package manager. This is good advice (/usr/local is fine though). 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. This makes cabal's inversion of default a violation of least surprise, however easy it may be to justify that user installs are better. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
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 jon.fairba...@cl.cam.ac.uk wrote: 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 public release of the Utrecht Haskell Compiler (UHC). UHC supports almost all Haskell98 features Why? Is there something about Haskell 98 that's hard to implement? Insanity. I doubt anyone is going to miss n+k patterns: That (taken with the followup from Richard O'Keefe saying he does use them) underlines my point, really. What follows is specific to Haskell, but the general point applies to most languages I've encountered. I have no love for n+k patterns, but they are part of Haskell98 -- and were the subject of protracted arguments for and against them before the Report was finished (I was against them, if I remember correctly). Any implementation claiming to be of Haskell98 should have them, whether or not the implementor likes them, because otherwise someone will come along with a valid Haskell98 programme and it won't compile, so they'll have to hack it around. This sort of thing (and resulting #ifdef all over the place) wastes far more programmer time in the end (assuming the compiler becomes popular) than it would take to implement the feature. 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 arguments for n+k patterns /in Haskell98/ were done long ago. -- Jón Fairbairn jon.fairba...@cl.cam.ac.uk http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2009-01-31) ___ 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: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
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 arguments for n+k patterns /in Haskell98/ were done long ago. if you really believe in that you said, you can spend your own time adding its support :) i never seen n+k patterns in real code so i understand developers that don't want to waste time just to compliant standard even if their efforts will be never really used -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
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 (both times) there were odds and ends that I really hated (some of those feelings have changed), but I did it anyway. -- Lennart On Mon, Apr 20, 2009 at 1:02 PM, Bulat Ziganshin bulat.zigans...@gmail.com wrote: 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 arguments for n+k patterns /in Haskell98/ were done long ago. if you really believe in that you said, you can spend your own time adding its support :) i never seen n+k patterns in real code so i understand developers that don't want to waste time just to compliant standard even if their efforts will be never really used -- Best regards, Bulat mailto:bulat.zigans...@gmail.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: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
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. (n+k)-patterns are nothing compared to that. Lennart Augustsson wrote on 20.04.2009 15:17: 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 (both times) there were odds and ends that I really hated (some of those feelings have changed), but I did it anyway. -- Lennart On Mon, Apr 20, 2009 at 1:02 PM, Bulat Ziganshin bulat.zigans...@gmail.com wrote: 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 arguments for n+k patterns /in Haskell98/ were done long ago. if you really believe in that you said, you can spend your own time adding its support :) i never seen n+k patterns in real code so i understand developers that don't want to waste time just to compliant standard even if their efforts will be never really used -- Best regards, Bulatmailto:bulat.zigans...@gmail.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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
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 JavaScript - essential features working differently in Internet Explorer, Firefox, Opera, and Safari, and sometimes they even differ between versions; Web programmers still manage. (n+k)-patterns are nothing compared to that. Lennart Augustsson wrote on 20.04.2009 15:17: 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 (both times) there were odds and ends that I really hated (some of those feelings have changed), but I did it anyway. -- Lennart On Mon, Apr 20, 2009 at 1:02 PM, Bulat Ziganshin bulat.zigans...@gmail.com wrote: 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 arguments for n+k patterns /in Haskell98/ were done long ago. if you really believe in that you said, you can spend your own time adding its support :) i never seen n+k patterns in real code so i understand developers that don't want to waste time just to compliant standard even if their efforts will be never really used -- Best regards, Bulat mailto:bulat.zigans...@gmail.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 ___ 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] Code Golf
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 exactly the combinators that I was looking for. Unfortunately, I still don't manage to mimic my version that uses functional lists and continuations (but no ++) mainly because I'm lacking an equivalent of the second line of the above solution which allows for the simpler 'zipWith (++)' instead of the merge function. Anyway, once you know what they mean, Matt's combinators are quite useful. Thanks for pointing that out! Cheers, Sebastian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
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 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 JavaScript - essential features working differently in Internet Explorer, Firefox, Opera, and Safari, and sometimes they even differ between versions; Web programmers still manage. (n+k)-patterns are nothing compared to that. Lennart Augustsson wrote on 20.04.2009 15:17: 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 (both times) there were odds and ends that I really hated (some of those feelings have changed), but I did it anyway. -- Lennart On Mon, Apr 20, 2009 at 1:02 PM, Bulat Ziganshin bulat.zigans...@gmail.com wrote: 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 arguments for n+k patterns /in Haskell98/ were done long ago. if you really believe in that you said, you can spend your own time adding its support :) i never seen n+k patterns in real code so i understand developers that don't want to waste time just to compliant standard even if their efforts will be never really used -- Best regards, Bulatmailto:bulat.zigans...@gmail.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 ___ 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
[Haskell-cafe] breaking too long lines
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. Therefore I make some
suggestions here and ask for comments.
If a one-liner does not fit on one line I break the line after =
rather than breaking the following infix- or prefix-expression.
(I break in the same way after - or - in case- or do- expressions)
(Some people move = to the next line, but I only suggest this for
proper infix operators, below.)
If a do or a short
case ... of or let ... in fits, I leave it at the end of the
previous line behind = (- or -).
A line should be broken after do or of (from case) in order to
allow insertions without breaking the layout, provided there is
preceding text at all.
The following is fine, because there's no text before do)
c x =
do y -...
z ...
But this is fine, too, if not better:
c x = do
y - ...
z ...
It's not necessary to put do (or let) on a separate line (and care
about the indentation of that keyword):
c x =
do
y -...
z ...
Because layout may easily break (if b is renamed) and the layout block
starts already too far to the right, this is really bad:
c b x =
unless b $ do y - ...
z ...
In many cases a do can be moved to the end of the previous line:
c b x = unless b $ do
y - ...
z
What applies to do could be applied to let as well (and vice versa),
but:
f x = let
y = x + x
z = y + y
in z
does not look as nice as:
f x =
let y = x + x
z = y + y
in z
And also a let (without in) within a do should not be broken after
let.
A long infix-expression should be broken _before_ an infix symbol to
better indicate it's continuation:
f ++ g
++ h
f . g
$ h x
(One should also put spaces around infix operators and should not put
unnecessary brackets around prefix applications.)
Surely a long prefix expression can be broken anywhere, but I try to
break expressions on the top-level and not within too deeply nested
sub-expressions:
f arg1 arg2 arg3
(longArg4 sa1 sa2
sa3 sa4)
arg5 arg6 arg7
After a line break (following =, do, -, or -) I try to stay as
far to the left as layout permits (using 2 spaces as minimal indentation).
I don't care if =, -, or - of one block line up (which surely is
difficult for the top-level module block) and I may put parts of the rhs
below parts of the lhs:
let longPattern = case bla of
Nothing - don't know
Just b -
a longer expression
vN = ...
The standard breaking of if-then-else (within do) is:
if ...
then ...
else ...
but I think the following variations are also fine:
... - if ...
then ...
else ...
if ... then ... else
...
By chance I rarely use guards and where, therefore I give no examples
for those expressions.
Somewhat tricky I've found are 2 do-expressions connected by an
infix-operator within an outer do-expression:
do c - letter
do d - digit
return [c, d]
| do
u - char '_'
return [c, u]
The line containing | do is critical to indentation. If | do is
moved (2 columns) to the left it'll be wrong (by chance c will not be in
scope). If | do is moved (3 columns) to the right it'll mean
something different, namely parsing and returning a letter and a digit
_or_ parsing a letter, a digit, and an underscore, but only return the
letter and the underscore.
In order to more clearly put the infix operator into the middle I've
tried to insert one more space:
do c - letter
do d - digit
return [c, d]
| do
u - char '_'
return [c, u]
Also the indentation of data types is an issue, because I think, code
shouldn't be indented due to long (constructor) names. I've nothing
against long names, but one shouldn't try to put blocks to the right of
them:
data TName =
LongConstructorName
{ selector1 :: C1
, ... }
| LongSecondConstructor
deriving ...
Cheers Christian
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Code Golf
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 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 exactly the combinators that I was looking for. Unfortunately, I still don't manage to mimic my version that uses functional lists and continuations (but no ++) mainly because I'm lacking an equivalent of the second line of the above solution which allows for the simpler 'zipWith (++)' instead of the merge function. Anyway, once you know what they mean, Matt's combinators are quite useful. Thanks for pointing that out! Cheers, Sebastian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Sjoerd Visscher sjo...@w3future.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] CPS and the product function
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] CPS and the product function
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 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Eugene Kirpichov Web IR developer, market.yandex.ru ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimizing unamb by determining the state of a thunk?
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimizing unamb by determining the state of a thunk?
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 think it is hnf that Peter was talking about needing to be in IO, not unamb. - Jake ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: General function to count list elements?
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 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 C way from the list for optimization... Okay big hack, and one could do this already with reallyUnsafePtrEquality# I guess... And when the need gets big enough you pull out StablePtr and use that. :) Waaagh! Don't give him ideas, he's going to do it... Make yourself an enum, generate your list, nub it, then transform it to a list of functions. Always do everything with the least information sanely feasible, and a function is more information than a value, even if you can't get at it, anymore. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ 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] Re: General function to count list elements?
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 C way from the list for optimization... Okay big hack, and one could do this already with reallyUnsafePtrEquality# I guess... And when the need gets big enough you pull out StablePtr and use that. :) Waaagh! Don't give him ideas, he's going to do it... Make yourself an enum, generate your list, nub it, then transform it to a list of functions. Always do everything with the least information sanely feasible, and a function is more information than a value, even if you can't get at it, anymore. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] CPS and the product function
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 ekirpic...@gmail.com Subject: Re: [Haskell-cafe] CPS and the product function To: michael rice nowg...@yahoo.com Cc: haskell-cafe@haskell.org Date: Monday, April 20, 2009, 9:40 AM 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 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Eugene Kirpichov Web IR developer, market.yandex.ru ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: breaking too long lines
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, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] CPS and the product function
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 ekirpic...@gmail.com wrote: From: Eugene Kirpichov ekirpic...@gmail.com Subject: Re: [Haskell-cafe] CPS and the product function To: michael rice nowg...@yahoo.com Cc: haskell-cafe@haskell.org Date: Monday, April 20, 2009, 9:40 AM 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 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 Eugene Kirpichov Making multiplication non-strict? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] breaking too long lines
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 like tables (e.g. step functions
for abstract machines).
do c - letter
do d - digit
return [c, d]
| do
u - char '_'
return [c, u]
I try to avoid these, e.g. I would use this instead:
do c - letter
choice
[ do d - digit
return [c, d]
, do u - char '_'
return [c, u]
]
Actually, I try to avoid do-blocks, but that's a different story.
data TName =
LongConstructorName
{ selector1 :: C1
, ... }
| LongSecondConstructor
deriving ...
I use
data Maybe a
= Just a
| Nothing
deriving Show
or
data Maybe a
= Just
{ fromJust :: a
}
| Nothing
deriving Show
However, I would prefer the following Coq-like syntax:
data Maybe a =
| Just a
| Nothing
Tillmann
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
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 Haskell 98 at all (all or nothing mentality), if you want to be really strict. The fact is we have a choice... I won't tell people not to implement things in a way I don't like, I'll just look at it and decide whether I care to use it or not. As a result, UHC is not something I care to use, though I'm sure it's interesting for those who are using it. If I cared enough, and I don't, and the UHC sources are licensed in a way permitting so, I could make a Haskell 98 conforming version of it, and fork it myself. Dave On Mon, Apr 20, 2009 at 4:31 AM, Lennart Augustsson lenn...@augustsson.netwrote: 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 JavaScript - essential features working differently in Internet Explorer, Firefox, Opera, and Safari, and sometimes they even differ between versions; Web programmers still manage. (n+k)-patterns are nothing compared to that. Lennart Augustsson wrote on 20.04.2009 15:17: 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 (both times) there were odds and ends that I really hated (some of those feelings have changed), but I did it anyway. -- Lennart On Mon, Apr 20, 2009 at 1:02 PM, Bulat Ziganshin bulat.zigans...@gmail.com wrote: 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 arguments for n+k patterns /in Haskell98/ were done long ago. if you really believe in that you said, you can spend your own time adding its support :) i never seen n+k patterns in real code so i understand developers that don't want to waste time just to compliant standard even if their efforts will be never really used -- Best regards, Bulatmailto:bulat.zigans...@gmail.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 ___ 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[2]: [Haskell-cafe] CPS and the product function
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 OTOH, boolean operations are expected to short-circuit, so they are defined properly. try and (iterate [True,False]) 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 ekirpic...@gmail.com Subject: Re: [Haskell-cafe] CPS and the product function To: michael rice nowg...@yahoo.com Cc: haskell-cafe@haskell.org Date: Monday, April 20, 2009, 9:40 AM 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 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] CPS and the product function
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]. The documentation page [3] has a link to the source code [4]. Depending on some flag, it is either product = foldl (*) 1 or an explicit loop with an accumulator. That means that even for a non-strict (*), the whole input list would be processed before a result could be returned. Does anyone know how to define it to avoid that? You have to define a multiplication function which is non-strict in the second argument if the first is 0. mult 0 b = 0 mult a b = a * b Now we can foldr this multiplication function over a list, and evaluation will stop at the first 0. foldr mult 1 ([1..100] ++ [0 ..]) However, this solution seems not to run in constant space. We can write it with a strict accumulator to avoid this problem: product = product' 1 where product' acc [] = acc product' acc (0 : xs) = 0 product' acc (x : xs) = (product' $! acc * x) xs Tillmann [1] http://www.haskell.org/hoogle/ [2] http://www.haskell.org/hoogle/?hoogle=product [3] http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:product [4] http://haskell.org/ghc/docs/latest/html/libraries/base/src/Data-List.html#product ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
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? http://cvs.haskell.org/Hugs/pages/users_guide/haskell98.html#BUGS-HASKELL98 Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] CPS and the product function
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 [1,2,3,4,5,0,6,7,8,9] 0 *Main Data.List myprod [1,2,3,4,5] 120 *Main Data.List myprod [0..] 0 *Main Data.List Michael --- On Mon, 4/20/09, Tillmann Rendel ren...@cs.au.dk wrote: From: Tillmann Rendel ren...@cs.au.dk Subject: Re: [Haskell-cafe] CPS and the product function To: haskell-cafe@haskell.org Date: Monday, April 20, 2009, 11:07 AM 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]. The documentation page [3] has a link to the source code [4]. Depending on some flag, it is either product = foldl (*) 1 or an explicit loop with an accumulator. That means that even for a non-strict (*), the whole input list would be processed before a result could be returned. Does anyone know how to define it to avoid that? You have to define a multiplication function which is non-strict in the second argument if the first is 0. mult 0 b = 0 mult a b = a * b Now we can foldr this multiplication function over a list, and evaluation will stop at the first 0. foldr mult 1 ([1..100] ++ [0 ..]) However, this solution seems not to run in constant space. We can write it with a strict accumulator to avoid this problem: product = product' 1 where product' acc [] = acc product' acc (0 : xs) = 0 product' acc (x : xs) = (product' $! acc * x) xs Tillmann [1] http://www.haskell.org/hoogle/ [2] http://www.haskell.org/hoogle/?hoogle=product [3] http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:product [4] http://haskell.org/ghc/docs/latest/html/libraries/base/src/Data-List.html#product ___ 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: General function to count list elements?
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 - Bool], but you want to remove all functions that are obviously equal in the C way from the list for optimization... Okay big hack, and one could do this already with reallyUnsafePtrEquality# I guess... And when the need gets big enough you pull out StablePtr and use that. :) Waaagh! Don't give him ideas, he's going to do it... Nah, I don't think so. I think, even after all this mess, we've been relatively clear that Eq is how you do it. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
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 isn't Haskell 98 in my stack. Do you not use Hugs for the same reason? http://cvs.haskell.org/Hugs/pages/users_guide/haskell98.html#BUGS-HASKELL98 Martijn. I never use hugs... the only time I've ever run hugs, is because it was available for Plan 9. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
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: http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs-and-infelicities.html#vs-Haskell-defn Regards, Malcolm It's still a matter of choice. So we're saying there are no implementations of Haskell 98? Sounds like the same problem C++ and C99 have. 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
[Haskell-cafe] [ANN] Hack: a sexy Haskell Webserver Interface ^^
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 = run hello
Hack is a brainless port of the brilliant Ruby Rack framework. Rack is
very modular and that's
very important.
Rack utilities and middlewares should be able to be ported with
minimal effort, I hope.
link / source: http://github.com/nfjinjing/hack/tree/master
--
jinjing
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANN] Hack: a sexy Haskell Webserver Interface ^^
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 $ Response
{ status = 200
, headers = [ (Content-Type, text/plain) ]
, body= Hello World
}
main = run hello
Hack is a brainless port of the brilliant Ruby Rack framework. Rack is
very modular and that's
very important.
Rack utilities and middlewares should be able to be ported with
minimal effort, I hope.
link / source: http://github.com/nfjinjing/hack/tree/master
--
jinjing
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
--
/jve
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANN] Hack: a sexy Haskell Webserver Interface ^^
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 nfjinj...@gmail.comwrote:
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 = run hello
Hack is a brainless port of the brilliant Ruby Rack framework. Rack is
very modular and that's
very important.
Rack utilities and middlewares should be able to be ported with
minimal effort, I hope.
link / source: http://github.com/nfjinjing/hack/tree/master
--
jinjing
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
--
/jve
--
/jve
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
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: http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs-and-infelicities.html#vs-Haskell-defn Regards, Malcolm It's still a matter of choice. So we're saying there are no implementations of Haskell 98? Sounds like the same problem C++ and C99 have. Dave Why is this such a problem? You can still write and compile very beautiful programs with both GHC and UHC. And keep in mind that the UHC compiler is probably not designed to replace GHC and to be fully compliant with the Haskell 98 standard. It still has a very useful place in education and is certainly worth looking at. It is intensively making use of the attribute grammar system to perform traversals over the different internally used languages. This is a very different approach from what GHC does which makes it very interesting from an educational and scientific point of view. I encourage you to take a look inside, it is reasonably easy to grasp what going on inside of UHC. -- Sebastiaan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANN] Hack: a sexy Haskell Webserver Interface ^^
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 = [ (Content-Type, text/plain) ]
, body= Hello World
}
main = run hello
Hack is a brainless port of the brilliant Ruby Rack framework. Rack is
very modular and that's
very important.
Rack utilities and middlewares should be able to be ported with
minimal effort, I hope.
link / source: http://github.com/nfjinjing/hack/tree/master
begin:vcard
fn:Joseph Fredette
n:Fredette;Joseph
adr:Apartment #3;;6 Dean Street;Worcester;Massachusetts;01609;United States of America
email;internet:jfred...@gmail.com
tel;home:1-508-966-9889
tel;cell:1-508-254-9901
x-mozilla-html:FALSE
url:lowlymath.net, humbuggery.net
version:2.1
end:vcard
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANN] Hack: a sexy Haskell Webserver Interface ^^
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 jfred...@gmail.com wrote:
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 = [ (Content-Type, text/plain) ]
, body= Hello World
}
main = run hello
Hack is a brainless port of the brilliant Ruby Rack framework. Rack is
very modular and that's
very important.
Rack utilities and middlewares should be able to be ported with
minimal effort, I hope.
link / source: http://github.com/nfjinjing/hack/tree/master
___
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] ANN: persistent-map-0.0.0
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANN] Hack: a sexy Haskell Webserver Interface ^^
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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimizing unamb by determining the state of a thunk?
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
shared thunk[1].
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 don't see any reason why it shouldn't be possible to fully force a and
update the IORef from unsafePerformIO. I see no need for any
additional thread safety here.
There is a relevant proposal in the haskell prime wiki[2].
Unless I'm way off topic.
Friendly,
--Lane
[1]
http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel/multiproc.pdf
[2] http://hackage.haskell.org/trac/haskell-prime/ticket/106
On Mon, 20 Apr 2009, Peter Verswyvelen wrote:
Yes indeed.
On Mon, Apr 20, 2009 at 3:42 PM, Jake McArthur jake.mcart...@gmail.com wrote:
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
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] CPS and the product function
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 another way to do the same thing without passing b through all those recursions? I'm not good enough with Haskell's syntax to see how to do it. Michael --- On Mon, 4/20/09, michael rice nowg...@yahoo.com wrote: From: michael rice nowg...@yahoo.com Subject: Re: [Haskell-cafe] CPS and the product function To: haskell-cafe@haskell.org, Tillmann Rendel ren...@cs.au.dk Date: Monday, April 20, 2009, 11:28 AM 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 [1,2,3,4,5,0,6,7,8,9] 0 *Main Data.List myprod [1,2,3,4,5] 120 *Main Data.List myprod [0..] 0 *Main Data.List Michael --- On Mon, 4/20/09, Tillmann Rendel ren...@cs.au.dk wrote: From: Tillmann Rendel ren...@cs.au.dk Subject: Re: [Haskell-cafe] CPS and the product function To: haskell-cafe@haskell.org Date: Monday, April 20, 2009, 11:07 AM 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]. The documentation page [3] has a link to the source code [4]. Depending on some flag, it is either product = foldl (*) 1 or an explicit loop with an accumulator. That means that even for a non-strict (*), the whole input list would be processed before a result could be returned. Does anyone know how to define it to avoid that? You have to define a multiplication function which is non-strict in the second argument if the first is 0. mult 0 b = 0 mult a b = a * b Now we can foldr this multiplication function over a list, and evaluation will stop at the first 0. foldr mult 1 ([1..100] ++ [0 ..]) However, this solution seems not to run in constant space. We can write it with a strict accumulator to avoid this problem: product = product' 1 where product' acc [] = acc product' acc (0 : xs) = 0 product' acc (x : xs) = (product' $! acc * x) xs Tillmann [1] http://www.haskell.org/hoogle/ [2] http://www.haskell.org/hoogle/?hoogle=product [3] http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:product [4] http://haskell.org/ghc/docs/latest/html/libraries/base/src/Data-List.html#product ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -Inline Attachment Follows- ___ 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] Optimizing unamb by determining the state of a thunk?
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. - Jake ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimizing unamb by determining the state of a thunk?
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 form.rwhnf :: Strategy a rwhnf x = x `seq` () but the documentation of seq says *seq* :: a - b - bSource file:///C:/app/ghc-6.10.2/doc/libraries/ghc-prim/src/GHC-Prim.html#seqEvaluates its first argument to head normal form, and then returns its second argument as the result. Furthermore: *rnf* :: Strategy file:///C:/app/ghc-6.10.2/doc/libraries/parallel/Control-Parallel-Strategies.html#t%3AStrategy aSource file:///C:/app/ghc-6.10.2/doc/libraries/parallel/src/Control-Parallel-Strategies.html#rnfReduces its argument to (head) normal form. So from the documentation rnf should be like seq, but it is not, rnf is a deep seq. I find this very confusing. Is the documentation of seq wrong (should be weak head normal form)? Anyway, so I guess we would actually need a function: iswhnf :: a - IO Bool But since the value of this iswhnf function depends on when it is called, I feel it has to be in the IO monad; actually multiple threads evaluating it have nothing to do with it? On Mon, Apr 20, 2009 at 10:05 PM, Jake McArthur jake.mcart...@gmail.comwrote: 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. - Jake ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANN] Hack: a sexy Haskell Webserver Interface ^^
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. ___ 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] FRP, integration and differential equations.
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 the plugging a space leak with an arrow papers reduces the recursive signal problem to * * * *e = integral 1 e* * * *Maybe the Nlift problem is a good example for dynamic collections, but I guess we'll need more examples.* * * *The reason why I'm talking about examples and not semantics is because the latter seems to be pretty hard to get right for FRP?* I would like to come back to this exemple. I am trying to write a small FRP in F# (which is a strict language, a clone of Ocaml) and I also came across space and/or time leak. But maybe not for the same reasons... Thinking about these problems and after some trials and errors, I came to the following conclusions: I believe that writing the expression e = integral 1 *something* where e is a Behavior (thus depends on a continuous time). has really two different meanings. 1. if *something *is independent of e, what the above expression means is the classical integration of a time dependent function between t0 and t1. Several numerical methods are available to compute this integral and, as far as I know, they need to compute *something *at t0, t1 and, possibly, at intermediate times. In this case, *something *can be a Behavior. 2. If *something *depends directly or indirectly of e then we are faced with a first order differential equation of the form: de/dt = *something*(e,t) where de/dt is the time derivative of e and *something*(e,t) indicates that *something* depends, without loss of generality, on both e and t. There exist specific methods to numerically solve differential equations between t0 and t1. Some of them only require the knowledge of e at t0 (the Euler method), some others needs to compute *something *from intermediate times (in [t0, t1[ ) *and *estimates of e at those intermediary times. 3. *something *depends (only) on one or more events that, in turns, are computed from e. This case seems to be the same as the first one where the integrand can be decomposed into a before-event integrand and an after-event integrand (if any event has been triggered). Both integrands being independent from e. But I have not completely investigated this case yet... Coming back to my FRP, which is based on residual behaviors, I use a specific solution for each case. Solution to case 1 causes no problem and is similar to what is done in classical FRP (Euler method, without recursively defined behaviors). Once again as far as I know... The second case has two solutions: 1. the 'integrate' function is replaced by a function 'solve' which has the following signature solve :: a - (Behavior a - Behavior a) - Behavior a In fact, *something*(e,t) is represented by an integrand function from behavior to behavior, this function is called by the integration method. The integration method is then free to pass estimates of e, as constant behaviors, to the integrand function. The drawbacks of this solution are: - To avoid space/time leaks, it cannot be done without side effects (to be honest, I have not been able to find a solution without assignement). However these side effects are not visible from outside of the solve function. .. - If behaviors are defined within the integrand function, they are not accessible from outside of this integrand function. 2. Introduce constructions that looks like to signal functions. solve :: a - SF a a - Behavior a where a SF is able to react to events and may manage an internal state. This solution solves the two above problems but make the FRP a bit more complex. Today, I tend to prefer the first solution, but what is important, in my opinion, is to recognize the fact that e = integral 1 *something* really addresses two different problems (integration and solving of differential equations) and each problem should have their own solution. The consequences are : 1. There is no longer any need for my FRP to be able to define a Behavior recursively. That is a good news for this is quite tricky in F#. Consequently, there is no need to introduce delays. 2. Higher order methods for solving of diff. equations can be used (i.e. Runge-Kutta). That is also good news for this was one of my main goal in doing the exercice of writing a FRP. Regards, J-C ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Runge-Kutta library -- solve ODEs
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 Hollerbach uhollerb...@gmail.com wrote: Damn, I never thought of that. Sorry! Guess I've only been haskell-hacking on my little old iMac... A new version is attached, with the version number bumped up by 0.0.1 and rungekutta.hs renamed to RungeKutta.hs. Hopefully it should work out-of-the-box now. Off to patch my repository... Uwe On 4/19/09, Alexey Khudyakov alexey.sklad...@gmail.com wrote: I have so far only tested it with ghc 6.8.3 on MacOS 10.3.9 (powerPC), but I know of no reason why it wouldn't work with other versions and OSs. It breaks on Linux (and all unices) because name of file in tarball is 'rungekutta.hs' not 'RungeKutta.hs' as required. In other words: god blame case-insensitive file systems. After renaming everything works just fine. ___ 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: [Announce] primes
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. EratoS.hs is explained in thorkilnaur.dk/~tn/Haskell/EratoS/EratoS2.txt. Please don't hesitate to ask questions about this. I'll do my best to answer. ... Best regards Thorkil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Petr Ročkai's darcs project accepted for Haskell GSoC
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 improve our performance so that one day we will able to recommend darcs for medium sized and larger projects. Until early 2008, we have been focused on darcs 2: which provides the darcs 2 theory (to solve most of the exponential merge problems), and also the hashed format repositories (including darcs 2). The project for this summer will allow us to complete the work on hashed repositories. In their current state, hashed format repositories make darcs a lot more robust and also allow us to fetch repositories faster (with darcs get --lazy and with a global patch cache). But in their current form, hashed repositories can can also slow down day-to-day operations like darcs whatsnew and darcs record. Petr has identified the cause of these delays has provided a work plan which we think will get hashed storage right. If his project is successful, future versions of darcs should make operations like darcs record and whatsnew much more comfortable in practice. Congratulations and good luck to Petr! And many thanks to the darcs and Haskell communities for their support. -- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow PGP Key ID: 08AC04F9 pgpnAFiBOvhlW.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
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, they make the code less readable; I use them because they make the code *MORE* readable. Some versions of the 'view' idea can be used to fake n+k patterns, so I imagine that this argument will be used to ensure that UHC never ever supports anything resembling views. If I want something that's almost a Haskell compiler but not quite, with some interesting extensions, I've known where to find Clean for a long time. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
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 that many people *can* install stuff in. This University, for example, has a strict policy that NO-ONE (not even heads of department) other than designated system administrators may have 'adminstrator' access, which is required to install stuff in /usr/local. Either stuff can be installed easily in my own directories (which is why I have ~/local on all my machines), or I have to ask the system adminstrators to install it when they can get around to it (I've been waiting a couple of months already for one thing), or it doesn't get installed. As long as there are Windows machines in this organisation, that policy is _not_ going to change, not even for Linux or MacOS or Solaris. 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 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 mean we have to copy them. This makes cabal's inversion of default a violation of least surprise, however easy it may be to justify that user installs are better. Sometimes it is _nice_ to be surprised. If someone out of the blue gave you a free car, would you turn it down because it violated the principle of least surprise? Least surprise is not as important as do the right thing. On Macs and Windows boxes, I expect installers to _ask_ me where I want to put things. In any case, there are two easy ways to address the issue. 1. Have the installation tools *ask* the user whether they want the software installed in their own files or in /usr/local. 2. If you want to follow the blundering herd as much as you can, have the installation process start by trying to install an empty file in /usr/local, and if it can't do that, do the right thing instead. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
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 libraries? For that matter, *GHC* isn't fully Haskell98: http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs-and-infelicities.html#haskell98-divergence -- 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 universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
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 cabal calls a 'global' install by default. 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 mean we have to copy them. The assumption is that you are running a multipurpose computer, i.e. your Haskell compiler isn't the only application you care about and you don't want it or other applications to interact badly together. The best way to do this is to have a package maintained by the distribution, and not have users or even sysadmins directly install it from source. Using non-standard installation methods makes it harder for package maintainers to package the application and suggests you haven't taken any care / don't care about making global installation safe. Edward ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
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 isn't Haskell 98 in my stack. So you don't use hierarchical libraries? For that matter, *GHC* isn't fully Haskell98: http://www.haskell.org/ghc/docs /latest/html/users_guide/bugs-and-infelicities.html#haskell98-divergence It's about compatibility. An implementation can diverge from the standard, but it should be able to parse the standard code correctly. It is totally okay to add something to the standard, but not remove something from the standard. Because by adding something, you wouldn't break the standard compliant code. But removing anything from standard would prevent any standard code from working correctly. The only thing that would make a standard code break in ghc is let x = 42 in x == 42 == True But I believe it is a much smaller issue compared to what UHC has. I believe the standard should be maintained as the intersect of all the valid implementations. If any implementation does not implement all of the standard, according to what should our coders write? -- c/*__o/* \ * (__ */\ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
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, graphic installers like firefox - is do to what cabal calls a 'global' install by default. 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 mean we have to copy them. The assumption is that you are running a multipurpose computer, i.e. your Haskell compiler isn't the only application you care about and you don't want it or other applications to interact badly together. The best way to do this is to have a package maintained by the distribution, and not have users or even sysadmins directly install it from source. Using non-standard installation methods makes it harder for package maintainers to package the application and suggests you haven't taken any care / don't care about making global installation safe. I second that. -- c/*__o/* \ * (__ */\ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: curl-1.3.5
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 reporting this problem. Bug reports / feature requests etc. most welcome, btw. enjoy --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FRP, integration and differential equations.
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 what's put in front of it or inside. If our implementation can't match this simplicity, then we got a problem! The arrow FRP gets rid of the leak problem and maintains a single definition of integral by using a restricted form of recursion - the loop operator. If you'd rather prefer having signals as first class objects, similar technique existed in synchronous languages [1], i.e., by using a special rec primitive. Disclaimer: I was the co-author of the leak paper [2]. [1] A co-iterative characterization of synchronous stream functions, P Caspi, M Pouzet. [2] Plugging a space leak with an arrow, H. Liu, P. Hudak -- Regards, Paul Liu Yale Haskell Group http://www.haskell.org/yale On 4/20/09, jean-christophe mincke jeanchristophe.min...@gmail.com wrote: 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 the plugging a space leak with an arrow papers reduces the recursive signal problem to * * * *e = integral 1 e* * * *Maybe the Nlift problem is a good example for dynamic collections, but I guess we'll need more examples.* * * *The reason why I'm talking about examples and not semantics is because the latter seems to be pretty hard to get right for FRP?* I would like to come back to this exemple. I am trying to write a small FRP in F# (which is a strict language, a clone of Ocaml) and I also came across space and/or time leak. But maybe not for the same reasons... Thinking about these problems and after some trials and errors, I came to the following conclusions: I believe that writing the expression e = integral 1 *something* where e is a Behavior (thus depends on a continuous time). has really two different meanings. 1. if *something *is independent of e, what the above expression means is the classical integration of a time dependent function between t0 and t1. Several numerical methods are available to compute this integral and, as far as I know, they need to compute *something *at t0, t1 and, possibly, at intermediate times. In this case, *something *can be a Behavior. 2. If *something *depends directly or indirectly of e then we are faced with a first order differential equation of the form: de/dt = *something*(e,t) where de/dt is the time derivative of e and *something*(e,t) indicates that *something* depends, without loss of generality, on both e and t. There exist specific methods to numerically solve differential equations between t0 and t1. Some of them only require the knowledge of e at t0 (the Euler method), some others needs to compute *something *from intermediate times (in [t0, t1[ ) *and *estimates of e at those intermediary times. 3. *something *depends (only) on one or more events that, in turns, are computed from e. This case seems to be the same as the first one where the integrand can be decomposed into a before-event integrand and an after-event integrand (if any event has been triggered). Both integrands being independent from e. But I have not completely investigated this case yet... Coming back to my FRP, which is based on residual behaviors, I use a specific solution for each case. Solution to case 1 causes no problem and is similar to what is done in classical FRP (Euler method, without recursively defined behaviors). Once again as far as I know... The second case has two solutions: 1. the 'integrate' function is replaced by a function 'solve' which has the following signature solve :: a - (Behavior a - Behavior a) - Behavior a In fact, *something*(e,t) is represented by an integrand function from behavior to behavior, this function is called by the integration method. The integration method is then free to pass estimates of e, as constant behaviors, to the integrand function. The drawbacks of this solution are: - To avoid space/time leaks, it cannot be done without side effects (to be honest, I have not been able to find a solution without assignement). However these side effects are not visible from outside of the solve function. .. - If behaviors are defined within the integrand function, they are not accessible from outside of this integrand function. 2. Introduce constructions that looks like to signal functions. solve :: a - SF a a - Behavior a where a SF is able to react to events and may manage an internal state. This solution solves the two above problems but
Re: [Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
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 you possibly know that? I can't; that's why I've said seems like. If I want something that's almost a Haskell compiler but not quite, with some interesting extensions, I've known where to find Clean for a long time. That's a strange desire. Personally, I want a compiler for a nice, simple, and useful language. I don't want a Haskell compiler; it just so happens that GHC is the best approximation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
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 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 mean we have to copy them. No. It's not an assumption, it's a default. No one is assuming anything. Both options are available. 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. In point of fact, I'm sure that a larger proportion of haskell users have their own machine than don't. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
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, but there are lots of people at this University in my situation. A default which means we can't install stuff is a default that I cannot regard with happiness, and which I cannot comprehend anyone contemplating with complacency. One of the suggestions I have made is that an installer could/should investigate whether it *can* install in the standard place (since ghc on my Mac is in /bin, not /usr/local/bin, and since I certainly didn't put it there, I wonder just how standard a standard place is), and if it *can't*, instead of failing miserably, it should *out of the box* *without recompiling from sources* let the user put it wherever it needs to go. This is compatible with the default on all systems where the default would actually _work_, while being _useful_ on systems where it wouldn't. It shouldn't be necessary to point out that the people least able to install in /usr/local are by and large going to be the people least able to build from sources, so saying build from sources if you can't install in a standard place would not be user-friendly. In point of fact, I'm sure that a larger proportion of haskell users have their own machine than don't. That's the wrong question. In addition to the several machines in my office, and the departmental laptop, I _do_ have several machines of my own. But the mere fact of possessing my own machines does NOT mean that I am able to install stuff on the machines I spend most of my time using. Some of the right questions are - how many potential whatever users would need to have whatever installed on _some_ machine they do NOT have administrator access to? - if people find Mac and Windows installers that show you where something is going to be put and offer you the chance to change it acceptable, why exactly would that be unacceptable under Linux or Solaris? - since we know install-anywhere binary releases are possible, and since we know that an installer _can_ probe to see whether installation in /usr/local (or any other standard place) is possible, why not do it? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
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 would be). Secondly, it seems like almost nobody uses (n+k)-patterns, How can you possibly know that? I can't; that's why I've said seems like. Plus, there was a movement to ban them: http://www.mail-archive.com/hask...@haskell.org/msg01261.html All jesting aside, after I read article I was even less eager to use them, and I never thought to use them in a real program anyway. 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 that if someone with haskell-src-ext experience sat down they could go through all of package in an automated way and count the number of uses of n+k patterns in source code that appears in the wild. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
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 mean we have to copy them. The assumption is that you are running a multipurpose computer, i.e. your Haskell compiler isn't the only application you care about and you don't want it or other applications to interact badly together. That cannot be right. By that definition, I *do* run a multipurpose computer, in fact several of them. If I _weren't_ running multipurpose computers, I wouldn't be wanting GHC on them. On none of them is it possible for me to install in /usr/local. On no computer that is ever attached to the University's network is it possible for me or any other staff member (except the designated sysadmins) to do so, let alone students. The best way to do this is to have a package maintained by the distribution, and not have users or even sysadmins directly install it from source. Whether or not one installs from source and whether one installs in a system location or a user location are INDEPENDENT questions. Quintus, for example, provided binary releases that customers could install wherever they wanted. We were doing that 25 years ago. Installing-wherever-the-user-wants WITHOUT source has been doable for a long time, and is what I _expect_ in a Windows or Mac program. There are dishonourable exceptions. Recently I bought a French drill program for my elder daughter. At home I use a dual-boot (MacOS/Windows Vista) laptop provided by the department. On the Windows side, it asked me where I wanted it to go, and went there, no worries. On the MacOS side, - I was logged in as XXX - in order to install, I had to enter my junior sysadmin (adminXXX) credentials -- I don't think I was supposed to be given this much power, but I'd given the sysadmins such a long shopping list of applications I wanted on this multipurpose computer that they preferred me to do most of it - the programs were actually _installed_ as owned by 'admin' with the result that I cannot run them, or change their permissions so that I can run them, or even remove them. You can imagine how happy that kind of nonsense makes me. If they could get it right on Windows, how come they got it so egregiously wrong on MacOS? By assuming that everyone can become the ultimate superuser at will. Using non-standard installation methods makes it harder for package maintainers to package the application and suggests you haven't taken any care / don't care about making global installation safe. I'm sorry, there is no such animal as safe global installation, in the sense of download this one package and do what it says. ghc 6.8.3 is /usr/bin/ghc on my office Mac, but nothing in the world prevents there being some other program called ghc that would also like to be there. Only by painstaking verification of a whole bunch of applications together can one be confident of safety. My $PATH has to be maintained with some delicacy, as more than 1200 command names appear in more than two directories on it. There seem, for example, to be 4 programs called 'python'; two of them are links to 2.4, one of them is 2.3, and I can't tell what the other is. And don't go blaming me for this state of affairs, because they are _all_ system directories. Oh, and none of the directories holding python is any part of /usr/local. Since the version of gcc in /usr/local is 2.95.2, if I want a less antique version of gcc, /usr/local/bin isn't much use in my $PATH. Put ghc there, and what makes you think I will be able to run it? (The version of Amaya there is also hopelessly out of date, but there is nothing I can do about it.) Package maintainers _should_ find it _easier_ to provide reliably installable packages if they _don't_ take it for granted that they can put things in questionably standard places. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
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 that if someone with haskell-src-ext experience sat down they could go through all of package in an automated way and count the number of uses of n+k patterns in source code that appears in the wild. I'm sorry, that wouldn't even come *close* to answering the question. It's a good way to demonstrate that people *are* using some feature (like hierarchical package names), but an incredibly bad way to show that they aren't. None of the Haskell code I've ever written, for example, will appear. Because none of that code was intended for general use. If every Haskell user contributed to Hackage, and if every contributer to Hackage contributed all the code they wrote, then it would make sense. In the Erlang mailing list, I frequently use the technique of trawling through publically available Erlang sources to demonstrate that features people claim are rare are not. But I'd never be silly enough to claim on the basis of such a scan that some feature _wasn't_ being used extensively in other sources. If the Haskell Great Powers decide to remove n+k patterns, so be it. I can live with that. It's not my language after all. I'm profoundly grateful to the people who designed and implemented it, and who keep stretching my mind with new levels of reuse and composition. I won't _like_ the loss of a contributor to readability, but I can live with it, just as I lived with having to use fmap instead of map. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
