hi,
Does any one have any sample code for the haskell GHC compiler. All I
have are examples of code meant for HUGS.
If you can help me please send me acopy of the code so I can know what
the syntax is for this compiler.
On 06-Oct-1999, Andreas Rossberg [EMAIL PROTECTED] wrote:
Down casts could be done. This would mean that each existential
constructor had to carry dynamic type information and there would be a
special pattern matching construct that checks this.
At first I thought a special language construct
Kevin Atkinson wrote:
Java is an evern cleaner language for OO as
questionable. Every *new* language should try to recycle the experience
gained from its predecessors. In the field of OO one thing springs to
my mind: The ability to extend/restrict the signature of a member function
in
Adrian Hey writes:
On Wed 06 Oct, Johan Nordlander wrote:
Just to avoid any unfortunate misconceptions: O'Haskell definitely
preserves the property we commonly refer to as referential transparency,
and so does Concurrent Haskell, or any other sound monadic extension of
the language.
[EMAIL PROTECTED] wrote,
Adrian Hey writes:
On Wed 06 Oct, Johan Nordlander wrote:
Just to avoid any unfortunate misconceptions: O'Haskell definitely
preserves the property we commonly refer to as referential transparency,
and so does Concurrent Haskell, or any other sound
"Frank A. Christoph" [EMAIL PROTECTED] wrote,
Manuel Chakravarty wrote:
The problem is that a pre-processor adds a new level of
semantic complexity to the language - so if we can do
without it, we'll definitely make our lives simpler.
Besides, one nice property of Haskell is its
Fergus Henderson wrote:
| instance Eq b = Eq (a - b) where
|f == g = error "can't compute equality of functions"
I hope that you are joking here ...
Why don't we propose this: add the following
default instance for *all* types in Haskell:
instance Eq a where
f == g = error
[EMAIL PROTECTED] wrote,
Manuel M. T. Chakravarty writes:
[EMAIL PROTECTED] wrote,
I'm not surprised you are puzzled. Concurrent Haskell, as
implemented in ghc, does NOT preserve referential
transparency, nor could it.
Of course it does! If it wouldn't many of the
Manuel M. T. Chakravarty writes:
[EMAIL PROTECTED] wrote,
Adrian Hey writes:
On Wed 06 Oct, Johan Nordlander wrote:
Just to avoid any unfortunate misconceptions: O'Haskell definitely
preserves the property we commonly refer to as referential transparency,
and so
Tim [EMAIL PROTECTED] wrote:
For example, consider a program where one thread prints a value from an MVar,
while another thread modifies it. The output of the program will vary from one
run to another, even though its input (none) is unchanged.
This is not a result of using concurrency.
You
The Haskell98 Library Report defines the Random class as:
class Random a where
randomR :: RandomGen g = (a, a) - g - (a, g)
random :: RandomGen g = g - (a, g)
randomRs :: RandomGen g = (a, a) - g - [a]
randoms :: RandomGen g = g - [a]
randomRIO :: (a,a) - IO a
randomIO ::
Adrian Hey wrote:
I've read this paper, and it is good, but I still see no reason to
change my opinion regarding referential transparency and IO.
But I am terribly confused about this issue, there seems to be no real
consensus about this in the FP world. I just can't see how if the
result of
Michael Hobbs wrote:
Adrian Hey wrote:
I've read this paper, and it is good, but I still see no reason to
change my opinion regarding referential transparency and IO.
But I am terribly confused about this issue, there seems to be no real
consensus about this in the FP world. I just
Fri, 8 Oct 1999 01:22:43 +0100 (BST), Adrian Hey [EMAIL PROTECTED] pisze:
I've read this paper, and it is good, but I still see no reason
to change my opinion regarding referential transparency and IO.
But I am terribly confused about this issue, there seems to be
no real consensus about
The Journal of Functional Programming will host
a special issue devoted to the design, analysis,
evaluation, and/or synthesis of algorithms and
data structures in functional programming languages.
For full details, see
http://www.dcs.gla.ac.uk/jfp/editorialAugust99.html
The deadline for
Carlos´ got the flue and could not come to work. I´d like to join
Kevin on his fight :-).
I think system CT is simple and will make the type system and life for
programmers simpler. A language based on system CT would require no
class or instance declarations (although they could be kept for
Michael Hobbs wrote:
Consider this:
type IO a = StateOfUniverse - (a, StateOfUniverse)
-- Not syntactically correct, but you know what I mean.
So anything that is declared, say `IO Int', means that it is actually a
function that reads in the state of the universe, potentially
On Thu 07 Oct, [EMAIL PROTECTED] wrote:
See the paper "Concurrent Haskell" by Simon Peyton Jones, Andrew Gordon and
Sigbjorn Finne, which states:
"forkIO :: IO () - IO () forkIO a is an action which takes an action, a, as
its argument and spawns a concurrent process to perform that action.
Marcin 'Qrczak' Kowalczyk wrote:
Tue, 5 Oct 1999 14:10:26 -0400 (EDT), Kevin Atkinson [EMAIL PROTECTED] pisze:
1) Dynamic types. You can't cast up. That is you can't recover the
original type from an object in a existential collection. You need to
use a dynamic type library for
Tue, 5 Oct 1999 14:10:26 -0400 (EDT), Kevin Atkinson [EMAIL PROTECTED] pisze:
1) Dynamic types. You can't cast up. That is you can't recover the
original type from an object in a existential collection. You need to
use a dynamic type library for that. And the library proved with hugs
and
At 05:12 PM 10/7/99 , you wrote:
Sorry that I really can't explain well why I think that this concept
does not fit into Haskell. I must have heard that such "typecase"
is most often a bad design.
In most situations, type-casting is a symptom of bad design. The only C++
situation, for
21 matches
Mail list logo
