S. Alexander Jacobson:
> Can we stop polluting the namespace with list based function
> definitions? Most of these functions: delBy, filter, map, concat, length,
> take, takeWhile, etc. are well specified for data structures other than
> lists. Regardless of whether Haskell includes generic pro
John Atwood:
> You have it right, except you need to
> 1) explicitly type test,
> test:: Reader [Char] Char
José Romildo Malaquias:
> > ---
> > test = do env <- ask
> > if env == "choose a"
> > then return 'a'
> > else return 'b'
> >
>
Frank Christoph:
> > I think he means the application term associated with second-order lambda
> > calculus' "big lambda," usually written "M [T]" or just "M T" where M is a
> > value term and T is a type term, e.g., "(/\X.\x.x) Int 3".
>
> Should be: "(/\X.\x:X.x) Int 3". (Doesn't make much sen
John Atwood:
> You have it right, except you need to
> 1) explicitly type test,
> test:: Reader [Char] Char
José Romildo Malaquias:
> > ---
> > test = do env <- ask
> > if env == "choose a"
> > then return 'a'
> > else return 'b'
> >
>
Now that rank-2 polymorphism seems to be part of the 'received standard'
(at least two implementations support 'em, and I assume they're a shoo-in
for Haskell 2), couldn't we really also do with type application?
It seems that ambiguity is here to stay in Haskell, and in principle
R2L makes the s
Eduardo Costa on small Haskell compilers:
> Besides, it becomes easier to install, and uninstall. For instance,
> Dr. Alcimar (that you know quite well) is finishing his prosthetic arm
> for amputees. Clean was able to produce code that was small enough,
> uses heap sparingly, and was fast enough
Alex, malreported, haskell and ghc-users lists...:
> It does me ego no end of good to find out that I'm right, and the
> compiler is wrong (for a change, it must be said...). Unless either
> ghc or hbc catch up to the Hugs extension, though, avails me little
> in practice, sadly. (Hint, hint.)
Hi Fergus.
> > > data OrdFuncExist = OE (Ord a => Char -> a)
> >
> That's not the syntax for a existential type,
> that's the syntax for a universally quantified type
> with rank-2 polymorphism. With that syntax, the
> argument of `OE' must be a polymorphic function
> with type `forall a . Ord
Hi Mark, all: thanks for the swiftly muddle-dispelling response.
> | Here's some of the threatened examples:
> |
> | > data OrdFuncExist = OE (Ord a => Char -> a)
> | > data OrdListExist = OLE (Ord a => [a])
>
> Perhaps this is a GHC/Hugs difference, but the syntax that you've
> used here isn
Here's some of the threatened examples:
> data OrdFuncExist = OE (Ord a => Char -> a)
> data OrdListExist = OLE (Ord a => [a])
> emap :: OrdFuncExist -> [Char] -> OrdListExist
> emap (OE f) l = OLE (map f l)
Grand... (Apparently.) But now I try to define an actual OrdFuncExist:
> blah = O
Hi all. I'm wrestling with a typing problem, which I keep hoping that
I ought to be able to solve with existentially quantified data types,
but such a problem keeps eluding me, leading me to rend my hair at the
prospect of instead having to use a some sort of dynamic type or
universal type hack.
Koen Claessen:
> I want to propose a modest extension to Haskell, which
> would solve a common irritating problem in programming
> in Haskell, and on-the-fly solves the practical programming
> problems occuring due to the monomorphism restriction.
I've banged into this more than once, so I have
Ronald J. Legere:
> Is there anyway to make a 'subtype' of lists? I have a type
> that is essentially a list,but I want to be able to overide
> 'show' for example. So in order to do that, I have to leave
> the world of type synonyms:
>
> newtype SS = SS [Int]
I'm forgetting the obvious here:
Ronald J. Legere writes:
> newtype SS = SS [Int]
>
> Now I can override show for my newtype, but
> unfortunately , I cant overide 'take' 'drop' etc...so
> I have to rewrite new versions 'sstake, ssdrop' that does
> nothing but peel the wrapper off. Ok, so is there
> any nice way to do this?
Wel
> Does anyone have a 'live' link to Johan Nordlander's O'Haskell?
> http://www.cs.chalmers.se/~nordland/ohaskell/ seems to be unwell.
You're all going to think I'm mad, but the above link has now
'recovered'...
Cheers,
Alex.
Does anyone have a 'live' link to Johan Nordlander's O'Haskell?
http://www.cs.chalmers.se/~nordland/ohaskell/ seems to be unwell.
Cheers,
Alex.
Me:
> > Your 'partial' list would appear, from a initial
> > inspection, to leave little left of either type safety or referential
> > transparency.
KA:
> Could explain how they could. There is a very nice paper written up on
> True ad-hoc polymorphism. By a build in build in dynamic type s
Kevin Atkinson:
> I have a generic mutable array class which has a few basic methods:
>
> class MArray ... where
> newArray :: Int -> m (mutArray st el)
> write :: mutArray st el -> Int -> el -> m ()
> read :: mutArray st el -> Int -> m el
> freeze :: m mutArray st el -> m array el
>
Kevin Atkinson, replying to me...
> > I think it should be eminently possible to write a good generic
> > container class without resorting to either dynamic typing, or to
> > ad hoc polymorphism. (I don't see how these would really help,
> > actually.)
>
> Neither of them will. Sorry if I
Kevin Atkinson:
> I never, ever, said that I would like Haskell to be able to do
> everything C++ can.
No, that was my inference from the general drift of your comments.
I also never said that I want Haskell to become a
> more type unsafe language. If it was implied I'm sorry. What I did s
Kevin Atkinson and I argue about C++'s 'Cleaner more natural syntax':
> I would like to be able to do the things in Haskell that I can do in C++
> but currently Haskell's type system is too simple to allow me to do
> them. There are also some things I can't do in C++ but really wish I
> could, I
Kevin Atkinson:
> > > 3) Encapsulation. You can't have private and protected members. Some
> > > of this can be done using modules. However it is more work.
> >
> > What exactly can't be done with classes, and how, substantively, is
> > it more work?
> class Foo
> private: -- only members
Kevin Atkinson:
> 2) More specific types, you can't _easilly_ call the more general type.
> For example in OO this is very commen:
>
> class Base
> virtual foo()
> do stuff
>
> class Derived, extends Base
> foo()
> call Base::foo()
> doo stuff
You can certainly do this in H
Jan Skibinski:
> What is available from haskell.org are two much outdated versions of CGI
> library: one by Erik himself and one modified (and adopted to Haskell 98)
> by Sven Panne. By outdated I mean that they both are based on Erik's
> earlier work and much predate the refined and simplified c
> Either, cpp (or some preprocessor standard), should be made part of the
> Haskell language definition or Haskell files that require a preprocessor
> should have a different extension.
>
> Since, I assume that the hugs team has a good reason not to build in cpp
> functionality, I am suggestin
Fergus Henderson:
> One example is the case where you already have existing code that
> creates a heterogenous collection, and you want to extract an
> element from that heterogenous collection, and then if it is
> a member of a particular type class perform action A otherwise
> perform action B,
> From [EMAIL PROTECTED] Mon Sep 27 18:50:33 1999
> X-Authentication-Warning: sun00pg2.wam.umd.edu: kevina owned process doing -bs
> Date: Mon, 27 Sep 1999 13:50:59 -0400 (EDT)
Kevin Atkinson:
> You have a collection of Shapes. Some of these shapes are circles,
> however, others are rectangl
Kevin Atkinson:
> I take it that you are happy with names such as:
[long list]
Yes. Certainly I'm more than happy that types with completely different
signatures have different names.
Fergus Henderson, replying to me:
> > That's far from clear. Certainly, I don't think it's likely to be
> > reasonably possible a conversative extension.
[...]
> Ad-hoc overloading and type inference don't mix so well, because
> you can easily get ambiguities which the compiler cannot resolve.
Kevin Atkinson, replying to me:
> > If I understand you correctly, then the best way of doing this would be
> > with existentially (boundedly) quantified data types, currently a
> > non-standard extention present in hbc (and I think, ghc, these days, not
> > sure if it's with the same generality
Kevin Atkinson:
> Yes but often putting things in type classes is tedious to do. I also
> want to be able to overload not only on the TYPE of parameters but also
> on the NUMBER of parameters. It IS possible to do these things and it
> DOES make sense in a curing system.
That's far from clear.
> Maintainer's note:
>
> The Haskell mailing list, and all the other lists served by
> haskell.org, have recently moved to a new machine (the "real"
> haskell.org). None of the addresses have changed, and the address for
> admin requests is still [EMAIL PROTECTED]
The mail headers certainly ch
I've managed to entirely confuse myself trying to install TclHaskell
on a Wintel machine, via Cynwin and ghc-4.03. Poking around it looks
like the problem is with the Tcl/Tk libraries, which seem to have been
complied up with Visual C++.
Now, is there a magic incantation that will persuade TclH
Wilhelm B. Kloke:
> has anybody there an idea which GUI is usable with Haskell 98 on
> a Unix/X11R6 system (FreeBSD to be complete)?
>
> It seems that all GUI stuff develepmont (Fudgets, Haggis ...)
> has been stalled since some years.
I'd look at TclHaskell, if I were you. It's not strictly s
Manuel Chakravarty and Olaf Chitil debate the fixity of ($):
> > I think the idea behind $ is exactly the change of
> > associativity.
>
> Hmm, I thought, the idea behind it is a change of precedence...
>
> > I use $ a lot to save a lot of brackets. I very much prefer
> >
> > f $ g $ h $ i $
Erik Meijer's nifty-looking CGI library, as described in his upcoming
JFP paper, looks like just the very thing I'm looking for, but alas,
I can't find a complete copy of the code anyplace. In particular,
some of combinators in the paper have only type sigs, not complete
definitions, and are not
Joe English:
> I was thinking of the example from the Haskell Report:
>
> let { len = genericLength xs } in (len, len)
>
> which, without the MR, computes 'len' twice.
> Operationally I expect that in "let x = f y in ... x ... x",
> 'f y' is only evaluated once, no matter what type it is.
Thomas Hallgren:
> The monomorphism restriction makes sure that certain values are computed at
most
> once by restricting them to be used at only one type. Couldn't the same be
> achieved by
>
>* getting rid the monomorphism restriction, i.e., let all definitions to be
> overloaded by
Joe English:
> (Am I the only one who's never been bitten by the MR restriction?)
If one always uses type sigs, or never/rarely uses compositional/
combinator style function definitions, it's much less likely to
crop up.
> How about leaving the 'a = b' binding form as it is,
> (monomorphism re
Christian Sievers replies to John Hughes:
> > Some suggest that it is enough for compilers to issue a warning when using
> > call-by-name. I disagree strongly. Such a warning may alert the programmer
> > at the time the overloaded definition is compiled. But programmers need to
> > understand pro
John Launchbury:
> I agree that the MR is a pain. [...]
> Now we find that some type declarations
> contain more class info than type!!
And some type(+class) declarations are longer than the definition!
This sounds a trite point, but it gets very annoying when one is
"rapid-prototyping" (aka hac
Simon encouraged me to bellyache with this reply in public, so here it
is...
> > Having just wasted an hour or so chasing MR-induced errors through
> > a moderate-sized module after introducing a relatively minor change,
> > I feel the need to vent on this topic, yet again.
> Alex, it's fine
Now that Haskell 98 is a done deal (for good or for ill -- what on earth
were people thinking of with 'isAlphaNum'?), can we hope that the committee
will revisit the Monomorphism Restriction, and somewhat more seriously
than it's done to date?
Having just wasted an hour or so chasing MR-induced
Greg O'Keefe:
> main =readFile "input-file" >>= \ s ->
> writeFile "output-file" (filter isAscii s) >>
> putStr "Filtering succesful\n"
[vs.]
> main =readFile "input-file" >>=
> \ s -> writeFile
Patrik Jansson:
> I like ? better than .., but maybe the Haskell "don't care"-symbol _
> could be even more suggesting:
>
> q :: a -> _ -> c
> qa_ = c
>
> Syntactically this is closer to what is currently allowed as type
> variables and it would easily (in the sense that such a pro
Hi Simon, you spake of simple-context restriction:
> My default position is not to change. Question: who, apart from
> Ralf, has actually tripped over the lack of contexts of the
> form (C (a t1 .. tn)) in Haskell 1.4?
*raises hand and jumps up and down* Me, mememe! I provided you
with
Various people write:
> cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
And so on. Please, these are _not_ the correct list addresses to
us for this list -- all list mail ought to go to [EMAIL PROTECTED],
and not any of these variants.
[Glasgow people, is it possible to tweak the list config so that
> No semantic objection, but GHC doesn't implement them because of
> the lack of a decent syntax.
OK, I suspected as much. I think I shall go off and try to
craft a syntax for a "logical" such extensions, so it can be shot
down in more detail!
The only snags I can think of off the top of my he
Hi all. Was there ever any sort of consensus about whether pattern
guards ought to be "nestable", or not?
And if not, was there some semantic objection to this, was the syntax
just considered to Unspeakable to be spoken of, or is the feature
just largely redundant? (I think you can always rewr
John Launchbury:
> I think I favor "20th century Haskell" myself :-)
I forsee legal wrangles with one R. Murdoch -- though on the plus
side, he might buy us all out for half a billion quid or so, perhaps.
[ soccer econo-political reference for those not up on the latest
NewsMegaCorp shenaniga
Jeff Lewis:
> I'm not sure what the parenthetical comment about the interpretation of a
means -
> take the definition at face value.
My point was: were they _intended_ to be same "a", or different? What
is "face value" is surely simply begging the question.
> It's not at all clear to me that
Hi Jeff.
> > http://www.cs.chalmers.se/~rjmh/Haskell/Messages/Display.cgi?id=274
> >
> > I think "A" is fine, it's "B" (and hence, SPJ's Composite Motion, A+B)
> > that worries me, for the reasons I alluded to. If "beefed up A"
> > does the job, I'm equally happy as with a more conservation syn
Sergey Mechveliani writes:
> Second, some compilers say at this:
> "
> (the instance type must be of form (T a b c)
> where T is not a synonym, and a,b,c are distinct type variables)
> "
> Maybe, they treat Int Int as a repeated variable?
Not quite, Int isn't a type variable at all, but an act
Hi Mark (and all).
> I think the way that Hugs 1.3c handles it would meet your goals. All that
> it requires is a strict extension to the syntax for patterns to allow type
> annotations. These can be useful in their own right, but also can be
> applied to problems like the one that you gave:
>
Alex Jacobson:
> > > > (./) :: (Stringable a,Stringable b)=> a->b->String
> > > > x./y = (toString x)++(toString y)
> > Wouldn't it be a great deal less tortuous to define:
> >
> > > x .++ y = show x ++ y
> >
> > > x ++. y = x ++ show y
> >
> > and then to use (++), (.++), or (++.), as approp
S. Alexander Jacobson writes:
> So I tried creating my own Stringable class:
> > class Stringable a where
> > toString::a -> String
> > (./) :: (Stringable a,Stringable b)=> a->b->String
> > x./y = (toString x)++(toString y)
Wouldn't it be a great deal less tortuous to define:
> x .++ y = sho
Further to discussion on the StdHask site, and (of all places) ghc-bugs,
I remain concerned about the program-breaking proposal to have typesigs
scope over equation groups, thereby binding any type variable occurrences
in local signatures. But I agree with the need to add this expressivity.
Sure
Sergey Mechveliani writes:
> But question aside, on "MPC forces me to use non-variable contexts":
> its this necessary to represent a Set as a constructor class?
> Why do not declare
>class (Foo a,Foo' b) => Set a b where ...
> ?
I'm not sure I follow. Can you elaborate on ho
SPJ:
> Alex: can you flesh out your example any more? I was expecting
> Num (s n) not Num [s n], for example.
The idea is to generalise numeric operations from sets (intervals say),
to sets of sets (lists of intervals). If it were possible to write Set
as a unary class, the instance declaration
John Peterson defends the DMR:
> read :: Read a => String -> a
> read s = let [(r,s')] = reads s in r
> This *won't compile* if you don't treat the let binding definition
> monomorphicly. Without monomorphism, the types of r and s' are
> r :: Read a => a
> s' :: Read a => String
> This leads
Fergus Henderson, replaying to me:
> > I haven't looked at this in great detail, so forgive me if I'm talking
> > through my hat, as seems quite likely: is it workable to require only
> > that contexts be non-increasing in size, and that there be no manifest
> > circularity where the sizes are no
Mark Jones:
> Looking at the `size' of types is, of course, a generalization of Simon's
> suggestion that contexts might be allowed to constrain only proper sub-
> expressions of types in the context. (Proper sub-expressions are, by
> definition, smaller in size.) However, it is still too stric
Hi Alex.
> If you use a different (but still lazy) definition of foldl:
> > myFoldl f s [] = s
> > myFoldl f s (x:xs) = f s (foldl f x xs)
Unless I'm more asleep than I realise, this is just foldr, isn't it?
(To wit, "fold to the right", rather than "fold to the left".)
In fact, foldr is the "
Alex Jacobson:
> Ooops, I forgot to remove the "and". Anyway, my point is that
> 1. it is not logically consistent to treat exceptions as return values
> 2. as an implementation matter it violates laziness to do so
OK, now I follow. And diagree. ;-) On your second point first:
I'm not sure w
Alex Jacobson:
> In the backchannel, Alastair Reid and Adrian Hey, have convinced me
> that the return values of functions and cannot be represented using
> algebraic types.
I'm not clear what you mean by this.
> I am not sure of syntax, but I am describing something like:
> > fun:: a->b->c :
S. Alexander Jacobson wonders:
> If you have a statement like:
>
> result= a || b || c
>
> does Haskell guarantee that a gets evaluated before b?
Indeed it does, for see the standard Prelude definition of (||):
True || _ = True
False || x = x
Hope that helps.
Slainte,
Alex.
Various people write:
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Can I ask people to be careful to which haskell-list address(es) they
followup to? My understanding is that list messages ought to be sent
_only_ to [EMAIL PROTECTED], and that any other addresses are symptoms
(and in some cases c
John "Poisson d'Avril" Peterson writes:
> Microsoft And Yale Conclude Agreement To License Technology For Haskell
Very droll. ;-)
Slainte,
Alex.
Frank A. Christoph:
> I hope that Either will be renamed to (+), or at
> least deprecated in favor of (+).
I'd basically agree with Frank here, though presumably for consistency
with Koen's (very reasonable) proposals, this would need to be the
symbol (:+:) -- or characters to that effect -- for
Greetings all. Why does the 1.4 report have "insert" use the "compare"
member function of Ord, rather than ">", hence giving insertBy a funny
type involving "Ordering"? This seems unnecessary, and not the most
convenient form for direct use of insertBy, either.
Slainte,
Alex.
Thanks Simon, you largely confirmed what I'd inferred. Pity there
isn't such a clear description -- or really, any such description
-- in the report!
Cheers,
Alex.
The 1.4 report says:
"A type may not be declared as an instance of a particular class more than
once in the program."
Doesn't it really mean that a type _constructor_ may not appear in more
than one instance declaration for a particular class? That (stronger)
condition seems to be what ghc and
I'm sure something like this has come up here before, but I've just
been banging my head against it, and feel like a mild grouse.
I recently found myself needing a partial order class, and found that:
The most likely-looking operator symbols are all "taken";
It'd be des
parser
grammar with as close a structure to that as is in the Report as
possible. Obviously the lack is gettable-roundable, though at further
cost to both efficiency and clarity.
Slainte,
Alex.
___
Dr. Alex Ferguson,
Graeme, you wrote:
> Has Happy (the parser generator) been upgraded to Haskell 1.3/1.4 yet?
Happy output works fine with ghc's 2.01 and 2.02. Progressively better
in fact, efficiency-wise. The only caveat is that a small tweak in the
includes becomes necessary for "happy -g" output (and probab
Graeme Moss asks about "map" defined over this type:
>newtype MyList a = MyList [a]
using variously case, an auxiliary function, a selector function, and
pattern guards.
> Should any of these rather cumbersome ways of defining the standard
> map over (MyList a) cause any more code than the
Phil Wadler, quoting K. Claesson:
> > At the moment you make an instance of a class that has default definitions
> > for one of its superclasses, and there is no corresponding instance for
> > that class, we implicitly insert the specified default instance. If
> > there are more instances to cho
Olaf Chitil suggests making "deriving" semi-detachable from type
declararations, thusly:
> deriving Tree (Eq, Ord, Show)
or:
> deriving (Tree a) (Eq, Ord, Show)
I think this is a pretty sensible idea, but I believe it would be
preferable to use a more instance-like syntax, given that's what
is
Lennart says of superclass defaults:
> there is an ambiguity problem when there are several different
> defaults available. E.g.
>
> class C a where
> m :: a -> Int
>
> class (C a) => C1 a where
> m x = 1
>
> class (C a) => C2 a where
> m x = 2
> I guess you could "solve" it by fo
Koen Claessen suggests:
> In this case we could allow the programmer giving a default declaration
> for the superclass methods during the class definition of the subclass. An
> example would be:
>
> class Functor f where
> map :: (a -> b) -> m a -> m b
>
> class Functor m => Monad m w
Koen Claessen:
> I would suggest you take a look at Simon, Erik and Mark's paper [1].
Thanks for the suggestion, but I already have.
> My answer is: yes, there are a lot of examples where this is useful.
> Simon's answer is: yes, but allowing this breaks other properties which I
> find more des
Koen Claessen:
> In fact, the connection between Monad and Functor is much stronger than
> the connection between MonadZero and Monad; the former relation can be
> expressed in terms of a direct default definition.
But alas, not in Haskell; this would be possible, though, if the
rules against ci
Heribert Schuetz:
> I wanted to point out
> that no use of patterns is really "essential" (see also the equivalences
> below), or at least that it is a bit arbitrary what one considers
> essential.
Let me rephrase then; it wasn't a convincing example, because the
non-pattern-guarding version (5a
Heribert Schuetz:
> 3. From Alex' example (version 5a) one could have learned that we do not
>need guards at all, because all sorts of guards (today's Haskell
>guards, Peyton-Jones-style guards, and nested guards) can be replaced
>by the Maybe monad in a *straightforward* way:
I don
A couple of minor counter-quibbles:-
Pablo E. Martinez Lopez suggests:
> You can define your own "sequential if" a la Hoare:
>
>data GuardedExp a = Bool :? a
>
>seqif :: [GuardedExp a] -> a
>seqif [True:?a] = a
>seqif ((b:?a):x:xs) = if b then a else seqif (x:xs
Oh, I forgot to say, concerning the Alternative Syntax (strict where's)
Simon mentions; I think this is not supportable, particularly for the
program-breaking reason SPJ mentions. (And especially because lots of
the borken programs would be mine, and I shudder at the thought of
adding ~'s all ov
Simon (PJ) sez:
> Is this a storm in a teacup? Much huff and puff for a seldom-occurring
> situation? No! It happens to me ALL THE TIME.
I have to join Simon out of the closet, and confess that I write
Clunky Functions rather a lot too, or at least find myself going to
significant lengths to a
... is that there's yet another of them!
Simon L Peyton Jones ordains:
> Don't bother with 2.01.
The trouble with regarding 2.02 as a Mere Bugfix Release are all those
*term deleted* library incompatibilities. Why is the August Committee
_still_ rearranging these things in seemingly incosequen
88 matches
Mail list logo
