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 w
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
http://www.haskell.org/mailman/listinfo/glasgow-haskell-
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. --clear-s
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 bu
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 tha
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
==
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, Lennart's
h.
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
7;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 fo
e 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.
I am not taking a position here on the merits of any extensions.
-Alex-
Simon Marlow wrote:
Alex
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 a
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 s
Yeah, since I use searchpath rather than cabal, I made searchpath
default to adding -fglasgow-exts when the "compiler" is ghc, ghci, or
runghc. Passing -fno-glasgow-exts on the command line turns this off.
-Alex-
Simon Marlow wrote:
Alex Jacobson wrote:
In any case, I'm
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 wh
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 men
wrote:
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-pat
ser manual (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: Johanne
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
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 t
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
agmas 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
exten
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 Jacobson <[EMAIL PROTECTED]
<mailto
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 to the top of your source files or
pu
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 ever
.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 fil
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
26 matches
Mail list logo
