Ian Lynagh wrote:
Hi all,
I note with some sadness the more restrictive license that may be placed
on the "Haskell 98 Report", as reported by the HC&A. The great
openness/freeness of haskell, both the report and implementations, is,
IMO, one of its most important features.
I have just grabbed a
Dr Mark H Phillips wrote:
>Hi,
>
>Does Haskell specify how div and mod should behave when
>given one or both arguments negative?
>
Yes, section 6.4.2 gives an exact definition.
>P.S. I notice in hugs if I type "-1 `div` 3" the `div`
>binds to the 1 and 3 first, and only applies the "-"
>at the
Joe English wrote:
>Java attempts platform independence by declaring that all
>the world *is*, in fact, a VAX [*].
>
>
>[*] More precisely, a 32-bit platform with IEEE 754 floating point.
>
And the original VAX did in fact not have IEEE floating point. :-)
-- Lennart
__
Jon Fairbairn wrote:
>
> I wasn't fit enough to follow the earlier discussions of the
> layout rule, so I'm not sure how this interacts with
> previous awkward cases. I'd be happiest if we could come up
> with a rule that didn't involve sticking in braces and
> semicolons because it won't parse
Ashley Yakeley wrote:
> I am certainly not proposing Haskell be modified to eliminate the layout
> option. I'm just curious as to why Haskell programmers choose to use it.
Because I find programs using layout to be more readable.
In Haskell (not in C) programs using {;} I've found that the inden
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 acad
Ashley Yakeley wrote:
> At 2002-04-08 12:45, Lennart Augustsson wrote:
>
> >I just just wanted to say that I agree with almost everything Conor said.
> >I find it a little odd that the extension to Haskell that allows explicit
> >forall
> >does not also allow you
I just just wanted to say that I agree with almost everything Conor said.
I find it a little odd that the extension to Haskell that allows explicit
forall
does not also allow you use explicit type application (and type lanbda).
-- Lennart
C T McBride wrote:
> Hi
>
> On Fri, 5 Apr 2002, Ashl
Thank you for making my point. All these are indeed examples of broken code.
(Not because it's Perl. :)
-- Lennart
Pixel wrote:
> Lennart Augustsson <[EMAIL PROTECTED]> writes:
>
> > Just because many applications use this doesn't make it safe or good.
> &
ate). You
then just have to handle the exception (that part is already in H98) or
proceed with the normal path. I claim the code simpler this way and you
avoid any race conditions.
-- Lennart
Pixel wrote:
> Lennart Augustsson <[EMAIL PROTECTED]> writes:
>
>
Hal Daume III wrote:
> subject says it all...
name says it all; it computes fixpoints in the ST monad. :-)
-- Lennart
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
> data CMap0 (p ::: * -> *) (q ::: * -> *) = MkCMap0;
Or
data (CMap0 :: (* -> *) -> (* -> *) -> *) = MkCMap0
-- Lennart
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Simon Peyton-Jones wrote:
> | hbc is on the Integral side, if that counts. :-)
> | Just because ghc doesn't follow the spec isn't a good reason
> | to change the spec. :-)
>
> I absolutely didn't say that! All I'm saying is
>
> * Two of the four impls have to change regardless
Only because two
Simon Peyton-Jones wrote:
> | Hugs "demands Integral" because that's what it was told to do
> | to follow the report. So in that sense, yes, the code
> | depends on having only one class. But it would be easy for
> | someone to change that.
> |
> | Then again, if we're following the rules of mi
Well, it was a deliberate decision to limit the n+k pattern to class Integral
because people at that time felt that n+k was something that should
only be used with integers. So it's not a fluke, it was quite deliberate.
I kind of like Integral for this (as much as I can like anything about n+k :)
John Hughes wrote:
> Simon PJ and I have come up with an extension to newtype deriving clauses
> which is intended to make it easier to make types abstract.
>
> The new extension allows you to derive these instances, just by adding the
> classes to the deriving clause of the newtype declaration.
[EMAIL PROTECTED] wrote:
> I need to create a function that checks if a file exists. My intention is to do
>something like:
>
> teste :: String -> Bool (Beeing the String the FilePath)
>
> I've tried to use openFile and catch functions, but i couldn't put it working. The
>purpose of this funct
> >> >What mechanism of transmiting parameters does Haskell implement?
> >>
> >> By value.
> >
> >Yes, though one might equally say that they are passed by
> >reference, since in
> >
>
> Oh, yeah, they're passed by thunk. I forgot about the laziness.
Well, Haskell does not really specify which
John Hughes wrote:
> We can construct rather large polymorphic values, which have
> to be converted in linear time to the same value of a
> different type.
>
>
> All true, but I doubt whether any of this is a big deal. MLers already live
> with their "value restriction", w
Hannah Schroeter wrote:
> I don't think so. Why not create a dictionary record while compiling
> the associated instance (which may, by the H'98 definition, occur
> only once in the program)?
One problem is that certain Haskell programs need an unbounded
number of instances.
-- Lennart
"Ch. A. Herrmann" wrote:
> >>>>> "Lennart" == Lennart Augustsson <[EMAIL PROTECTED]> writes:
>
> Lennart> "Ch. A. Herrmann" wrote:
> >> (1) What is the justification for the types "Float" and "Double&q
Tim Barbour wrote:
> Lennart Augustsson writes:
> > "Ch. A. Herrmann" wrote:
> >
> > > (1) What is the justification for the types "Float" and "Double"
> > > to be members of the type class "Enum"? This mig
"Ch. A. Herrmann" wrote:
> (1) What is the justification for the types "Float" and "Double"
> to be members of the type class "Enum"? This might induce students
> to use floating point values as counters in arithmetic
> sequences.
And what's wrong with that? If the students are using
Jerzy Karczmarczuk wrote:
> Did Joe Fasel include this consciously? If yes,
> my respect - already almost infinite, is even bigger now).
I'm pretty sure he did, but he can speak for himself. I know he
discussed these things with his numerical collegues when designing
the prelude.
Look at this d
> That's a good idea too.
> Is there a reason for defining acosh as above instead of
> acosh x = log(x + sqrt(x*x-1))
If there is one I can't remember it. :-)
-- Lennart
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/
> | sinh x = (exp(x) - exp(-x))/2
> | cosh x = (exp(x) + exp(-x))/2
...
> This looks pretty reasonable to me. We should have default methods
> for anything we can.
Why not provide defaults for the inverse functions as well?
asinh x = log (x + sqrt (1+x*x))
acosh x = log (x + (x+1) * sqr
> 2. So, they hold for the Complex numbers as well. The gymnastics with
>complex sinh and cosh seems to be redundant.
Well, I would be a little careful changing these. Some of the definitions
in numerical part of the Prelude look more convoluted than they need to
be, but it's because they hav
"S. Alexander Jacobson" wrote:
> Great. So that is something that goes into some library conventions
> document. Java has a convention that libraries should have reverse domain
> name structure. Is that how we should use _?
Yes, I think that could be the way. And in addition there should be
"S. Alexander Jacobson" wrote:
> On Wed, 26 Sep 2001, Manuel M. T. Chakravarty wrote:
> > > Given that Haskell98 is not ready for libraries anyway, why are you so
> > > concerned about it?
> >
> > It isn't? Why? Because of the lack of hierachical name
> > spaces? Then, C isn't ready for librar
Brian Boutel wrote:
> Sigbjorn Finne wrote:
> > >
> > > What does the language definition say about this?
> >
> > Nothing at all, I believe, but the convention is for tab characters
> > to be interpreted by an output device as moving the cursor to
> > the next tab stop/alignment column. In the ab
Marcin 'Qrczak' Kowalczyk wrote:
> Fri, 14 Sep 2001 01:00:06 +0200, Lennart Augustsson <[EMAIL PROTECTED]> pisze:
>
> > I have been writing substantial Haskell programs and I use *NO*
> > experimental features.
>
> In a 2000-line interpreter I used:
>
[EMAIL PROTECTED] wrote:
> Thanks, that's very valuable information. It's hard to appreciate the
> relative utility (as you can see :-)) of different experimental features.
>
> It's also confusing that things like exceptions, concurrency, and FFI are
> labeled 'experimental'. They're so (IMHO) cr
Marcin 'Qrczak' Kowalczyk wrote:
> BTW, a better definition than
> fix f = f (fix f)
> is
> fix f = let x = f x in x
> because it increases sharing, avoiding recomputation.
The latter definition is more likely to give you sharing, but Haskell
gives you no such guarantees. There are also
"Alexander V. Voinov" wrote:
> Hi All,
>
> Lennart Augustsson wrote:
> > > Each pseudorandom generator generates a countable sequence of values,
> > > which is isomorphic to a sequence of integers. In good old (Turbo)C we
> > > got something be
"Alexander V. Voinov" wrote:
> Hi All,
>
> Fergus Henderson wrote:
> > Ah, now I think I understand your problem. You want to `random' to
> > generate random numbers that span all the possible values of the type
> > within the range [0, 1], or at least a substantial subset, but the "Real"
> > cl
"Rishiyur S. Nikhil" wrote:
> Stephen Bailey wrote:
> >
> > > Why hbc did not succeeded?
> >
> > I heard rumors that the author went off to some cushy industrial job,
> > or is spending all his time writing NetBSD drivers, or something like
> > that :^)
> >
> > Steph
>
> I heard that he had becom
Josef Svenningsson wrote:
> John,
>
> On Thu, 17 May 2001, John Meacham wrote:
>
> [..]
> > namely that you don't necisarilly know all of the types of polymorphic
> > functions when they are in a module that is compiled seperately from the
> > rest of the program. the solution used by many C++ co
Rijk-Jan van Haaften wrote:
> Hello,
>
> While I were writing a RealFrac implementation for BigDouble's (for
> high-precision computations) I found a strange implementation of
> round in the standard prelude (from the haskell definition):
>
> round x =
> let (n,r) =
> prop
OK, so since noone liked my original example here's another one.
It involves no defaulting and no classes in the funny function definition.
-- Here's the type signature that makes a difference.
--fun :: a -> Char
fun x = const (fun x) (fun True)
fix f = let x = f x in x
class C a where
m ::
Marcin 'Qrczak' Kowalczyk wrote:
> Thu, 03 May 2001 06:29:35 -0400, Lennart Augustsson <[EMAIL PROTECTED]>
>pisze:
>
> > Try this program:
> > -- Try commenting out this type signature.
> > fun:: (Num a) => a -> Int
>
> Test.hs:7:
>
Simon Peyton-Jones wrote:
> | a) That adding a type signature can change the dynamic semantics
> | of the program. This would be the first and only
> | occurrence of
> | such behaviour.
> |
> | At present, adding a type signature changes both the static
> | semantics an
Simon Peyton-Jones wrote:
> John: just to check, you do realise that (B) means
>
> a) That adding a type signature can change the dynamic semantics
> of the program. This would be the first and only occurrence of
> such behaviour.
Not so, there are already Haskell program that give a di
"S.D.Mechveliani" wrote:
> Can we solve and close the problem of the meaning of decimal pointed
> leterals?
There is no problem, it's clearly specified by the report.
(There is a problem with Hugs, it doesn't implement literals properly.
Or has that ancient bug been fixed?)
> > "The floating p
"S.D.Mechveliani" wrote:
> he matter is in what the _language standard_ says.
> If it puts that `0.9' in the user program means precizely 9%10,
> then Lennart is right.
I quote the report:
"The floating point literal f is equivalent to fromRational (n Ratio.% d), where
fromRational is a
meth
Jerzy Karczmarczuk wrote:
> Lennart Augustsson wrote:
>
> > "S.D.Mechveliani" wrote:
> ... ...
> > > Probably, the source of a `bug' is a language agreement that the
> > > input is in decimal representation (`0.9') and its
"S.D.Mechveliani" wrote:
> People wrote about toRational (0.9) == 9%10 = False
> ...
> Probably, the source of a `bug' is a language agreement that the
> input is in decimal representation (`0.9') and its meaning is a
> floating approximation in _binary_ representation.
W
Ashley Yakeley wrote:
> At 2001-04-16 18:35, [EMAIL PROTECTED] wrote:
>
> >> Why (toRational 0.9) == (9 % 10) is False?
>
> I tried this in Hugs. It gives (toRational 0.9) as 7549747 % 8388608
> (i.e. 37748735/41943040 instead of 37748736/41943040 = 9/10).
>
> This is probably because Hugs attemp
Andreas Leitner wrote:
> Hi,
>
> I hope this is the right forum to post my question to.
>
> Given a lazy pure functional language do we need to differntiate (in
> syntax) between constants and functions without agruments? And if we
> don't need to, does Haskell make a difference?
>From a pedanti
Thomas Johnsson wrote:
> Lennart Augustsson writes:
> > > Simon Peyton Jones' comments about dictionary passing are a red herring,
> > > since they assume a particular form of compiler. Various (MLj, MLton)
> > > ML compilers already inline out all polymo
> Simon Peyton Jones' comments about dictionary passing are a red herring,
> since they assume a particular form of compiler. Various (MLj, MLton)
> ML compilers already inline out all polymorphism.
ML is a language where you can do this. In Haskell it is not always
possible to eliminate all pol
Anton Moscal wrote:
> Hello!
>
> When I apply hugs to the following program:
>
> import Char (ord) class Conv a b | a -> b where conv:: a -> b
> instance Conv Char Int where conv = ord
> instance (Conv a b, Conv b c) => Conv a c where conv = conv . conv
>
> Hugs reports:
>
> ERROR "fdep.hs" (line
Simon Peyton-Jones wrote:
> I think you can simplify the example. Given
>
> class HasFoo a b | a -> b where
> foo :: a -> b
>
> instance HasFoo Int Bool where ...
>
> Is this legal?
>
> f :: HasFoo Int b => Int -> b
> f x = foo x
>
> You might think so,
Eduardo Nahum Ochs wrote:
> > > Why have any other computer when you can have a Mac?
> > >
> > > Mine runs:
> > > DVD Movies
> > > MacOS
> > > JVM
> > > Playstation games
> > > Windows 95
> > > Windows 2000 (a bit slugglish)
> > > and could run:
> >
> Why have any other computer when you can have a Mac?
>
> Mine runs:
> DVD Movies
> MacOS
> JVM
> Playstation games
> Windows 95
> Windows 2000 (a bit slugglish)
> and could run:
> Linux (but I have no use for it at present)
I notice that y
Marcin 'Qrczak' Kowalczyk wrote:
> Wed, 2 Aug 2000 17:01:09 +0200 (CEST), Wojciech Moczydlowski, Jr
><[EMAIL PROTECTED]> pisze:
>
> > The follow piece of code is accepted by hugs and ghc, rejected by
> > nhc and (I haven't seen it) by hbc. Is this code correct or not?
> >
> > type A = Either Int
> If you are happy with the isomorphism
>
> (T1 x T2 x ...) <-> (T1 x (T2 x (...)))
But in Haskell these are not isomorphic.
(a,b,c) is NOT isomorphic to (a,(b,c)), just think about bottom.
--
-- Lennart
Julian Assange wrote:
> [EMAIL PROTECTED] (Carl R. Witty) writes:
>
> > Fergus that this behavior is undesirable and should be avoided for
> > Haskell, unless a flag like "-funsafe-fast-math" is provided.
> >
> > double inverse(double val) {
> > if (val == 0) {
> > printf("Oops! divided by
[EMAIL PROTECTED] wrote:
> Michael Weber writes (on the ghc-users list):
> > I'm slightly puzzled about the definition of list enumerations in
> > GHC (and possibly other Haskell implementations)...
> >
> > ``[0.0, 2 .. 9] :: [Float]''
> > ==> [0.0, 2.0, 4.0, 6.0, 8.0, 10.0]
> >
> > Never
Peter Hancock wrote:
> >>>>> "Lennart" == Lennart Augustsson <[EMAIL PROTECTED]> writes:
>
> >> I always thought that the Int argument to showsPrec is the precision.
> >> So what is it good for? The library report does not explain
Michael Marte wrote:
> > Michael Marte wrote:
> >
> > > I have a simple problem but it seems to be quite involved: I want to print
> > > floating point numbers with a given number of decimal points.
> > >
> > > First, I found out that both ghc and hugs do not consider the precision
> > > argument
> Using `Left' and
> `Right' for such cases is fundamentally confusing since it is not
> clear what the meaning of `Left' and `Right' is.
Well, I don't totally agree. Anyone using Right for Wrong deserves to
have his/her head examined. :)
-- Lennart
Michael Marte wrote:
> I have a simple problem but it seems to be quite involved: I want to print
> floating point numbers with a given number of decimal points.
>
> First, I found out that both ghc and hugs do not consider the precision
> argument to showPrec.
What precision argument? There's
Frank Atanassow wrote:
> To be fair, I can give 4 arguments against it.
>
> 1) Hugs's error messages don't qualify names, so they become very difficult
> to read when you use this convention.
That's a totally bogus reason. Tell the implementors to fix Hugs.
> 2) The Prelude doesn't u
Chris Okasaki wrote:
> I've taken a look at these. I'll limit myself to just one comment:
>
> >1.1.1. Constructor names
> >
> >Empty values of type X have the name emptyX, e.g. emptySet.
>
> You've struck a pet peeve of mine. These suffixes are doing namespace
> management, avoiding name cl
Simon Peyton-Jones wrote:
> In Haskell,
> case e of { y->b }
> is equivalent to
> let y=e in b
Actually, it's equivalent to
(\ y -> b) e
since the let could be polymorphic.
> That is, case is not strict unless the patterns
> make it so. You may think it's curious but that's
Sven Panne wrote:
Another question: Compile-time constant folding for
Float/Double is
always done via Rational in GHC, so it is more exact than the runtime
computation.
-- Bar.hs
main :: IO ()
main = print (0.7480 - 0.0433 :: Float,
0.7480 -
Tony wrote:
> Hello All,
> I'm stumped by a problem that seems to me to be hard to
> do efficiently in Haskell or any 'pure' functional language. That is,
> making an inverse index.
>
> The particular problem stems from a particularly efficient method of
> string searching (at lea
Koen Claessen wrote:
> I just went through my code and
> looked at how many definitions in do-notation actually were
> polymorphic.
And what was the result?
--
-- Lennart
Koen Claessen wrote:
> which you want to depend on a few state variables or
> something, then I do the following:
>
> funWrapper y = runST computation
> where
> computation =
> do var <- newSTRef []
>let fun x = .. var .. x ..
>fun y
Where is the polym
Marcin 'Qrczak' Kowalczyk wrote:
> Of course I still think that div and sort should not have any form of mode
> argument.
Agreed!
--
-- Lennart
"S.D.Mechveliani" wrote:
> D. Tweed <[EMAIL PROTECTED]> writes on 1 Jun 2000
>
> >> We also may paste
> >> True :: Bool instead of False
> >> (the type design does not help),
> >> x / 0 instead of x / 2,
> >>
Matt Harden wrote:
> "S.D.Mechveliani" wrote:
> >
> > More example on standard functions needing the *mode*:
> > in quotRem, quot, rem,
> > divMod, div, mod.
> >
> ... blather about adding a "Char" ar
"Ronald J. Legere" wrote:
> Thanks that explaination was very very helpfull! (Also Martins comments).
> One thing that I would like to understand is why so many of these
> nonstandard extensions get used all the time. It is very hard to
> find any application package that doesnt use some nonstan
> As Mark Jones has allready said this thread should end or come to a
> conclusion. Unfortunately he said more than that . He said that the
> discussion was all about the difference a -> a and forall a. a -> a . And
> that's not
> true . One only has to read the first 2 or 4 emails about this
Jan Brosius wrote:
> > "x" in the domain of your model, and that that element, at least,
> satisfies
>
> x is a variable ; no domain ; no model
You must have some assumed convention that makes x a variable.
For the rest of us it might as well be a constant, because there is
no way to tell if it
Jan Skibinski wrote:
> digest :: String -> String
> digest string
> = unsafePerformIO (
> marshall_string_ string >>= \x1 ->
> prim_Md5Digest_digest x1 >>= \x2 ->
> unmarshall_string_ x2 >>= \x3 ->
>
> The definition
> of (*) in the Prelude has to be clumsy because it cannot
> assume that this will the case because users can construct
> their own Ratios.
How can a user create his own Ratio? The % operation does the
GCD reduction, as does every other operation that creates a Ratio.
--
> I am not quite sure how to express this in Haskell
> terms but here it goes anyway: Why is :% in Ratio
> not hidden?
What?!? Of course :% is hidden. It's always been hidden.
If it isn't it's a bug in your implementation or a (new) bug
in the repotr. It's always been hidden before; exposing i
Mark P Jones wrote:
> The Numeric.showFloat function is there for the more expert programmers
> who care about the last few bits after the floating point. That's the
> function that a Haskell programmer should use if they need this kind of
I don't agree. Numeric.showFloat is for the novice who
George Russell wrote:
> (LONG and about floating point, so I suspect many Haskellers are not
> going to be interested in this message . . .)
Thank you George for your message. You said it better than I could (and did).
-- Lennart
Julian Assange wrote:
> The precission and or rounding used by hugs/ghc seems strange, to wit:
>
> Prelude> sin(pi)
> -8.74228e-08
> Prelude> pi
> 3.14159
> sin(3.14159265358979323846)
> -8.74228e-08
>
> ghc:
>
> module Main where
> main = do
> print pi
> print (sin pi)
>
> ./a.ou
Take a look at what a hard core game programmer thinks about the
evolution of programming languages. Unreal is a very sucessful
game so maybe people listen to him...
http://www.gamespy.com/articles/devweek_b.shtm
You need to read until about page 5 to get to the part I enjoyed most.
--
Mark P Jones wrote:
> Simon Marlow writes:
>
> | All known Haskell compilers implement the IO type as a function type,
> | something like (World -> (World, a)). You can think of the monad
> | as just a convenient way to hide the passing around of the world token.
> |
> | And because it is abstra
Jan de Wit wrote:
> I'm under the impression that Hugs has the most features (probably because
> it's relatively easy to hack on, being an interpreter in C), GHC comes next
> after that and tends to adopt features introduced in Hugs, and NHC and HBC
> lag far behind that (no compiler wars please
Antti-Juhani Kaijanaho wrote:
> On Mon, Nov 29, 1999 at 03:06:07PM +0100, Marko Schuetz wrote:
> > For those who do not like to read legalese this is a standard
> > BSD license.
>
> No it is not. The standard BSD license includes an evil advertising
> clause. This one is thus better.
There are
Malcolm Wallace wrote:
> > When no good reason for this restriction exists, it should be removed
> > IMHO. This only extends the set of programs which can be compiled, and
> > existing programs don't change their meaning.
>
> You will be pleased to hear that neither hbc nor nhc98 implement the
>
Marcin 'Qrczak' Kowalczyk wrote:
> Sat, 9 Oct 1999 12:42:20 +1300, Brian Boutel <[EMAIL PROTECTED]> pisze:
>
> > Be careful. '<-' is two symbols. Replacing it by one symbol can change the
> > semantics of a program by affecting layout.
>
> No, because only the indent before the first non-whitespa
George Russell wrote:
> Simon Peyton-Jones wrote:
> > One solution is to add
> > macros (presumably in a more hygienic form than cpp), but I'm reluctant
> > to advocate that, because macros undoubtedly do overlap with functions.
> You don't need macros. (For speed purposes inline functions are o
Mark Engelberg wrote:
> 3. It appears that there are significant speed gains when you explicitly
> describe the types. I don't really understand yet how the Haskell type
> system works; I glossed over it because the tutorial implied that most of
> the time declaring types was optional -- Haskel
Oops, I forgot to include the time with optimization:
no optopt
hbc0.761u0.663u
cc 1.055u0.167u
--
-- Lennart
So I did a test run too, on a 450MHz Pentuim II running NetBSD.
I used Manuel's Haskell code, but I added a type signature for
the expand function, and the original C++ code.
dogbert% cc c.cc -o c.out -lstdc++
dogbert% time c.out
1942530768
1.043u 0.010s 0:01.05 100.0%0+0k 0+1io 0pf+0w
dogber
Reginald Meeson wrote:
> >Lennart Augustsson wrote:
> >
> >>...
> >
> >Ooops, I miscounted. It's 376 lines of Haskell; still 137 in the optimizer.
> >(Not much productivity, just 1 line/minute.)
> >
>
> It appears Lennart is exercising
Mark Engelberg wrote:
>
> This is a huge difference, and makes Haskell look incredibly slow by
> comparison. The speed difference in this case is well worth the extra few
> lines of code.
Well, Hugs is an interpreter. Comparing interpreted Haskell with compiled
C++ isn't really fair. Try comp
Lennart Augustsson wrote:
>
> 547 lines of Haskell, 137 of those line is the "optimizer", the rest is
> parsing, printing, etc.
> The parser uses parsing combinators.
> I used HBC (what else? :)
Ooops, I miscounted. It's 376 lines of Haskell; still 137 in the opt
Simon Peyton-Jones wrote:
> > Just curious, a few questions :
> > - How long was your program?
> > - How did you do the parsing? with happy?
> > parser combinators? ...
> > - Which compiler did you use ? (Okay, i think i know ... :-))
> > - Other information you want to share with us ...
> > (e
Simon Peyton-Jones wrote:
> Good guess for Si^3. And I'd bet a lot of money that LA
> is Lennart. He is a demon. I nearly didn't enter because I
> anticipated the shame of a team of three of us lagging way
> behind Lennart, on his own, probably writing his in the gaps
> between implementing a
Marcin 'Qrczak' Kowalczyk wrote:
> Wed, 15 Sep 1999 00:02:02 +0200, Lennart Augustsson <[EMAIL PROTECTED]> pisze:
>
> > Only numeric types are subject to defaulting.
>
> And I don't like this solution. Maybe it is practical, but inelegant.
> Haskell is
> The question: is it reasonable to expect (,y) to be a right section of
> the (,) operator, or would this syntax break something (or perhaps lead
> to confusing error messages)?
It's very reasonable, nothing breaks, and it's quite useful.
I suggested it for Haskell (1.3, I think), but it was
r
Christopher Jeris wrote:
> > det
> ERROR: Unresolved overloading
> *** Type : Ix a => Array (a,a) Double -> Double
> *** Expression : det
> It confuses me that the numeric type is defaulted and the other type
> isn't.
Only numeric types are subject to defaulting.
--
-- Lennart
Christopher Jeris wrote:
> Hi everyone. I am a sometime O'Camler just learning Haskell. Type
> classes are fun and I like the expressiveness you get without grafting a
> whole "object system" onto your nice functional language. But sometimes
> they baffle me, as in the following.
>
> This func
101 - 200 of 377 matches
Mail list logo
