| Here are some questions for the Haskell-98 enthusiasts.
Are implementors allowed to answer too? :-) It was a nice little puzzle!
| 1. Why is the following declaration group illegal?
|
| f :: String
| f = g 1 ++ g True
|
| g :: Show a = a - String
| g x = fst (show x, show f)
Well
| As you probably know, GHC and Hugs now support an exception mechanism
| which lets you recover from calls to 'error' -- but of course that's
| not in H98.
Sorry Simon, but it's not supported in any currently
released version of Hugs either.
All the best,
Mark
| Pro a change
| Mark Jones mildly
| Olaf Chitil?mildly [I can't locate his message]
|
| My rule of thumb is that the status quo wins if there's any
| doubt, and there is, so I'll reverse my proposal and leave
| things unchanged.
Actually, I'm neither pro or
| Right associativity allows:
| f = \x-
| g = \y-
| h x
| which with left associativity will be rejected because x is unbound
| (in h x), or even worse: if x is bound at an outer scope, you might get
| completely the wrong value (or if you're lucky a type error).
No worries here: the
Hi Jan,
| Could anyone explain what is a relation between
| number of reductions and execution time of any
| given Haskell function? Is there any linear
| relationship between the two on any given machine
| and compiler/interpreter?
Absolutely, definitely not. To
[Apologies if you receive multiple copies of this message]
A new *beta* version of Hugs is available from:
ftp://ftp.cs.nott.ac.uk/haskell/hugs/Hugs-98-source.zip
or, if you prefer, from:
ftp://ftp.cs.nott.ac.uk/haskell/hugs/Hugs-98-source.tar.gz
This version combines the type
Hi Alex,
| 1. Does hugs now support mutually recursive modules?
As far as I know, there are no versions of Hugs that support this.
The underlying infrastructure in the Hugs implementation was never
designed with this in mind, and would need some substantial changes.
There is interest in doing
| I don't agree with your argument that
| because pattern match failure in function definitions is not catched by the
| type-checker justifies dropping that extra safety for pattern matching in
| the do-notation.
You've missed my point, the nub of which was that we should get
our compilers to
| 1.Fix up the current version.
| use MonadZero for do expressions with *irrefutable* patterns
| (instead of *unfailable* patterns as now)
| 2.Nuke MonadZero altogether.
| add mfail :: m a to Monad instead
There is another variation on 2 that you don't seem to be considering:
Hi Jan,
| ... I realized that
| there are several quite annoying problems with Haskell numerical
| types and classes.
| ...
| + Hugs is supplied with the type Number. According to its
| author: "Fixed width integers with overflow detection.. Unlike
| Int, overflows are detected and
Hi Keith,
| Following recent discussions about instance declarations in Haskell-2
| on the Haskell mailing list, and the suggestion that without
| sufficient restrictions in this area Haskell's type system would
| become undecidable, I decided to demonstrate this directly. In this
| brief paper
| Michael suggested
|
| f :: [a] - c
| f xs = if len fromInteger 3 then len else 0
| where
| len :: c
| len = length xs
|
| This relies on the 'c' from the type signature scoping over
| the definition, which is on alternative notation for scoped
| type variables.
Hmm,
Hi Alex,
| I think the way that Hugs 1.3c handles it ...
| ...
| AKA "Proposal A" in SPJ's recent message on this topic:
|
| http://www.cs.chalmers.se/~rjmh/Haskell/Messages/Display.cgi?id=274
Exactly, although I hadn't been referring to that at the
time. The only negative point for proposal
Ok, back to the main list we go!
| But the problem is that I need the type name c inside the body of
| the function! I'm assuming always that I can solve a typeing
| problem by adding an explicit type signature wherever it's needed;
| however, that implies that I need to be able to get at the
We've seen several examples now, from Ralf, Alex, and others, where it is
useful to relax the proposed restriction:
The types in an instance-declaration context must all be type variables.
(Item 10 in Simon's list:
http://www.dcs.gla.ac.uk/~simonpj/multi-param.html)
Hugs and GHC are currently
Hi Fergus,
| Without the restriction, it is easy to come up with examples that could
| lead to non-termination.
|
| Is non-termination really a problem in practice?
I don't think so, which is why I've been happy not to enforce
restrictions in Hugs. For example, Gofer programs can
| Fergus Henderson writes of:
| the monomorphism restriction (which exists for a similar reason,
| to ensure termination of type inference).
|
| Is this true? The rationale normally given for it by its advocates
| (boo, hiss) seems invariably the "no re-evaluation of CAFs" mantra.
Yes, I
| delete :: (Dictionary dict key dat) = key - dict - dict
|
| It would not *always* result in ambiguity. For example, consider
|
| instance Dictionary (MyDict dat) Int dat where ...
|
| f :: MyDict dat - MyDit dat
| f d = delete (3::Int) d
|
| Here, the polymorphism in
| class (Eq key, Ord key) = Dictionary dict key dat where
|delete :: key - dict - dict
| ...
| the first error:
|
| Class type variable `dat' does not appear in method signature
| delete :: key - dict - dict
|
| Why does ghc expect that I use all of the type
[It's been moderated since '94. Spam posts that are clearly system
specific (e.g., "my program fails to compile,{hugs,{g,n,h}{h,b}c}-wurble
needs the Flarp library - where can I find a copy of it?") are not
relayed - do you want them to? It's up to the list corpus to decide
whether it should
| Is the following legal Haskell?
|
| infixr 0 `foo`
| infixr 0 `bar`
| ...
| dubious a b c = a `foo` b `bar` c
|
| According to the grammar in the Haskell report, I don't think it is.
| However, ghc-0.24 (ancient, I know) and Hugs 1.3 both accept it without
| complaint.
I believe that it
This message is an attempt to comment on the relationship between the
various treatments of extensible records that have been referred to in
the past couple of days.
While the proposal on records for Haskell 2 that I just posted is
intended for a fairly wide Haskell audience, this one will
101 - 122 of 122 matches
Mail list logo
