Re: [Haskell] recursive deriving
This seems very, very wrong. The missing instance(s) might be left out because of some good reason (e.g. if you have implemented sets with list and not provided Ord). On Nov 21, 2007 12:59 AM, Duncan Coutts [EMAIL PROTECTED] wrote: On Tue, 2007-11-20 at 19:18 -0500, Alex Jacobson wrote: When you want automated deriving of show/read etc., you need all the components of your type also to be instances of show/read but you won't want to *require* them to be automatically generated verions. Standalone deriving does the wrong thing here. Standalone deriving should not cause an overlapping instance error if someone derives an instance manually. Instead, the manually derived instance should be treated as more specific and win out. The other part of this problem is that you can't do automatic recursive deriving and this results in a ridiculous amount of boilerplate. I know some people have a theory that they want to avoid accidentally creating instances for things that shouldn't have them, but the solution to that is probably to add some declaration for types that prohibits automatic deriving for those types. The 99% case is that automatic deriving is ok. Proposed syntax: derive instance Show T recursively data T = T no-deriving (Ord,Eq) I would expect that if the data constructor for T is not exported then standalone deriving should not work. However this appears not to be the case which breaks module abstraction. Foo.hs: module Foo ( T, t ) where data T = T t = T Bar.hs: import Foo deriving instance Eq T $ ghci Bar.hs -XStandaloneDeriving [1 of 2] Compiling Bar ( Bar.hs, interpreted ) [2 of 2] Compiling Main ( Baz.hs, interpreted ) Ok, modules loaded: Bar, Main. *Main t == t True You could write that Eq instance by hand since they do not have access to the T constructor, then StandaloneDeriving should not be able to so either. I think it's a design flaw in standalone deriving. Does anyone else agree? Should we file a bug report? Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc 6.8.1 windows link issue ?
Fernand wrote: Fernand a écrit : Dear all, Giving a try to GHC 6.8.1 under Windows, I stumble upon the following issue (yes, I'm struggling with HDirect), which did not occur with the 6.6 version : the linking phase of my project fails with Actually, the issue appears with the following program : module Oops where import Data.Graph ds_groups :: [SCC String] ds_groups = stronglyConnComp ([] :: [(String, Int, [Int])]) main = do putStrLn Oops! return () $ C:/ghc/ghc-6.8.1/bin/ghc.exe -main-is Oops Oops.hs -o oops.exe Oops.o(.text+0x46):fake: undefined reference to `containerszm0zi1zi0zi0_DataziGraph_stronglyConnComp_closure' Oops.o(.text+0x2db):fake: undefined reference to `__stginit_containerszm0zi1zi0zi0_DataziGraph_' Oops.o(.data+0x0):fake: undefined reference to `containerszm0zi1zi0zi0_DataziGraph_stronglyConnComp_closure' collect2: ld returned 1 exit status Compiling that same program with GHC-6.6 (same command line) works fine. Do I need to submit a bug or did something changed in the librairies' structure that I missed somewhere ? You haven't told GHC that you want to link the containers package. Try adding -package containers, or using --make which does this automatically. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci changes in 6.8 that are not improvements
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 :) 2. reload now reloads all modules rather than just the modules that changed (faster but not as fast as not reloading them at all). That is certainly not intentional, and I don't see that behaviour here. Can you give us code and steps to reproduce? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: suggestion: add a .ehs file type
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 arbitrary collection of
extensions. It doesn't contain all the extensions provided by GHC, as many
of them steal syntax and you probably don't want them all on at the same
time. We're trying to move away from -fglasgow-exts, which is why GHC
6.8.1 provides separate flags for all the extensions we provide.
Eventually we'll have a new standard (Haskell' or whatever) that will
collect many of the extensions together, so you'll just have to write {-#
LANGUAGE Haskell' #-}.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc 6.8.1 windows link issue ?
Simon Marlow a écrit : Compiling that same program with GHC-6.6 (same command line) works fine. Do I need to submit a bug or did something changed in the librairies' structure that I missed somewhere ? You haven't told GHC that you want to link the containers package. Try adding -package containers, or using --make which does this automatically. Cheers, Simon Hello, Thank you. Indeed, I found the answer too this morning. Sorry for the bandwidth. BTW, my patched HDirect compiles with GHC 6.8.1, though I still have some strange behavior with typelibs support (Excel automation works fine, but I cannot manage to have Word to work ; I desesperately get « unsupported interface » errors, whatever I try). Sincerely yours, sL ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: single-stepping and infinite recursion
Hi Wolfgang, you are right, this behaviour is a bit surprising. What you want to observe can be obtained with, for example: loop c = putChar c loop c where loop is not a CAF anymore since it takes an argument. In the definition that you gave, main is a CAF and gets evaluated only the first time. The subsequent times it is entered do not trigger any further evaluation: the IO action is already evaluated and the only thing left to do is execute it. This does not trigger a breakpoint since no evaluation proper is done. For more information about CAFs see http://haskell.org/haskellwiki/Constant_applicative_form That page remarks that CAFs are an optimization which does not alter referential transparency. Unfortunately their special behaviour is highlighted by the ghci debugger. If you want to find the reason for an infinite loop: 1. enable the flag -fbreak-on-error 2. run your expression with :trace (eg :trace loop 'a') 3. hit Ctrl-C while your program is stuck in the loop to have the debugger break in the loop. 4: use :history and :back to find out where the loop is located and why. Cheers pepe On 20/11/2007, at 16:09, Wolfgang Jeltsch wrote: Hello, please consider the following program: main = putChar 'A' main I load this into GHCi, enter :step main, followed by :step and a second :step. Although I would expect to get the As in the output step by step, GHCi now hangs inside the infinite loop. Is this intentional? To me, this seems rather weird. I wanted to use GHCi’s debugger to find the reason for an infinite recursion but from my experience it looks as if this might not be possible. :-( Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: suggestion: add a .ehs file type
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 -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 file. -Alex- ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Luis Cabellos, http://malcodigo.blogspot.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
if-them_else
Dear GHC developers, when compiling the function f x = if x them False else True ghc-8.8.1 reports:parse error on input `else' . When there is a large expession after `them', it is sometimes difficult to locate a typo. Why does not it report parsing if-then-else: cannot find `then' ? Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: if-them_else
Maybe it's from Chicago and doesn't see anything wrong with them in that context. :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Serge D. Mechveliani Sent: Wednesday, November 21, 2007 9:04 AM To: glasgow-haskell-users@haskell.org Subject: if-them_else Dear GHC developers, when compiling the function f x = if x them False else True ghc-8.8.1 reports:parse error on input `else' . When there is a large expession after `them', it is sometimes difficult to locate a typo. Why does not it report parsing if-then-else: cannot find `then' ? Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC 6.8.1 and HDirect
Hi dear fellow ghc users, I simply wanted to let people know that I apparently succeeded in compiling a patched version of HDirect with GHC 6.8.1 (with typelibs support). At least, I could compile some of the examples and had very simple test programs launch/connect to Word and Excel using automation. I lack time to really clean up the library (I did not made any Cabal patch and currently directly link with the « .a » and « .o » of the various modules), but feel free to contact me if you need some help to use hdirect with GHC 6.8.1. Sincerely yours, sL ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: suggestion: add a .ehs file type
Am Dienstag, 20. November 2007 22:35 schrieb Alex Jacobson:
[…]
{-# LANGUAGE TemplateHaskell, FlexibleInstances,
OverlappingInstances, UndecidableInstances, CPP,
ScopedTypeVariables, PatternSignatures, GADTs,
PolymorphicComponents, FlexibleContexts,
MultiParamTypeClasses, DeriveDataTypeable,
PatternGuards #-}
FYI, I grabbed the above from a source file that had been upgraded to
6.8 in which I kept adding pragmas until it compiled. Forcing the user
to do this sort of thing manually every time they write code is
ridiculous.
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 different compiler which doesn’t support all of GHC’s extensions?
Taken to its logical conclusion, why don't we also add RecordSyntax
and DoSyntax etc.
Because they are part of the standard. If Haskell' will be released at some
point in the future, we won’t have to include MultiParamTypeClasses,
Concurrency, etc. into our LANGUAGE pragmas.
The compiler obviously knows which extensions are actually being used
when the user uses them.
I don’t think so. For example, if you don’t use rank-2 polymorphism and
similar things, forall is a perfect name for a type variable.
[…]
-Alex-
Best wishes,
Wolfgang
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: if-them_else
Am Mittwoch, 21. November 2007 15:03 schrieb Serge D. Mechveliani: Dear GHC developers, when compiling the function f x = if x them False else True ghc-8.8.1 reports:parse error on input `else' . When there is a large expession after `them', it is sometimes difficult to locate a typo. Why does not it report parsing if-then-else: cannot find `then' ? Regards, them is a perfect identifier. So probably x them False gets parsed as an expression (x applied to them and the result applied to False). Haskell’s lightweight syntax makes programs short and easy to read (in my opinion) but it often makes the compiler unable to guess where your mistake lies. Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.8.1 on Mac OS X 10.5 (Leopard)
Simon Marlow wrote: Christian Maeder wrote: #!/bin/sh reldir=`dirname $0` topdir=`(cd $reldir; pwd)` There's no guarantee that $0 holds anything reasonable: you can set $0 to whatever you like when calling exec*(). The above script simply does not work, if it is linked to from another place. (I don't know if that's related to exec, but I see the problem now.) Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc/haskell tool registry
Claus Reinke wrote: registry sounds like overkill to me. If really an absolute hardcoded path is needed, I would appreciate if it is stored only in a single place (for ghc, ghci, ghc-pkg and package.conf). that was my point: how do you find that 'single place', given the wide variety of versions, platforms, packagers, installation-specific availability, ..? the only half-way portable solution (without a special case for every platform) i can think of is a program in PATH. we don't always keep all versions of ghc tools in PATH, but we need one single tool to bind them all..;-) as long as that tool can be found in PATH, it can serve as a mediator/abstract interface for finding everything else, independent of platform. Other tools have a relocate script, that only changes that location after unpacking (or move). think of 'ghc-tools' as the guardian for your 'single place' and of 'ghc-tools relocate' as your relocate script. I think `ghc-pkg` should play this central role, that must in the PATH and knows the package.conf location. So ghc (or the ghc wrapper) must call ghc-pkg for the package.conf file (ghci could simply call ghc, like runghc does call ghc) Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: suggestion: add a .ehs file type
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 this advertized? It seems that's what I've been missing for years. Best regards, Johannes. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: suggestion: add a .ehs file type
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 extensions are used. Then the person doing
the compiling can decide to modify code not to use those features, to
add pragmas so as not to cause warning, or to add compiler flags that
tells it not to issue them.
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.
-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. Having -fglasgow-exts turned on by default
also works.
-fglasgow-exts is a historical relic. It's just an arbitrary collection
of extensions. It doesn't contain all the extensions provided by GHC,
as many of them steal syntax and you probably don't want them all on at
the same time. We're trying to move away from -fglasgow-exts, which is
why GHC 6.8.1 provides separate flags for all the extensions we provide.
Eventually we'll have a new standard (Haskell' or whatever) that will
collect many of the extensions together, so you'll just have to write
{-# LANGUAGE Haskell' #-}.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci changing 'm' to 'g'
On Nov 21, 2007 1:07 PM, Greg Fitzgerald [EMAIL PROTECTED] wrote: Running 6.8.1 on Windows XP, typing 'main' while :r is still processing causes the 'm' in 'main' to morph to a 'g'. :r [1 of 2] Compiling Language.QidlTypeLibrary.Parser ( Language/QidlTypeLibrary/Parser.hs, interpreted ) Ok, modules loaded: Main, Language.QidlTypeLibrary.Parser. main interactive:1:0: Not in scope: `gain' Thanks, Greg What a weird bug. It sounds like a joke but it isn't one. I just reproduced it (also works with :l). P:\5. Tools\Cleansing\CustomerMasterghci GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude :l CustomerMaster.hs [1 of 1] Compiling Main ( CustomerMaster.hs, interpreted ) Ok, modules loaded: Main. *Main main interactive:1:0: Not in scope: `gain' I wonder if it's a Windows only bug. Cheers, Olivier. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
HUnit 1.2.0.0 on 6.8.1 vs 1.1.1 on 6.6.1
On Windows, HUnit's assertions are not working - trace below in ghci 6.8.1and 6.6.1. Can others reproduce? Is this the right place to report bugs? Should I confirm a bug here and then create a ticket, create a ticket and that's it, or just mention it here and someone else creates a ticket? GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. :m Test.HUnit abc @=? efg Loading package HUnit-1.2.0.0 ... linking ... done. *** Exception: (unknown) ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. :m Test.HUnit abc @=? efg Loading package HUnit-1.1.1 ... linking ... done. *** Exception: user error (HUnit:expected: abc but got: efg) Thanks, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci changes in 6.8 that are not improvements
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 it until I pointed it out. If it was an accident, it was still a really useful feature and would love to have it back. 2. reload now reloads all modules rather than just the modules that changed (faster but not as fast as not reloading them at all). That is certainly not intentional, and I don't see that behaviour here. Can you give us code and steps to reproduce? $ darcs get http://happs.org/HAppS-Begin $ cd HAppS-Begin $ curl http://searchpath.org/searchpath/SearchPath.hs SearchPath.hs $ ghc --make SearchPath.hs -o sp $ sp ghci -ihaskell haskell/Main.hs Prelude :r Also, HAppS.Server.Facebook takes forever to compile. I don't understand why. -Alex- ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci changing 'm' to 'g'
On Wed, Nov 21, 2007 at 01:16:34PM -0500, Olivier Boudry wrote: On Nov 21, 2007 1:07 PM, Greg Fitzgerald [EMAIL PROTECTED] wrote: Running 6.8.1 on Windows XP, typing 'main' while :r is still processing causes the 'm' in 'main' to morph to a 'g'. :r [1 of 2] Compiling Language.QidlTypeLibrary.Parser ( Language/QidlTypeLibrary/Parser.hs, interpreted ) Ok, modules loaded: Main, Language.QidlTypeLibrary.Parser. main interactive:1:0: Not in scope: `gain' Thanks, Greg What a weird bug. It sounds like a joke but it isn't one. I just reproduced it (also works with :l). P:\5. Tools\Cleansing\CustomerMasterghci GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude :l CustomerMaster.hs [1 of 1] Compiling Main ( CustomerMaster.hs, interpreted ) Ok, modules loaded: Main. *Main main interactive:1:0: Not in scope: `gain' I wonder if it's a Windows only bug. It's very old. http://hackage.haskell.org/trac/ghc/ticket/831 Stefan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: suggestion: add a .ehs file type
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 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 different compiler which doesn’t support all of GHC’s extensions? That compiler also won't recognize the pragmas and the code won't compiler either way. Only now you have code that has lots of pragmas in it. The compiler obviously knows which extensions are actually being used when the user uses them. I don’t think so. For example, if you don’t use rank-2 polymorphism and similar things, forall is a perfect name for a type variable. Actually it probably isn't a great name given the risk that forall may appear in a standard some time soon. But either way, if you are not using forall in the context of forall syntax, then the compiler knows that and can handle it appropriately. 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. -Alex- ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: if-them_else
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wolfgang Jeltsch Sent: Wednesday, November 21, 2007 10:32 AM To: glasgow-haskell-users@haskell.org Subject: Re: if-them_else Am Mittwoch, 21. November 2007 15:03 schrieb Serge D. Mechveliani: Dear GHC developers, when compiling the function f x = if x them False else True ghc-8.8.1 reports:parse error on input `else' . When there is a large expession after `them', it is sometimes difficult to locate a typo. Why does not it report parsing if-then-else: cannot find `then' ? Regards, them is a perfect identifier. So probably x them False gets parsed as an expression (x applied to them and the result applied to False). Haskell’s lightweight syntax makes programs short and easy to read (in my opinion) but it often makes the compiler unable to guess where your mistake lies. That means that the compiler does not know about the error at the time the them token is parsed. It doesn't imply that the error message cannot be better. In this case, since the compiler, indeed, detects the error at the token else, it should be straightforward to improve the error message. Now, whether it is worth the effort is a separate question, and a judgement call, but it is surely possible and not even terribly difficult. Seth Kurtzberg Software Engineer Specializing in Security, Reliability, and the Hardware/Software Interface Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: suggestion: add a .ehs file type
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: indeed I just checked the docs and found -XDisambiguateRecordFields Was this advertized? It seems that's what I've been missing for years. Best regards, Johannes. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci changes in 6.8 that are not improvements
On Wed, 21 Nov 2007, Alex Jacobson wrote: 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 it until I pointed it out. If it was an accident, it was still a really useful feature and would love to have it back. I knew about it too, though I'd assumed that it repeated the previous : command. It's just that ':r' is the only command I ever repeat. I'd quite like it back too, in either form. Cheers, Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: suggestion: add a .ehs file type
| So what is DisambiguateRecordFields? It's documented in the user 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: 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: | | [...][ 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 this advertized? It seems that's what I've been missing for years. | | Best regards, Johannes. | | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: suggestion: add a .ehs file type
-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 Mozilla - http://enigmail.mozdev.org iD8DBQFHRKOL3ZnXZuOVyMIRAsCeAKCmSdefclDcNk4ERx1Km3JgADZpxACeJjdy i8/gb70DMXF68pS9ivZGClA= =3ohO -END PGP SIGNATURE- ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
label syntax vs DisambiguateRecordFields
Nice feature but feel like a band-aid. In particular it makes SYB style programming more difficult because field labels aren't types. Almost every other record syntax plan involves field labels as types so you can do interesting type dispatch. With this syntax, there is increasing probability that salary becomes a standard field name rather than a type. What would be really much more useful would be an alternative newtype syntax like this: label Salary = salary::Float deriving Show which would be equivalent of newtype Salary = Salary Float deriving Show salary (Salary x) = x Does this make sense? -Alex- Tracking these open issues: * too many pragma declarations * recursive deriving * labels * : for reload in ghci * not reloading all the modules on :r Simon Peyton-Jones wrote: | So what is DisambiguateRecordFields? It's documented in the user 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: 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: | | [...][ 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 this advertized? It seems that's what I've been missing for years. | | Best regards, Johannes. | | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: suggestion: add a .ehs file type
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 -XDisambiguateRecordFields instead). Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci changing 'm' to 'g'
Greg Fitzgerald wrote: Running 6.8.1 on Windows XP, typing 'main' while :r is still processing causes the 'm' in 'main' to morph to a 'g'. Olivier Boudry wrote: it (also works with :l). Stefan O'Rear wrote: It's very old. http://hackage.haskell.org/trac/ghc/ticket/831 But these observations indicate several clues that do not yet appear in the Trac ticket: 1. Occurs on Windows (I can't reproduce it in on Mac OS X Intel or Debian Lenny) 2. Occurs also with :r and :l, not just evaluating an expression. Perhaps someone with with a Trac login should make note of them. -Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: suggestion: add a .ehs file type
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 #-}
foo _ = lol
main = putStrLn (foo wut)
where
foo !x = x
Duncan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: suggestion: add a .ehs file type
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 syntax in your existing code, you have manually to audit your code
to make sure nothing else got broken and that is difficult even for
experts to do really well. The example you provide is actually evidence
that this bang-pattern extension is probably a bad one.
-Alex-
Duncan Coutts 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-patterns #-}
foo _ = lol
main = putStrLn (foo wut)
where
foo !x = x
Duncan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: suggestion: add a .ehs file type
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 that you should use. This is actually better than the case where you forget to import something when ghc doesn't helpfully tell you which module you forgot to import. As others have said, one major reason for declaring extensions is for portability. 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 syntax in your existing code, you have manually to audit your code to make sure nothing else got broken and that is difficult even for experts to do really well. The example you provide is actually evidence that this bang-pattern extension is probably a bad one. In general I'd agree. In the case of bang patterns it's actually very hard to construct examples where the code compiles both ways (and is actually used). Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: suggestion: add a .ehs file type
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 which extension it is that you should use. This is actually better than the case where you forget to import something when ghc doesn't helpfully tell you which module you forgot to import. My point is that the default should be to give a warning rather than an error and provide the user with the ability to turn those warnings off. As others have said, one major reason for declaring extensions is for portability. The warning should be enough information for people who want to avoid accidentally adding features that will cause their code not to run on other compilers. For those that don't care, forcing them to add zillions of pragmas is an excessive burden. -Alex- ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci changing 'm' to 'g'
On Thu, Nov 22, 2007 at 01:12:16AM +0200, Yitzchak Gale wrote: Greg Fitzgerald wrote: Running 6.8.1 on Windows XP, typing 'main' while :r is still processing causes the 'm' in 'main' to morph to a 'g'. Olivier Boudry wrote: it (also works with :l). Stefan O'Rear wrote: It's very old. http://hackage.haskell.org/trac/ghc/ticket/831 But these observations indicate several clues that do not yet appear in the Trac ticket: 1. Occurs on Windows (I can't reproduce it in on Mac OS X Intel or Debian Lenny) That *is* in the ticket - look at the Operating System field. 2. Occurs also with :r and :l, not just evaluating an expression. Personally I think that this is the least relatively suprising behavior, and it would be most noteworthy if it only affected expressions. But others may disagree. Perhaps someone with with a Trac login should make note of them. You have one! User 'guest', password 'guest'. In fact, it says this at the bottom of every page! (Spammers are smart enough to try and create accounts, but can't read page footers - go figure). Remember to sign your comment with contact info. Stefan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci changing 'm' to 'g'
On Wed, Nov 21, 2007 at 05:11:05PM -0800, Stefan O'Rear wrote: Perhaps someone with with a Trac login should make note of them. You have one! User 'guest', password 'guest'. In fact, it says this at the bottom of every page! (Spammers are smart enough to try and create accounts, but can't read page footers - go figure). Remember to sign your comment with contact info. You can register new accounts nowadays, so you don't have to remember to sign everything. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci changing 'm' to 'g'
Quoth InteractiveUI.runGHCi: case maybe_expr of Nothing - do #if defined(mingw32_HOST_OS) -- The win32 Console API mutates the first character of -- type-ahead when reading from it in a non-buffered manner. Work -- around this by flushing the input buffer of type-ahead characters, -- but only if stdin is available. flushed - io (IO.try (GHC.ConsoleHandler.flushConsole stdin)) case flushed of Left err | isDoesNotExistError err - return () | otherwise - io (ioError err) Right () - return () #endif -- enter the interactive loop interactiveLoop is_tty show_prompt Could this be related somehow? -Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: HUnit 1.2.0.0 on 6.8.1 vs 1.1.1 on 6.6.1
On Nov 21, 2007 11:13 AM, Greg Fitzgerald [EMAIL PROTECTED] wrote: On Windows, HUnit's assertions are not working - trace below in ghci 6.8.1 and 6.6.1. Can others reproduce? I reproduce the Exception: (unknown) in 6.8.1 (with HUnit-1.2.0.0) on Linux. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
