Tue, 13 Feb 2001 18:32:21 -0500, Dylan Thurston pisze:

I'd like to copy this over to this revised library. But the numeric constants have to be wrapped in explicit calls to fromInteger.

ghc's docs (the CVS version) say that -fno-implicit-prelude causes numeric literals to use whatever fromInteger is in scope. AFAIR it worked at some time, but it does not work anymore! BTW, why not let 'import MyPrelude as Prelude' work that way? -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

On Wed, Feb 14, 2001 at 09:53:16PM +0000, Marcin 'Qrczak' Kowalczyk wrote:

Tue, 13 Feb 2001 18:32:21 -0500, Dylan Thurston pisze:

...

Here's a revision of the numerical prelude. I like it!

I'd like to start using something like this in my programs. What are the chances that the usability issues will be addressed? (The main one is all the fromInteger's, I think.)

...

...

class (Real a, Floating a) => RealFrac a where -- lifted directly from Haskell 98 Prelude properFraction :: (Integral b) => a -> (b,a) truncate, round :: (Integral b) => a -> b ceiling, floor :: (Integral b) => a -> b These should be SmallIntegral.

It could be either one, since they produce the type on output (it calls fromInteger). I changed it, on the theory that it might be less confusing. But it should inherit from SmallReal. (Oh, except then RealFloat inherits from SmallReal, which it shouldn't have to. Gah.)

...

For an instance of RealIntegral a, it is expected that a `quot` b will round towards minus infinity and a `div` b will round towards 0. The opposite.

Thanks.

...

...

class (Real a) => SmallReal a where toRational :: a -> Rational class (SmallReal a, RealIntegral a) => SmallIntegral a where toInteger :: a -> Integer ... I find names of these classes unclear: Integer is not small integral, it's big integral (as opposed to Int)! :-)

I agree, but I couldn't think of anything better. I think this end of the heirarchy (that inherits from Real) could use some more work. RealIntegral and SmallIntegral could possibly be merged, except that it violates the principle of not combining semantically disparate operations in a single class. Best, Dylan Thurston

Perhaps I mentioned that I use Haskell to teach compilation, since I think that functional structures are good not only for parsers, but for a legible semantics for virtual machines, for the code generators, etc. The main assignment was to write a syntactic converter from a Haskell-like language to Scheme, and the exam included such exercises as Find the type of fm in fm _ z [] = return z fm g z (a:aq) = g z a >>= \y->fm g y aq When I started correcting the exam, I thought I would jump out of the window. First 30 copies: The type of fm is ff -> b -> [c] -> b (with an appropriate constraint for the functional type ff). The result had for them the same type as the type of z. My inquiry proved beyond any doubt that my students are so conditioned by "C", that despite the fact that we worked with monads for several weeks, they *cannot imagine* that "return z" may mean something different than the value of "z". Any suggestions? [Yes, I have one! Stop teaching, find a more appropriate job, e.g., cultivate genetically modified, mutant tomatoes.]] Jerzy Karczmarczuk "C"-aen, Fran-"C"-e.

On Fri, 16 Feb 2001, Jerzy Karczmarczuk wrote:

[..]

fm _ z [] = return z fm g z (a:aq) = g z a >>= \y->fm g y aq

When I started correcting the exam, I thought I would jump out of the window. First 30 copies: The type of fm is

ff -> b -> [c] -> b

(with an appropriate constraint for the functional type ff). The result had for them the same type as the type of z.

My inquiry proved beyond any doubt that my students are so conditioned by "C", that despite the fact that we worked with monads for several weeks, they *cannot imagine* that "return z" may mean something different than the value of "z".

Any suggestions?

Not that it would help you much, but I also think that return is a rather confusing name for what might otherwise be called liftM0. Regards, Andreas. ------------------------------------------------------------------------ Andreas Gruenbacher gruenbacher@geoinfo.tuwien.ac.at Research Assistant Phone +43(1)58801-12723 Institute for Geoinformation Fax +43(1)58801-12799 Technical University of Vienna Cell phone +43(664)4064789

Why should we change and not C? Erik ----- Original Message ----- From: "Jan Skibinski" To: "Jerzy Karczmarczuk" Cc: ; Sent: Friday, February 16, 2001 1:17 AM Subject: Re: Just for your fun and horror

On Fri, 16 Feb 2001, Jerzy Karczmarczuk wrote:

...

My inquiry proved beyond any doubt that my students are so conditioned by "C", that despite the fact that we worked with monads for several weeks, they *cannot imagine* that "return z" may mean something different than the value of "z".

Any suggestions?

Perhaps the name "return" in the monadic definitions could be replaced by something more suggestive of an action? How about running a little experiment next time, with a new name, to see whether this would remove this unfortunate association with C-like "return" in the minds of your students?

Jan

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 16-Feb-2001 Matthias Felleisen wrote: | | The problem is Haskell, not your student. | | Haskell undermines the meaning of 'return', which has the same meaning in | C, C++, Java, and who knows whatelse. These languages use 'return' to | refer to one part of the denotation of a function return (value) and | Haskell uses 'return' to refer to two parts (value, store). These languages | have been around forever; Haskell came late. These languages are | imperative; Haskell is a wanna-be imperative language. The denotation of a return command in a typical imperative language supplies a value and a store to a calling continuation, so why is the name not entirely appropriate? Joseph H. Fasel, Ph.D. email: jhf@lanl.gov Technology Modeling and Analysis phone: +1 505 667 7158 University of California fax: +1 505 667 2960 Los Alamos National Laboratory post: TSA-7 MS F609; Los Alamos, NM 87545