Alex Jacobson wrote:
My original point (refined) was that I'd like a file extension (.ehs)
that defaults to including all extensions that don't change the meaning
of a .hs program but that may cause a small subset of them not to
compile (e.g. ones that use forall as a type variable, foreign as a
function, or 'd' as the result value of a list comprehension)
This does not seem like a major change, does not break any existing
code, and has the advantage of making it really obvious when people are
going beyond haskell98.
It'll break all sorts of things when .ehs has to get merged into .hs the
next time this conversation comes around, unless it's guaranteed that
all .hs processors will eventually be upgraded to cope with .ehs
semantics. I don't think anyone's arguing for that...
--
Alex
-Alex-
Simon Marlow wrote:
I see, all you're saying is you'd like the default to be different.
(That's not the same as saying "Extensions that change syntax are
effectively declared by the use of that syntax", which is what you
said earlier, BTW.)
Well, we could change the default. I don't think it's a great idea
personally - I think we should default to compiling whatever is the
most recent standard, i.e. Haskell 98. But you're arguing that the
proportion of Haskell 98 code that would fail to compile is relatively
small; that might well be true. This isn't a decision we could take
lightly, though.
Furthermore, it's only something we could change in 6.10, by which
time it is likely that we'll have a clearer idea of what Haskell' is,
so there might well be a -fhaskell-prime flag (or it might even be the
default).
Cheers,
Simon
Alex Jacobson wrote:
Simon, I think we've been trying to be too clever...
The simple question is: for a given extension, what is the risk of
leaving it turned on by default?
Clearly we don't want extensions turned on that causes code to
compile but with a different meaning. We may not want extensions
turned on that cause most reasonable code not to compile.
But I would say neither risk is significant in the case of most
extensions. To use your examples:
* FFI doesn't not cause h98 code to compile to a different meaning.
The worst case is that code that uses 'foreign' as a function name
doesn't compile. That seems okay in that more code probably uses FFI
than uses foreign as a function name and the user can apply a
language pragma to turn it off if really desired.
* Existential types won't cause h98 code to compile with a different
meaning. The worst case is that code that uses 'forall' as a type
variable won't compile. That seems ok....
* TemplateHaskell also not compatible with h98. The worst case is
the loss "[d|" in list comprehensions.
* MagicHash: Does not appear in the ToC or the Index of the user's
guide so should probably be turned off. I have no idea what it does.
Note, in all cases where the extension is turned on by default, there
should be a language pragma to turn it off.
-Alex-
Simon Marlow wrote:
Alex Jacobson wrote:
Simon, from what I can tell, with GHC 6.8.1, use of foreign as a
function name or forall as a type variable or leaving out a space
in a list-comprehension doesn't "parse differently" when the
relevant extensions are enabled, it causes a parse error.
>
Extensions allow the same code to parse but with different meanings
need to be declared explicitly. But, extensions that are obvious
from syntax should be allowed to be declared simply from the use of
that syntax.
So for the first example I gave,
f x y = x 3# y
the "MagicHash" extension is one that you'd require to be explicitly
declared, because the expression parses both with and without the
extension.
Now, Let's take the Template Haskell example:
f x = [d|d<-xs]
So this is valid Haskell 98, but invalid H98+TH. You would
therefore like this example to parse unambiguously as H98, correct?
But in order to do that, our parser would need arbitrary lookahead:
it can't tell whether the expression is legal H98+TH until it gets
to the '<-' in this case. Certainly it's possible to implement this
using a backtracking parser, but Haskell is supposed to be parsable
with a shift-reduce parser such as the one GHC uses. Or we could
try parsing the whole module with various combinations of extensions
turned on or off, but I'm sure you can see the problems with that.
So basically the problem is that you need a parser that parses a
strict superset of Haskell98 - and that's hard to achieve.
Cheers,
Simon
I am not taking a position here on the merits of any extensions.
-Alex-
Simon Marlow wrote:
Alex Jacobson wrote:
Extensions that change syntax are effectively declared by the use
of that syntax. If you can parse the source, then you know which
extensions it uses.
I thought we'd already established that this isn't possible. Here
are some code fragments that parse differently depending on which
extensions are enabled:
f x y = x 3# y
f x = [d|d<-xs]
foreign x = x
f :: forall -> forall -> forall
You could argue that these syntax extensions are therefore badly
designed, but that's a separate discussion.
Cheers,
Simon
-Alex-
Duncan Coutts wrote:
On Fri, 2007-11-23 at 16:26 +0100, Wolfgang Jeltsch wrote:
Am Freitag, 23. November 2007 03:37 schrieben Sie:
On Fri, 2007-11-23 at 01:50 +0100, Wolfgang Jeltsch wrote:
Dont’t just think in terms of single modules. If I have a
Cabal package,
I can declare used extensions in the Cabal file. A user can
decide not
to start building at all if he/she sees that the package uses an
extension unsupported by the compiler.
Indeed. In theory Cabal checks all the extensions declared to
be used by
the package are supported by the selected compiler. In
practise I'm not
sure how well it does this or what kind of error message we get.
The problem is, of course, that you are not forced to specify
all used extensions in the Cabal file since you can still use
language pragmas. Sometimes it is even desirable to use
LANGUAGE pragmas instead of information in the Cabal file. For
example, even if some modules use undecidable instances, I
might not want all modules of the package to be compiled with
-XUndecidableInstances since this could hide problems with my
class structure.
Our tentative plan there is to separate the extensions field
into those
used in some module, and those applied by cabal to every module.
So that
would allow you to specify a feature in one file but not all, while
still declaring to the outside world that the package uses the
feature.
As for enforcing that, that may come almost for free when we get
dependency chasing as we'll be looking for imports anyway. It
shouldn't
be much harder to look for language pragmas too.
Duncan
_______________________________________________
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
_______________________________________________
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
