To meet Ian's observation below, I propose to replace the
lexical production
newline - a newline (system dependent)
by
newline - return linefeed | return | linefeed
which, given maximal munch, will behave decently on
any normal system.
Any objections?
Simon
|
I don't know if it makes sense. You've written down some syntax,
but it's not clear to me what you intend by it.
The instance decls remind me somewhat of the generalisation described
towards the end of a paper Ralf Hinze and I wrote, Generic type
classes.
There we describe why instance decls
I don't want to do that until its finished!
Which I earnestly hope will be soon.
Simon
| -Original Message-
| From: David Feuer [mailto:[EMAIL PROTECTED]]
| Sent: 20 February 2002 08:43
| To: [EMAIL PROTECTED]
| Subject: Haskell 98 Report
|
|
| Is the revised Haskell98 report going
be useful to you? I only have the
example in our paper as motivation so far.
Simon
| -Original Message-
| From: Ashley Yakeley [mailto:[EMAIL PROTECTED]]
| Sent: 20 February 2002 01:08
| To: Simon Peyton-Jones; Haskell List
| Subject: RE: foralls in class assertions
|
|
| At 2002-02-19 09:21
Submission deadline: 21 March 2002 18:00 UTC
Program Chair: Simon Peyton Jones (Microsoft Research)
Full call for papers including submission details:
http://icfp2002.cs.brown.edu/CfP/
ICFP 2002 seeks original
I had meant to send this message to the Haskell list, because I think
there may be some readers who have good ideas about it.
Simon
-Original Message-
From: Simon Peyton-Jones [mailto:[EMAIL PROTECTED]]
Sent: 20 February 2002 21:16
To: Patrik Jansson; Haskell Cafe List
Cc: Ralf Hinze
| Consider the following Haskell 98 expressions:
|
| (let x = 10 in x `div`)
| (let x = 10 in x `div` 3)
|
| To parse the first, a bottom-up parser should reduce the
| let-expression before the operator, while to parse the second
| it should shift. But it needs 4 tokens of
| -Original Message-
| From: Ross Paterson [mailto:[EMAIL PROTECTED]]
| Sent: 26 February 2002 16:06
| To: Simon Peyton-Jones
| Cc: [EMAIL PROTECTED]
| Subject: Re: H98 Report: expression syntax glitch
|
|
| On Tue, Feb 26, 2002 at 07:30:44AM -0800, Simon Peyton-Jones wrote:
| Replace The ambiguity
| It'd be lovely if the Haskell report took a stand on the
| issue, but I suspect that may be too much to hope for.
Actually, it'd be an easy, non-destablising change to make
to the Report to specify the behaviour of the Int instance of
fromInteger on numbers larger than will fit in an Int.
PROTECTED]]
| Sent: 27 February 2002 10:43
| To: Simon Peyton-Jones
| Cc: [EMAIL PROTECTED]
| Subject: Re: H98 Report: expression syntax glitch
|
|
| On Tue, Feb 26, 2002 at 08:23:03AM -0800, Simon Peyton-Jones wrote:
| I didn't phrase it right. I meant that a let/lambda/if always
| extends
| By the way, the report says: Class Enum defines operations
| on sequentially
| ordered types. I think the sequentially means that
| multiple applications
| of succ to a value shall not result in the same value. That's
| why I think
| that succ (maxBound :: Int) should be an error and not
| So I would claim that these two types are the same:
|
| forall x. Class x = (forall y. Class y = y - y) - x - x
| (forall y. Class y = y - y) - (forall x. Class x = x - x)
|
| ...so you should be able to do this:
|
| combinator :: (forall y. Class y = y - y) - (forall x.
| Class x = x
Mark Shields and I are writing a paper. The technical
basis is in Putting type annotations to work Odersky/Laufer,
POPL'96.
Simon
| -Original Message-
| From: Artem S Alimarine [mailto:[EMAIL PROTECTED]]
| Sent: 07 March 2002 16:27
| To: [EMAIL PROTECTED]
| Subject: rank-n
| Looking at the type of sequ,
| the foralls for t end up at the top.
| Hence, I have no chance to define sequential
| composition.
Indeed the foralls are at the top, but I claim that wherever
you could use the composition function you were expecting,
you can also use the one GHC gives you. The
| The problem I think is with the lightweight thread implementation -
| Win32 calls can (and will) block the OS thread that makes the call,
| which blocks the entire system. Given that I'm wanting to write a
| network server with a Win32 GUI, this is obviously a Bad Thing.
Yes, that's true at
There's a remark at the beginning of 7.2 that says:
delete, (\\), union and intersect preserve the invariant
that lists don't contain duplicates, provided that
their first argument contains no duplicates.
The same applies to unionBy etc. This design is one
you might reasonably disagree
Ross points out that this is really hard to parse:
| case x of y | ($ True) $ \ z - z :: Bool - Bool - y
because the parser doesn't know when to stop eating the type
and treat the arrow as the case-alternative arrow.
Carl reminds us that this is hard to parse too:
| do a == b == c
| Ahem - how far would this be from a real multithreaded
| implementation, i.e. one that could use a few OS threads to
| take advantage of multiple CPUs in an SMP system?
Not very far. We have had a working implementation of
such a thing, but not in a robust releasable state.
S
| type Generic i o = forall x. i x - o x
|
| type Id x = x
|
| comb ::
| (Generic Id Id)
| - (Generic Id Id)
| - (Generic Id Id)
| comb = undefined
| So now let's ask for the type of comb in ghc.
| It turns out to be the rank-1 (!!!) type I captured as
| explicit type
| Ok, that's what I meant: in RHSs of other type synonyms.
| BTW, it also works when passing parameters to parameterized
| datatypes. Here is a variation on defining Generic as a
| datatypes as opposed to the earlier type synonym. Id is still
| the same type synonym as before.
|
| data
I agree with Ian here (and not just because of what GHC does!)
Does anyone disagree?
Simon
-Original Message-
From: Ian Lynagh [mailto:[EMAIL PROTECTED]]
Sent: 10 March 2002 15:23
To: Haskell list
Subject: Layout indentation marking
Given this module
module Main where
joyful task (aided by many others) to try to
illuminate the darkness, so I invite your opinions about which
fix (the one below, or Ross's) is better.
Simon
-Original Message-
From: Ross Paterson [mailto:[EMAIL PROTECTED]]
Sent: 11 March 2002 17:59
To: Simon Peyton-Jones
Subject: Re: H98
Folks
Olaf points out a problem with the specification of 'deriving' Show.
In particular:
| The representation will be enclosed in parentheses
| if the precedence of the top-level constructor operator in x
| is less than d.
Olaf proposes that we should change less than to less than or
, Pittsburgh, USA
Final call for papers
Submission deadline: 21 March 2002 18:00 UTC
Program Chair: Simon Peyton Jones (Microsoft Research)
Full call for papers including submission
Folks
Before I get buried in ICFP submissions I thought I should
get out the H98 report draft.
It's in the usual place:
http://research.microsoft.com/~simonpj/haskell98-revised
Main changes since the Dec release are:
Much improved informal semantics of pattern matching (3.17).
Dean
| From Simon Marlow's reply, I gather that the current
| implementations of Concurrent Haskell provide concurrency
| but not parallelism, and that provision of parallelism is
| not likely in the near term.
That's more or less right. The trouble is that for shared-memory
parallelism
-
This is an inconsistency that was fixed in the revised Haskell98
report (Apr 2001). See
http://research.microsoft.com/~simonpj/haskell98-revised
In the bug list look for Page 90.
It looks as though Hugs hasn't quite caught up with this change.
Simon
| -Original Message-
|
James White has noticed that the draft Haskell 98 report
gives the following translation for do-notation:
do {e}= e
do {e;stmts} = e do {stmts}
do {p - e; stmts} = let ok p = do {stmts}
ok _ = fail ...
|I think the point that's being missed in this discussion
|is that a monad is a n *abstract* type, and sometimes the
|natural equality on the abstract type is not the same as
|equality on representations. ... If we can give a
| more efficient
|
It's a bug in GHC 5.02 and earlier; fixed in 5.03
Simon
| -Original Message-
| From: Hal Daume III [mailto:[EMAIL PROTECTED]]
| Sent: 04 April 2002 00:15
| To: Haskell Mailing List
| Subject: deriving over renamed types
|
|
| Why can't I do this:
|
| import FiniteMap
| type FM =
| ...which would be very useful, but would probably have unpleasant
| consequences for type inference...
|
| To my mind, this is not a credible objection. The horse has
| already bolted; there's no point in trying to shut the stable
| door. The existing post-Hindley-Milner aspects of
Yes, and there will be one this year too. Tim Sheard is organising it.
Simon
| -Original Message-
| From: Tom Pledger [mailto:[EMAIL PROTECTED]]
| Sent: 05 April 2002 04:03
| To: [EMAIL PROTECTED]
| Subject: functional programming contest
|
|
| Andre W B Furtado writes:
| | I was
| Ah yes, silly me. What I had in mind, I suppose, was
| something more along the lines of:
|
| foo :: Double - (exists q . Foo q = q)
Correct. Currently you can only express this by wrapping
the existential in a constructor:
data R = forall q. Foo q = MkR q
foo :: Double -
Folks
Following a good deal of email I now propose to
DO NOTHING
to the rules defining do-notation in the Haskell 98 Report.
That means that GHC and Hugs, and nhc perhaps, should
change so that they actually implement the do-notation
translation rule
do {e ; stmts} = e do
| So, changing the translation in GHC might actually introduce
| a very nasty space leak in existing programs!
It might, conceivably. But the H98 report doesn't seem the right
place to try to tweak full laziness. So I'm going to leave the report
as it is. Hugs and GHC have changed to match.
Hal,
[I think this sort of question would be better on the haskell-cafe
list.]
I don't think what you want can be done directly. It's the old
thing about not having lambdas at the type level. You want:
instance Eq a = Coll (\x. x - Bool) a where ...
and you just can't do that.
| Yet another H98 question, this time regarding the module
| Char: Is it a deliberate design decision that readLitChar
| handles decimal, octal, and hex escapes, but lexLitChar
| handles only decimal ones? It looks more like an oversight to me...
Me too. It's a messy part of the language
| Here's a bit of background I managed to dig up:
|
http://www.mail-archive.com/haskell@haskell.org/msg05160.html
| It appears that a change to the monomorphism
| restriction to match Hugs's behaviour was considered for
| Haskell 98, but it looks like it never made it into the report
|
Yes, I agree, and I shall make this change forthwith
unless anyone disagrees.
thanks
Simon
| -Original Message-
| From: Ross Paterson [mailto:[EMAIL PROTECTED]]
| Sent: 27 May 2002 13:04
| To: [EMAIL PROTECTED]
| Subject: minor H98 anomaly: class declarations
|
|
| 4.3.1 has
|
|
Fixed.
Simon
| -Original Message-
| From: Simon Marlow [mailto:[EMAIL PROTECTED]]
| Sent: 17 May 2002 10:34
| To: Thomas Hallgren; [EMAIL PROTECTED]
| Subject: RE: Negative literals and the meaning of case -2 of
| -2 - True
|
|
|
| To find out how Haskell implementations treat
Folks
I'm back to tidying up the Haskell Report.
In the Numeric library, there is the useful function
readFloat :: RealFloat a = ReadS a
But you can't use it for reading rationals, because Rational
isn't in RealFloat!
This is a Royal Pain, and entirely unnecessary. In fact,
readFloat
| 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
| Idle curiosity: which aspects of the Haskell language are the
| ones that make it complicated -- e.g., long-time stuff like
| lazy evaluation, typeclasses inferrence, etc or newer stuff
| like functional dependencies, etc or something else entirely
| -- and do they only make it
| Especially converting rationals to a string and back should
| always be the identity. It would be better to print rationals in the
| form
|numerator % denominator
|
| and read them in the same form.
Oh yes, that is absolutely what Haskell does for Rationals.
The 'read' and
HaskellDirect (or HDirect for short) is very much alive and
being actively maintained by Sigbjorn Finne.
http://www.haskell.org/hdirect/
It's built on top of the Haskell FFI, but it is much higher level.
Simon
| -Original Message-
| From: Jamie Love [mailto:[EMAIL PROTECTED]]
essage -----
From: "Simon Peyton-Jones" [EMAIL PROTECTED]
To: "Sigbjorn Finne" [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Tuesday, June 04, 2002 04:03
Subject: RE: cvs commit: hugs98/lib IO.hs
Prelude.hs
Should I change the Report wording to be clearer?
Si
Folks,
I've finally managed to push out the May 2002 release of
the Haskell 98 report.
http://research.microsoft.com/~simonpj/h98-revised
As far as I know there are no outstanding issues, so I hope
that there will be blissful silence for a month and I can freeze it.
I'd have done so
if nothing substantial arises before then.
Simon
| -Original Message-
| From: Jon Fairbairn [mailto:[EMAIL PROTECTED]]
| Sent: 20 June 2002 16:27
| To: Simon Peyton-Jones
| Subject: Library report, monad zero laws
|
|
| The old report used to include
|
| m zero = zero
| zero = m = zero
would love you for ever, rather than it'd
be nice.
Simon lazy evaluation PJ
| -Original Message-
| From: Ashley Yakeley [mailto:[EMAIL PROTECTED]]
| Sent: 19 July 2002 03:24
| To: Simon Peyton-Jones; Haskell List
| Subject: RE: foralls in class assertions
|
|
| At 2002-02-20 13:15, Simon
Thanks. Fixed.
Incidentally, the cement is set just about solid. I've had no
substantive bug reports since the June release, so I'm on the
point of declaring the H98 Report finished. I'm just waiting for
a few hours spare to do some cosmetics.
(This message is a genuine bug, but I'm not
Folks,
Another small but long-standing bug in the Haskell Library report:
the recursive calls to 'reads' and 'shows' in the Read and Show
instances for Ratio and Array should be calls to readsPrec and showsPrec
respectively. The corrected defintions are below.
(c.f. the example of derived
I'm just catching up with some old mail here.
Iavor writes:
| class C a b | a - b
| class C a b = D a
|
| vs.
|
| class C a b | a - b
| class C a b = D a b
|
| Hugs accepts both of those, while GHC insists on the second.
| The first example is a little shorter and one might argue that if
| As near as I can tell, the precedence of the bounds and
| indices in an array doesn't matter at all. Simon M's
| suggested change to Page 24 is therefore good for
| consistency, but doesn't appear to actually have any effect.
| Am I missing something?
I think you are right, because the
| I've often felt a tinge of disappointment not being able to
| derive classes over data structures that are defined in the
| libraries (DeepSeq FiniteMap, for instance). I was wondering
| if any of the tools (drift, etc.) or GHCs built-in meta
| programming would allow you to say something
Folks
I'm happy to say that the Haskell 98 Report (both language and
libraries) is going to be published as a book! It'll be a (very)
special issue of the Journal of Functional programming (Jan 2003),
but will be available separately through bookshops as a book
published by Cambridge
Hal
I don't quite understand the intuitions behind your program, but the
bug is easy enough:
| instance (Eq e, Foo p) = Foo (Wrap p) where
| foo (Bar p) e q = foo p e q
This instance declaration is guaranteed to give problems if it is
ever used, and GHC should probably bleat about it.
I don't know what you are trying to do, but I do know why your program
is rejected.
The *whole point* of a value of type (STArray s Int Int) is that it can
only
be read by a state thread with the same type parameter 's' as the array.
Given your decls
class Foo a where
foo :: a - IO Int
They aren't identical.
runST guarantees to run a complete state thread that can't interact
with any other. stToIO runs some imperative actions that might
interact with other stToIO calls.
You might find it helpful to read 'State in Haskell' if you havn't
already done so.
Simon
|
There are two things going on.
1. Hugs deals with mutual recursion in a more sophisticated
way than GHC. Mark T is absolutely right, and the THIH paper explains.
2. Furthermore,GHC implements the H98 requirement that the context of
all functions in a mutually recursive groups must be the
The code should not be able to see c. Nor the data constructor A.
You don't say which Haskell implementation you are using.
Simon
| -Original Message-
| From: Andre W B Furtado [mailto:[EMAIL PROTECTED]]
| Sent: 09 September 2002 19:15
| To: [EMAIL PROTECTED]
| Subject: Labelled types
Ketil says:
| While we're at it, are there any plans to remove this paragraph from
| section 2.1:
|
| | Haskell uses a pre-processor to convert non-Unicode character sets
| | into Unicode. This pre-processor converts all characters to Unicode
| | and uses the escape sequence \u, where the h
A perfectly sensible idea.
Main difficulty I see: its not
clear what T.x would mean if both type T and module T existed, though.
Also if I have
data T = T { x,y::Int }
data
S = S { x,y::Int }
I might write
f :: S - T
f
s = T { x = S.y s, y = S.x s }
So just
Sigbjorn writes:
| Re: your request to have a final look through the report
| for any wibbles that might remain -- Section 11.3.2 of the
| lib report isn't clear on what the expected behaviour of
| (hClose h hClose h) ought to be, i.e., will the second
| hClose fail or not?
|
| Both GHC and
| No yelling, but some random points for consideration:
|
| 1. It might be worth being more explicit, i.e. stating whether this is
| because the runtime explicitly enables echoing, or because it's
| assumed that echoing will already be enabled.
Well, at Haskell user doesn't care. It's
What I intended was
a simple interactive Haskell program should behave the same
on any OS/environment
What you and Ross seem to be saying is
no, the behaviour of the program can, and should, depend
on the OS/environment
If that's the consensus I'll happily
Ahem how true. I have not idea why it was removed. But I can't put
anything back in at this stage.
Simon
| -Original Message-
| From: Malcolm Wallace [mailto:[EMAIL PROTECTED]]
| Sent: 18 September 2002 10:04
| To: Simon Peyton-Jones
| Cc: [EMAIL PROTECTED]
| Subject: Re: Haskell 98
Peyton-Jones
| Cc: [EMAIL PROTECTED]
| Subject: RE: Haskell 98: Behaviour of hClose
|
|
| Simon Peyton-Jones wrote:
|
|
| | 2. Is there actually anything special about the treatment of
stdin, or
| | does this apply to any input stream which is associated with a
| | terminal?
|
| I'm
Folks
As you know, we're in the home straight for Haskell 98. With the
exception of the recent discussion of echoing, there have been very,
very few changes since the May release. (Check out the bugs list.)
Cambridge University Press are going to publish the Language and Library
Reports, both
| contributions. So the book currently shows me as editor, while the
| preface attempts to give credit where credit is due. Please help me
to
| improve it.
|
| You don't specify very clearly when someone deserves to be on the
| contribution list.
|
| I reported some errors in the report
On the matter of echoing, in Section 7.1 there seem to be two
possibilities:
1. Delete the sentence By default, these input functions echo to
standard output. altogether.
2. Replace the sentence by
If the standard input (stdin) is a terminal device,
any input on stdin is
Glynn writes:
| 2. Regarding the buffering issue, I suggest adding something along the
| lines of the following to section 11.4.2 of the library report:
|
| For a stream which is associated with a terminal device, setting the
| mode to no-buffering will also disable any line-buffering which
| Replace:
| A datatype declaration may optionally include field labels for
some
| or all of the components of the type.
| With:
| A datatype declaration may optionally include field labels.
Each
| constructor must use either labelled fields or unlabelled
fields,
| but
| The report says The expression F {}, where F is a data constructor,
is
| legal whether or not F was declared with record syntax, provided F has
no
| strict fields: it denotes F _|_1 ... _|_n where n is the arity of F.
|
| It unclear to me why there needs to be this provision for records with
| The report says The expression F {}, where F is a data constructor,
is
| legal whether or not F was declared with record syntax, provided F has
no
| strict fields: it denotes F _|_1 ... _|_n where n is the arity of F.
|
| It unclear to me why there needs to be this provision for records with
| I think the sentence in question (end of 3.15.2) is just a
clarification;
| the preceding 4 rules are sufficient and clear: F{}, S{} and S{x=3}
are
| all illegal because they omit a value for a strict field. That is,
it's
| correct, though not strictly necessary, nor does it cover all the
| I looked on the web for a precompiled binary version of those
| libraries, in vain. I found the GUM web page but it seems to be much
| outdated, based on the ghc-4.06. Is there any more recent version
available?
Not as far as I konw. The parallel version of GHC is maintained and
developed by
| I want to define something like
| class (Eq (forall a. T a), Monad T) = C T
| where the context shall mean that T has to be an instance of Monad and
| that for every type a the type T a has to be an instance of Eq.
| Is such a thing possible with some Haskell implementation?
Not currently,
| (1) In the first section, in:
|
| instance (cx, cx') = Ci (T u1 ... uk) where { d }
|
| the use of (cs, cs') is a bit loose (that is, suggestive rather than
| precise syntax). One can't (according to the report, though GHC seems
to
| allow it) have nested parentheses in a context, which
| In GHC 5.04.1, derived instances of Show mishandle precedence:
|
| Prelude putStrLn (showsPrec 10 (Just 0) )
| Just 0
|
| The result should be: (Just 0)
I think it's a bug in the Report, not in GHC, actually. The Report says
(Section D.4)
The function 'showsPrec d x r' accepts a
Folks
The concrete is setting fast, but Ross points out that the instance for
Enum (Ratio a) is inconsistent with that for Enum Float and Enum Double.
(It's strange that these non-integral types are in Enum, but we're stuck
with that.)
All three use 'numericEnumFrom' etc for the enumFrom method,
| Since I suppose you also want to receive constructive suggestions,
| I'd suggest to remove some instance definitions from the
| report.
I definitely can't do that at this stage. I have never liked
Float/Double/Ratio being in Enum, but there is no possibility of
removing them now. A year or
|
| It's inconsistent to remove the +1/2 for numericEnumFromTo but to
leave
| the +(n'-n) for numericEnumFromThenTo. I think you probably mean to
| remove both (actually, all three).
|
| I wouldn't recommend these changes for Float and Double (the
increments
| are there to account for
| I definitely can't do that at this stage. I have never liked
| Float/Double/Ratio being in Enum, but there is no possibility of
| removing them now. A year or two ago, maybe.
|
| Just to clarify: Did you mean for Haskell 98 or did you mean forever?
Thanks for raising that
I
GHC questions to ghc-users please, not the
main Haskell list.
You need the -ffi flag to use the FFI.
S
-Original Message-
From: David Abbs
[mailto:[EMAIL PROTECTED]]
Sent: 04 November 2002 14:38
To: [EMAIL PROTECTED]
Subject: problems with ghc ffi
I am having
Thomas, Iavor,
Thanks for your message.
| Are you saying that you think the report doesn't fully define the
| meaning of the module system, or just that difficult to understand and
| needs to be clarified?
The former, and hence it ought to be clarified. But after contemplating
your message,
,
but it places no limitations on what else may be done with it. The copyright will
still be (c) Simon Peyton Jones (as it has for some while; it has to be attached to
someone or some thing), and the existing notice that says you can do what you like
with this Report will stay unchanged. No non
Folks
Template Haskell is now being used by a few brave souls (they have to
build GHC from scratch), and I don't want to overload the Haskell
mailing list with nitty-gritty discussion about the finer points of TH.
So Simon M has created a separate mailing list
[EMAIL PROTECTED]
for
| going to stop gtk+hs because of this. So it seems we are all
| waiting for the critical user mass that makes our own beloved
| GUI library (binding) the standard GUI library. For the sake
| of Haskell, we can only hope that this will actually happen
| one day. A sad side-effects of this is
Matthew
| Many spectral estimation routines are defined in terms of special
| matrices (ie, Toeplitz, etc). Arrays defined recursively by list
| comprehensions make it easy to implement algorithms like
Levinson-Durbin
| recursion, and they look very similar to the mathematical definitions:
|
|
| the haskell 98 time library is horribly broken, if you are using ghc,
| you can deconstruct the time constructor which has an Integer
containing
| the number of seconds since epoch... otherwise you can use
|
...
| I dont supose this could be considered a typo in the haskell 98
report?
| it is
Don't forget Helium (recently announced)
http://www.cs.uu.nl/~afie/helium/index.html
Also Manuel Chakravarty teaches Haskell to hordes.
Simon
| -Original Message-
| From: Hal Daume III [mailto:[EMAIL PROTECTED]]
| Sent: 04 February 2003 00:02
| To: Haskell Mailing List
| Subject:
No there isn't. Its in the revised version at
http://research.microsoft.com/~simonpj/haskell98-revised/haskell98-repor
t-html/index.html
I'll ask John to upload it.
Simon
| -Original Message-
| From: Antony Courtney [mailto:[EMAIL PROTECTED]]
| Sent: 07 February 2003 22:04
|
| GHC used to have an optimisation for static argument like this. It
would
| turn both of the above programs into a similar form using a local
| recursive function:
|
| interp y xs = interpaux xs
| where interpaux [] = []
| interpaux (x:[]) = x:[]
| interpaux (x:xs) =
Interesting example
| class Monad2 m a ma | m a - ma, ma - m a where
| return2 :: a - ma
| bind2 :: Monad2 m b mb = ma - (a - mb) - mb
| _unused :: m a - ()
| _unused = \_ - ()
| instance Monad2 [] a [a] where
| bind2 = error urk
The functional dependencies say
m a -
| since this claims that it will take a Bool and produce a value of type
b
| for all types b. However, would it be all right to say (in
| pseudo-Haskell):
|
| f :: exists b . Bool - b
| f x = x
But this is a singularly useless function, because it produces a result
of utterly unknown type, so
| The reason, which is thoroughly explained in Simon Peyton-Jones'
| message, is that the given type signature is wrong: it should read
| f1 :: (exists b. (C Int b) = Int - b)
|
| Right. Simon pointed out that this is a pretty useless function, but
not
| entirely so, since the result
Folks
I am holding in my hands the first copy of the Haskell 98 Report to roll off the
presses at Cambridge University Press. It looks great. And it has a copyright
notice that says It is intended that this Report belong to the entire Haskell
community..., just as the online version does.
| The following is a more flexible alternative to overloading. We
| essentially define a function on types and invoke it, seemingly at run
| time. No Dynamics or unsafe computations are employed. We only need
| existential types, multi-parameter classes and functional
| dependencies. The code also
| I believe something along the lines of the following would work:
|
| class C a b | a - b where { foo :: b - String }
| instance C Int Int where { foo x = show (x+1) }
| x :: forall b. C Int b = b
| x = 5
|
| (Supposing that the above definition were valid; i.e., we didn't get
the
| type
GHC has a multi-generational garbage collector. If you have enough
physical memory on your machine so that the GC isn't thrashing trying to
find the 100 free bytes that remain, then you should find the database
migrates to the oldest generation and stays there. If you use +RTS
-Sstderr you'll
301 - 400 of 3117 matches
Mail list logo
