Replacing the Prelude

[Dylan Thurston]

--uAKRQypu60I7Lcqm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, May 12, 2002 at 09:31:38PM -0700, Ashley Yakeley wrote:
> I have recently been experimenting writing code that replaces large=20
> chunks of the Prelude, compiling with -fno-implicit-prelude. I notice=20
> that I can happily redefine numeric literals simply by creating functions=
=20
> called 'fromInteger' and 'fromRational': GHC will use whatever is in=20
> scope for those names.
>=20
> I was hoping to do something similar for 'do' notation by redefining=20
> (>>), (>>=3D) etc., but unfortunately GHC is quite insistent that 'do'=20
> notation quite specifically refers to GHC.Base.Monad (i.e. Prelude.Monad,=
=20
> as the Report seems to require). I don't suppose there's any way of=20
> fooling it, is there? I was rather hoping 'do' notation would work like a=
=20
> macro in rewriting its block, and not worry about types at all.
>=20
> I accept that this might be a slightly bizarre request. There are a=20
> number of things I don't like about the way the Prelude.Monad class and=
=20
> 'do' notation are set up, and it would be nice to be able to experiment=
=20
> 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
--uAKRQypu60I7Lcqm
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE84RY2Veybfhaa3tcRAp+YAJsFfrck3zzzxDVvkYMJc4K/LPzxCACfR+ME
mQnyq/mfIjFBsMPAWVcFBzw=
=hT7O
-----END PGP SIGNATURE-----

--uAKRQypu60I7Lcqm--