% You can apply any constructor e1 with a kind (k1 -> k2), be it a
% variable, constant, or application, to any other constructor e2 of
% kind k1, forming a (possibly partial) application (e1 e2), as described
% on pages 31--32 of the (draft) report. As you say, this permits currying.
Yes, but
%But there are no types `(\x->x)' or `(\x->())' in Haskell.
%So the expression does not typecheck (at least that is
%my understanding of how it works).
%You might think that
% type I x = x
%and then using I alone would give you the type `(\x->x)',
%but partial ap
The new Haskell report 1.3 (preliminary) allows type variables of
other kinds than *, e.g. it gives the example (page 51)
data App f a = A (f a)
where the type variable f has kind *->*, and App has (*->*)->*->*.
My problem is that I haven't seen (in the report) any mention
about the in
Suggestion:
add another form of statement for monad expressions:
stmts -> ...
if exp
which is defined for MonadZero as follows:
do {if exp ; stmts} = if exp then do {stmts}
else zero
Based on this, one can define list comprehensions by
John Hughes mentioned a deficiency of Haskell:
OK, so it's not the exponential of a CCC --- but
Haskell's tuples aren't the product either, and I note the proposal to
change that has fallen by the wayside.
and Phil Wadler urged to either lift BOTH products and functions,
or none of them
Mark's suggestion for declaring the selector functions
within the datatype already exists in the language OPAL
(developed at TU Berlin). Besides selectors, you also get the
test predicates there.
Example: the declaration
DATA list == empty
:: (first:char, rest: lis
Following up this discussion on
which laws are there in the presence of lifting,
which are not, and which one do we actually care about,
here is another observation.
On most occasions when you (well, I actually) write a datatype,
you think about it inductively.
In a lazy language however, you ge
> Parsing Haskell list comprehensions deterministically ((LA)LR) is currently very
> hard, since both "pat <- exp" (or also "pat gd <- exp", as suggested by Thomas)
> and "exp" are allowed as qualifiers in a list comprehension. Patterns and
> expressions can look very much alike. Could o
Phil Wadler wrote:
> Mark suggests that Mu types might be better that recursive type
> synonyms. I think of them as pretty much equivalent, and it's
> simply a question of whether one makes the `mu' syntax accessible
> to the user. One certainly needs `mu' or an equivalent internally
>
Phil's (Robin Milner's ??) example typechecks in ML.
%Incidentally, there has been a lot of work done on Milner's type
%system extended to allow polymorphic recursion; this system is
%sometimes called ML+. One motivating example -- which I first
%heard from Milner -- is:
%
%
> | Another strange thing about n+k patterns.
> |
> | Its definition uses >= , but >= is not part of the class Num.
> | Does that mean that n+k patterns have to be instances of class Real?
>
> Certainly. In fact, they're really meant to apply only to class
> Integral (and it would be
Another strange thing about n+k patterns.
Its definition uses >= , but >= is not part of the class Num.
Does that mean that n+k patterns have to be instances of class Real?
One could leave it class Num, if the translation were expressed
in terms of "signum" rather than ">=".
Question:
Can one
Phil wrote:
> Both (>=) and (-) belong to classes defined in PreludeCore,
> and hence cannot be rebound. This was a deliberate decision,
> made in order to turn your point into a non-problem.
>
> Long live (n+k)! -- P
The Report tries to handle this by "always implicitly importing"
Pr
Lennart mentioned this recently; the situation is as follows:
1. semi-unification (the general one) is undecidable
2. it is semi-decidable
3. the semi-decision procedure for semi-unification can be augmented
with heuristics that finds almost all cases in which it fails
(this is a kind of mo
Hi folks,
I just wanted to draw attention to the fact
that there is an ANSI group working on the standardisation of
"Language independent arithmetic". The draft is undergoing public
review now. Scanning casually through the pages,
my first impression is that there might be some differences to t
SNA=Shah Namrata Abhaykumar
SNA Consider the following eg.
SNA
SNA Using the above tanslation ,
SNA
SNA case (1,2) of { ~(a,b) = a + b ; _ -> 0 }
SNA
SNA == let { y = (1,2) }
SNA in
SNA let { x1' = case y of { (a,b) -> a }}
SNA in
SNAlet { x2' = case y of {
I like John's idea with a class Strict, but I think there should also be
a second class Eval for computing whnf's:
class Strict a where
strict :: a -> Bool
class Eval a where
eval :: a -> Bool
Example: for Complex we get:
instance Strict a => Strict (
Joe,
Your definition of divFloorRem (and probably divCeilingRem as well)
doesn't seem to be quite right, because I end up with
(-4) `mod` (-3) == -4
because divTruncateRem (-4) (-3) is (1,-1).
The condition in the "if" should be something like
signum r == -signum d
rather than r<
Page 19:
"In the apptern-matching rules given below we distinguish two kinds of
patterns: an irrefutable pattern is either of the form ^apat, a
variable, or a wildcard; all other patterns are refutable."
var@apat is irrefutable if apat is, isn't it?
Stefan Kahrs
19 matches
Mail list logo
