- Haskell - Haskell.org

Java class file reader
by Jacques Carette 14 Jul '04

14 Jul '04

Does anyone have a Java class file reader (written in Haskell, naturally)? I have found a writer, but no reader? [Google came up empty...] If this does not exist (yet), any recommendations as to how one goes about reading such mixed binary data? Thanks for any help, Jacques

1 0

Problem with HSQL 1.4
by Alfonso 14 Jul '04

14 Jul '04

Hello, My name is Alfonso Meléndez I work at Escuela Colombiana de Ingeniería in the Computer Scienca Faculty. I work with ghc 6.2.1 and I Install HSql-1.4 but when I try to run the test programs I obtain the message of mismatched interface file versions: C:/Archivos de programa/HaskellDB/test/TestConnect.hs:1: Failed to load interface for `Database.HSQL': Bad interface file: c:/HToolkit/HSQL/GHC/imports/Database/HSQL.hi mismatched interface file versions: expected 6021, found 6020 I guess the installer for HSQL-1.4 installs the 6.2 interface fles and not the 6.2.1. files Is the installer wrong? Or maybe I made a mistake? Thank you Alfonso Meléndez Dirección de Proyectos Facultad de Ingeniería de Sistemas Escuela Col de Ingeniería Tels: 676266,6763888, Ext: 224, 371 Cel: (315) 8938216 ##################################################################################### This e-mail message has been scanned for Viruses and Content and cleared by NetIQ MailMarshal #####################################################################################

1 0

GHC fixes for alternative main module/function on general release?
by Graham Klyne 14 Jul '04

14 Jul '04

I recall there was a problem with the options for specifying alternative main module/function names in the last release of GHC that I tested with. Is this now fixed in a generally released version? #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

Availability of Hugs with Unicode support?
by Graham Klyne 14 Jul '04

14 Jul '04

When can I expect a version of Hugs with Unicode support to be generally released? I've been using an unofficial build of Hugs with Unicode character support to develop enhancements to the HaXml parser which are needed for my RDF/XML parser. I'm starting to think about packaging these as a general release, but if this relies on a non-standard Hugs build, that's likely to make my software harder to install and use. I'd really like to be able to test my release kit against a general release of Hugs (as well as GHC of course). #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

Call for software demonstration at the MathUI workshop
by Paul Libbrecht 14 Jul '04

14 Jul '04

:please distribute: Call for Software Demonstrations -------------------------------- at the Mathematical User Interfaces Workshop Sept 18th 2004, Bialowezia, Poland before the Third Mathematical Knowledge Management Conference The workshop will host a one-hour session of software demonstration. Interested contributors are requested follow instructions at: http://www.activemath.org/~paul/MathUI/

1 0

CFP: TFP04 Symp on Trends in Functional Programming
by Hans-Wolfgang Loidl 13 Jul '04

13 Jul '04

[ Functional apologies for repeated copies of this message apply -- HWL ] CALL FOR PAPERS TFP 2004 Fifth Symposium on Trends in Functional Programming November 25-26th 2004, Ludwig-Maximilians University, Munich, Germany http://www.tcs.ifi.lmu.de/~hwloidl/TFP04 The Symposium on Trends in Functional Programming is an international forum for researchers with interests in all aspects of functional programming languages. It succeeds TFP03 in Edinburgh and continues the Scottish Functional Programming Workshop series from 1999-2002. Papers on all aspects of functional programming are welcomed, be they theoretical, implementation-oriented, or experience papers. The venue for this year's symposium will be Ludwig-Maximilians University in central Munich. WORKSHOP TOPICS Papers on any aspect of functional programming are welcomed. Papers on the following subject areas are particularly welcome: * design and implementation of functional or declarative languages; * rich type systems, including type systems for expressing side-effects, resource bounds, or other safety properties; * linear type systems, soft type systems, typeful programming; * formal aspects of functional programming, semantics, reasoning, verification; * inductive or co-inductive techniques, proof nets; * mobile-code functional programming languages; * parallel programming with functional languages, cost models for functional programs; * functional aspects of imperative programming, functional bytecode; * interoperability with imperative programming languages, calling imperative from functional or vice versa; * type inference algorithms, type error repair, deep types; * strongly-typed imperative languages with inference; * optimisation techniques, implementation techniques, and performance measurements; * experience papers: applications of functional programming or functional programming in education. PROCEEDINGS As with the previous instances of TFP and SFP, we intend to publish a high-quality subset of contributions in the Intellect Trends in Functional Programming series. All speakers attending the workshop are invited to submit a paper for the draft proceedings. Revised papers will be refereed after the symposium according to normal conference standards for publication by Intellect. This implies (among other things) that: * the paper should be written in English * the paper is well written * the topic of the paper should be stated clearly * the approach to solve the problem should be outlined clearly * a detailed discussion of the solution has to be given * the solution is compared with relevant related work * there is an abstract, introduction and conclusion. * the conclusion should summarise the problem, the solution, and how this solves the problem. * papers must not exceed 16 pages. * the paper should conform to the TFP format <http://www.tcs.ifi.lmu.de/~hwloidl/TFP04/cameraready.zip> * the paper should be submitted as a PostScript or a PDF file by email to the programme chair, Hans-Wolfgang Loidl <hwloidl(a)informatik.uni-muenchen.de> DATES Nov 1st 2004: Registration deadline Nov 15th 2004: Submission for draft proceedings Nov 25-26th 2004: Symposium at Ludwig-Maximilians University, Munich Dec 20th 2004: Submission for referees process Jan 31st 2005: Notification of acceptance/rejection PREVIOUS WORKSHOPS The previous instance of TFP was held in Edinburgh 2003 and continues the Scottish Functional Programming Workshop series with previous meetings at Stirling (2001), St. Andrews (2000), and Stirling (1999). The TFP series <http://www.tifp.org/> strives to combine an active workshop environment for presenting latest research, with a formal post-symposium refereeing process and the publication of a high-profile proceedings (see <http://www.intellectbooks.com/authors/hammond/trends3.htm>). For a review of past TFP proceedings, see the July 2003 issue of the JFP 13(4):823-824 at <http://titles.cambridge.org/journals/JFP/>. Sponsorship funding available to us will be used to reduce registration rates for PhD students, who present proof of affiliation in advance of the symposium. PROGRAM COMMITTEE (PROVISIONAL) * Stephen Gilmore, University of Edinburgh * Gaetan Hains, Universite d'Orleans * Kevin Hammond, University of St Andrews * John Hughes, Chalmers University * Hans-Wolfgang Loidl, Ludwig-Maximilians-University Munich (Chair) * Rita Loogen, Philipps-University Marburg * Bruce McAdam, Robert Gordon University * Greg Michaelson, Heriot-Watt University * John O'Donnell, University of Glasgow * Ricardo Pena, Universidad Complutense de Madrid * Phil Trinder, Heriot-Watt University * Phil Wadler, University of Edinburgh SPONSORS TFP is supported this year by the APPSEM II Thematic Network and the Mobile Resource Guarantees project, funded by the IST programme of the European Union.

1 0

SCP Special Issue on Foundations of Aspect-Oriented Programming
by Ralf Laemmel 13 Jul '04

13 Jul '04

[ Functional programming has contributed to the foundations of AOP over the last few years. For instance, see Walker's and Wand's contributions at ICFP 2003. ] Special Issue on Foundations of Aspect-Oriented Programming Science of Computer Programming Guest Editors: Pascal Fradet and Ralf Lämmel Call for contributions Modularity concepts support the separation of concerns, and hence they are crucial for mastering the complexity of software. In recent years, the modularity concept of aspects has been introduced. Aspects facilitate the modularisation of crosscutting concerns. The corresponding paradigm, aspect-oriented programming (AOP), is part of a larger effort -- Aspect-Oriented Software Development (AOSD). Clearly, AOP and AOSD have attracted a great deal of interest: various AOP tools are being developed and AOP is now successfully used in real-world applications. However, a widely shared criticism of AOP is that it still lacks firm foundations. For instance, the untamed form of AOP that we see today is often criticised for defeating encapsulation and preventing local reasoning. Likewise, the interference of multiple aspects is considered an unacceptable risk of current AOP techniques. This special issue is dedicated to the foundations of aspect-oriented programming including formal methods, tools, languages and calculi. The special issue goes along with the successful series of FOAL workshops (Foundations of Aspect Oriented Languages), but submission to the special issue is completely open. The special issue will be published in the journal Science of Computer Programming, which implies excellent visibility and high quality standards. The guest editors solicit high-quality contributions that address the foundations of AOP, and that improve the state of the art of developing, understanding, controlling and reasoning about aspect-oriented programs. Work on modularity concepts other than aspects is also solicited provided that such work is clearly related to AOP. For instance, fundamental contributions to reflection are likely to be relevant for the foundations of AOP. Specific topics of interest include, but are not limited to: * Reasoning about aspect-oriented programs. * Semantics of aspects and weaving. * Formal aspect languages or calculi. * Formal properties of aspects, advice, and join-point models. * Type systems for aspect-oriented languages. * Verification and static analysis of aspect-oriented programs. * Theory of aspect composition and aspect interactions. * Aspect-oriented programming pearls. Deadline for submissions: *1 February 2005* Author's notification: 1 June 2005 Special issue's publication: Winter 2005/2006 Special issue's web site: http://www.cs.vu.nl/faop-scp/ The submissions should be sent in PDF or Postscript to the guest editors via email: Pascal.Fradet(a)inria.fr, Ralf.Laemmel(a)cwi.nl. Authors who want to discuss potential submissions are encouraged to contact the guest editors. For details about the policy of the Science of Computer Programming journal, and the requirements for prospective authors see a recent issue of the journal and check the journal's web site http://www.elsevier.com/locate/scico/.

1 0

Any way to change state type in a monad?
by Ben.Yu＠combined.com 13 Jul '04

13 Jul '04

Hi, I'm trying to implement some rule combinators. I'm hoping my combinators can change the state type implicitly passed around. Basically, a rule should be something like: newtype Rule m u u' = ... where it takes an input u and returns type u' as the result. m represents an inner monad. For the supported operations, I'd like to bind my rules with compatible output and input types; `mplus` rules with same input and output types; 'try' a rule without changing state in m; tell if a rule succeeded or failed and take action accordingly. For the latter two, it has been pretty tricky to me. Looks like many monads don't support such functionality. It does not seem like possible to do this in a monad because Monad is for type constructors with only one parameter while Rule m u u' and Rule m u' u'' obviously cannot be in the same monad type. So, is this design inherently flawed or there's just no such implementation yet? Thanks. Ben. This message is intended only for the addressee and may contain information that is confidential or privileged. Unauthorized use is strictly prohibited and may be unlawful. If you are not the intended recipient, or the person responsible for delivering to the intended recipient, you should not read, copy, disclose or otherwise use this message, except for the purpose of delivery to the addressee. If you have received this email in error, please delete and advise us immediately.

2 1

Re: [Haskell] for large x, log (x::Integer) :: Double
by Edmund GRIMLEY EVANS 13 Jul '04

13 Jul '04

Dylan Thurston: > For those who aren't aware: working with logs base 2 internally will > be very much faster than logs base 10, since the numbers are stored > internally in a base-2 representation. (Note that 'show' converts to > base 10, which involves a large number of divisions in the easy > algorithm.) Does Haskell provide any means of determining the number of binary digits in an Integer other than by repeated division? In the absence of an appropriate built-in or library function it may be that the fastest way is to use (length (show x)), multiply by some fiddle factor, add some fiddle term to get n, then check whether x < 2 ** n. Could "log2 :: Integer -> Integer" be added to some wish list?

3 4

Re: [Haskell] type class does not compile
by Graham Klyne 13 Jul '04

13 Jul '04

At 19:24 12/07/04 -0500, Ben.Yu(a)combined.com wrote: >Hi, >please bear with me if my question turns out to be a stupid mistake. It has >taken me hours to figure this out. > >class Rule r u u' m where > apply :: r -> u -> m u' > >data And = And > >data Bin a b o = Bin a b o > >instance (Monad m, Rule r1 u u' m, Rule r2 u' u'' m) => Rule (Bin r1 r2 >And) u u'' m where > apply (Bin r1 r2 _) u = apply r1 u >>= apply r2 > >Ghc complains about "Could not deduce (Rule r1 u u'1 m, Rule r2 u'1 u'' >m)", but it is obviously same as the constraint I gave in the instance >declaration. > >What am I doing wrong here? There's no information in the instance type for the compiler to figure out what u' (in the constraint expressions) might be. (See other responses.) ... I would question whether or not you really should be using a type class here -- that depends on your application, but I've done some work involving simple inference rules and found that a polymorphic algebraic datatype (with function-valued members) served my purposes better than a type class. #g -- >Thank you very much! > > >This message is intended only for the addressee and may contain information >that is confidential or privileged. Unauthorized use is strictly prohibited >and may be unlawful. If you are not the intended recipient, or the person >responsible for delivering to the intended recipient, you should not read, >copy, disclose or otherwise use this message, except for the purpose of >delivery to the addressee. If you have received this email in error, please >delete and advise us immediately. > >_______________________________________________ >Haskell mailing list >Haskell(a)haskell.org >http://www.haskell.org/mailman/listinfo/haskell ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0