Re: replacing the Prelude (again)
On Tue, Jul 16, 2002 at 04:02:44PM +1000, Bernard James POPE wrote: I would like to use do-notation in the transformed program, but have it refer to Prelude.Monad and not MyPrelude.Monad which is also in scope. Why do you have a MyPrelude.Monad (different from Prelude.Monad) if you don't want to use it? --Dylan msg03803/pgp0.pgp Description: PGP signature
RE: replacing the Prelude (again)
|Ambiguities in the class Num are most common, so Haskell | provides another |way to resolve them---with a default declaration: |default (t1 , ... , tn) |where n=0, and each ti must be a monotype for which Num ti holds. | ^^ |In situations where an ambiguous type is discovered, an | ambiguous type |variable is defaultable if at least one of its classes is | a numeric class |(that is, Num or a subclass of Num) and if all of its | classes are defined | ^ |in the Prelude or a standard library | ^ |Each defaultable variable is replaced by the first type in | the default list |that is an instance of all the ambiguous variable's | classes. It is a |static error if no such type is found. | | Do these become whatever Num is in scope when I use | -fno-implicit-prelude, and whatever classes from standard | libraries are in scope? If they don't then I think I'm in a pickle. I confess that I had forgotten about this. It's not easy to see what a good alternative design would be... I suppose it could be whatever Num is in scope or a subclass thereof, but what would correspond to defined in the Prelude or a standard lib? An alternative would be to drop the rule altogether with -fno-implicit-prelude and let all ambiguous types be defaulted with the specified list of types. The motivation for the rules as stated is to avoid excessive defaulting, which silently affects the meaning of your program. As you say, the absence of an obvious design point means I'm unlikely to fiddle just now. If a consensus emerges (and it's not to hard to do) I'd be willing to fiddle, though. Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: replacing the Prelude (again)
I'm fond of the idea proposed by Marcin 'Qrczak' Kowalczyk: | May I propose an alternative way of specifying an alternative Prelude? | Instead of having a command line switch, let's say that 3 always means | Prelude.fromInteger 3 - for any *module Prelude* which is in scope! That's a perfectly reasonable idea, but GHC can't make it the default because it's not H98. It *would* be possible to make GHC's -fno-implicit-prelude flag mean that 3 means Prelude.fromInteger 3 rather than fromInteger 3 I quite like the fact that you would then have to say import MyPrelude as Prelude thereby stressing that you are importing the Prelude stuff. But it would be that *plus* -fno-implicit-prelude, I'm afraid. If there were a consensus in favour of this I'll gladly do it (5 min job). | anymore. What I would like is that the defualting rules refer | to the classes in my version of the Prelude, | not the Standard Prelude. You can always get that (with the -fno-implicit-prelude thing) by adding default [Int, Double] or whatever to your source module, just after the import that gets your new standard Prelude. Doesn't that do it? It would also not be hard to arrange that the default default declaration became scoped with -fno-implicit-prelude (like fromInteger), if that was useful. It's a good point; I thought that *all* the numeric stuff was un-coupled from the Prelude with -fno-implicit-prelude, but it isn't quite. Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: replacing the Prelude (again)
At 2002-07-15 01:05, Simon Peyton-Jones wrote: I quite like the fact that you would then have to say import MyPrelude as Prelude thereby stressing that you are importing the Prelude stuff. Doesn't this assume your Prelude stuff is all in one module? Or can you import several modules as Prelude? As a Prelude-replacer, my preference is rather towards keeping it as it is... it seems a bit simpler and easier to understand. -- Ashley Yakeley, Seattle WA ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: replacing the Prelude (again)
| anymore. What I would like is that the defualting rules refer
| to the classes in my version of the Prelude,
| not the Standard Prelude.
You can always get that (with the -fno-implicit-prelude thing) by adding
default [Int, Double]
or whatever to your source module, just after the import that gets your
new standard Prelude. Doesn't that do it?
We came across the same problem in the Hat tracer (which is also a
source-to-source transformation, and can also be used for debugging).
The problem is that the transformation introduces new classes, so
Prelude.Ord - HatPrelude.Ord
Prelude.Eq - HatPrelude.Eq
Prelude.Num - HatPrelude.Num
The defaulting mechanism *only* applies to types constrained by
the original builtin Prelude.Num, not to the transformed class
HatPrelude.Num.
I think you are saying that if we
import HatPrelude as Prelude
together with -fno-implicit-prelude in GHC, then defaulting should work
over the HatPrelude classes rather than the Prelude ones?
Unfortunately, in Hat at least, we continue to use the original
Prelude in *addition* to the replacement HatPrelude. So how would
defaulting work in the following?
{-# -fno-implicit-prelude #-}
import Prelude as Original
import HatPrelude as Prelude
default (Integer,Double)
Regards,
Malcolm
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: replacing the Prelude (again)
Hi All, Thanks to everyone for their comments. I can see that this is quite a difficult design problem, and it is unlikely that one solution will please everyone, which makes me think that the current solution will probably stand. Simon Peyton-Jones writes: Bernie writes: | anymore. What I would like is that the defualting rules refer | to the classes in my version of the Prelude, | not the Standard Prelude. You can always get that (with the -fno-implicit-prelude thing) by adding default [Int, Double] or whatever to your source module, just after the import that gets your new standard Prelude. Doesn't that do it? I'll get back to you on this soon. It would also not be hard to arrange that the default default declaration became scoped with -fno-implicit-prelude (like fromInteger), if that was useful. That sounds a lot like what I would like to have, but I'm probably being selfish here. It's a good point; I thought that *all* the numeric stuff was un-coupled from the Prelude with -fno-implicit-prelude, but it isn't quite. What I would like to know is the semantics of -fno-implicit-prelude with respect to this bit from the Haskell Report: 4.3.4 Ambiguous Types, and Defaults for Overloaded Numeric Operations Ambiguities in the class Num are most common, so Haskell provides another way to resolve them---with a default declaration: default (t1 , ... , tn) where n=0, and each ti must be a monotype for which Num ti holds. ^^ In situations where an ambiguous type is discovered, an ambiguous type variable is defaultable if at least one of its classes is a numeric class (that is, Num or a subclass of Num) and if all of its classes are defined ^ in the Prelude or a standard library ^ Each defaultable variable is replaced by the first type in the default list that is an instance of all the ambiguous variable's classes. It is a static error if no such type is found. Do these become whatever Num is in scope when I use -fno-implicit-prelude, and whatever classes from standard libraries are in scope? If they don't then I think I'm in a pickle. Ooroo, Bernie. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: replacing the Prelude (again)
Hi again, Malcolm writes: We came across the same problem in the Hat tracer (which is also a source-to-source transformation, and can also be used for debugging). The problem is that the transformation introduces new classes, so Prelude.Ord - HatPrelude.Ord Prelude.Eq - HatPrelude.Eq Prelude.Num - HatPrelude.Num The defaulting mechanism *only* applies to types constrained by the original builtin Prelude.Num, not to the transformed class HatPrelude.Num. I did wonder how Hat tackled this. Out of curiosity what is the solution that Hat uses? And what is the situation in nhc98? I think you are saying that if we import HatPrelude as Prelude together with -fno-implicit-prelude in GHC, then defaulting should work over the HatPrelude classes rather than the Prelude ones? That's what I had hoped for. Unfortunately, in Hat at least, we continue to use the original Prelude in *addition* to the replacement HatPrelude. This adds an extra element of difficulty to the problem. I am trying my hardest to avoid needing the to import the original Prelude in a transformed module - this requires quite a bit of desugaring in the transformation. Still, I would like to be able to use do notation and have it refer to Prelude.Monad, not MyPrelude.Monad. I can live without it of course. For what reasons do you require the original prelude? Cheers, Bernie. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: replacing the Prelude (again)
The defaulting mechanism *only* applies to types constrained by the original builtin Prelude.Num, not to the transformed class HatPrelude.Num. I did wonder how Hat tackled this. Out of curiosity what is the solution that Hat uses? Hat doesn't have a solution. When the lack of correct defaulting causes Hat to generate type-incorrect code, the underlying compiler will complain vociferously. Our advice to users is to write `default ()' at the top of the module, then resolve the type errors they get from the normal compilation so that defaulting is completely eliminated. The code will then go through Hat smoothly. It isn't very satisfactory, but in practice, defaulting doesn't really occur very often, so it isn't too much of a hardship. Ideally, the solution is a language design issue. Defaults are currently very implicit, second-class things. It would be much better if we could have a more generalised defaulting mechanism, applicable to any class. For instance default Num (Integer, Double) default Monad (IO) default MyClass (MyType) or something - at the least an association of a set of types with a named class. Maybe more is required. This adds an extra element of difficulty to the problem. I am trying my hardest to avoid needing the to import the original Prelude in a transformed module - this requires quite a bit of desugaring in the transformation. For what reasons do you require the original prelude? Exactly the same reasons. We want to do as little desugaring as necessary in the transformation, so inevitably we need at least a small part of the Prelude in scope. Regards, Malcolm ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: replacing the Prelude (again)
Malcolm writes: Bernie writes: I did wonder how Hat tackled this. Out of curiosity what is the solution that Hat uses? Hat doesn't have a solution. When the lack of correct defaulting causes Hat to generate type-incorrect code, the underlying compiler will complain vociferously. Our advice to users is to write `default ()' at the top of the module, then resolve the type errors they get from the normal compilation so that defaulting is completely eliminated. The code will then go through Hat smoothly. It isn't very satisfactory, but in practice, defaulting doesn't really occur very often, so it isn't too much of a hardship. That was going to be my fallback strategy, I'm glad I'm not the only one! This adds an extra element of difficulty to the problem. I am trying my hardest to avoid needing the to import the original Prelude in a transformed module - this requires quite a bit of desugaring in the transformation. For what reasons do you require the original prelude? Exactly the same reasons. We want to do as little desugaring as necessary in the transformation, so inevitably we need at least a small part of the Prelude in scope. I would like to use do-notation in the transformed program, but have it refer to Prelude.Monad and not MyPrelude.Monad which is also in scope. The reason I mention this is that the behviour of -fno-implicit-prelude seems to have changed with respect to desugaring do notation, at least according to this post from Simon Peyton-Jones: http://www.haskell.org/pipermail/glasgow-haskell-users/2002-July/003688.html In the upcoming 5.04 release you'll be able to do exactly that. GHC will use whatever = is in scope if you say -fno-implicit-prelude. Sure I can always get by without do notation, but the transformed program is then a lot uglier and harder to comprehend. Does hat work with ghc 5.04? Cheers, Bernie. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Replacing the Prelude
Ping!
At 2002-05-14 07:17, Simon Peyton-Jones wrote:
Ashley writes
| I was hoping to do something similar for 'do' notation by redefining
| (), (=) etc., but unfortunately GHC is quite insistent
| that 'do' notation quite specifically refers to GHC.Base.Monad
Dylan replies
| I'm surprised that ghc uses the fromInteger and fromRational
| that are in scope; I thought there was general agreement that
| it should use the Prelude.from{Integer,Rational} in scope.
Ashley is referring to a GHC extension. Normally, GHC uses
Prelude.fromInteger etc, regardless of what is in scope. But if you
say -fno-implicit-prelude, GHC will instead use whatver fromInteger
is in scope. (This is documented in the manual.)
Ashley's question, as I understand is whether something similar
could be done for monads.
Answer: I think so, without much bother. I'm beavering away on
a Haskell workshop paper at the moment, but ping me in a fortnight
to do it.
Simon
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Replacing the Prelude
On Sun, May 12, 2002 at 09:31:38PM -0700, Ashley Yakeley wrote:
I have recently been experimenting writing code that replaces large
chunks of the Prelude, compiling with -fno-implicit-prelude. I notice
that I can happily redefine numeric literals simply by creating functions
called 'fromInteger' and 'fromRational': GHC will use whatever is in
scope for those names.
I was hoping to do something similar for 'do' notation by redefining
(), (=) etc., but unfortunately GHC is quite insistent that 'do'
notation quite specifically refers to GHC.Base.Monad (i.e. Prelude.Monad,
as the Report seems to require). I don't suppose there's any way of
fooling it, is there? I was rather hoping 'do' notation would work like a
macro in rewriting its block, and not worry about types at all.
I accept that this might be a slightly bizarre request. There are a
number of things I don't like about the way the Prelude.Monad class and
'do' notation are set up, and it would be nice to be able to experiment
with alternatives.
A while ago, there were extensive discussions about replacing the
Prelude on this list. (Search for Prelude shenanigans.) I started
to write up a design document for how to enable replacing the Prelude.
This boiled down to taking most of the syntactic sugar defined in
the report seriously, ignoring the types (as you say).
I'm surprised that ghc uses the fromInteger and fromRational that are
in scope; I thought there was general agreement that it should use the
Prelude.from{Integer,Rational} in scope.
As I recall, there were several relevant bits of syntactic sugar:
- Numeric types, including 'fromInteger', 'fromRational', and
'negate'. This all works fine, except that the defaulting mechanism
is completely broken, causing a number of headaches.
- Monads. The translation given in the report is clean, and it seems
like it can be used without problems.
- Bools. There was a slight problem here: the expansion of
'if ... then ... else ...' uses a case construct referring to the
constructors of the Bool type, which prevents any useful
redefinition of Bool. I would propose using a new function,
'Prelude.ifThenElse', if there is one in scope.
- Enumerations. Clean syntactic sugar.
- List comprehensions. The report gives one translation, but I think
I might prefer a translation into monads.
- Lists and tuples more generally. At some point the translations
start getting too hairy; I think I decided that lists and tuples
were too deeply intertwined into the language to change cleanly.
I'll dig up my old notes and write more, and then maybe write a
complete design document and get someone to implement it.
--Dylan Thurston
msg03485/pgp0.pgp
Description: PGP signature
RE: Replacing the Prelude
Ashley writes
| I was hoping to do something similar for 'do' notation by redefining
| (), (=) etc., but unfortunately GHC is quite insistent
| that 'do' notation quite specifically refers to GHC.Base.Monad
Dylan replies
| I'm surprised that ghc uses the fromInteger and fromRational
| that are in scope; I thought there was general agreement that
| it should use the Prelude.from{Integer,Rational} in scope.
Ashley is referring to a GHC extension. Normally, GHC uses
Prelude.fromInteger etc, regardless of what is in scope. But if you
say -fno-implicit-prelude, GHC will instead use whatver fromInteger
is in scope. (This is documented in the manual.)
Ashley's question, as I understand is whether something similar
could be done for monads.
Answer: I think so, without much bother. I'm beavering away on
a Haskell workshop paper at the moment, but ping me in a fortnight
to do it.
Simon
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
