Simon Peyton-Jones wrote:
> I wrote:
> > Another question: What is visible in Bar when the name of MakeDing
> > is changed to Ding, too?
>
> Discussed explicitly on page 66 (item 2 in Section 5.3). The
> constructor is hidden too.
OK, then I'll rephrase my question: What's the rationale of thro
> I am wondering what is the best way (in terms of
> easy-to-use and easy-to-install) to use a parser
> for Haskell in Hugs. As far as I know the parsers
> by Sven Panne and Manuel Chakravarty require ghc.
You could try using the parser from nhc98, written using
space-efficient parser combinators
Simon Peyton-Jones wrote:
> I wrote:
> > I'm totally
> > confused. What does
> >
> >module M1(module M2)
> >import M2 hiding (H)
> >...
> >
> > exactly mean?
>
> The intention is this: M1 exports everything that M1 imports from M2.
> Since H is not imported, it should not be exported
I would like some clarification about the circumstances under which defaults
are applied. The relevant section of the Haskell report is on P49, and
reads
as follows (the annotations are mine):
"In situations where an ambiguous type is discovered, an ambiguous type
variable is defaultable if
I am wondering what is the best way (in terms of
easy-to-use and easy-to-install) to use a parser
for Haskell in Hugs. As far as I know the parsers
by Sven Panne and Manuel Chakravarty require ghc.
In any case, wouldn't it be a good idea to include
with each Haskell implementation a module "AST"
The Haskell 98 Report has (in 3.14):
exp -> do { stmts } (do expression)
stmts -> stmt1 ; ... ; stmtn (n>=0)
stmt -> exp
| pat <- exp
| let decls
| (empty statment)
which allows the following:
do {}
do {let x = 5}
do {x <- ret
> [EMAIL PROTECTED] (Martin Erwig) wrote,
>
> I am wondering what is the best way (in terms of
> easy-to-use and easy-to-install) to use a parser
> for Haskell in Hugs. As far as I know the parsers
> by Sven Panne and Manuel Chakravarty require ghc.
Our Haskell parser library works fine with Hu
> OK, then I'll rephrase my question: What's the rationale of throwing
> different namespaces together in the hiding clause?
Maybe they shouldn't be -- but if not, then
hiding( Ding )
would hide a type constructor or class Ding, but not a constructor Ding,
which is arguably odd. But eq
> The strange thing about this part of Haskell 98 is that given
>
> -- Baz.hs --
> module Baz where
> newtype Ding = MakeDing Int
> -- Bar.hs --
> module Bar(module Baz) where
> import Baz hiding (Ding)
>
That seems extremely reasonable. I propose to treat it as
a Haskell98 typo; it doesn't change the meaning of the language
as described by the current report, since no meaning is given
to do {} and friends.
Does anyone think there is a reason *not* to do this?
Simon
> -Original Message---
> I'm totally
> confused. What does
>
>module M1(module M2)
>import M2 hiding (H)
>...
>
> exactly mean?
The intention is this: M1 exports everything that M1 imports from M2.
Since H is not imported, it should not be exported either. It does
not make any difference whether or not
11 matches
Mail list logo
