On Wednesday 29 May 2002 02:58, Hal Daume III wrote:
Is there any particular reason FiniteMap (and hence Set) aren't instances
of Ord? I realize it's weird to define a map to be ordered, but even if
the Ord definition were in some sense nonsensical, being able to have,
for instance, Sets of
(Re: Eray's code using FiniteMaps/Sets)
Comments welcome,
I'd suggest
show s = mkSet ++ show (setToList s)
show fm = listToFM ++ show (fmToList fm)
That way you can easily paste the output of a program
into your code back again, and you can easily tell
the type of the `showed'
I don't know if anyone can help with this; I've checked the FAQs and
the bug-reports on SourceForge and found nothing but I'd have thought
it might be a common problem for folks migrating from hugs to ghci.
I'm used to using hugs in
haskell 98 mode but it seems that functions need not be
Hello Haskellers, I've just joined this email group because I am
teaching Haskell to our 2nd year students. I'm not a Haskell expert
but I do enjoy functional programming.
I don't know if anyone can help with this; I've checked the FAQs and
the bug-reports on SourceForge and found nothing but
The GHC docs claim Ptr a is an instance of Eq, Ord and Show, but it
doesn't actually seem to have a Show instance. At least the docs should
reflect the fact that there is not instance; preferably, could someone
actually make an instance? It would be nice (primarily for debugging
purposes) to be
--- Matt Fairtlough [EMAIL PROTECTED]
wrote:
instance (Eq a, Testit a) = Super (Test a) where
sup1 (Test{f1=x, f2=y}) = Just Test{f1=x, f2=y}
where
y' = top y
x' = top x
top :: [a] - a
top (s:st) = s
is it possible to compile this program in
ghc-5.02.3?
Maybe
| It would be strange to name a function readFloat if its type is
| RealFrac a = ReadS a.
| I think the function should be named readFrac. For
| compatibility, one could put the following into the prelude:
| readFloat :: RealFloat a = ReadS a
| readFloat = readFrac
Well, that would
Hi,
As I understand it, function application has highest precedence
(10 even!) whereas $, the operator which does the same thing, has
lowest precedence (0 even!). But there's something that doesn't
make sense to me.
Suppose I have functions
f :: Int - Int
f x - x * x
g :: Int
f $ g x
using the notations from http://haskell.org/onlinereport/lexemes.html,
`f' and `g' are varids, while `$' is a conid.
see also http://haskell.org/onlinereport/exps.html, `f $ g x' is parsed as
exp - exp qop exp - exp qop ( fexp ) - exp qop (fexp axep)
(regardless of
Hi Mark,
Suppose I have functions
f :: Int - Int
f x - x * x
I suppose you mean: f x = x * x
g :: Int - Int
g x - x + 1
The lazy application operator $ allows me to do:
f $ g x
instead of
f (g x)
But I don't understand why it works this way! Let
foldr, foldM, etc. derive a recursive computation from the
recursive structure of an input list, so you have to feed
one in. If you want to bypass the list, you could use
IO-observations (getLine, isEOF) instead of list
observations (head/tail, null):
Yes you can define it,
And you can,
At 2002-05-30 02:26, Jon Fairbairn wrote:
I think this is extremely bad language design! In general I
like having layout rules, but
...
What's the deal with the whole layout thing anyway? I've never come
across it before in another language. Is it an academic thing? It drove
me nuts when I
At 2002-05-30 02:46, I wrote:
What's the deal with the whole layout thing anyway? I've never come
across it before in another language.
Oh, wait, there's Python and Ruby. For some reason it doesn't bother me
so much with them.
--
Ashley Yakeley, Seattle WA
Ashley Yakeley wrote:
At 2002-05-30 02:26, Jon Fairbairn wrote:
I think this is extremely bad language design! In general I
like having layout rules, but
...
What's the deal with the whole layout thing anyway? I've never come
across it before in another language. Is it an academic thing?
On Thu, 30 May 2002, Ashley Yakeley wrote:
it). Certainly I find {;} more readable, and I suspect anyone else with a
C/C++/Java background (or even a Scheme/Lisp background) does too./RANT
Just a data point: I learned Basic, Pascal, Standard ML, C, Haskell, C++,
Perl, Python in that order
At 2002-05-30 02:54, Lennart Augustsson wrote:
If you look at C ( offspring), it's not the {;} that makes the code
readable, it's the indentation that does. So why not acknowledge that?
In C, the indentation is an important visual clue, but there are many
different indentation styles. It's
Johannes Waldmann [EMAIL PROTECTED] writes:
HTk, a graphical user interface toolkit and library for Haskell.
what are the differences to FranTk ( http://haskell.cs.yale.edu/FranTk/ ) ?
In a nutshell, it uses a different event model. As far as I
understand, FranTk allows you to
Hugs has a bug in Time. I would expect toUTCTime and toCalendarTime to be
inverses of toClockTime (modulo the IO monad).
toCalendarTime :: ClockTime- IO CalendarTime
toUTCTime:: ClockTime- CalendarTime
toClockTime :: CalendarTime - ClockTime
module Main(main)
I like layout but I think the existing rules are too complicated. Unfortunately it's
difficult to do anything with them without breaking vast swathes of existing code,
so we'll just have to put up with them.
The reason I think layout is better than using {'s and ,'s is that humans
use the
Martin Odersky [EMAIL PROTECTED] writes:
Redundancy maybe? What's wrong in having both layout and punctuation?
Short answer: What's wrong with it is that humans use layout to infer
the semantic meaning, compilers use punctuation. Thus it's not really
redundancy.
-kzm
--
If I haven't seen
What's the deal with the whole layout thing anyway? I've never come
across it before in another language.
Python has it as well (they stole it from Haskell?)
If I were teaching Haskell to working programmer types like myself, I
would encourage them to always use full semicolons and braces
... layout rules somewhat
like Haskell's. In our experience it was the single thing that
confused students most.
same here, for exactly these reasons. students get really confused.
on the other hand, students regularily get confused by other things as well,
like homework assignments on
At 2002-05-30 04:19, Johannes Waldmann wrote:
same here, for exactly these reasons. students get really confused.
on the other hand, students regularily get confused by other things as well,
like homework assignments on formal languages,
so that alone is not enough reason to drop the subject
At 2002-05-30 03:59, Ketil Z. Malde wrote:
Short answer: What's wrong with it is that humans use layout to infer
the semantic meaning,
No... layout by itself can't be trusted. It's only a clue. One needs to
learn the precise Haskell-specific layout rules, and they're not obvious.
--
Ashley
Hi everyone,
I thought I would bring a students perspective into this discussion.
Moving from a C background to Haskell, the layout wasn't very intuitive at
first. This was mainly due to my hand's on approach (looking at examples
and trying to code similar programs). Given that if i read up on
Functional and Declarative Programming in Education (FDPE02)
A one day workshop at PLI'02
Monday 7 October 2002, Pittsburgh, PA, USA
SECOND (AND FINAL) CALL FOR SUBMISSIONS
* * Deadline June 25 2002 * *
Functional and declarative programming plays an
Hey Simon et al at Micro$oft, when will there be an H#?
(Ok, I'll settle for Haskell.NET :-)
-Paul
---BeginMessage---
Title: Message
Paul, I just saw this,
and I think you and I were talking about using ML. Let me know if we need
to follow-up on this further.
Scott
On Thu, 30 May 2002, Don Syme wrote:
going to provide. Given the general complexity of GHC, the longish
compile times and the reliance of the GHC library implementation on C
and C libraries in so many places I decided to implement a simpler
language from scratch. I like the idea that a
Hey Simon et al at Micro$oft, when will there be an H#?
But H# is C! we don't want that, surely? :-)
Jón
--
Jón Fairbairn [EMAIL PROTECTED]
31 Chalmers Road [EMAIL PROTECTED]
Cambridge CB1 3SZ+44 1223
I like layout but I think the existing rules are too
complicated. Unfortunat ely it's difficult to do anything
with them without breaking vast swathes of existing code,
so we'll just have to put up with them.
Well, there's two things to consider: Haskell 98, which
probably shouldn't change,
Yes you can define it,
And you can, as well.
Man sollte sich nicht darauf verlassen, daß ein Englander
man verwendet, wenn es angebraucht wäre¹.
That's how common idioms come into being;
there's no special magic about the folds already in existence.
Well, my point is that there is --
Jon Fairbairn wrote
[snip]
Well, there's two things to consider: Haskell 98, which
probably shouldn't change, and extended Haskell, which
probably should. Especially if we can make the rules both
simpler and better.
[snip]
How can I resist? I proposed the following revised layout rule some
I wrote:
Can someone remind me why the A close brace is also inserted whenever
the syntactic category containing the layout list ends part
of the rule is there?
Lennart wrote:
It's so you can write
let x = 2+2 in x*x
(and similar things)
and Arjan van IJzendoorn wrote:
x = (3,
Paul Hudak [EMAIL PROTECTED] writes:
Hey Simon et al at Micro$oft, when will there be an H#?
(Ok, I'll settle for Haskell.NET :-)
There's hugs98.net and it's with us now:
http://galois.com/~sof/hugs98.net/
--sigbjorn
___
Haskell mailing list
Hey Sigbjorn, that looks great! I'll look forward to trying it out.
Perhaps when the source release is available someone could look at
getting hugs98.net to be able to interop. with ILX components as well,
making combined F#/hugs98.net apps feasible. I'm one who believe both
Haskell and ML have
Sigbjorn has already shown how a non-IL-generating approach is possible.
I think a simple implementation of a Haskell.NET compiling to IL is
feasible, especially if you're willing to do the interop with .NET
components by extending the language as with F# or SML.NET. It's more
that GHC is a bit
Hi Don --
Thanks for all the informative stuff regarding FP implementations on
.NET. However I am a little surprised by one thing you say:
... But the only truly serious complications added by .NET
itself are (a) the general problem of Haskell interop with imperative
libraries, requiring
... But the only truly serious complications added by .NET
itself are (a) the general problem of Haskell interop with
imperative
libraries, requiring you to reach for monads quite often (or to wrap
the libraries yourself) and (b) ...
IMHO problem (a) will always be the thing that
My dissertation, Hybrid Eager and Lazy Evaluation for Efficient
Compilation of Haskell, is now available on the web:
http://www.csg.lcs.mit.edu/~earwig/thesis.html
Abstract (1st paragraph only):
The advantage of a non-strict, purely functional language such as
Haskell lies in its clean
Don Syme [EMAIL PROTECTED] wrote,
And getting top-notch performance is obviously always a huge challenge
for Haskell, and you can't play some common implementation tricks when
compiling to IL. But the only truly serious complications added by .NET
itself are (a) the general problem of
D. Tweed [EMAIL PROTECTED] wrote,
On Thu, 30 May 2002, Don Syme wrote:
going to provide. Given the general complexity of GHC, the longish
compile times and the reliance of the GHC library implementation on C
and C libraries in so many places I decided to implement a simpler
language
G'day all.
On Thu, May 30, 2002 at 01:10:03PM +0200, Johannes Waldmann wrote:
Python has it as well (they stole it from Haskell?)
Python's layout rule looks more like Occam's than Haskell's, to my eyes.
Aside: Was Occam the first language of the post-punched-card era to use
layout as syntax?
Hi All,
Andrew J Bromage wrote:
G'day all.
On Thu, May 30, 2002 at 01:10:03PM +0200, Johannes Waldmann wrote:
Python has it as well (they stole it from Haskell?)
Python's layout rule looks more like Occam's than Haskell's, to my eyes.
Aside: Was Occam the first language of the
[redirected to haskell-cafe]
Ashley Yakeley wrote (on 30-05-02 03:18 -0700):
At 2002-05-30 02:54, Lennart Augustsson wrote:
If you look at C ( offspring), it's not the {;} that makes the code
readable, it's the indentation that does. So why not acknowledge that?
In C, the indentation is
On Thursday 30 May 2002 13:43, Frank Atanassow wrote:
Anyway, I have the feeling that, for every person on this list who
complains about layout being unintuitive, there are 10 people who would say
the opposite. Shall we take a poll?
It's not unintuitive, it's counter-intuitive. :) The errors
Just to add my voice to the din...
I come from a c/c++/java background, and I taught myself haskell. The
layout rules were the part I had the least problem with. I'd prefer that
if any change is made it's one that adds options, not removes them. I'm
confused as to the source of the problem,
[redirected to haskell-cafe]
Jón Fairbairn wrote:
1. Why -f anyway? It took me ages to work out what
-fallow-overlapping-instances meant -- I wondered how
fallow could apply to overlapping instances.
I believe the authors of GHC followed the naming conventions
of GCC, which can be gleaned
At 2002-05-30 16:51, [EMAIL PROTECTED] wrote:
-Wmissing-protons
Compiles BASIC?
--
Ashley Yakeley, Seattle WA
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
-Wmissing-prototypes, actually (http://www.esat.kuleuven.ac.be/~gcc/). But good guess.
;)
-J-
-Original Message-
From: Ashley Yakeley [mailto:[EMAIL PROTECTED]]
Sent: Thu 5/30/2002 5:26 PM
To: Haskell Cafe List
Cc:
Subject:
49 matches
Mail list logo
