External Core front end is completely broken
Using the latest version of GHC downloaded from CVS, it's impossible to use GHC to compile any .hcr files that it generates itself. The reason for this is that, as per the CVS log for prelude/PrelNames.lhs, all Main modules now contain a definition for $Main.main -- however, the External Core lexer still requires module names to begin with an upper-case letter, resulting in a parse error. -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Higher rank types
| The paper has a strongly tutorial flavour, and comes complete with a | prototype implementation that you can play with. | | Does the prototype implementation not support recursive lets? | | *Main tcs let fix = (\\f . f (fix f)) in fix | Not in scope: `fix' No it does not. As the paper explains. Easy exercise: add recursive lets! Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Higher rank types
G'day all. On Tue, Jul 08, 2003 at 08:56:10AM +0100, Simon Peyton-Jones wrote: No it does not. As the paper explains. Serves me right for playing with the toy before I read the manual. Cheers, Andrew Bromage ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Higher rank types
I took a quick skim through this -- not closely enough to follow all the details but I still found some useful background understanding. For me, it clarified slightly the role of types on the left and right hand sides of a function arrow, which I've seen mentioned in passing but never explained, but there's still a gap in my grasp of this notion (something to do with types on LHS of arrow being subject to pattern matching?). A lingering question in my mind, which may be pretty irrelevant to your purpose, is the relationship between these higher rank types and GHC's existentially bound types (which also use the 'forall' keyword). (Working as I do with Semantic Web technologies and ideas, I was interested to note your simple rules ... rather than trying to exploit every ounce of inference. I have similar views regarding the role of inference in semantic web applications. I think it will be interesting to study your inference patterns in detail (when I find time!), and in particular to compare your approach to subsumption with the Description Logic approach favoured by many in the SWeb community.) #g -- At 11:23 07/07/03 +0100, Simon Peyton-Jones wrote: Dear Haskellers For a long time now, Mark Shields and I have been writing a paper describing GHC's approach to type inference for higher-rank types. We've finally finished a complete draft: Practical type inference for arbitrary-rank types Simon Peyton Jones and Mark Shields http://research.microsoft.com/~simonpj/papers/putting/index.htm The paper has a strongly tutorial flavour, and comes complete with a prototype implementation that you can play with. My hope is that, in addition to describing higher-rank stuff, the paper may serve as a kind of tutorial on type inference generally, and the use of monads to support the plumbing in particular. There's nothing really new about this aspect of the paper, but I don't know of a comparable tutorial that takes a monadic approach. It's still very much a draft, so I'd be very interested in your feedback about it. Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell --- Graham Klyne [EMAIL PROTECTED] PGP: 0FAA 69FF C083 000B A2E9 A131 01B9 1C7A DBCA CB5E ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
literal default value for an unknown type
Is it possible replace the question mark in the following code in order to
make defaultMyType return a don't care value for b?
data MyType t = MyType { a :: Int, b :: t}
defaultMyType :: MyType
defaultMyType = MyType {a = 0, b = ?}
Cheers,
-- Andre
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: literal default value for an unknown type
On Tue, 8 Jul 2003 23:16:33 -0300
Andre W B Furtado [EMAIL PROTECTED] wrote:
Is it possible replace the question mark in the following code in
order to make defaultMyType return a don't care value for b?
data MyType t = MyType { a :: Int, b :: t}
defaultMyType :: MyType
defaultMyType = MyType {a = 0, b = ?}
First you do need the type parameter (:: MyType t).
Then you have (at least) three options.
You can replace the ? with undefined. You can omit b altogether in the
record construction and get the same effect as the first option, or you
could have b :: Maybe t and have the ? be Nothing. Which (of the
really two options) is best depends on how you intend to use the record.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Reading/Writing Binary Data in Haskell
Hello to all, I'm recently working on doing some atmospheric modelling for my PhD thesis work and I've been writing parallel implementations in Java, Ruby, and Haskell. I picked up Haskell as part of the LoTY project and was especially impressed by how expressive and clean the code is. I've been quite successful at writing most of my numerical libraries in Haskell (typically at a much reduced SLOC) but I'm not butting my head against binary data. I have a large store of data, output by a Fortran model, which essentially consists of binary files containing arrays of floating point values. In doing some googling on reading binary data in Haskell I've come across some old ( 1 year) references to some mailing list discussions on reading binary data. So given the background I have a few questions: 1 - Is there yet a standard, or at least commonly supported by hugs and ghc, method for dealing with binary data. 2 - If not, is there a standard library that is used to manipulate binary data. I've seen some references to some implementations but given that this is being done in my limited spare time (I'm not a full time student) I'd rather not spin my wheels on something that's going to be dead in a matter of months. 3 - What is the current status of getting binary data into the Haskell standard? I understand that I can write a C extension, but part of my interest in Haskell lies in the ability to write scientific software that very closely resembles the mathematics that are being modelled. On that note, I'd also be very interested in conversing with people that are doing physics modelling (atmospheric dynamics and chemistry is esp. interesting) using functional languages. Thanks! Gordon Miller [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Reading/Writing Binary Data in Haskell
Gordon James Miller wrote: 1 - Is there yet a standard, or at least commonly supported by hugs and ghc, method for dealing with binary data. 2 - If not, is there a standard library that is used to manipulate binary data. I've seen some references to some implementations but given that this is being done in my limited spare time (I'm not a full time student) I'd rather not spin my wheels on something that's going to be dead in a matter of months. There isn't a standard mechanism for binary I/O. However, a simple and fairly generic mechanism for doing this is: 1. Read in a list of Chars with the standard I/O functions. 2. Use map (fromIntegral . ord) ... to get a list of Word8s (octets). 3. Use with, poke, peek, castPtr etc to coerce a list of octets to the desired type(s). For output, do the reverse. This way, you can read/write any instance of Storable in the host's native format (i.e. C format), and the code should be portable. The key here is step 3; if you want to sacrifice portability for performance, use Posix.read (or the Win32 equivalent) to read directly into memory (Ptr/Addr), or even write an import declaration for mmap(). -- Glynn Clements [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Representing cyclic data structures efficiently in Haskell
Hi Sarah, On Mon, 2003-07-07 at 16:04, Sarah Thompson wrote: What is the best way to represent cyclic data structures in Haskell? Lists are trivial. Trees are trivial. But what if the thing you're trying to represent is shaped like an electronic circuit, ... ... How do people typically solve this problem at the moment? I know a few people out there have written hardware compilers in Haskell and similar languages, ... You're right, this is a longstanding problem! I've experimented with several solutions to it in Hydra, a pure functional hardware description language whose aims include preserving referential transparency, and also keeping within a natural functional style. My view is that if you have to resort to encoding a C-style solution in a functional language, then you might as well use C instead. Anyway, there are several papers on Hydra that are relevant. The first solution, described in a paper from 1988, is to build the circular graphs in the obvious way and then to use a pointer-equality predicate to traverse the graphs safely. Of course, this makes the hardware description language impure, it breaks referential transparency, and it has other drawbacks. You can find that paper on my web page, but it was written before Haskell appeared, and it uses an older functional language with different syntax. I wrote a paper about the problem in 1992, www.dcs.gla.ac.uk/~jtod/papers/1992-Netlist/ This paper discusses the problems with the pointer-equality solution and introduces naming as a pure alternative. The idea of naming is to give unique labels to some of the nodes, so that you can build the circular graph in the usual way, and you can also traverse the graph safely. This is a pure functional solution, and it has a lot of advantages over adjacency lists, but it does require that the labels are introduced correctly. The best way to put the labels in is by a transformation. Currently, Hydra uses an automated transformation implemented with Template Haskell to introduce the names. I think this is the ideal solution: it results in a very clean notation for specifying the circuit, and it supports traversal of the graph, yet it preserves simple equational reasoning and all the supporting algorithms are in a pure functional style. I'm currently writing a paper on the details of this solution. It won't be finished for some time, but there already exists a brief survey of the solution, which you can find at: www.dcs.gla.ac.uk/~jtod/drafts/ (Embedding a hardware description language in Template Haskell) This paper focuses on the way Hydra is implemented as a domain specific language embedded in Haskell, and the last part of it talks about the graph traversal issues. This is a draft, submitted for publication, and any comments on it would be welcome! (However, the actual method used in Hydra is considerably more complex than what's presented in the draft paper, because there are a number of other issues that need to be addressed in addition to just traversing the circular graph safely.) There are a lot of alternative approaches to the problem. They will be compared in more detail in the paper-in-progress, but briefly they include: (1) Using adjacency lists, which have the disadvantages that you pointed out. (2) Using a monadic approach, which can be used in several distinct ways to solve the problem, but which have a bad impact on the specification style and the ease of reasoning about the circuit. (3) Using impure solutions, such as the pointer equality method used in the 1988 Hydra paper. Observable sharing (Claessen and Sands, 1999) is identical to the solution that was implemented in Hydra in the mid 80's and described in the 1988 paper; the difference is that they call the approach observable sharing instead of pointer equality. Best wishes, John O'Donnell ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Hugs Humor
On 2003-07-08 at 10:15+0200 Jerzy Karczmarczuk wrote: If it's a _Rational_, surely you want it to be exactly the same as you get for 31415926536%100? No. If 'you' means concretely me, then no. Simply no. Writing pi = 3.1415926536 :: Rational and expecting to continue the computations with an exact fraction 31415926536%100, with the well known explosion of Nums Dens seems pragmatically silly. Ah, well, I'd say that writing pi = 3.1415926536 :: Rational is just misleading -- we all know jolly well that pi isn't a rational, so anyone who writes that deserves what they get. Now, if you were to write pi = 3.1415926536 :: Real I'd be happy to argue over just what the conversion is supposed to do. Unfortunately we don't have Real (in libraries as far as I remember -- if you have a continued fraction implementation of it, it ought to go to the libraries list). Cheers, Jón -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Representing cyclic data structures efficiently in Haskell
What is the best way to represent cyclic data structures in Haskell? There used to be some work on direct cyclic representations at UCL: Dynamic Cyclic Data Structures in Lazy Functional Languages Chris Clack, Stuart Clayman, David Parrott Department of Computer Science, University College London, October 1995 The link to the project, from http://www.cs.ucl.ac.uk/staff/C.Clack/research/report94.html is broken, but the paper seems to be online at http://www.cs.ucl.ac.uk/teaching/3C11/graph.ps If you want to go for this direct cyclic representation, the interplay with lazy memo functions is also interesting: J. Hughes, Lazy memo-functions, Functional Programming Languages and Computer Architecture, J-P. Jouannaud ed., Springer Verlag, LNCS 201, 129-146, 1985. (lazy memo-functions remember previous input-output pairs based only on pointer-info, which is sufficient to write functions over cyclic structures that, instead of infinitely unrolling the cycles, produce cyclic results) (not online?-( Claus ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Hugs Humor
G'day all. On Tue, Jul 08, 2003 at 01:06:23PM +0100, Jon Fairbairn wrote: Unfortunately we don't have Real (in libraries as far as I remember -- if you have a continued fraction implementation of it, it ought to go to the libraries list). Not one, but TWO implementations! One using continued fractions, one using LFTs. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/haskell-libs/libs/exactreal/ Cheers, Andrew Bromage ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
