On 21-May-2000, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
> Sat, 20 May 2000 13:13:22 -0700, Simon Peyton-Jones <[EMAIL PROTECTED]> pisze:
>
> > Explicit lists [a,b,c]
> > List comprehensions
> > Numeric constants (1 means 'fromInteger 1')
> > do notation
> >
> > Here is an idea for an extension to Haskell 98 to support this.
> [...]
>
> It has small problems (and IMHO nobody should need to replace the
> list type etc.).
>
> What about string literals - do they refer to Prelude list type or
> the replacement?
For consistency, I would recommend the latter.
> The first is a bit inconsistent, the second does
> not allow optimizations.
Why do you say the second does not allow optimizations?
Surely the compiler can perform exactly the same optimizations,
if it just makes those optimizations conditional on this feature
not being used. If you don't use the feature, you don't pay for it!
Of course a compiler could also do better, and perform the same
kind of optimizations even if an alternative prelude was used,
so long as those optimizations still make sense. That might be a
little more difficult to implement, since the optimizations would have
to be done in a slightly more general way. But I don't see it
as being infeasible.
> If list comprehensions are translated literally as the report says,
> they don't allow optimizations too, unless the compiler is smart
> enough to optimize the translation. Currently GHC does not optimize
> concatMap (\x -> [x]) into identity.
The issue here is the same. GHC can do exactly the same optimizations
it currently does, if it just makes them conditional on this feature
(the `{#- SYNTAX -#}' pragma, or whatever syntax is chosen for it)
not being used. If the feature is used, then it would have to use
the translation in the report, and then optimization might be a bit
harder; but optimization is still possible, it's just a quality of
implementation issue.
> If the programmer says:
> data [a] = () | a:[a]
> data () = []
> is [1,2,3] a type error (because it gets translated to 1:2:3:[])?
>
> If he says:
> data X = Int:Stop
> data Stop = []
> is [1] permitted?
>
> Is this permitted:
> type (,) = Prelude.[]
> type [] = Either
> f :: (,) ([Int] String)
> f = [Left 5, Right "foo"]
So far no-one has proposed allowing special symbols such as `[]',
`()', or `:' in definitions -- only in import and export lists.
So with the current proposals, those examples would all be
syntax errors.
Unless someone can suggest a good reason why there would be some
benefit in allowing people to define those symbols, I see no reason to
do so. But being able to import and/or re-export such symbols is
necessary if you want to be able to implement an alternative prelude.
> Must the type of Main.main be Prelude.IO something, or it can be a
> replacement of IO? The latter does not have a semantics, so it must
> be the former.
Right. But an alternative prelude could define a function
run :: AltPrelude.ReplacementForIO t -> Prelude.IO t
and then `main' could be defined using `run'
main = run (...)
so I don't see that as being a problem.
--
Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
