Stricts _
ghci-6.3 (from CVS) shows me strictness information when I request :info for a data type, like: [...] Send Mailbox Stricts: _ [...] I have no idea how to read that output, and it doesn't seem to be documented in the manual either. Does the underscore signify that (in the example above) Mailbox is a strict value? Or is it the opposite? Sorry if this is a dumb question, but I simply don't know it. :-) Peter ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Stricts _
On 13 July 2004 15:02, Peter Simons wrote: ghci-6.3 (from CVS) shows me strictness information when I request :info for a data type, like: [...] Send Mailbox Stricts: _ [...] I have no idea how to read that output, and it doesn't seem to be documented in the manual either. Does the underscore signify that (in the example above) Mailbox is a strict value? Or is it the opposite? Sorry if this is a dumb question, but I simply don't know it. :-) I don't think :info is working properly in the HEAD right now. It's something we need to fix before 6.4. I suggest just ignoring the spurious output for now. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Stricts _
On Tue, Jul 13, 2004 at 03:16:39PM +0100, Simon Marlow wrote: On 13 July 2004 15:02, Peter Simons wrote: ghci-6.3 (from CVS) shows me strictness information when I request :info for a data type, like: [...] Send Mailbox Stricts: _ [...] I have no idea how to read that output, and it doesn't seem to be documented in the manual either. Does the underscore signify that (in the example above) Mailbox is a strict value? Or is it the opposite? Sorry if this is a dumb question, but I simply don't know it. :-) I don't think :info is working properly in the HEAD right now. It's something we need to fix before 6.4. I suggest just ignoring the spurious output for now. Based on :info Maybe and :info Complex.Complex the info looks right to me, with _ meaning non-strict and ! meaning strict. Presumable you mean that it should print just Send Mailbox or Send !Mailbox? I assume this is just what you told GHC when you defined the type, though, rather than telling you anything about optimisations GHC has done. Also, it looks like :info doesn't work for tuples: Prelude :info (,,) -- *** Exception: No match in record selector TyCon.algTyConRhs Thanks Ian ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] type class does not compile
At 19:24 12/07/04 -0500, [EMAIL PROTECTED] 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 [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] for large x, log (x::Integer) :: Double
On Tue, Jul 13, 2004 at 05:01:32PM +0800, Dylan Thurston wrote: This library will let you use a shift instead of a division, but won't give you a constant time size function for Integers. You can easily get a logarithmic time size function from the shift. But did you see Data.Bits.bitsize? My mistake, bitSize is not useful for this purpose. Peace, Dylan signature.asc Description: Digital signature ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Any way to change state type in a monad?
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. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] SCP Special Issue on Foundations of Aspect-Oriented Programming
[ 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: [EMAIL PROTECTED], [EMAIL PROTECTED] 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/. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] CFP: TFP04 Symp on Trends in Functional Programming
[ 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 [EMAIL PROTECTED] 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 athttp://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,
Re: [Haskell-cafe] migrating from python
At 16:34 13/07/04 +0200, paolo veronelli wrote: I'm working on semantics and triples (RDF co) I've been working on something very similar, in Haskell. I also did some work in Python before moving to Haskell. My project is Swish [1]. (I've also just completed coding/testing of an RDF/XML parser, which I've yet to integrate into Swish.) It is my experience that at the heart of almost any inference process I have tried is a query of the RDF graph. (I've played with conventional rules and some class-based inference approaches, and a key operation seems to be query.) I don't know how different you expect the Haskell way to be -- it's maybe less so than one might expect. My own experience is that Haskell works more like a specification language than conventional programming approaches, and that it's relatively easy to maintain a close correspondence between executable code and a logical description of the domain information. But actually directing (planning) an inference process remains a tricky problem. Python's dictionaries are neat, and very easy to use. With Haskell you have to choose a mechanism, but there are many there, waiting to be used. So far, all my work has used a very primitive linear search (horribly inefficient, I know, but efficiency hasn't been my primary concern, and it's easy enough to swap out one mechanism for another. I'm not sure what kind of information you're after, so there's not much more I can say at this stage. But have fun with the functional way! It's taken me a while to get a feel for it; sometimes, things just seem to be unreasonably easy, and at other times it seems little different to any other language. #g -- [1] http://www.ninebynine.org/RDFNotes/Swish/Intro.html At 16:34 13/07/04 +0200, paolo veronelli wrote: I'm working on semantics and triples (RDF co) Python code for inference in based totally on dictionaries (associative arrays ??),nested three or four times. The result is astonishing me:compact beautiful modular and extremely readable. I imagine that haskell way should be different but I'm in the dark. As the stream of triples coming from outside estabilishes the actions to be done for inference,the searching through keys (the words that form any triple) is the main job:every time I pick up a triple I have to enlarge the knowledge more or less near the resources represented by the words. And after I have produced (possibly) some new inferred triples surely I have to reswitch on some already read triples, matching a pattern. All these are very natural with dictionaries, so I'd like to figure out the haskell view. Thanks for your quiteness and answers Paolino -- lotta dura per la verdura ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
