September 2004 - Haskell

CfP LDTA 2005
by Thomas Noll 17 Sep '04

17 Sep '04

****************************************************************** *** CALL FOR PAPERS *** *** *** *** Fifth Workshop on *** *** Language Descriptions, Tools and Applications *** *** LDTA 2005 *** *** *** *** Satellite event of ETAPS 2005 *** *** April 3, 2005 *** *** Edinburgh, Scotland, UK *** *** *** *** http://www-i2.informatik.rwth-aachen.de/Events/LDTA2005/ *** ****************************************************************** SCOPE: The aim of this one-day workshop is to bring together researchers from academia and industry interested in the field of formal language definitions and language technologies, with a special emphasis on tools developed for or with these language definitions. This active area of research involves the following basic technologies: Program analysis, transformation, and generation Formal analysis of language properties Automatic generation of language processing tools For example, language definitions can be augmented in a manner so that not only compilers or interpreters can be automatically generated but also other tools such as syntax-directed editors, debuggers, partial evaluators, test generators, documentation generators, etc. Although various specification formalisms like attribute grammars, action semantics, operational semantics, and algebraic approaches have been developed, they are not widely exploited in current practice. It is the aim of the LDTA workshops to bridge this gap between theory and practice. Among others, the following application domains can benefit from advanced language technologies: Software component models and modeling languages Re-engineering and re-factoring Aspect-oriented programming Domain-specific languages XML processing Visualization and graph transformation Programming environments such as Eclipse, Rotor, SUN Java, etc. The workshop welcomes contributions on all aspects of formal language definitions, with special emphasis on applications and tools developed for or with these language definitions. INVITED SPEAKER: LDTA 2005 is going to feature an invited talk by Erik Meijer from Microsoft Research. SUBMISSION PROCEDURE AND PUBLICATION: Submission will be open from autumn 2004. Papers (of at most 15 pages) should be submitted electronically as (optionally compressed/gzipped) PostScript or PDF files to one of the program committee chairs. The message should also contain a text-only abstract and contact author information. Please use the ENTCS style available on the ENTCS Macro Home Page http://www.math.tulane.edu/~entcs/ for preparing your submission. Final versions of accepted papers must not exceed 20 pages and have to conform to the proceedings style. Accepted papers will be published and made available during the workshop. After revision, final copies of the accepted papers will be published in Electronic Notes in Theoretical Computer Science (ENTCS), Elsevier Science. Author's instructions are given here. The authors of the best papers will be invited to write a journal version of their paper which will be separately reviewed and, after acceptance, be published in a special issue devoted to LDTA 2005 of the journal Science of Computer Programming (Elsevier Science). PROGRAM COMMITTEE: John Boyland, University of Wisconsin-Milwaukee, USA (co-chair) <Boyland(a)cs.uwm.edu> G?rel Hedin, Lund Institute of Technology, Sweden (co-chair) <Gorel.Hedin(a)cs.lth.se> Shigero Chiba, Tokyo Institute of Technology, Japan Jim Cordy, Queen's University, Kingston, Canada Susan L. Graham, University of California, Berkeley, USA Adrian Johnstone, University of London, UK Paul Klint, CWI, Amsterdam, The Netherlands Jens Knoop, Vienna University of Technology, Austria Eric Madeleine, INRIA, Sophia Antipolis, France Arnd Poetzsch-Heffter, University of Kaiserslautern, Germany Ganesh Sittampalam, Oxford University, UK Anthony Sloane, Macquarie University, Sydney, Australia Doaitse Swierstra, Utrecht University, The Netherlands Kris de Volder, University of British Columbia, Vancouver, Canada Andrew Wendelborn, University of Adelaide, Australia ORGANIZING COMMITTEE: Thomas Noll, RWTH Aachen University, Germany Joost Visser, University of Minho, Braga, Portugal Eric van Wyk, University of Minnesota, Minneapolis, USA IMPORTANT DATES: Submission deadline: December 1, 2004 Notification: January 17, 2005 Final version due: February 15, 2005 Workshop: April 3, 2005

1 0

call for papers
by L A C L 2 0 0 5 16 Sep '04

16 Sep '04

Apologies for multiple copies / please redistribute to whom it may concern ************************************************* L A C L 2 0 0 5 Logical Aspects of Computational Linguistics -- fifth international conference --- 28-29-30 avril 2005, Bordeaux (France) http://lacl.labri.fr/ CNRS - INRIA -- Universités Bordeaux 1 & 3 ************************************************* Submission deadline: monday 3 january 2005 LACL conference series ---------------------- LACL-2005 is the 5th edition of a series of international conferences on logical and formal methods in computational linguistics. It addresses in particular the use of proof theoretic and model theoretic methods for describing natural language syntax and semantics, as well as the implementation of natural language processing software relying on such models. A selection of the 1995 articles appeared in a special issue of the Journal of Logic, Language and Information (7:4, 1998). The proceedings of the international conferences LACL`96 ,LACL`97, LACL`98 et LACL`2001 appeared in the series Lecture Notes in Artificial Intelligence (volumes 1328, 1582, 2014, 2099) published by Springer. Topics ------ Computer scientists, linguists, mathematicians and philosophers are invited to present their work on the use of logical methods in computational linguistics and natural language processing, in natural language analysis, generation or acquisition. * logical foundation of syntactic formalisms * categorial grammars * minimalist grammars * dependency grammars * tree adjoining grammars * model theoretic syntax * formal language theory for natural language processing * data-driven approaches * logic for semantics of lexical items, sentences, discourse and dialog * discourse representation theory * Montague semantics * compositionality * dynamic logic * game semantics * situation semantics * generative lexicon * applications of these models to natural language processing * software for natural language analysis * software for acquiring linguistic resources * software for natural language generation * software for information extraction * question answering and human computer interaction in natural language * evaluation * scalability Submission format and publication --------------------------------- Articles should be written in the LaTeX format of LNCS/LNAI by Springer should not exceed 16 pages (including figures, bibliography, possible apendices). Articles, in PDF format, should be sent by email to lacl(a)labri.fr. Accepted papers, after revision if needed, will be published as a volume of the LNAI/LNCS series by Springer-Verlag. Scientific inquiries: --------------------- Philippe Blache blache(a)lpl.univ-aix.fr Edward Stabler stabler(a)ucla.edu Practical inquiries : --------------------- Joan Busquets busquets(a)u-bordeaux-3.fr Richard Moot moot(a)labri.fr Brigitte Larue-Bourdon +33 5 40 00 69 30 Important dates: ---------------- Paper submission deadline : monday 3rd january 2005 Notification of acceptance : monday 14th february 2005 Camera-ready papers due : monday 28th february 2005 LACL conference : thursday 28th, friday 29th, and saturday 30th april 2005 Program committee : ------------------- Philippe Blache (co-chair)(CNRS LPL Aix-en-Provence) Edward Stabler (co-chair) (University of California, Los Angeles CA) Johan Bos (University of Edinburgh) Joan Busquets (Université Bordeaux 3 & ERSS-CNRS & INRIA-Futurs) Henning Christiansen (Roskilde Universitetscenter, Roskilde) Veronica Dahl Simon Fraser University, Vancouver) Denys Duchier (INRIA-Lorraine & LORIA, Nancy) Marc Dymetman (Xerox Research Center Europe Grenoble) Sandiway Fong (University of Arizona, Tucson AZ) Kim Gerdes (Université Bordeaux 3 & ERSS-CNRS & INRIA-Futurs) Philippe de Groote (INRIA-Lorraine & LORIA,Nancy) Gerhard Jäger (Universität Potsdam) Marcus Kracht (University of California, Los Angeles CA) Alain Lecomte (Université Grenoble 2) Uwe Mönnich (Universität Tübingen) Michael Moortgat (Universiteit Utrecht) Richard Moot (CNRS LaBRI & INRIA-Futurs) Glyn Morrill (Universitat Politècnica de Catalunya, Barcelona) Gerald Penn (University of Toronto) Christian Retoré (Université Bordeaux 1 & LaBRI-CNRS & INRIA-Futurs) Maarten de Rijke (Universiteit van Amsterdam) James Rogers (Earlham College, Richmond IN) Vijay Shanker (University of Delaware, Newark DE) Mark Steedman (University of Edinburgh) Organizing committee : ---------------------- Joan Busquets (co-chair) (Université Bordeaux 3 & ERSS-CNRS & INRIA-Futurs) Richard Moot (co-chair) (CNRS LABRI & INRIA-Futurs) Maxime Amblard (Université Bordeaux 1 & LaBRI-CNRS & INRIA-Futurs) Catherine Girard (INRIA-Futurs) Patrick Henry (CNRS LaBRI & INRIA-Futurs) Brigitte Larue-Bourdon (INRIA-Futurs) Jean-Louis Lassartesses (Université Bordeaux 1) Christian Retoré (Université Bordeaux 1& LaBRI-CNRS & INRIA-Futurs) LACL 2005 web site: http://lacl.labri.fr Désolé des envois répétés / merci de redistribuer à toute personne intéressée ********************************************************************************* L A C L 2 0 0 5 Logical Aspects of Computational Linguistics -- fifth international conference Aspects logiques de la linguistique informatique -- cinquième colloque international --- 28-29-30 avril 2005, Bordeaux (France) http://lacl.labri.fr/ CNRS - INRIA -- Universités Bordeaux 1 & 3 ******************************************************************************** Date limite de soumission des articles : lundi 3 janvier 2005 Les colloques LACL ------------------ LACL-2005 est la 5ème édition d'une série de colloques internationaux portant sur les aspects logiques et formels de la linguistique informatique. On y traite plus particulièrement de la description de la syntaxe et de la sémantique des langues dans le cadre de théories logiques, ainsi que de réalisations informatiques basées sur de tels modèles. Une sélection des articles de 1995 est parue comme numéro spécial du Journal of Logic, Language and Information (7:4, 1998). Les actes de LACL`96 ,LACL`97, LACL`98 et LACL`2001 ont ensuite été publiés par Springer dans la collection Lecture Notes in Artificial Intelligence (volumes 1328, 1582, 2014, 2099). Thématique ---------- Informaticiens, linguistes, mathématiciens et philosophes sont invités à présenter leurs travaux sur les méthodes logiques utilisées en Traitement Automatique des Langues (TAL), que ce soit pour l'analyse, la génération ou l'acquisition du langage naturel. * fondements logiques et informatiques des formalismes syntaxiques * grammaires catégorielles * grammaires minimalistes * grammaires de dépendances * TAGs * syntaxe et théorie des modèles (model theoretic syntax) * théorie des langages pour le TAL * analyse guidée par les données (data-driven approaches) * logiques pour la sémantique du mot, de la phrase, du discours ou du dialogue * théorie de la représentation du discours * sémantique de Montague * compositionnalité * logique dynamique * sémantique des jeux * sémantique des situations * lexique génératif * réalisations de TAL utilisant des méthodes logiques * logiciels d'analyse du langage naturel * logiciels d'acquisition de ressources linguistiques * logiciels de génération de phrases ou de textes en langage naturel * systèmes de questions-réponses et interfaces homme machine en langage naturel * évaluation et passage à l'échelle des systèmes et logiciels fondés sur des méthodes logiques Format des articles soumis et publication ----------------------------------------- Les articles n'excèderont pas 16 pages (incluant figures, bibliographie et annexes éventuelles) et utiliseront le format LATEX de la collection LNCS/LNAI de Springer. Les articles, mis au format PDF, sont à envoyer par courrier électronique à l'adresse lacl(a)labri.fr. Les articles acceptés seront publiés après révisions éventuelles dans un volume de la collection LNCS/LNAI publié par Springer-Verlag. Renseignements scientifiques: ----------------------------- Philippe Blache blache(a)lpl.univ-aix.fr Edward Stabler stabler(a)ucla.edu Renseignements pratiques: ------------------------- Joan Busquets busquets(a)u-bordeaux-3.fr Richard Moot moot(a)labri.fr Brigitte Larue-Bourdon +33 5 40 00 69 30 Calendrier ----------- Date limite de soumission des articles : lundi 3 janvier 2005 Date de notification aux auteurs: lundi 14 février 2005 Date limite d'envoi des articles corrigés: lundi 28 février 2005 Dates du colloque: jeudi 28 vendredi 29 et samedi 30 avril 2005 Comité de programme: -------------------- Philippe Blache (co-président) (CNRS LPL Aix-en-Provence) Edward Stabler (co-président) (University of California, Los Angeles CA) Johan Bos (University of Edinburgh) Joan Busquets (Université Bordeaux 3 & ERSS-CNRS & INRIA-Futurs) Henning Christiansen (Roskilde Universitetscenter, Roskilde) Veronica Dahl Simon Fraser University, Vancouver) Denys Duchier (INRIA-Lorraine & LORIA, Nancy) Marc Dymetman (Xerox Research Center Europe Grenoble) Sandiway Fong (University of Arizona, Tucson AZ) Kim Gerdes (Université Bordeaux 3 & ERSS-CNRS & INRIA-Futurs) Philippe de Groote (INRIA-Lorraine & LORIA,Nancy) Gerhard Jäger (Universität Potsdam) Marcus Kracht (University of California, Los Angeles CA) Alain Lecomte (Université Grenoble 2) Uwe Mönnich (Universität Tübingen) Michael Moortgat (Universiteit Utrecht) Richard Moot (CNRS LaBRI & INRIA-Futurs) Glyn Morrill (Universitat Politècnica de Catalunya, Barcelona) Gerald Penn (University of Toronto) Christian Retoré (Université Bordeaux 1 & LaBRI-CNRS & INRIA-Futurs) Maarten de Rijke (Universiteit van Amsterdam) James Rogers (Earlham College, Richmond IN) Vijay Shanker (University of Delaware, Newark DE) Mark Steedman (University of Edinburgh) Comité d'organisation: ---------------------- Joan Busquets (co-président) (Université Bordeaux 3 & ERSS-CNRS & INRIA-Futurs) Richard Moot (co-président) (CNRS LABRI & INRIA-Futurs) Maxime Amblard (Université Bordeaux 1 & LaBRI-CNRS & INRIA-Futurs) Catherine Girard (INRIA-Futurs) Patrick Henry (CNRS LaBRI & INRIA-Futurs) Brigitte Larue-Bourdon (INRIA-Futurs) Jean-Louis Lassartesses (Université Bordeaux 1) Christian Retoré (Université Bordeaux 1& LaBRI-CNRS & INRIA-Futurs) Site Internet de LACL 2005: http://lacl.labri.fr

1 0

Haskell in industry?
by Heribert.Schuetz.extern＠HVB.de 16 Sep '04

16 Sep '04

Hello, I am currently working on the redesign of some software system that has been developed in-house at a bank. To get a proof-of-principle implementation up and running quickly, I decided to use a high-level programming language. I returned to Haskell, which I used a few years ago in an academic environment. It turned out that Haskell really allowed me to implement something quite powerful in relatively short time. Meanwhile I am quite convinced that Haskell might not only be the right choice for a prototype, but also for the "real thing". But inevitably some people around here are scared about about the risks of using a non-mainstream programming language, and to some degree I understand them. The questions they are asking include: * Are there any references for using Haskell in industry? (I have looked at the Haskell-in-Practice page on haskell.org, but there I can't see how seriously all these applications are being used. For some of them it is immediately clear that they are academic or toy applications. But others might actually be used in production. I would be particularly interested in customer-specific software projects that have used Haskell.) * Can Haskell code be integrated with .NET, in case the department should decide to base more of its software on this platform? (I have found Sigbjorn Finne's integration of Hugs with .NET, but I would prefer the native-code compilation of GHC. I remember rumors about such a project years ago when Simon PJ went to Microsoft, but didn't find anything recent about this on the Web. I found notes about the GHC/.NET integration in the Mondrian project, but that appears to be unmaintained. Correct me if I am wrong.) * Will Haskell programmers be available 5 years from now to do the rather boring work of maintaining a then-legacy system? (Well, here I don't expect definitive answers. I just mentioned it here to give you a more complete picture. Unfortunately there was not much response to Jochen Leidner's message from September 2. BTW, with "then-legacy system" ) * Can't much of the simplicity of the Haskell code also be reached by just switching from C++ to something like Java or C#? (Probably an example from the application domain will be most convincing. So I probably have to bite the bullet and reimplement some code in Java or C#. But if you have some examples, they might be helpful. The quicksort example in http://www.haskell.org/complex/why_does_haskell_matter.html is unfortunately Haskell vs. C++.) I would be grateful for your hints, Heribert. PS: If I get permission from the bank, I will be happy to report in more detail about the project, which is an interesting Haskell application of its own.

5 6

arrows
by Sebastian Boldt 15 Sep '04

15 Sep '04

Hello, I am a bit confused about command stacks. I tried to run the following code in ghc: mshowA :: (Arrow a, Show b) => a (b, String) String mshowA = proc (x,s) -> returnA -< s ++ show x ++ s f :: Arrow a => a Int String f = proc x -> do a <- (mshowA -< x) "***" returnA -< a To my understanding (this doesn't mean anything :-) this is correct because (mshowA -< x) "***" should be equivalent to (mshowA -< (x,"***")), but somehow ghc is rejecting the code with the error message "Non-empty command stack at command: mshowA -< x". The arrow pre-processor from Ross Paterson compiles the code with no problems to ordinary haskell and the resulting code runs as expected in ghc, so, my question is, what's wrong? Me, ghc, arrowp... Thanks in advance for every answer or hint you can give me ...Sebastian

1 0

RE: [Haskell] Haskell in industry?
by Nick Benton 15 Sep '04

15 Sep '04

Haskell and ML certainly have advantages over Java and C#. But it's important to realise firstly that they have disadvantages too, and secondly that the imperative/OO languages are evolving fast. When the mainstream was only C/C++, the most important advantage of functional languages was garbage collection. Once Java and C# became popular, polymorphism became the "unique selling proposition". But now both Java and C# have generics and anonymous functions. For example, in C# 2.0 the most obvious translation of map is just static IEnumerable<T2> map<T1,T2>(IEnumerable<T1> arg, Converter<T1,T2> f) { foreach (T1 x in arg) yield return f (x); } this is type-safe, takes any type of collection as input and returns a lazily-evaluated collection of results. Or we could have static S2 map<T1, T2, S1, S2>(S1 arg, Converter<T1, T2> f) where S1:IEnumerable<T1> where S2:ICollection<T2>,new() { S2 result = new S2(); foreach (T1 x in arg) result.Add(f(x)); return result; } Which is parameterized over both the element types *and* both the collection types. You can use it like this: int[] myints = { 1, 2, 3 }; List<string> mystrings = map<int,string,int[],List<string>>( myints, delegate (int i) {return (i+1).ToString();}); where I've mapped over an array, producing a list and passing in an anonymous function. You can download the free beta of Visual C# Express and compile that code today, within a powerful IDE. Plus C# lets you do all sorts of real-world things (graphics, networking, database access, web page generation,...) considerably more conveniently that most existing implementations of functional languages. Agreed, the syntax of these examples is a bit heavy (though Java has more inference for type parameters than C#), but if we want to argue the genuine advantages of functional programming, especially in an industrial context, "map" just isn't enough any more. One possible position is simply to declare victory - generics and anonymous functions wouldn't be in Java and C# if it weren't for functional programmers. Another is to move the discussion to a higher level and start to talk about reasoning principles, rather than comparing lines of code. This is where the real advantages come, but it's a pretty subtle argument to put to a PHB, I fear. Nick -----Original Message----- From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Vincenzo aka Nick Name Sent: 15 September 2004 00:25 To: haskell(a)haskell.org Subject: Re: [Haskell] Haskell in industry? On Tuesday 14 September 2004 18:18, Heribert.Schuetz.extern(a)HVB.de wrote: > * Can't much of the simplicity of the Haskell code also be > reached by just switching from C++ to something like Java or C#? > (Probably an example from the application domain will be most > convincing. So I probably have to bite the bullet and reimplement > some code in Java or C#. But if you have some examples, they might be > helpful. I don't have examples but I've been working with C# 8 hours per day for 6 months and I ensure you that no, they are not simple. C++ is simpler for enterprise uses than C#, IMHO, because you fundamentally reuse other people libraries and so worry _less_ about memory management than you'd expect, but YMMV. On the other hand, C# has NO parametric polymorphism and after a while I've begun to miss C++ templates. C# has functional programming, they say, but no you can't use a method name as a function. You first have to create an "event". Composing this with the absence of parametric polymorphism and type inference, here's what a _monomorphic_ "map" function looks like, with a possibly naive syntax because I don't have the compiler handy (and worked 8 hours today,too). ///// public delegate int myDelegate(int i); //This is a type declaration public ArrayList map(myDelegate fn,ArrayList list); // Note that the list is untyped, but the function is strongly typed. { ArrayList result = new ArrayList(); foreach (Object obj in list) { result.Add(fn(obj)); } return result; } ///// 6 rows of effective code, untyped, contrived and poorly reusable. And this is the way you call it (you already know, ok, but now I am having fun :)) public int increment(int i) { return i+1; } map(new myDelegate(increment),myList); // note the call to "new" The map function from the haskell prelude: map f xs = [f x | x <- xs] and how you call it: map (\ x -> x+1) myList It's strongly typed, polymorphic and reusable. And it's far more readable and clear in intent, too. Do I need to say more? If you have the possibility to use haskell, ocaml or SML at work, do so :) OK, I realize that you already knew haskell, but you asked first :) Vincenzo _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell

1 0

Re: [Haskell] Haskell in industry?
by Graham Klyne 15 Sep '04

15 Sep '04

At 20:18 14/09/04 +0200, Heribert.Schuetz.extern(a)HVB.de wrote: >Meanwhile I am quite convinced that Haskell might not only be the right >choice for a prototype, but also for the "real thing". But inevitably some >people around here are scared about about the risks of using a >non-mainstream programming language, and to some degree I understand them. >The questions they are asking include: And to make a completely different, if unworthily cynical, kind of response to this question... It seems to me that an awful lot of demonstrable prototypes get tidied up and delivered as final code. So by using Haskell for prototyping, the sales-people might resolve the other question for you ;-) #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

Re: [Haskell] Haskell in industry?
by Graham Klyne 15 Sep '04

15 Sep '04

I regard myself as a practical "in the trenches" kind of programmer, not an academic researcher, (though I seem to work in the murky no-man's-land between research and commercial exploitation, and have tended to operate at the "bleeding edge" for my commercial work). I see real value in Haskell as a language for commercial use, *provided* it gets strong library support for a range of support functions. FWIW, I have used Haskell to implement tools for helping me perform some real work ([1] is a document prepared from Semantic Web data using, in part, a translator program [2] written in Haskell), but as yet have not delivered any commercial code written in Haskell. [1] http://www.ietf.org/internet-drafts/draft-klyne-hdrreg-mail-05.txt [2] http://www.ninebynine.org/Software/CompileRDF/RepToRDFMain.hs (and related files) At 20:18 14/09/04 +0200, Heribert.Schuetz.extern(a)HVB.de wrote: >* Will Haskell programmers be available 5 years from now to do the >rather boring work of maintaining a then-legacy system? (Well, here I don't >expect definitive answers. I just mentioned it here to give you a more >complete picture. Unfortunately there was not much response to Jochen >Leidner's message from September 2. BTW, with "then-legacy system" ) I think that several universities are teaching Haskell now (I note that Oxford teaches Haskell as the *first* language introduced in its CS course). This bodes well for future availability of programmers who have at least heard of Haskell. I've been talking to people about using Haskell in conjunction with the Web (especially Semantic Web), where I think there is a good fit (if/when the required support libraries are available). The kind of response I'm getting is not so much "Haskell what?" (as it is in some other fields), but "I've heard of that, it looks cool, I must investigate further". >* Can't much of the simplicity of the Haskell code also be reached by >just switching from C++ to something like Java or C#? (Probably an example >from the application domain will be most convincing. So I probably have to >bite the bullet and reimplement some code in Java or C#. But if you have >some examples, they might be helpful. The quicksort example in >http://www.haskell.org/complex/why_does_haskell_matter.html is unfortunately >Haskell vs. C++.) For small programs, I think Haskell simplicity is difficult to transfer into other languages. The use of higher order functions seems to open up a number of very neat ways of expressing algorithmic ideas. For larger programs, I'm less certain, in that it seems to me that the overhead of organizing larger bodies of code may be largely independent of the language. That said, Haskell seems to support a wider range of programming styles and idioms within what is at core a very simple language design. (An example I think of is the work on aspect-oriented programming in conventional OO languages, one of whose goals is separation of cross-cutting concerns. It seems to me that this potential comes for free in a language with higher order functions.) In a world where software reliability concerns are becoming more widespread and urgent, I think think Haskell has some real advantages that other languages really would be hard-pushed to match. So, for commercial use, I guess I'd be more inclined to emphasize that aspect than simplicty. (The fly-in-the-ointment here is predicting resource usage, which can impact reliability. Much as I like Haskell, maybe ML would be a better choice?) Further, I think that Haskell has great strengths from a software engineering standpoint, in that higher order functions provide a powerful set of tools for isolating different parts of an application. I've generally been very impressed by how easy it is to use a variety of different function libraries working together in a single application -- there seems to be little need to overcome stylistic programing idioms to make different libraries work together cleanly (this is less true of libraries that are heavily monad-based, IMO). (Cf. the "Scrap your boilerplate" work.) Another factor, central to your concerns, is maintainability. Usually, I really hate trying to figure out other people's code. With Haskell, I have found the process to be quite painless. Once the relevant higher-level concepts have been identified, working with and modifying existing code seems to be quite easy. (Again, in my experience, less so where monads are heavily used.) And finally, tangentially, there's an article someone told me about recently that is probably quite well known to old hands in this community, but which was new to me... "Haskell vs. Ada vs. C++ vs. Awk vs. ..., An Experiment in Software Prototyping Productivity" http://www.haskell.org/papers/NSWC/jfp.ps #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

ACL2 Workshop, Nov. 18-19
by Matt Kaufmann 14 Sep '04

14 Sep '04

Greetings [and apologies if you get multiple copies]: The fifth ACL2 Workshop will be held November 18-19, 2004, in Austin Texas, USA, in conjunction with (and immediately following) FMCAD. We invite users of ACL2, users of other theorem provers, and persons interested in the applications of theorem proving technology to attend. ACL2 is a state-of-the-art automated reasoning system, which grew out of the Boyer-Moore theorem prover and has been used successfully on a number of industrial and academic projects. ACL2 is described at http://www.cs.utexas.edu/users/moore/acl2. The ACL2 workshops provide a forum for the presentation and discussion of projects using ACL2 as well as the evolution of the tool. For more information, including a schedule of talks and general information (including registration, which costs less prior to October 15, and lodging), see: http://www.cs.utexas.edu/users/moore/acl2/workshop-2004/ Regards, Matt Kaufmann and J Moore (Organizing Committee)

1 0

RE: [Haskell] Applicative translucent functors in Haskell
by Simon Peyton-Jones 13 Sep '04

13 Sep '04

| cumbersome. This message is an attempt to interpret some of Ken's | results in idiomatic Haskell with the full use of type classes. We | will also show that type sharing constraints can be expressed in a | scalable manner, so that the whole translation is practically | usable. Thus we can enjoy the sophisticated, first-class higher-order | module system in today's Haskell. No new extensions are required; Crafty. You might want to show it to Derek Dreyer and other ML module experts. The ML orthodoxy says that it's essential to give sharing constraints by name, not by position. If every module must be parameterised by every type it may wish to share, modules might get a tremendous number of type parameters, and matching them by position isn't robust. I think that would be the primary criticism from a programming point of view. I have no experience of how difficult this would turn out to be in practice. Simon

3 3

parsing and printing user defined types
by Stephan Zaubzer 11 Sep '04

11 Sep '04

Hi Guys! I have defined the following type: data Entry a = EmptyEntry | MakeEntry a a i have defined show and read as follows: --------------------------------------------- instance (Show a) => Show (Entry a) where showsPrec _ x = showEntry x showEntry :: (Show a) => Entry a -> String -> String showEntry EmptyEntry = shows "Empty" showEntry (MakeEntry a b) = shows a . (':':) . (' ':) . shows b instance (Read a) => Read (Entry a) where readsPrec _ s = readEntry s readEntry :: (Read a) => ReadS (Entry a) readEntry s = [(EmptyEntry, x) | ("Empty", x) <- lex s] ++ [(MakeEntry a b, w) | (a, u) <- reads s, (": ", v) <- lex u, (b, w) <- reads v] ------------------------------------------------ when I use show or read in any function, i get the following errormessage from hugs: ERROR "./main.hgs":14 - Cannot justify constraints in explicitly typed binding *** Expression : getandparse *** Type : String -> Entry a *** Given context : () *** Constraints : Read a printing an instance of Entry directly ( print (MakeEntry "Hello" "World") ) works. But using print in a function that takes a string, doesn't work... Does anybody have an idea how to solve the problem? thanks Stephan

1 0