Distribution.Simple.PreProcess could be extended to register
SearchPath as a preprocessor for .ehs files (see stuff near
PPSuffixHandler). Of course, this requires changing Cabal.
Alternately, I think the same effect could be had using Cabal's
UserHooks (see stuff near hookedPreProcessors).
That
Alex, Lennart's suggestion makes me think: Why not make SearchPath
into a preprocessor? It could recognize a .ehs extension, and then do
some very simple preprocessing (adds pragmas according to user's
settings).
--
Robin Bate Boerop
On 22/11/2007, Lennart Augustsson [EMAIL PROTECTED] wrote:
Right now I have it automatically add -glasgow-exts unless the user
explicitly turns it off. I prefer to have packages that are also cabal
compatible If there is a way to get cabal also to preprocess .ehs
correctly then we are good to go!
-Alex-
Robin Bate Boerop wrote:
Alex,
Am Dienstag, 27. November 2007 19:21 schrieb Alex Jacobson:
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?
The risk is that one thinks that one’s program is Haskell-98-compliant while
it
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
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'
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
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
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
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
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
Alex Jacobson wrote:
Ok, added as a feature request.
http://hackage.haskell.org/trac/ghc/ticket/1921#preview
this doesn't seem to say anything about perhaps let's have patchy
ad-hoc-ness
Nevertheless, patchy and ad-hoc solutions are sometimes very
convenient. I certainly agree that
Cabal is not a solution to this problem because
1. you want your code to work via ghci and runhaskell and perhaps via
searchpath.
2. you may want to move a module from one package to another and you
don't want to have to examine the cabal file to figure out how to do
that. The source file
On Fri, 2007-11-23 at 14:59 -0500, Alex Jacobson wrote:
Cabal is not a solution to this problem because
1. you want your code to work via ghci and runhaskell and perhaps via
searchpath.
2. you may want to move a module from one package to another and you
don't want to have to examine
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
Ok, added as a feature request.
http://hackage.haskell.org/trac/ghc/ticket/1921#preview
Simon Peyton-Jones wrote:
| So, my suggestion is that in any case where the compiler currently
| suggests use of a particular pragma in an error message, it should
| instead turn that pragma on and produce
Alex,
| Ok, I'm game to default to haskell98 in the presence of ambiguity, but
| in most cases the extension involves new syntax and that should be enough.
Trying to compile the program both ways (or 2^n ways) to check for ambiguity
sounds like a pretty heavy hammer to crack this nut.
GHC is
Wolfgang Jeltsch [EMAIL PROTECTED] writes:
It made me discover that I use more language extensions than I thought I was
using.
I think, it’s a good thing if you have to be clear about what extensions you
use and what you don’t use. What if someone wants to compile your code with
a
Alex Jacobson wrote:
Isn't use of the extensions detectable by the compiler?
Not always, no. Some extensions modify the syntax, such that programs
accepted with the extension turned on are not necessarily a superset of
those accepted with the extension turned off. For example: MagicHash
Alex Jacobson wrote:
In any case, I'm pretty sure the correct answer is not 50 language
pragmas with arbitrary spellings for various language features at the
top of each source file.
You probably won't like any of these, but there are many ways to avoid
writing out all the pragmas at the
Or use a preprocessor that inserts a LANGUAGE pragma. :)
On Nov 22, 2007 9:14 AM, Simon Marlow [EMAIL PROTECTED] wrote:
Alex Jacobson wrote:
In any case, I'm pretty sure the correct answer is not 50 language
pragmas with arbitrary spellings for various language features at the
top of
into the final program.
I think that the biggest limitation of this setup is managing the files
if multiple stages of pre-processing are performed.
Richard
Original Message
Subject:Re: suggestion: add a .ehs file type
Date: Thu, 22 Nov 2007 10:19:57 +
From: Lennart
It seems like use of a lot of extensions is so obvious from syntax that
the compiler is able to suggest the correct pragma to turn on to enable
that syntax. In fact the way I know to use most of these pragmas is
because the compiler told me about them.
So, my suggestion is that in any case
| So, my suggestion is that in any case where the compiler currently
| suggests use of a particular pragma in an error message, it should
| instead turn that pragma on and produce a warning.
In the cases where the compiler makes that suggestion, yes what you suggest
would be feasible I think.
Am Mittwoch, 21. November 2007 19:38 schrieb Alex Jacobson:
Isn't use of the extensions detectable by the compiler?
So you want extension inference. ;-)
[…]
In any case, I'm pretty sure the correct answer is not 50 language
pragmas with arbitrary spellings for various language features at
Am Donnerstag, 22. November 2007 02:07 schrieb Alex Jacobson:
Duncan Coutts wrote:
On Wed, 2007-11-21 at 19:26 -0500, Alex Jacobson wrote:
Ok, I'm game to default to haskell98 in the presence of ambiguity, but
in most cases the extension involves new syntax and that should be
enough.
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
Alex Jacobson wrote:
I'm fine with that as well. I'm just opposed to being force to look up
the precise names the compiler happens to use for each language
extension I happen to use. Having -fglasgow-exts turned on by default
also works.
-fglasgow-exts is a historical relic. It's just an
What about literate files? the inclusion of extended haskell files expand to
too much file extension in my opinion.
*.hs
*.lhs
*.ehs
*.elhs
On Nov 20, 2007 10:15 PM, Alex Jacobson [EMAIL PROTECTED] wrote:
.ehs stands for extended haskell and encapsulates the 90% case of people
just wanting
Am Dienstag, 20. November 2007 22:35 schrieb Alex Jacobson:
[…]
{-# LANGUAGE TemplateHaskell, FlexibleInstances,
OverlappingInstances, UndecidableInstances, CPP,
ScopedTypeVariables, PatternSignatures, GADTs,
PolymorphicComponents, FlexibleContexts,
Alex Jacobson wrote:
[...][ 50 language pragmas with arbitrary spellings [...]
Indeed.
For instance, I always get an error for -XMultiParameterTypeClasses .
(Without looking at the documentation: do you see why?)
PS: indeed I just checked the docs and found -XDisambiguateRecordFields
Was
Isn't use of the extensions detectable by the compiler?
If so, then forcing the user manually to enumerate them at the top of a
source file seems like forcing the user to write a lot of unnecessary
boilerplate. It seems preferable for the compiler ny default just to
issue warnings about what
Wolfgang Jeltsch wrote:
It made me discover that I use more language extensions than I thought I was
using.
yes, it is likely that many of those extensions are in so many people's
codes that they are de-facto standards whether they have been written
into a specification document or not.
I
So what is DisambiguateRecordFields?
-Alex-
Johannes Waldmann wrote:
Alex Jacobson wrote:
[...][ 50 language pragmas with arbitrary spellings [...]
Indeed.
For instance, I always get an error for -XMultiParameterTypeClasses .
(Without looking at the documentation: do you see why?)
PS:
] On Behalf Of Alex Jacobson
| Sent: 21 November 2007 20:26
| To: Johannes Waldmann
| Cc: glasgow-haskell-users@haskell.org; Simon Marlow
| Subject: Re: suggestion: add a .ehs file type
|
| So what is DisambiguateRecordFields?
|
| -Alex-
|
| Johannes Waldmann wrote:
| Alex Jacobson wrote
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alex Jacobson wrote:
So what is DisambiguateRecordFields?
http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#disambiguate-fields
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with
On Wed, Nov 21, 2007 at 07:55:51PM +0100, Johannes Waldmann wrote:
PS: indeed I just checked the docs and found -XDisambiguateRecordFields
Was this advertized?
It's in the 6.8.1 release notes (well, the -fdisambiguate-record-fields
flag is, but we should have advertised
On Wed, 2007-11-21 at 15:03 -0500, Alex Jacobson wrote:
Proof that the compiler knows which extensions are being used: it can
compile the program sucessfully when the extension is turned on and not
otherwise.
Counterexample (not my own):
http://hpaste.org/3855
{-# OPTIONS_GHC
Ok, I'm game to default to haskell98 in the presence of ambiguity, but
in most cases the extension involves new syntax and that should be enough.
Note: I would also argue that extensions that change the meaning of old
code are prime-facie a bad idea. It means that, if you start using the
new
On Wed, 2007-11-21 at 19:26 -0500, Alex Jacobson wrote:
Ok, I'm game to default to haskell98 in the presence of ambiguity, but
in most cases the extension involves new syntax and that should be enough.
In these cases ghc does generally give an error message which mentions
which extension it is
Duncan Coutts wrote:
On Wed, 2007-11-21 at 19:26 -0500, Alex Jacobson wrote:
Ok, I'm game to default to haskell98 in the presence of ambiguity, but
in most cases the extension involves new syntax and that should be enough.
In these cases ghc does generally give an error message which mentions
.ehs stands for extended haskell and encapsulates the 90% case of people
just wanting -fglasgow-exts with a minimum of fuss.
Having a filetype seesm better than the alternatives of either adding
boilerplate language/options pragmas to the top of your source files or
putting them in a cabal
Hi Alex,
.ehs stands for extended haskell and encapsulates the 90% case of people
just wanting -fglasgow-exts with a minimum of fuss.
That goes against the general GHC direction of trying to wean people
off -fglasgow-exts and on to more specific language pragmas.
Thanks
Neil
If you take away -fglasgow-exts, then you force me to have to look up
the exact name of each language extension I use every time I want to use
it. Since that is annoying and breaks flow, the simpler answer is just
to put a big honking language pragma at the top of all my source files
with
Am Dienstag, 20. November 2007 22:15 schrieb Alex Jacobson:
.ehs stands for extended haskell and encapsulates the 90% case of people
just wanting -fglasgow-exts with a minimum of fuss.
Having a filetype seesm better than the alternatives of either adding
boilerplate language/options pragmas
I'm fine with that as well. I'm just opposed to being force to look up
the precise names the compiler happens to use for each language
extension I happen to use. Having -fglasgow-exts turned on by default
also works.
-Alex-
Wolfgang Jeltsch wrote:
Am Dienstag, 20. November 2007 22:15
I'm very much in favor of listing the exact extensions used in each file,
because I try to keep them to a minimum.
I would like to see a LANGUAGE Haskell' which includes the things that are
likely to be in Haskell' (if there is ever a Haskell').
-- Lennart
On Nov 20, 2007 9:42 PM, Alex
For people like Lennart, perhaps the correct answer is a compiler flag
that enumerates the extensions used as a warning. The warning should be
enough to help him keep the extensions to a minimum.
-Alex-
Lennart Augustsson wrote:
I'm very much in favor of listing the exact extensions used
48 matches
Mail list logo
