| 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
___
Warning
Unable to process data:
multipart/related;boundary = "NextMimePart"
"Simon Peyton-Jones" <[EMAIL PROTECTED]> writes:
> | 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
| 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 ty
The following passages differ on the status of (a+b+):
3 Expressions
aexp -> ...
| ( expi+1 qop(a,i) ) (left section)
| ( qop(a,i) expi+1 ) (right section)
3.5 Sections
Syntactic precedence rules apply to sections as follows. (op e) is
legal if a
| 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 Generic
Antony,
> But unfortunately the Makefile.inc used to build hmake does some tricky
> $(PWD) shenanigans that have nothing to do with configure, and then
> passes the resulting path to ghc. Unfortunately, $(PWD) returns
> Cygwin-style paths, and I failed to find a good workaround for this in
>
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
main
In response to my recent message (below), Ross asks:
"Are you rejecting the fix I suggested:
Add a side condition to the grammar in 3.13: the guard must not
end with a type signature (because the following -> looks like
part of the type)."
Indeed, this would be possible.
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
Here's the basic idea. Suppose we have the function:
> sum [] acc = acc
> sum (x:xs) acc = sum xs (acc+x)
This is tail recursive, but not strict in the accumulator argument. What
this means is that the computation will be performed lazily, so sum
[4,5,8,10,14,20] 0 will go like this:
> sum [4
I found the following text when visiting the Clean (a functional language)
site:
"Clean is the only functional language in the world which has a special type
system, uniqueness typing. It enables to update function arguments
destructively retaining the purity of the language."
Then I have some q
Andre W B Furtado wrote:
> I found the following text when visiting the Clean (a functional language)
> site:
>
> "Clean is the only functional language in the world which has a special type
> system, uniqueness typing. It enables to update function arguments
> destructively retaining the purity
Hi!
Did you know that 85% of your potential customers will be using
search engines to find what they are looking for on the Internet?
Have you ever thought about getting your website listed on search
engines worldwide?
TrafficMagnet offers a unique technology that will
Oops, I made a false statement:
> > f $! a = f a
>
> but the difference is that $! causes "a" to be reduced completely, so it
> won't build a huge thunk.
This isn't true. $! will only perform one reduction, so for instance:
> id $! (a+1,b+1)
will not cause a+1 and b+1 to be calculated; it wi
On Tue, 12 Mar 2002, Hal Daume III wrote:
> Here's the basic idea. Suppose we have the function:
>
> > sum [] acc = acc
> > sum (x:xs) acc = sum xs (acc+x)
>
> This is tail recursive, but not strict in the accumulator argument. What
> this means is that the computation will be performed lazily,
> When I compile a program using GHC 5.02.2 on Windows 200 using HGL,
I don't have GHC installed on my Windows partition (nor space for it,
I suspect) so I'll ask some questions and hope they suggest an answer.
Does it work ok using Hugs and HGL?
Sigbjorn Finne did a great job of packaging
Aha! Gotcha. Thanks for the explanation.
I suppose that, in general, for tail recursion to work right, the
accumulator has to be evaluated strictly (as is how my code was fixed)?
Jyrinx
[EMAIL PROTECTED]
On Tue, 2002-03-12 at 09:34, Hal Daume III wrote:
> Here's the basic idea. Suppose we have
Hal Daume III:
>Here's the basic idea. Suppose we have the function:
>
>> sum [] acc = acc
>> sum (x:xs) acc = sum xs (acc+x)
>
>This is tail recursive, but not strict in the accumulator argument.
...
Just a nitpick here. sum is indeed strict in its second argument (given that
(+) is strict in i
19 matches
Mail list logo
