RE: The impossible happened
Excellent bug report, thank you. It's a bug in 4.08.
I hope we can ensure that it won't be in 4.08.1.
Workaround: ermove the context from the newtype declaration.
Simon
| -Original Message-
| From: Jose Emilio Labra Gayo [mailto:[EMAIL PROTECTED]]
| Sent: 25 August 2000 12:05
| To: [EMAIL PROTECTED]
| Subject: The impossible happened
|
|
|
| {-
|
| The following piece of program produces:
|
| panic! (the `impossible' happened):
| applyTypeToArgs
| (__coerce (f{-ar4-} (THIS.FixTest.Fix{-r2,x-} f{-ar4-}))
| zddFunctor{-ari-})
| x{-arb-}
|
| Some details:
|
| - It loads if I remove the context in the Fix declaration:
| newtype Fix f = In {out :: f (Fix f) }
| - It loads ok with Hugs98
| - I am using ghc 4.08 and the problem arises both in Debian
| Linux and in
| Win32
|
| BTW, I was looking for a list of known bugs in ghc but I
| couldn't find it.
| Does it exist?
|
| Best Regards, Jose Labra
| http://lsi.uniovi.es/~labra
|
| -}
| module FixTest where
|
| newtype (Functor f) = Fix f = In { out :: f (Fix f) }
|
| para g x = g (fmap (para g) (out x)) x
|
|
|
|
|
|
RE: File names with +?
Yes, that's a bug in the ghc-4.08 driver. I think we'll classify it as a Known Bug for 4.08, but not fix it. It's already fixed in the head of the tree, which has a completely new driver, written in Haskell. Thanks for reporting it Simon | -Original Message- | From: Jose Emilio Labra Gayo [mailto:[EMAIL PROTECTED]] | Sent: 29 August 2000 09:39 | To: [EMAIL PROTECTED] | Subject: File names with +? | | | I was trying to compile a file "h++.hs" and it seems that ghc does not | like that name. When I try to compile it, I obtain: | | //h++\.hi/: nested *?+ in regexp at | /usr/local/lib/ghc-4.08/ghc-iface.prl | line 141. | | If I rename the file as "hpp.hs" then it works fine. | | Best regards, Jose Labra | |
RE: Undefined methods: bad behaviour
Well you may say that it's a mistake, but
that's the behaviour specified by the language report (as you request).
The default methods for show and showsprec are each
defined in terms of each other.
If you specify one or the other, you're fine. If you specify
neither you get an inifiniite loop.
It's hard for the compiler to be sure when you've done this.
Even a termination analysis may not work becuase it's hard
to distinguish divergence from (error "urk").
But I agree it's rather counterintuitive. I'm just not sure
how to improve matters
Incidentally,there *is* a way to derive the standard instances
data A = A deriving( Show )
Simon
| -Original Message-
| From: Michael Marte [mailto:[EMAIL PROTECTED]]
| Sent: 30 August 2000 08:05
| To: [EMAIL PROTECTED]
| Cc: Michael Marte
| Subject: Undefined methods: bad behaviour
|
|
| Hi,
|
| look at the following example:
|
|
| module Main where
|
| data A = A
| instance Show A
|
| main = do print A
|
|
| This program does not work, it just loops eating all the heap
| (ghc-4.08-1). With respect to the Haskell 98 Report (4.3.2), this
| behaviour is ok. ("If no binding is given for some class
| method then the
| corresponding default class method in the class declaration
| is used (if
| present); if such a default does not exist then the class
| method of this
| instance is bound to undefined and no compile-time error results.")
| However, the looping behaviour is not very helpful. Why not print a
| message like "Calling undefined class method type.class.method"?
|
| (In my eyes, the rule cited above is nonsense. This default
| behaviour is
| not intuitive. Why not derive the standard instances? In a large
| project, each module may need its own instances. Some modules require
| special stuff, for others the default instances might be
| sufficient. For
| the latter modules, it would be *very helpful* to have some means to
| derive the standard instances. AFAIK, ghc-4.06 did it the way
| I like it,
| but in ghc-4.07 this was changed and all my programs were broken. Is
| there any reason for doing it the way prescribed by the
| Haskell Report?)
|
| Michael
|
|
|
|
Re: using Hudak's SOE book
Dear Paul, thanks for your remarks, However, especially because you have a group of experienced programmmers: ... it is exactly this group that needs to be trained to think differently, Yes, I will definitely keep that in mind. That said, don't be thrown off by the introductory nature of SOE. In particular, chapters 13, 15, and 19 ... Certainly. But for instance in chapter 15, I am quite worried about the usage of the memo "function", without which the whole thing wouldn't work. To students, this looks as if for "really interesting" tasks, standard Haskell isn't sufficient. Chapter 13 is on animations (behaviours), from a user's (not implementor's) perspective. I will definitely cover this, but here i would like to use FranTk, not FAL. why? 1) FranTk runs with hugs *and* with ghc (does this hold for FAL as well? last I checked it seemed hugs only) 2) FranTk has all those fancy input widgets Again i want to avoid the impression that Haskell is a toy language because all examples are run on a seemingly small interpreter, and the graphics libraries are too simple. As I said, the students have done some programming, including Java. Their Java experience is also my motivation to present Haskell parser combinators - I know some of the students' previous projects, which involded writing expression parsers from scratch. I think they noticed that this isn't funny, and they will appreciate a good parser combinator library. Best regards, -- -- Johannes Waldmann http://www.informatik.uni-leipzig.de/~joe/ -- -- [EMAIL PROTECTED] -- phone/fax (+49) 341 9732 204/252 -- === Drittes Leipziger Jongliertreffen 6. - 8. Oktober === === http://www.informatik.uni-leipzig.de/~joe/juggling/dreilei/ ===
Haskell-GUIs (was Re: using Hudak's SOE book)
Hello, "Johannes" == Johannes Waldmann [EMAIL PROTECTED] writes: Johannes 1) FranTk runs with hugs *and* with ghc (does this hold Johannes for FAL as well? last I checked it seemed hugs only) Johannes 2) FranTk has all those fancy input widgets Johannes Again i want to avoid the impression that Haskell is a toy Johannes language because all examples are run on a seemingly small Johannes interpreter, and the graphics libraries are too simple. As Johannes I said, the students have done some programming, including Johannes Java. I have got a little programming experience with both FranTk and Java applets and got the impression that FranTk is appropriate for a simple graphical interface to a program which you want to be written in Haskell. In my impression, the Haskell GUI most supported is the binding to GTK by Manuel Chakravarty. Despite the fact, whether GTK or FranTk is more comfortable, I'd decide for a GUI which is going to be supported in the future by several people and maybe even part of the main ghc distribution. Sometime in the future, when a combination of ghc and hugs is available, the GUI should run with hugs if it runs compiled with ghc. Cheers -- Christoph Herrmann E-mail: [EMAIL PROTECTED] WWW: http://brahms.fmi.uni-passau.de/cl/staff/herrmann.html
Re: using Hudak's SOE book
Hi Johannes: That said, don't be thrown off by the introductory nature of SOE. In particular, chapters 13, 15, and 19 ... Certainly. But for instance in chapter 15, I am quite worried about the usage of the memo "function", without which the whole thing wouldn't work. To students, this looks as if for "really interesting" tasks, standard Haskell isn't sufficient. Indeed, it isn't :-). Chapter 13 is on animations (behaviours), from a user's (not implementor's) perspective. I will definitely cover this, but here i would like to use FranTk, not FAL. why? FranTk is a great choice, I'm not arguing with that, especially if you want to do GUI's. However, I wonder if you look into the guts of FranTk, if there isn't at least one unsafePerformIO? I'm assuming that you will get your students to USE FranTk, not implement it. The "memo" function in SOE is used to IMPLEMENT Fal, not use it. 1) FranTk runs with hugs *and* with ghc (does this hold for FAL as well? last I checked it seemed hugs only) True, GHC does not know about the graphics lib. If you're intent on using GHC, then you're right, this would be a showstopper. 2) FranTk has all those fancy input widgets Yes, they're great! Again i want to avoid the impression that Haskell is a toy language because all examples are run on a seemingly small interpreter, and the graphics libraries are too simple. As I said, the students have done some programming, including Java. Yes, this is the compromise in teaching how to implement a DSL, not just use it. At Yale, however, all of our work with real robots, for example, uses the core implementation that's in SOE. It's simplicity is one of the nice things about it. Anyway, sounds like you've made some good choices. -Paul
RE: Haskell compilers targetting Wintel platforms, or microsoft's .NET...
GHC (http://haskell.org/ghc) generates native code for Wintel. We are actively working on making it more Wintel friendly (e.g. packaging with Installshield, using DLLs). We are also working on targeting the .NET platform, but it's at an experimental stage right now. Definitely not ready for prime time. Simon | -Original Message- | From: larisys [mailto:[EMAIL PROTECTED]] | Sent: 29 August 2000 11:14 | To: '[EMAIL PROTECTED]' | Subject: Haskell compilers targetting Wintel platforms, or microsoft's | ".NET"... | | | There is at the moment a great fuss around the new Microsoft's ".NET" | platform. Articles about the related virtual machine and run-time | environment often cite Haskell as a language targetting the | ".NET". Does | anybody out there knows about existing Haskell compilers | generating code | for the ".NET", or native code for WinTel platforms ? | | Thank you for dedicating some of your time to reading and | answering this... |
