- Haskell - Haskell.org

RE: GHC Core Language
by Andrew Tolmach 07 Feb '01

07 Feb '01

[moving to haskell-cafe] > From: matt hellige [mailto:matt@immute.net] > a quick question re: ghc's Core language... is it still very similar > to the abstract syntax given in, for example, santos' "compilation by > transformation..." (i think it was his dissertation?) and > elsewhere, or > has it changed significantly in the last couple of years? i only ask > because i know the language used in that paper is somewhat > different from > the Core language given in peyton jones and lester's > "implementing functional > languages" from 92, and includes type annotations and so on. > > m > The current Core language is still quite similar to what is described in Santos' work; see SL Peyton Jones and A Santos, "A transformation-based optimiser for Haskell," Science of Computer Programming 32(1-3), pp3-47, September 1998. http://research.microsoft.com/Users/simonpj/papers/comp-by-trans-scp.ps.gz But there have been some noticeable changes; for example, function arguments are no longer required to be atomic. A more recent version of Core is partially described (omitting types) in SL Peyton Jones & S Marlowe, "Secrets of the Glasgow Haskell Compiler Inliner," IDL'99. http://research.microsoft.com/Users/simonpj/papers/inline.ps.gz

1 0

Re: Revamping the numeric classes
by Ketil Malde 07 Feb '01

07 Feb '01

Brian Boutel <brian(a)boutel.co.nz> writes: > * most usage of (+), (-), (*) is on numbers which support all of them. Yes, but the problem is that the way this is implemented is a nuisance and a hindrance to those who wants to apply these operators to different data types. Also, it means functions become less general than they need to be (or that they need to be parametrized by the necessary operators) E.g. way back, I wrote a simple differential equation solver. Now, the same function *could* have been applied to vector functions, except that I'd have to decide on how to implement all the "Num" stuff that really didn't fit well. Ideally, a nice class design would infer, or at least allow me to specify, the mathematical constraints inherent in an algorithm, and let my implementation work with any data satisfying those constraints. Obviously, a good and elegant, yet simple design of type classes is quite hard. I think it can be done, though. -kzm -- If I haven't seen further, it is by standing in the footprints of giants

2 1

Implementing the Show class for a Hash
by Shlomi Fish 07 Feb '01

07 Feb '01

Hi! I've written a hash implementation in pure Haskell. The hash is more of a collection of elements organized in a table of linked lists, and it can serve as a dictionary by having each one be a key-value pair. However, I ran into problems when implementing the show function and hugs keeps reporting errors. Can anybody implement it for me based on the hash implementation, and the function which I have commented out? The URL for the code is : http://techst02.technion.ac.il/~shlomif/haskell/Hash/Hash.hs Regards, Shlomi Fish ---------------------------------------------------------------------- Shlomi Fish shlomif(a)vipe.technion.ac.il Home Page: http://t2.technion.ac.il/~shlomif/ Home E-mail: shlomif(a)techie.com The prefix "God Said" has the extraordinary logical property of converting any statement that follows it into a true one.

1 0

Announcing haskelldoc
by Henrik Nilsson 07 Feb '01

07 Feb '01

Dear Haskellers, At the recent Haskell Implementors' meeting in Cambridge, UK, it was decided that it would be useful to have a standard for embedded Haskell documentation. Such standards, and associated tools for extracting and formating the documentation in various ways, exists for other languages like Java and Eiffel and have proven to be very useful. Some such tools also exist (and are being actively developed) for Haskell, but there is as yet no generally agreed upon standard for the format of the embedded documentation as such. To address this, a mailing list has been started with the aim of defining a standard for embedded Haskell documentation, and possibly also related standards which would facilitate the development of various tools making use of such documentation (formatters, source code browsers, search tools, etc.). We feel that it is important to involve all who might be interested in this work at an early stage, so that as many aspects as possible can be taken into consideration, and so that the proposal for a standard which hopefully will emerge has a reasonable chance of gaining widespread support. Thus, You are hereby cordially invited to join haskelldoc(a)haskell.org. To join, just goto http://www.haskell.org/mailman/listinfo/haskelldoc. Best regards, Armin Groesslinger <groessli(a)fmi.uni-passau.de> Simon Marlow <simonmar(a)microsoft.com> Henrik Nilsson <nilsson(a)cs.yale.edu> Jan Skibinski <jans(a)numeric-quest.com> Malcolm Wallace <malcolm(a)abbess.demon.co.uk>

2 1

RE:
by Andrew Tolmach 06 Feb '01

06 Feb '01

Christoph Hermann <herrmann(a)fmi.uni-passau.de> wrote: > > Dear Haskellers, > > >>>>> "Simon" == Simon Peyton-Jones <simonpj(a)microsoft.com> writes: > > Simon> We agreed that it would be a Jolly Good Thing if GHC > Simon> could be persuaded to produce GHC-independent Core output, > Simon> ready to feed into some other compiler. For example, > Simon> Karl-Filip might be able to use it. ANDREW will write a > Simon> specification, and implement it. > > a good idea. Before ANDREW will put a lot of effort in the > specification > and implementation, it would be good to have a discussion > about the core > representation that is gradually evolving. Indeed, I plan to publish a draft specification (quite soon) and will be delighted to get feedback from the community before investing heavily in implementation. I'm very glad to hear that others are interested! > There is the risk > that the representation, made by insiders, will be too complicated > to be used by several other people as I feel the core output > currently produced by GHC is. Actually, I am something of an outsider myself (though physically located near a bunch of insiders just at the moment!) so I hope I'll be sensitive to this point. But perhaps Simon should not have written "GHC-independent" Core output; my goal is to expose GHC's existing Core language, or something very close to it, rather than to invent an ideal Core Haskell. So some GHC-specific complexities may be unavoidable. > It would be good to put all stuff related to this topic onto a > WWW page, containing links to relevant papers, conventions, > example pairs (Haskell source,core equivalent) which can be > discussed. A good idea; I'll set up such a page and put the draft there to get things started. > A toy interpreter (e.g., using happy) which > interprets the core language and which is written with the goal of > documentation, not under efficiency aspects, may be helpful. Yes, I had already thought of doing this. Perhaps a type-checker too. > I'm not sure whether you like the idea, but a quick solution for > a small subset of Haskell would, in my opinion, be smarter > to the user, since her or she can get used to the representation > and we have something concrete to discuss. Well, yes. But the entire core language *is* really fairly small, so I am optimistic that a fairly complete job can be done in fairly short order. Cheers, Andrew Tolmach

2 1

fixST in GHC
by Pedro Baltazar Vasconcelos 06 Feb '01

06 Feb '01

Hello all, I'm experimenting with the ST monad GHC/Hugs extension and came across a puzzling omisson: in GHC 4.06 if I import the LazyST module instead of the standard one then the knot-tying fixST combinator is not defined. Aparently the reason for this omisson is not documented in the ghc manual... BTW, in Hugs both LazyST/ST define fixST. Regards, Pedro Vasconcelos.

1 0

8th Static Analysis Symposium : Last CFP
by Radhia Cousot 06 Feb '01

06 Feb '01

========My apologies for duplicates of this announcement========= ================================================================= = = = Call For Papers = = = = 8th INTERNATIONAL STATIC ANALYSIS SYMPOSIUM = = = = = = La Sorbonne, Paris = = 16-18 July, 2001 = = = = http://www.ens.fr/sas01/ = = = ================================================================= Static Analysis is increasingly recognized as a fundamental technique for high performance implementations and verification systems of high-level programming languages. The series of Static Analysis Symposia has served as the primary venue for presentation of theoretical, practical and applicative in the area. The Eigth International Static Analysis Symposium (SAS2'01) will be held at La Sorbonne in Paris and followed immediately at La Mutualite by the Thirteenth Conference on Computer Aided Verification (CAV'01, http://www.lsv.ens-cachan.fr/cav01/}. Previous symposia were held in Santa Barbara, Venice, Pisa, Paris, Aachen, Glasgow and Namur. The technical program for SAS'01 will consist of invited lectures, tutorials, panels, presentations of refereed papers, and software demonstrations. Contributions are welcome on all aspects of Static Analysis, including, but not limited to abstract interpretation data flow analysis verification systems optimizing compilers abstract domains program specialization theoretical frameworks type inference abstract model checking complexity analysis abstract testing security analysis Submissions can address any programming paradigm, including concurrent, constraint, functional, imperative, logic and object-oriented programming. Survey papers that present some aspect of the above topics with a new coherence are also welcome. Submitted papers must not substantially overlap with papers that have been published or that are simultaneously submitted to a journal or a conference with a refereed proceedings. Submitted papers should be at most 15 single space 11-point font pages excluding bibliography and well-marked appendices. Program committee members are not required to read any appendices, and so a paper should be intelligible without them. The papers should be submitted as PostScript documents that are interpretable by Ghostscript and/or in PDF format, and they must be printable on both US letter and A4 paper; to facilitate this, extensive use of special fonts and colors should be avoided. Submissions should arrive by February 15, 2001. All submissions must be done electronically at http://www.ens.fr/sas01/. Authors will be notified of the acceptance or rejection of their papers by April 2, 2001. Final versions of the accepted papers must be received in electronic form by April 30, 2001. Important Dates: Submission: February 15, 2001. Notification: April 2, 2001. Final Version: April 30, 2001. Program Chair: Patrick Cousot Ecole Normale Superieure Departement d'Informatique 45, Rue d'Ulm 75230 Paris Cedex 05, France Email: sas01(a)ens.fr Phone: & + 33 1 44 32 20 64 Fax: & + 33 1 44 32 21 52 Program Committee: M. Bruynooghe (KU, Leuven) P. Cousot (ENS, Paris) G. Fil'e (Padova) M. Hagiya (Tokyo) C. Hankin (IC, London) L. Hendren (McGill, Montreal) M. Hermenegildo (UPM, Madrid) N. Jones (DIKU, Denmark) J. Larus (Microsoft, Redmond) J. Palsberg (Purdue) S. Sagiv (Tel Aviv) D. Sands (Chalmers, Goteborg) D. Schmidt (Kansas S.) M.L. Soffa (Pittsburgh) H. Sondergaard (Melbourne) R. Wilhelm (Saarbruken) K. Yi (KAIST, Taejon) General Chair: Radhia Cousot CNRS & Ecole polytechnique rcousot(a)lix.polytechnique.fr

1 0

"Job Adverts" on haskell.org
by Olaf Chitil 06 Feb '01

06 Feb '01

Haskell.org has a page "Job Adverts". http://www.haskell.org/jobs.html This page lists university and industry positions for people who want to work with Haskell. However, besides that, it shall also contain other kinds of adverts. Haskell is based on open source software to which a large number of people contribute. If you are working on some Haskell project and could do with some help, then advertise here (and on the Haskell mailing list). Even more importantly: If you built some Haskell software and unfortunately no longer feel able to maintain it, then please advertise here (and on the Haskell mailing list) for new people to take it over and give it a home. Thus we may alleviate the problem of the large number of Haskell tools and libraries that are half complete and no longer maintained. Mail John and me if you want to place an advert on the page. mailto:peterson-john@cs.yale.edu,olaf@cs.york.ac.uk Cheers, Olaf -- OLAF CHITIL, Dept. of Computer Science, University of York, York YO10 5DD, UK. URL: http://www.cs.york.ac.uk/~olaf/ Tel: +44 1904 434756; Fax: +44 1904 432767

1 0

how to set default editor in hugs 98 for win and linux
by andrew long 06 Feb '01

06 Feb '01

I've just started to use hugs in both the windows 98 and linux environments and wanted to assign notepad and kwrite as the default editors to their respective os'. If you could enlighten me on this setup procedue for both systems ot wuld be greatly appreciated a.p.long(a)ncl.ac.uk cheers big a

3 2

binary files in haskell
by Timmy Douglas 06 Feb '01

06 Feb '01

I was wondering if anyone here has a solution for writing binary files that works in hugs and ghc that doesn't require getting libs. I looked at this page: http://haskell.cs.yale.edu/ghc/docs/latest/set/sec-ioexts.html and the haskell.org libraries page and I didn't see anything. the ghc documentation didn't provide any examples so I was unable to figure out how to write a binary file.

3 4