[Haskell] HaXml
I'd be grateful for some help on using HaXml. 1. I can parse a String into a Document but it's not clear how you operate on it as the combinators all operate on Content. The only function I could find that operated on a Document was document in Pretty. 2. I can construct a CFilter but it's not clear how you operate on it. How do I calculate the number of components of an Element? What I would like to do is accept vname (with 3 elements) and reject iname (with 4 elements). I'd also like to check that the characters in givenName, initial and familyName are in a given range (for example upper case or between ' ' and '~'). Thanks, Dominic. import Text.XML.HaXml import Text.XML.HaXml.Pretty xmlName = NamegivenNameJohn/givenName ++ initialP/initial ++ familyNameSmith/familyName ++ /Name d = document $ xmlParse tmp xmlName gn = mkElemAttr givenName [] [literal John] i = mkElemAttr initial [] [literal P] fn = mkElemAttr familyName [] [literal Smith] validName = mkElemAttr Name [] [gn,i,fn] invalidName = mkElemAttr Name [] [gn,i,i,fn] vname = processXmlWith validName iname = processXmlWith invalidName *Main d Name givenName John/givenName initial P/initial familyName Smith/familyName/Name *Main *Main vname ?xml version='1.0'? Name givenName John/givenName initial P/initial familyName Smith/familyName/Name *Main ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ICTCS'05 Preliminary call for papers
Apologies if you receive multiple copies of this mail Ninth Italian Conference on Theoretical Computer Science (ICTCS'05) Certosa di Pontignano (Siena), Italy October 12 - 14, 2005 Preliminary Call for Papers The Ninth Italian Conference on Theoretical Computer Science will take place at the Certosa di Pontignano (Siena), Italy. Papers presenting original contributions in any area of theoretical computer science are being sought. Topics include (but are not limited to): analysis and design of algorithms, computability, computational complexity, cryptography, formal languages and automata, foundations of programming languages and program analysis, foundations of artificial intelligence and knowledge representation, foundations of web programming natural computing paradigms (quantum computing, bioinformatics), parallel and distributed computation, program specification and verification, term rewriting, theory of concurrency, theory of data bases, theory of logical design and layout, type theory, security, symbolic and algebraic computation, Program Committee: Michele Bugliesi (Venezia), Mario Coppo (Torino, Co-Chair), Pierluigi Crescenzi (Firenze), Giulia Galbiati (Pavia) Luisa Gargano (Salerno), Giorgio Ghelli (Pisa), Roberto Grossi (Pisa), Benedetto Intrigila (L'Aquila), Nicola Leone (Cosenza), Elena Lodi (Siena, Co-Chair), Flaminia Luccio (Trieste), Andrea Masini (Verona), Giancarlo Mauri (Milano), Corrado Priami (Trento), Geppino Pucci (Padova), Davide Sangiorgi (Bologna). Organizing Committee: S. Brunetti (Siena), G. Michele Pinna (Cagliari - Siena, Chair), E.B.P. Tiezzi (Siena). Invited Speakers: Three invited speakers are foreseen. Names have to be announced. Dates and Deadlines: Submission Deadline: 15 April 2005 Acceptance Notification: 7 June 2005 Camera-ready deadline: 2 July 2005 Early registration deadline: 16 September 2005 Conference: 12-14 October 2005 Submissions: Authors are invited to submit electronically one copy of their extended abstract, not exceeding twelve pages. The extended abstract should clearly indicate the results achieved, their significance, and their relation to other work in the area. It is planned to publish the proceedings in the Springer Lecture Notes in Computer Science series. It is recommended to use Latex and the Springer LNCS style www.springer.de/comp/lncs. The web-based submission form will be announced soon. Conference Page: This preliminary Call For Papers is available online at the conference web page ictcs05.dsmi.unisi.it Registration Details: The registration form will be reachable from the conference web page. A limited number of grants for students and young researchers covering the registration fees are available. Details for the applications are in the conference web page. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Symposium on Principles of Programming Languages 2005: Call for Participation
POPL 2005 Call for Participation 32nd AnnualACM SIGPLAN - SIGACT Symposium on Principles of Programming Languages Long Beach, California January 12-14, 2005 http://www.cs.princeton.edu/~dpw/popl/05/ Scope of the Conference The annual Symposium on Principles of Programming Languages is a forum for the discussion of fundamental principles and important innovations in the design, definition, analysis, transformation, implementation and verification of programming languages, programming systems, and programming abstractions. Important Dates * Hotel reservation deadline: December 21, 2004 * Reduced fees deadline: December 30, 2004 (11:59 PM, EST USA) - Register at http://www.regmaster.com/popl2005.html * Main conference: January 12-14, 2005. * Affiliated events: January 10-11 and January 15, 2005 Invited Speakers * Pat Hanrahan (Stanford University) * Rob Pike (Google): Interpreting the Data * Peter Selinger (University of Ottawa): Programming Languages for Quantum Computing Location Hotel The POPL 2005 conference site is Hyatt Regency Long Beach, 200 South Pine Avenue, Long Beach, CA. Complete information concerning how to book rooms and travel to Long Beach may be found at the conference web site (http://www.cs.princeton.edu/~dpw/popl/05/). The Hyatt Regency is right next to a variety of entertainment areas, including the Shoreline Village, the Rainbow Harbor, and the Shoreline Marina, which offer sport fishing, boat rentals, personal boat rentals, shopping, great food and other diversions. For those wishing to take in some sun this January, one can walk east from the hotel, about a 1/4 mile, along the Shoreline Marina, to a large, sandy, public beach. In addition, the remarkable Aquarium of the Pacific, which houses more than 12,500 animals and offers the possibility of coming face-to-face or even touching the world's greatest predators, is only a 1/4 mile west. On Thursday January 13th, we will be having a tour and banquet on the Queen Mary ocean liner. Be sure to reserve your room by December 21st, 2004 and register for the conference by December 30th, 2004. Program Wednesday, Jan 12 8:30AM -- 9:30AM: Invited talk: Interpreting the Data, Rob Pike (Google) 10AM Session: * Associated Types with Class - Manuel Chakravarty, Gabriele Keller, Simon Peyton-Jones, Simon Marlow * Environmental Acquisition Revisited - Richard Cobbe, Matthias Felleisen * Polymorphic Bytecode: Compositional Compilation for Java-like Languages - Davide Ancona, Ferrucio Damiani, Sophia Drossopoulou, Elena Zucca * A Simple Typed Intermediate Language for Object-Oriented Languages - Juan Chen, David Tarditi 1:30PM Session: * Parametric Polymorphism for XML - Haruo Hosoya, Alain Frisch, Giuseppe Castagna * A Bisimulation for Type Abstraction and Recursion - Eijiro Sumii, Benjamin Pierce * A Syntactic Approach to Eta Equality in Type Theory - Healfdene Goguen * Slot Games: A Quantitative Model of Computation - Dan Ghica 4PM Session: * Synthesis of Interface Specifications for Java Classes - Rajeev Alur, Pavol Cerny, P. Madhusudan, Wonhong Nam * Dynamic Partial-Order Reduction for Model Checking Software - Cormac Flanagan, Patrice Godefroid * Proof-Guided Underapproximation-Widening for Multi-Process Systems - Orna Grumberg, Flavio Lerda, Ofer Strichman, Michael Theobald * Transition Predicate Abstraction and Fair Termination - Andreas Podelski, Andrey Rybalchenko 6PM: Business meeting / PC report Thursday, Jan 13 8:30AM: Invited talk: Programming Languages for Quantum Computing, Peter Selinger (University of Ottawa) 10AM Session: * Communicating Quantum Processes - Simon Gay, Rajagopal Nagarajan * Downgrading Policies and Relaxed Noninterference - Peng Li, Steve Zdancewic * A Probabilistic Language Based Upon Sampling Functions - Sungwoo Park, Frank Pfenning, Sebastian Thrun * Mutatis Mutandis: Safe and Predictable Dynamic Software Updating - Gareth Stoyle, Michael Hicks, Gavin Bierman, Peter Sewell, Iulian Neamtiu 1:30PM Session: * Transactors: A Programming Model for Maintaining Globally Consistent Distributed State in Unreliable Environments - John Field, Carlos Varela * Theoretical Foundations for Compensations in Flow Composition Languages - Roberto Bruni, Hernan Melgratti, Ugo Montanari * From Sequential Programs to Multi-Tier Applications by Program Transformation - Matthias Neubauer, Peter Thiemann * Combinators for Bi-Directional Tree Transformations: A Linguistic Approach to the View Update Problem - Nathan Foster, Michael Greenwald, Jonathan Moore, Benjamin Pierce, Alan Schmitt 4:30PM: Tour and conference dinner on the Queen Mary ocean liner Friday, Jan 14 8:30AM: Invited talk, Pat Hanrahan (Stanford University) 10AM Session: * Separation Logic and Abstraction - Matthew Parkinson, Gavin Bierman * Permission
[Haskell] RE: ANNOUNCE: Haskell support for Visual Studio .NET 2003 and Assignment Manager tools
Congratulations! Shan and Rogerio, please get in contact with Andre. I would love to see a demo of this. Thanks Morris From: Andre W B Furtado [mailto:[EMAIL PROTECTED] Sent: Wed 11/24/2004 22:37 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Morris Sim Subject: ANNOUNCE: Haskell support for Visual Studio .NET 2003 and Assignment Manager tools We are pleased to announce an alpha/preview version of VHS (Visual Haskell), which integrates the Haskell functional language with the Microsoft Visual Studio .NET 2003 IDE, and VHS-AM, which allows the use of VHS with the Microsoft Assignment Manager tools. This preview version supports: - Syntax coloring - Brace matching through CTRL+] (including module/where, let/in, etc.)* - Brace highlighting (including module/where, let/in, etc.)* - Brace matching text indicated in the status bar - TODO comments in code are added to the task list and can be reached by double-clicking it - Quick-info* - Word-completion* - Method tip* - Member-list popup* - Haskell Console Application creation - Haskell Console Application compilation (integrated with GHC) - Haskell Console Application execution - The presence of parse errors is indicated on-the-fly in the task list (specific errors are still not specified) - Error source location can be reached by double-clicking the task list - Haskell Assignment Manager exercise creation and advertisement - Haskell Assignment Manager exercise answering and submission - Compilation checking (via GHC) and output checking of Haskell exercises by Assignment Manager server Please note that this first release of VHS has some known bugs: - A VS.NET session can become unstable if you open a .hs file or create a Haskell Console Application project. - After opening a .hs file, the devenv.exe process is not being killed when VS.NET exits. - The above features marked with * sometimes do not work 100% as expected, mainly if the haskell module under development has errors. - Some features do not work in a inter-module fashion. - The Visual Haskell logo does not disappear from VS.NET splash screen after uninstall. Note: development of a Visual Studio plugin for Haskell has been proceeding on two fronts. Simon Marlow Krasimir Angelov have been working on adding complete editor support and a project framework integrated with Cabal, whereas this release is based on a fork of the codebase several months ago, and has a different feature set. We hope to combine these versions and make further releases in the future. Downloads, documentation and screenshots can be found in: http://www.cin.ufpe.br/~haskell/vhs-am/ http://www.cin.ufpe.br/~haskell/vhs/ The VHS/VHS-AM team is: - Simon Marlow - Krasimir Angelov - Andre Santos - Andre Furtado - Mauro La-Salette - Marden Costa This project was partially supported by a MS grant for extending the Assignment Manager tool. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Execution Contexts
On 27 Nov 2004, at 00:59, Benjamin Franksen wrote: I finally understood that George Russell's Library is not really about global variables. Rather it is about what I want to call 'execution contexts', which are -- as Marcin Kowalczyk observed -- a restricted form of dynamically scoped variables. yes. [snip] type XIO a = StateT Context IO a ...which, amusingly, brings us almost full circle to the message which sparked off this particular iteration of the Great Global Variables Debate: http://groups.google.com/groups?selm=fa.hvrd8p7.nmg2r7%40ifi.uio.no ..which uses StateT Env IO Although your work is rather more complete than what I sketch in that message. A problem is the ability to pass callbacks to external libraries... Jules ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Lexically scoped type variables
[EMAIL PROTECTED] writes: and use `asTypeOf` result wherever we need to refer to resType. I don't like being left with only asTypeOf, because when the desired type has its structure shuffled, it forces to invent a transformation on unused expressions which yields the given transformation on their types - ugly. It should be possible to name every part of a type (or at least every polymorphic part) with a type variable, and use it in local type signatures. For me it's fine if implicit foralls bring type variables into scope. The only disadvantage is that it's incompatible with Haskell 98. -- __( Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Execution Contexts
Jules Bean wrote: A problem is the ability to pass callbacks to external libraries... Why not just put all the state in a record, then there's only one thing to pass around... you can use the state monad to hide this (or the state monad transformer if you need to layer over IO) then use partial function application to pass the necessary state to the callback on creation? Also another take on the TWI question... Doesn't this equate to the same thing as first class modules... then a module can be defined within the scope of a function? printablePoint x_init = do x - newIORef x_init return $ module PrintablePoint where getX = readIORef x ... And the above can be seen as a model of an object... So using the HList library you can write this: class_printable_point x_init self = do x - newIORef x_init returnIO $ mutableX .=. x .*. getX .=. readIORef x .*. moveD .=. (\d - modifyIORef x ((+) d)) .*. ooprint .=. ((self # getX ) = print) .*. emptyRecord Of course true top-level TWIs behave like static objects... But with dynamic objects you can guarantee that each object is only initialised once, but cannot guarantee that only one object of a given type exists (and I think encapsulation is a more important property than uniqueness). Keean. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Re: Global Variables and IO initializers
On Friday 26 November 2004 08:39, George Russell wrote: Benjamin Franksen wrote (snipped): What non-standard libraries have I used (that you don't)? OK, but you have to test every element of the dictionary with fromDynamic until you find one with the type you want, which is not a good idea if the dictionary is big. My implementation is equally inefficient now (because TypeRep's have no Ord), but if TypeRep's had Ord or a hashing function (both would be very easy to provide from GHC's implementation) I could make my implementation efficient very easily, while you'd have to completely rewrite yours to get the same effect. [completely off-topic but anyway:] This is yet another incidence where Robert Will's ByMaps would be very useful: http://www.stud.tu-ilmenau.de/~robertw/dessy/fun/principles.html#bymap I am quite astonished that apparently none of the data structure library projects have taken up the idea. Ben ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Execution Contexts
A general point on top-level TWIs. It occurs to me that all variables are local to something (function, object, thread, process, machine, network, world...). I think it is an error to limit Haskells domain. If we allow unique per process variables (top-level TWI's) we limit our level of abstraction to a process - haskell cannot dispatch processes beacuse it cannot handle the multiple process contexts required. All the attempts at modelling execution contexts therefore seem a better solution than top-level TWIs which limit us to a single process world model. It seems the real world is an infinitely deep nesting of abstractions, so uniqueness is always relative to its context. Using the object model, we can have a process object, this object can ensure uniqueness of values within the context of a process - which is what Adrian wants. However if we want uniqueness at the next level, say the per CPU level, then a CPU object is the relavent context. It seems to me the object model fits perfectly, and what people are trying to do is turn modules into primitive objects complete with data-hiding and constructors (top-level TWIs)... However modules cannot be nested so the model breaks down, and we end up needing first-class modules anyway. Of course objects can be modeled another way (see http://www.cwi.nl/~ralf/OOHaskell) using the HList library... The syntax is simple enough, but would still benefit from a little sytactic sugar (hopefully to be providied by template-haskell, but this part is a work in progress). So in conclusion, it seems to me that that objects in Haskell solve all the problems that top-level TWIs solve, and still allow encapsulation and multiple 'process' contexts to be handled by the RTS. So use them! Sorry for the rambling explanation and shameless promotion of HLists... Keean. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Execution Contexts
On Saturday 27 November 2004 17:10, you wrote: On Sat, 27 Nov 2004, Benjamin Franksen wrote: An execution context is a mutable finite map from types to (monomorphic) values. Each IO action implicitly carries exactly one such map and by default passes it on to the actions that follow. Execution contexts sound a good description of them. Building on your recoding of this, if you have top-level declarations of newMVar / newIORef then how much of this can you do by just keeping a dictionary in a global variable? This should certainly save some of the StateT plumbing; and such declarations are safe, becuase they are affine central (see http://groups.google.com/groups?selm=fa.doh68b9.96sgjd%40ifi.uio.no ) I like your definition of ACIO and I think it is sound (I have also suggested centrality, see http://www.haskell.org//pipermail/haskell/2004-November/014743.html). I would think that with ACIO we have a nice mathematical characterization for the IO actions that would be safe even at the top-level. (Safe meaning mainly that we do not open a can-of-worms with regard to execution order.) I don't know how easy or hard it is to prove of a certain IO action that is in fact in ACIO. However, monadic execution contexts don't need any safety proofs, because they are purely functional. With modest support from the compiler they could be implemented quite efficiently. And they would solve almost all problems for which global variables have been used or proposed as a solution. To be more precise, they would solve all those problems, provided you replace any reference to the whole program by a certain execution context. I think this would be good enough for almost all applications. A function is provided to (implicitly) create a new mapping and run a given IO action with the new mapping as its execution context, instead of the default one. Update the global MVar, do the IO, then reset it? This breaks down as soon as the IO action does a forkIO. This breakdown is one of the reasons I dislike global variables so much. Sure, you can find a way to code around this special probem.(*) But the fact that you have to (explicitly take concurrency into consideration) doesn't bode well for global variables. One of the nice features of (monadic) execution contexts is that they are automatically protected from such problems, without taking any special precaution. I am almost sure that even the trick of indexing the dictionary via types (and thus the dependency on Data.Typeable and ghc extensions) can be avoided with a little more effort. Another global MVar to issue a sequence of unique index keys? Maybe this is possible. But I'd rather have a library that depends on Dynamics (plus some compiler support) than a highly controversial new language feature. Ben (*) You'd probably need a hack like using ThreadIds to identify the IO action being run under the new context, see George Russel's implementation. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Execution Contexts
On Saturday 27 November 2004 17:55, you wrote: A general point on top-level TWIs. It occurs to me that all variables are local to something (function, object, thread, process, machine, network, world...). [...] It seems to me the object model fits perfectly, and what people are trying to do is turn modules into primitive objects complete with data-hiding and constructors (top-level TWIs)... However modules cannot be nested so the model breaks down, and we end up needing first-class modules anyway. [...] So in conclusion, it seems to me that that objects in Haskell solve all the problems that top-level TWIs solve, and still allow encapsulation and multiple 'process' contexts to be handled by the RTS. So use them! Timber (formerly O'Haskell) has gone this way. Its object model is defined (and in fact was implemented) by a straight-forward translation into a (state) reader monad transformer over the IO monad. It is noteworthy that in this translation the (local) state of a Timber object is not a record but just an (IORef to an) anonymous tuple. [It is true that they added 'real' records and subtyping to the language but these additions are completely orthogonal to the object model. Records are merely used to group the monadic actions that define the interface of an object into a suitable type hierarchy (in order to model a weak form of interface inheritance).] So, one of the things I learned when studying Timber's object model is that records (or modules) with mutable fields (and inheritance and so on) are *not* the whole story. The most interesting aspect is how objects react to external stimulus, i.e. their representation as monadic effects. One *can* program in such a way in Haskell. What's missing is not so much records or first class modules, nor top-level IO actions (safe or not), but suitable syntactic sugar to alleviate the burden of having to lift (sic!) all IO actions to a suitable object/context monad. Ben ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Re: Global Variables and IO initializers
On Friday 26 November 2004 08:39, you wrote: Benjamin Franksen wrote (snipped): What non-standard libraries have I used (that you don't)? OK, but you have to test every element of the dictionary with fromDynamic until you find one with the type you want, which is not a good idea if the dictionary is big. My implementation is equally inefficient now (because TypeRep's have no Ord), but if TypeRep's had Ord or a hashing function (both would be very easy to provide from GHC's implementation) I could make my implementation efficient very easily, while you'd have to completely rewrite yours to get the same effect. [completely off-topic but anyway:] This is yet another incidence where Robert Will's ByMaps would be very useful: http://www.stud.tu-ilmenau.de/~robertw/dessy/fun/principles.html#bymap I am quite astonished that apparently none of the data structure library projects have taken up the idea. Ben ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
