1. just using : at the prompt caused a reload. Now you have to type :r.
2. reload now reloads all modules rather than just the modules that
changed (faster but not as fast as not reloading them at all).
-Alex-
___
Glasgow-haskell-users mailing list
.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
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
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 to the top of your source files or
putting them
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 Jacobson [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote
with arbitrary spellings for various language features at the
top of each source file.
-Alex-
Simon Marlow wrote:
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
Simon Marlow wrote:
Alex Jacobson wrote:
1. just using : at the prompt caused a reload. Now you have to type :r.
Interesting, I was not aware of that behaviour, so probably fixed it by
accident :)
Yeah, Igloo said the same thing. Everyone I talked to about the feature
didn't know about
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
(for the HEAD):
http://www.haskell.org/ghc/dist/current/docs/users_guide/syntax-extns.html#disambiguate-fields
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:glasgow-haskell-
| [EMAIL PROTECTED] On Behalf Of Alex Jacobson
| Sent: 21 November 2007 20:26
| To: Johannes Waldmann
:
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 -fbang-patterns
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
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
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
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
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.
I am not taking a position here on the merits of any extensions.
-Alex-
Simon Marlow wrote:
Alex Jacobson wrote
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
, 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
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,
Will this also work with Tiger or do I have to upgrade?
-Alex-
Manuel M T Chakravarty wrote:
Ian Lynagh wrote:
=
The (Interactive) Glasgow Haskell Compiler -- version 6.8.2
I just built from source on Tiger fine.
-Alex-
Christian Maeder wrote:
Manuel M T Chakravarty wrote:
Alex Jacobson:
Will this also work with Tiger or do I have to upgrade?
it will not work on Tiger
I don't know. I have no box with Tiger to test. Give it a try. The
worst that can
My experience with the mac stuff is that you are just better off
building everything yourself. It runs in the background while you go
eat dinner and then you are done.
-Alex-
Hugo Pacheco wrote:
The binaries do work in Leopard, but it misses all library files, such
as System.IO.
How can I
The current docs use -i without any arguments to reset the path back to
[]. That is an interesting feature but it is much less useful than
being able to use shell based tab completion when entering command line
options. I suggest that the -i reset feature be removed in favor of
e.g.
Right now, if you recompile with --make, the exeutable gets a new
timestamp. That seems incorrect. Is this a bug?
-Alex-
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
I think this was a bug on my part. Some file was getting touched that I
wasn't aware of. Sorry.
-Alex-
Simon Marlow wrote:
Alex Jacobson wrote:
Right now, if you recompile with --make, the exeutable gets a new
timestamp. That seems incorrect. Is this a bug?
If the executable was re
25 matches
Mail list logo
