[Haskell-cafe] Question about updating GHC on MacOS
Hi, I have Haskell Platform with GHC[i] 7.4.2 installed on a MacOS system. There's a problem with the handling of certain Markdown constructs in literate Haskell (lines starting with '#') that I understand is fixed in 7.6.2. Therefore, I'd like to be able to update my GHC installation to 7.6.2. But I haven't yet been able to find any instructions about how to upgrade an existing GHC installation. Am I missing something? #g -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] building ghc on arch linux ARM?
On 09/04/2012 00:45, Joey Hess wrote: Thomas DuBuisson wrote: On Sun, Apr 8, 2012 at 4:03 PM, Francesco Mazzolif...@mazzo.li wrote: No, it is not possible to build GHC without GHC. Building GHC on ARM is going to be extremely tricky (I'm not sure anyone has ever done it). I used to use an unregistered build of GHC built by someone in the Debian community - it worked well enough. It ships with Debian, along with the full Haskell Platform built for ARM and lots of other libraries. Other than speed, it's fine. Hmmm... I wonder if it will squeeze onto a Raspberry Pi :) #g -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why so many strings in Network.URI, System.Posix and similar libraries?
Hi, I only just noticed this discussion. Essentially, I think you have arrived at the right conclusion regarding URIs. For more background, the IRI document makes interesting reading in this context: http://tools.ietf.org/html/rfc3987; esp. sections 2, 2.1. The IRI is defined in terms of Unicode characters, which themselves may be described/referenced in terms of their code points, but the character encoding is not prescribed. In practice, I think systems are increasingly using UTF-8 for transmitting IRIs and URIs, and using either UTF-8 or UTF-16 for internal storage. There is still a legacy of ISO-8859-1 being defined asthe default charset for HTML (cf. http://www.w3.org/International/O-HTTP-charset for further discussiomn). #g -- On 14/03/2012 06:43, Jason Dusek wrote: 2012/3/12 Jeremy Shawjer...@n-heptane.com: On Sun, Mar 11, 2012 at 1:33 PM, Jason Dusekjason.du...@gmail.com wrote: Well, to quote one example from RFC 3986: 2.1. Percent-Encoding A percent-encoding mechanism is used to represent a data octet in a component when that octet's corresponding character is outside the allowed set or is being used as a delimiter of, or within, the component. Right. This describes how to convert an octet into a sequence of characters, since the only thing that can appear in a URI is sequences of characters. The syntax of URIs is a mechanism for describing data octets, not Unicode code points. It is at variance to describe URIs in terms of Unicode code points. Not sure what you mean by this. As the RFC says, a URI is defined entirely by the identity of the characters that are used. There is definitely no single, correct byte sequence for representing a URI. If I give you a sequence of bytes and tell you it is a URI, the only way to decode it is to first know what encoding the byte sequence represents.. ascii, utf-16, etc. Once you have decoded the byte sequence into a sequence of characters, only then can you parse the URI. Mr. Shaw, Thanks for taking the time to explain all this. It's really helped me to understand a lot of parts of the URI spec a lot better. I have deprecated my module in the latest release http://hackage.haskell.org/package/URLb-0.0.1 because a URL parser working on bytes instead of characters stands out to me now as a confused idea. -- Jason Dusek pgp /// solidsnack 1FD4C6C1 FED18A2B ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: swish 0.3.0.0
Excellent, thanks for running with this! I have an RDF/XML parser (based on a fork of HaXML) that I'd like to integrate at some time, and it's remotely possible that I might have a little time to work on this in the coming months.. #g -- Doug Burke wrote: I am pleased to announce an update of the swish package to version 0.3.0.0 [1]. It is mainly meant to be a maintenance upgrade over the existing version on Hackage [2] by Vasili I. Galchin, but does add additional functionality in that it now supports the NTriples format and the N3 parser and formatter has been updated to better match the current specification. For those not aware of what Swish actually is, it is an experiment by Graham Klyne in writing a Semantic Web framework in Haskell [3]. I note that the wonderful machinery behind Hackage has already processed the documentation so you can read more about it at [1] as well as the very-sparsely-documented Wiki at [4]. [1] http://hackage.haskell.org/package/swish-0.3.0.0 [2] http://hackage.haskell.org/package/swish-0.2.1 [3] http://www.ninebynine.org/Software/swish-0.2.1.html [4] https://bitbucket.org/doug_burke/swish/wiki/Home Thanks for reading this far, Doug ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RE: [Haskell] Proposal: Form a haskell.org committee
Simon Peyton-Jones wrote: | As membership of the Haskell community is not well-defined, and voting | would potentially be open to abuse if anyone were able to vote, we | propose that the committee should choose their replacements from open | nominations. I agree with the problem, and I think your proposed solution may do for now, but it's obviously not a robust solution. I trust you five, but in three years time you may all have stood down! A possible solution would be to have an electoral college of people entitled to vote. It should be easy to become a member of the college: any track record of contributions to the Haskell community, including constructive contributions to Haskell Cafe, would be enough. Then the college can elect the committee. It's debatable whether this is worth the bother at this point. Maybe it would be enough to document on the committee page that we don't regard the nomination process as robust, and if any concern arises we will consider something more substantial. FWIW, the IETF faces the same situation, and addresses it through a Nominating Committee (NomCom) mechanism, which for the most part has worked well for many years (http://tools.ietf.org/html/rfc3777). #g ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] RE: [Haskell] Proposal: Form a haskell.org committee
Simon Peyton-Jones wrote: | As membership of the Haskell community is not well-defined, and voting | would potentially be open to abuse if anyone were able to vote, we | propose that the committee should choose their replacements from open | nominations. I agree with the problem, and I think your proposed solution may do for now, but it's obviously not a robust solution. I trust you five, but in three years time you may all have stood down! A possible solution would be to have an electoral college of people entitled to vote. It should be easy to become a member of the college: any track record of contributions to the Haskell community, including constructive contributions to Haskell Cafe, would be enough. Then the college can elect the committee. It's debatable whether this is worth the bother at this point. Maybe it would be enough to document on the committee page that we don't regard the nomination process as robust, and if any concern arises we will consider something more substantial. FWIW, the IETF faces the same situation, and addresses it through a Nominating Committee (NomCom) mechanism, which for the most part has worked well for many years (http://tools.ietf.org/html/rfc3777). #g ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Code that writes code
Maybe not helpful to you at this stage, but... An alternative to generating source code is to factor out the common boilerplate elements into separate functions, suitably parameterized, and to use higher order functions to stitch these together. An example of this kind of approach, which is handled by code generation in some other languages (e.g. lex, yacc, etc), is the Parsec combinator-based parsing library (http://www.haskell.org/haskellwiki/Parsec) - instead of generating code, the syntax rules are written directly using Haskell functions and assemble the common underlying repeated logic dynamically, behind the scenes. I adopted a development of this approach for a programme with a built-in scripting language that I implemented some time ago: the scripting language was parsed using Parsec, not into a syntax tree, but directly into a dynamically assembled function that could be applied to some data to perform the scripted function (http://www.ninebynine.org/RDFNotes/Swish/Intro.html). What I'm trying to point out here that, rather than go through the step of generating source code and feeding it back into a Haskell compiler, it may be possible to use higher order functions to directly assemble the required logic within a single program. For me, this is one of the great power-features of functional programming, which I now tend to use where possible in other languages that support functions as first class values. #g -- Andrew Coppin wrote: I'm working on a small Haskell package. One module in particular contains so much boilerplate that rather than write the code myself, I wrote a small Haskell program that autogenerates it for me. What's the best way to package this for Cabal? Just stick the generated file in there? Or is there some (easy) way to tell Cabal how to recreate this file itself? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Shootout update
Simon Marlow wrote: We really need to tune the flags for these benchmarks properly. Do I sense the hidden hand of Goodharts law? :) -- http://en.wikipedia.org/wiki/Goodhart's_law #g ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] jQuery is a monad
Nice blog post: http://importantshock.wordpress.com/2009/01/18/jquery-is-a-monad/ #g ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] install-dirs on Mac OS X
Mark Lentczner wrote: [*] The Apple guidelines for the /Library and ~/Library files are here:http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPFileSystem/Articles/LibraryDirectory.html#//apple_ref/doc/uid/20002282-BAJHCHJI Thanks for the link. I followed through to a couple of other links that broadly support your position: [1] http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPFileSystem/Articles/LibraryDirectory.html [2] http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPFileSystem/Articles/Domains.html But, on reading [1], I also see Although an application can use this directory [/Library] to store internal data or temporary files, it is not intended for storage of the application bundle itself or for user data files. Application bundles belong in an appropriate /Applications directory, while user data belongs in the user’s home directory. This makes me question whether /Application might be the appropriate place? I'm pleased to see this issue is getting some serious consideration: I haven't actually used Haskell for a while, and since I last did I've switched to using a Mac for much ogf my development, so when I return to the Haskell fold it will be nice to have the system play nicely with the host environment. #g ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Semantic Web
I'd like to thank Vasili for resurrecting this project, which I thought had all-but-died for lack of nurture (the day job, etc.). It's really nice to know that, when (I hope!) the day comes that I want to pick up my Haskell work again, it won't have completely been left behind by the many exciting developments in the Haskell platform. When I have just a little time, I'd like to help move the code into a suitable open repository. Many thanks! #g -- Vasili I. Galchin wrote: I. Swish-0.2.1(Semantic Web Inference uSing Haskell) is a semantic web toolkit designed and implemented by Graham Klyne - g...@ninebynine.org mailto:g...@ninebynine.org: 1) http://www.ninebynine.org/RDFNotes/Swish/Intro.html 2) http://www.ninebynine.org/Software/swish-0.2.1.html I am personally very excited about Graham's work and the role of Haskell in his toolkit! II.) My role I cabalized Swish-0.2.1, brought namespace issues up to 6.8.2 standards and fixed many compiler warnings. There are still numerous warnings mostly related to lack of function type signatures. Swish-0.2.1 however does build and the tests that Graham wrote do run ok. Currently Swish-0.2.1 is currently hosted on Hackage but will most likely move to another site in the future. The downloader will find that there are TBDs in the swish.cabal file and other places. Please be patient. Kind regards, Vasili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Cryptographic hash uniquness (was [Haskell-cafe] Simple network client)
This is a very late response ... but I did some calculations as part of some work I did a while ago: http://www.ietf.org/rfc/rfc2938.txt (See appendix A The birthday paradox) #g -- Peter Verswyvelen wrote: winds up having a write cache, which is mutable in practice. The interesting thing is that the block's location is the cryptographic hash of its contents, which leads to all sorts of neat properties (as well as requiring immutability). That's interesting. When I developed a version control system for a customer, I also used a cryptographic hash as the database key of file+content in question, but I was afraid I might have clashes (two files with different content generating the same hash)... My intuition told me that the odds of two cryptographic hashes (on meaningful content) colliding was much less than the earth being destroyed by an asteroid... But this is just intuition... What does computer science tell us about this? Thank you, Peter -- Graham Klyne Contact info: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] ANNOUNCE: Haskell Communities Activities Report (10th ed., June 2006)
Andres Loeh wrote: On behalf of the many, many contributors, I am pleased to announce that the Haskell Communities and Activities Report (10th edition, June 2006) http://www.haskell.org/communities/ This is a gem ... many thanks! It will be very useful to me when I manage to get some time to use Haskell again. So much has been happening, it would be difficult to catch up without a great overview like this. #g -- Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Learning C after Haskell
I did the transition the other way, and even now the real-world keeps me using more C-like languages (Java, Python). Unlike the transition from imperative languages to Haskell, I don't think there's much you have to unlearn or rethink. But I suspect you may feel a degree of frustration at how incredibly primitive C may seem after learning to use the power that Haskell makes available. Where you can map Haskell idioms into C, I think they may serve you well (I've found this to be the case with Python, but the gap from Haskell to C is somewhat greater). You mention high performance computing. I think there are two ways of achieving this: the C way might be described as micro optimization -- getting the small but important things to run as efficiently as possible The Haskell was is more a case of macro optimization -- getting the overall algorithmic approach to be as smart as possible. There's a place for both, but once you get involved in micro-optimization it can be very difficult to go back and fix the macro performance issues. So you might do well to first code algorithms in Haskell first, and experiment with the algorithms, if only as a way of specifying the solution to be implemented in C. #g -- Chad Scherrer wrote: Ok, so I'm doing things somewhat backward. I've been using Haskell for a while now, whenever I get a chance to. But in order to become more involved in high-performance computing projects at my work, I need to learn C. I've heard a lot of people say that experience in Haskell can improve one's abilities in other languages, but I also wonder how different the C way of doing things is different from Haskell's. My question is, as I learn C, are there any particular Haskell concepts I should keep in the back of my mind, or is it better to approach C from scratch? Thanks in advance! Preparing for a foot-shooting, Chad ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] develop new Haskell shell?
Did you see [http://nellardo.com/lang/haskell/hash/] ? Google also finds some links to code. #g -- Marc Weber wrote: Hi. Who wants to try devloping a new shell with me? The main goals: try adding some haskell scriting instead of bash/zsh, history dependend on a) executing program b) current dir c) last commands d) workspaces which should mean that the shell should save at least the last 10 commands of a,b,c,d. So you can do emerge (lookup parameters in history) even if you haven't used emerge for ages.. :) Nice, isn't it? d) Workspaces should mean: You can define some kind of workspace like workspace=haskellproject, wash, apache to add these tags together with the commands to the history.. So when working only in the wash workspace you can easily find those commands.. Perhpas it's even useful to attach commands or even scripts to those workspaces? eg the startApache script may be attached to admin, apache, ..., the cd /etc/init.d command only to admin.. I also would like to have some advanced kind of directory matching, defining aliases for directories. eg just type cd /usl to get a list of diretories looking like this: /UserShupportLocales /usr/src/linux /usl ? Using tab and bash is nice but it might be done better? Any suggestions? One would have to think about how to run processes in background and so on ... adding files as parameters the way it's possible in mc ( select them and add them to the command line ) perhaps even implement cp/mv/ ... for virtual file systems like zip files/ ftp/ ... ? and last but not least: on windows add all Programs beeing found in Start- Programs to the path list... I wish I could just do word/ Enterprise Manager at a shell and not searching for the menu entries over and over again.. ;) I know I can add them the to the path.. but that would be some work, too.. and not desirable in any case. I could imagine adding a small prefix to each cmd eg. eb (execute bash cmd) ez (execute zsh cmd) r (remove file list) efs (execute from windows start menu) bg cmd run in background like bashs feature. Perhaps even introduce some new syntax ? or use ghci or hugs with a preprocessor to translate these commands to haskell commands? What do you think? Marc Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] ANNOUNCE: HAppS 0.8
This looks very interesting! I must try and find time to look at at. MACID sounds like a really powerful idea... #g -- Einar Karttunen wrote: Hello, HAppS - Haskell Application Server version 0.8 has been released and contains a complete rewrite of the ACID and HTTP functionalities. Features include: * MACID - Monadic framework for ACID transactions: Write apps as a set of simple state transformers. MACID write-ahead logging and checkpointing make it easy for you to guarantee application integrity in the face of unplanned outages. MACID even guarantees that your side effects will be executed at-least-once if they can complete within a timelimit you define. * HTTP Server: Performs better than Apache/PHP in our informal benchmarks (thanks to Data.FastPackedString), handles serving both large (video) files and lazy (javascript) streaming, supports HTTP-Auth, and more. * SMTP Server Handle incoming email in your application without worrying about .procmail or other user level inbound mail configuration hackery. Just have the HAppS.SMTP listen on port 25 or have the system mail server SMTP forward mail for your app to some internal port. * Mail delivery agent Stop worrying about making sure a separate local mail server or DNS is up and running to deliver your mail. HAppS takes care of making sure your mail is delivered as long as your application itself is running and makes sure no outbound mail is lost even with unplanned restarts. * DNS resolver in pure Haskell For resolving MX records and concurrent queries. Can use an upstream DNS server or root servers directly. * XML and XSLT Separate application logic from presentation using XML/XSLT. With HAppS, you can have your application output XML (via HTTP or SMTP) and handle style/presentation via separate XSLT files at runtime. HAppS takes care of doing server side XSLT for outbound mail and HTTP user-agents that don't support it client side. * Sessions and much more! Where to get? http://happs.org/ darcs get http://happs.org/HAppS -- Einar Karttunen ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell -- Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] web servers
I'm interested, but I don't have the time to look right now (or in the next couple of months, as far as I can see). What would really interest me is a system that can provide the functionality of the Python packages I currently use (TurboGears [1], of which the web server/controller component is CherryPy [2]). There's also some interesting recent CherryPy-related discussion about web dispatching that I think could translate very well to Haskell [3][4]. ... I'd also be interested in a system that handled overlapped asynchronous requests in a fashion not dissimilar to Twisted [5]. I've very recently been playing with Twisted as a way to deal with large numbers of overlapping lightweight requests without having large numbers of active threads. Twisted requires one to string together asynchronous callbacks to assemble a process that completes over time. It seems to me that the sequencing of asynchronous operations is very much like threading computations in a monad, and that the higher-order functions on monads could also be used for composition of asynchronous operations. I just implemented a sequence function for Twisted operations whose implementation started to feel very like foldr. This can't be new, and I'm wondering if there is any interesting work out there on using monads for multiple asynchronous I/O operations. (And, much as I'd love to use Haskell for this, is there work that would translate cleanly to Python?) #g -- [1] http://www.turbogears.com/ [2] http://www.cherrypy.org/ [3] http://pythonpaste.org/do-it-yourself-framework.html (cf. descriptions of object publishing) [4] The above link was posted in this discussion thread: http://groups.google.com/group/cherrypy-users/browse_frm/thread/47035d8d78adad69/bf02b489e45ce6c5?tvc=1hl=en#bf02b489e45ce6c5 [5] http://twistedmatrix.com/ http://twistedmatrix.com/projects/core/ Daniel McAllansmith wrote: Following is a message I sent yesterday, sans attachment. Looks like the code was too bloated to get through under the list size limit. As I say in the original message , I'm keen for any feedback. So let me know if anyone wants the actual code (20 KB, compressed) to have a look through. Cheerio Daniel On Sunday 09 April 2006 06:24, Tim Newsham wrote: I found a copy of Simon Marlow's HWS on haskell.org's cvs server. I know there's a newer plugin version, but I cant find a working link to the actual code. There's this link: http://www.mdstud.chalmers.se/~md9ms/hws-wp/ From memory I think there may have been a more recent version at scannedinavian.org (possibly only accessible with darcs?), but still a couple of years with no apparent activity. Besides HWS, what other web servers exist? Does anyone actually use a haskell based web server in practice? Which web server is considered the most mature? stable? fastest? I'm trying to decided if I should sink some time into HWS or if I should use another server. Several months ago I had a bit of play-time available which I spent on writing a HTTP server in Haskell. The goal was a HTTP 1.1 compliant server that could be embedded in a Haskell app, be reconfigured on the fly and have different request handlers added/removed. I did have a quick look at HWS before I started but I seem to recall it was pretty basic (in terms of the amount of the HTTP spec. implemented). In any event, I started from scratch. It's certainly not finished, and it's the very first thing I wrote with Haskell so it's a bit of a dogs breakfast, but it might be of interest. There's lots that needs doing but it should just be a case of writing a request handler to get it doing _something_ useful. It's always been my intention to get back to it, clean it up a bit/lot and release it under a more liberal licence (currently 'all rights reserved'), but have had little time available. Eventually I hope to actually use it in anger. If anyone is interested in using it, contributing to it, or picking over it for use in an existing project, I'll try and find somewhere stable to host it and change the licence. Feel free to ask questions on what it does/doesn't do. You'll probably need to, given the documentation ;-) Regardless of it's utility, any criticism or advice on the code would be appreciated. Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Web application frameworks
Björn Bringert wrote: Graham Klyne wrote: [Switching to haskell-cafe] Niklas Broberg wrote: ... On 3/6/06, Graham Klyne [EMAIL PROTECTED] wrote: - Options to run the whole thing behind Apache to leverage its security and web space management capabilities Lemmih has implemented a HSP/FastCGI binding for Apache. I also know that work is being done on building a direct HSP/Apache binding. All work in progress though. Yes, I was aware of a fastCGI for Haskell. Didn't Bjorn Bringert (also) implement one? I tend to think of CGI programs as run-to-completion-then-exit, even when a fastCGI interface allows a persistent wrapper program to speed startup. But I could easily be missing something here. Yes, I have written a FastCGI binding (darcs repo here: http://www.cs.chalmers.se/~bringert/darcs/haskell-fastcgi/). If I'm not mistaken, that's what Lemmih is using for his HSP/FastCGI binding. I have only used FastCGI the way you describe, as CGI without start-up penalty, though I can't see why you couldn't keep some state between requests to a FastCGI application. I believe that Ruby-on-Rails (which I've never used, so I'm not too sure) can use FastCGI. One problem with Apache and FastCGI is that the Apache FastCGI module doesn't seem to support concurrent requests to a single FastCGI process (even though the FastCGI protocol allows this). This means that Apache will have to run several instances of the Haskell-over-FastCGI app to serve concurrent requests, or be forced to serialize the requests. Having several instances of course means that you can't really keep stuff like session data in memory in the FastCGI process. If the Apache module supported concurrent requests we could spawn a new Haskell thread to serve each request, which ought to scale well. Aha! I think that homes in on what I was after when mentioning long-running processes. I think there are some separate but related issues to consider: (a) can a single CGI invocation handle (respond to) a series of HTTP requests, or is it strictly one http request for each CGI invocation? Without this, you may have to throw away session state after each request. (b) is there a way to maintain state between CGI invocations? (c) can multiple concurrent CGI/HTTP requests be handled? Of these, I think (c) may be the least important, other than for performance reasons (and maybe not even then), provided that there are ways to handle upstream I/O asynchronously, and to encapsulate all the relevant session state in a way that can be passed between invocations. I guess it comes down to a choice between an event-driven or multi-threaded processing model (and the former seems to me to be a nicer fit with Haskell). I think the minimum requirement is ((a) OR (b)) AND ((c) OR (asynchronous I/O completion)) #g -- Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Web application frameworks (was: [Haskell] Re: Trying On Learn Haskell Web Server)
[Switching to haskell-cafe]
Niklas Broberg wrote:
Ehum, shameless plug. :)
Pretty much what I was fishing for...
On 3/6/06, Graham Klyne [EMAIL PROTECTED] wrote:
Cale Gibbard wrote:
Ah, neat, I knew about WASH, but somehow I'd missed the fact that
there was a server there :)
Interesting... at a casual glance, this looks as if it could be coming close
to
being a full stack web application framework for Haskell, looking to occupy
the same kind of territory as systems like Java/Servlets+JSP+the rest,
Ruby/Rails or Python/Turbogears (the last a package I'm currently using).
Have you looked at HSP [1]? This is exactly what the HSP project aims
for, although there is quite some ways to go yet.
I've noticed it, but haven't yet taken a closer look. Currently, I'm pretty
busy with non-Haskell activities, but I'd love to find a sufficiently mature
tool to migrate some of my work to Haskell.
I think see:
The web server
CGI process dispatching
Web page templating
Relational database access
All of these are present in HSP.
I noticed that WASH makes some mention of HSP. My main concern with a *SP
approach, and a reason I haven't delved more deeply, is that they are, AFAICT,
heavily dependent on code embedded in HTML, when I really want to separate the
code and markup as much as possible.
Additional features of a full-stack web application framework that may or may
not be present are:
- Support for longer-running web processes (implemented in haskell, of
course)
HSP has that.
Ah, OK... I wasn't aware of that.
- An easy way to map incoming URIs to specific functions (hmm.. or to monadic
values, I think)
I don't think I understand what you're after exactly, but I'm sure
it's interesting, care to explain a bit further? :-)
I'll try and explain using Turbogears as example. Actually, I think that
Turbogears would make a good model for building a Haskell Web application
framework, since many of the key integration points are implemented using higher
order functions. It makes heavy use of Python 2.4 decorators, which are a
(constrained) form of functional composition for class member functions.
The web server/controller component of Turbogears is CherryPy. Roughly, a class
maps to a web server directory in URI space, with a declared class
(conventionally root) corresponding to path / for a server. Member variables
use used to create subdirectories. here's an example from soemthign I'm
working on:
[[
class Root(controllers.Root):
panel= PanelRenderer() ### Note 1
webbrick = WebBrickAccess()
itunes = ITunesAccess()
@turbogears.expose(html=templates.welcome)### Note 2
def index(self):
return dict(now=time.ctime())
@turbogears.expose(html=templates.listpanels) ### Note 2
def panels(self):
def selectPanelName((_,nam)):
return nam[:-4]
pattern = re.compile( r'^.+\.xml$' )
c = CollectFiles(../resources/paneldef/,pattern,recursive=False)
return { 'baseuri' : turbogears.url(/)+panel/, ### Note 3
'panels' : map(selectPanelName,c) }
]]
Notes:
1. These assignments create sub-pages of the root page for http://.../panel/,
http://.../webbrick/, http://.../itunes/.
2. This is the Python decorator syntax, that defines a class method as a
composition of the decorator function (turbogears.expose) and the function
definition that follows. The turbogears.expose decorator performs two functions
here: (a) it causes the function to be exposed as a web page; e.g.
http://.../index or http://.../panels, (b) it uses the output from the defined
function as input to a templating system to format and return an HTML web page.
3. The templating system uses a Python dictionary type to accept values that
are included in the constructed web page. You will note that this code is
completely independent of the details of the templating syst actually used.
Indeed, Turbogears can be used with more than one templating system, and (in
principle), I think the decorator system would allow miore than one such system
to be used within a single application - not that I advocate this ;).
I think all of this could be converted quite easily to appropriate Haskell
idioms.
- Easy mapping from Haskell data structures to underlying SQL - what would be
called an Object-Relational Mapper (ORM) in OO languages
Some of our students are working on bringing the power of Ruby/Rails
to HSP, with emphasis on smooth database interfacing. Not sure exactly
what this entails though, I've never used Rails... :-)
IMO, Rails suffers in this respect by being too-tightly integrated with its ORM
system. It's fine if you want, as Bruce Tate says, to babysit a relational
database. By in my application, I actually want to babysit a collection of
web-connected devices.
Turbogears, by contrast, leaves the controller/model interface completely in the
open: there is no presumtpion
Re: [Haskell] Re: Trying On Learn Haskell Web Server
Cale Gibbard wrote: Ah, neat, I knew about WASH, but somehow I'd missed the fact that there was a server there :) Interesting... at a casual glance, this looks as if it could be coming close to being a full stack web application framework for Haskell, looking to occupy the same kind of territory as systems like Java/Servlets+JSP+the rest, Ruby/Rails or Python/Turbogears (the last a package I'm currently using). I think see: The web server CGI process dispatching Web page templating Relational database access Additional features of a full-stack web application framework that may or may not be present are: - Support for longer-running web processes (implemented in haskell, of course) - An easy way to map incoming URIs to specific functions (hmm.. or to monadic values, I think) - Easy mapping from Haskell data structures to underlying SQL - what would be called an Object-Relational Mapper (ORM) in OO languages - Handling of interaction with a browser-side Javascript library for smoother AJAX support - Options to run the whole thing behind Apache to leverage its security and web space management capabilities I think that continuation-based web session state management, ala Smalltalk/Seaside, would be a very natural fit for a Haskell framework -- all handled by a Web session monad, maybe. (Or maybe I just don't know what I'm talking about ;) How far are we from having such a framework for Haskell? #g -- Cale Gibbard wrote: On 06/03/06, Shae Matijs Erisson [EMAIL PROTECTED] wrote: Cale Gibbard [EMAIL PROTECTED] writes: Looks like there's an updated version here which supports dynamically loadable plugins: http://www.mdstud.chalmers.se/~md9ms/hws-wp/ Peter Thiemann has a more recent version that uses hs-plugins: http://www.informatik.uni-freiburg.de/~thiemann/haskell/WASH/ Ah, neat, I knew about WASH, but somehow I'd missed the fact that there was a server there :) - Cale ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell -- Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Re: [Haskell] page renaming on the Haskell Wiki
[EMAIL PROTECTED] wrote: Hello Graham, Wednesday, February 22, 2006, 12:57:39 PM, you wrote: GK How to do this in a wiki, I'm not sure, though I don't take that to mean we GK shouldn't try. I think the mediawiki mechanism you mention is reasonable if not GK ideal, though this would clearly be overwhelmed if page-renaming were to become GK the norm. my 2c is what new wiki is just two months old and we should refactor it now extensively to make it useable in the future. for example, i think that all libraries should be under Library or Libraries root and so on. we started with filling up the pages, now we had enough contents to see what the structure will serve better Well, yes, better now than later, for sure. My comments were really directed toward longer term principles. I think I've said enough for now. #g -- Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] page renaming on the Haskell Wiki
Wolfgang, [Switching to haskell-cafe] Re: [1] http://www.mail-archive.com/haskell@haskell.org/msg18352.html [2] http://www.mail-archive.com/haskell@haskell.org/msg18356.html [3] http://www.w3.org/Provider/Style/URI Wolfgang Jeltsch wrote (in [2]): On the other hand, I think that the above W3C article is far too extreme. It tells you that stability is the most important thing concerning URIs. I will pursue this a little further, because I think that getting the web presence right is very important to maintaining an online community. It may be that we must agree to disagree, but based on my experience of using the web, stability of URIs *is* the most important thing (after content, of course). I have been using the W3C web site now for many years, and the inconsistencies you mention have never been a problem for me -- indeed, I hadn't even noticed them until you mentioned them. Why is this? I hypothesize that it is because, when the Web is used effectively, it is really quite rare to enter a URI manually. Instead, one uses various index pages, RSS feeds, search tools and so on to find a URI, and then simply click on it. Many URIs are never seen by human eye, but placed behind descriptive links. W3C themselves use URIs very intensively in transient communications, and their mailing system is set up to facilitate this (see their x-archived-at mail headers). A result of this is that the email archives, together with the web site pages, form a tightly interlinked collection of documents and comments that can be, and are, frequently cross-referenced rather than reinvented. But, for this to work, once a link has been placed in a document, feed, archive or whatever, it is crucially important that it continues to work for as long as the information it references is of interest to people. Without this, all the devices we use to find our way around the web simply fail -- not all at once, but over time. Even with every intent to maintain stability, this happens, but if you allow that URI stability is somehow less important than other conveniences, then I think all hope is lost for information continuing to be accessible. As for the difficulty of designing a consistent URI naming scheme for all time, the W3C position explicitly recognizes this, and this is why they recommend incorporating dates near the the root of the URI path. That way, fashions can change without requiring that pages published using older conventions be removed. How to do this in a wiki, I'm not sure, though I don't take that to mean we shouldn't try. I think the mediawiki mechanism you mention is reasonable if not ideal, though this would clearly be overwhelmed if page-renaming were to become the norm. There are, as you indicate, other technical concerns. But I still think they are more easily solved that the problems that arise by failing to maintain URI stability. Best regards, #g -- Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] page renaming on the Haskell Wiki
In making such changes, please bear in mind Cool URIs Don't Change: http://www.w3.org/Provider/Style/URI This isn't to say don't, but where possible, provide some redirection from the old name to the new name. To be effective, the web relies on stable links, so that references from elsewhere don't fade away. In the end, it is publishers own (presumed) goals in publishing to the Web that are compromised if URIs become inaccessible. #g -- Wolfgang Jeltsch wrote: Hello, I just renamed several wiki pages. One reason for this renaming was the inconsistent capitalization of page titles. The thread starting with http://www.haskell.org//pipermail/haskell/2006-January/017485.html contains some background of this renaming. I think that a consistent and sensible naming of pages of the Haskell Wiki is very important. Since no further opinions were given concerning page naming and late page renamings might be inconvenient for wiki users, I decided to do this page renaming now, according to what was said in the above-mentioned thread and to what I thought was sensible. I have put some further information about the renaming on the wiki itself under http://haskell.org/haskellwiki/User:Wolfgang_Jeltsch/Page_renaming. Maybe the rationale for page titles given there can server as a basis for a kind of standard for Haskell Wiki page names? I'm open to comments. Best wishes, Wolfgang ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell -- Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] HaXml: ampersand in attribute value
Lennart Augustsson wrote: But speaking of HaXml bugs, I'm pretty sure HaXml doesn't handle % correctly. It seem to treat % specially everywhere, but I think it is only special inside DTDs. I have many XML files produced by other tools that the HaXml parser fails to process because of this. Indeed. This is an area that I found required a fair amount of work on the version of HaXML I was playing with, some time ago. The change log at the end of: http://www.ninebynine.org/Software/HaskellUtils/HaXml-1.12/src/Text/XML/HaXml/Lex.hs has some clues to what I had to do. Notably: [[ -- Revision 1.12 2004/06/04 21:59:13 graham -- Wortk-in-progress: creating intermediate filter to handle parameter -- entity replacement. Separated common features from parse module. -- Created new module based on simplified use of parsing utilities -- to dtect and substitute PEs. The result is a modifed token sequence -- passed to the main XML parser. ]] The parameter entity filter is defined by: http://www.ninebynine.org/Software/HaskellUtils/HaXml-1.12/src/Text/XML/HaXml/SubstitutePE.hs The parameter and entity entity handling aspect of the code was not pretty, due mainly to the somewhat quirky nature of XML syntax, especially concerning parameter and general entities. #g -- Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HaXml: ampersand in attribute value
Malcolm Wallace wrote: Lennart Augustsson wrote: But speaking of HaXml bugs, I'm pretty sure HaXml doesn't handle % correctly. It seem to treat % specially everywhere, but I think it is only special inside DTDs. I have many XML files produced by other tools that the HaXml parser fails to process because of this. I believe I fixed at least one bug to do with % characters around version 1.14. But that is the development branch in darcs, not formally released yet. Nevertheless, if you know of such bugs, do report them; even better if you can send a small test case. Malcolm, Did you come across the HaXml test harness I created based on a subset of W3C conformance tests? http://www.ninebynine.org/Software/HaskellUtils/HaXml-1.12/test/ This covers all the parameter entity problems I fixed some time ago. #g -- Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell XSLT interpreter?
S. Alexander Jacobson wrote: Has anyone written a pure haskell xslt interpreter? If not, how difficult would it be to do so? (Ah, another cool project idea that fell by the wayside sigh!) Back when I was doing more web work in Haskell, inventing a translation of XSLT into Haskell was one of the ideas I was gestating. Unfortunately (or not), a day job came along and distracted me from that. ... Without reading in detail, I notice subsequent debate about how to write a pure function that deals with XML constructs that might perform IO. This was one of the problems I encountered when working on HaXML: I wanted to have options to use use the parser in pure mode (String - XML), but also to be able to support full XML that may require I/O (XML defines an internal subset that doesn't require processors to perform I/O). In the event, I cheated and used unsafePerformIO. But it did occur to me that by parameterizing the XML processing function with a polymorphic function to turn an entity declaration into a string, like this: getEntityString :: Monad m = decl - m String then the dependency on IO could itself be parameterized. For pure use, an identity monad could be used, which the calling program could safely unwrap. But if external entity support is required, then the type 'm' must be (or incorporate) an IO, so the value returned to the calling program would only be accessible within an IO monad. I feel sure this must be a known Haskell idiom for this kind of problem, but I can't say that I've noticed it anywhere. Or is there a snag I didn't notice? #g -- Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Spotted in Haskell Weekly News: February 06, 2006
Donald Bruce Stewart wrote: Haskell Weekly News: February 06, 2006 : Oleg says, The implementation of RSA on the type level is left for future work. Methinks this gives a whole new meaning to type security. :) #g -- Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Pythonic monads
Constructing some code today in Python, using some functional-style coding
idioms, I found myself wondering if there would be any real benefit to using a
monad-based implementation (i.e. other than to demonstrate that it can be done).
The application that sparked this line of thought was a simple filter to trim
comments and whitespace out of an XML document. I ended up with a simple
state-machine driven filter, thus:
[[
# Strip comments from XML strings
def stripXmlComments(x):
# State table for stripping XML comments
stStripXmlComments = \
{ 0: match1('',(1,stateFilterHold),(0,stateFilterPass))
, 1: match1('!',(2,stateFilterHold),(0,stateFilterPass))
, 2: match1('-',(3,stateFilterHold),(0,stateFilterPass))
, 3: match1('-',(4,stateFilterDrop),(0,stateFilterPass))
, 4: match1('-',(5,stateFilterDrop),(4,stateFilterDrop))
, 5: match1('-',(6,stateFilterDrop),(4,stateFilterDrop))
, 6: match1('',(0,stateFilterDrop),(4,stateFilterDrop))
}
return stateFilter(stStripXmlComments,x)
# Simple state machine driven filter
#
# The state table is a dictionary indexed by state values, where the
# initial state is 0, and each entry is a function that accepts a next
# symbol and returns a pair of (next state, action), where action is
# one of 'stateFilterPass', 'stateFilterDrop', 'stateFilterHold'.
# stateFilterHold means that the disposition will be determined later.
#
# The result is an iterator that returns elements from the filtered
# subsequence of the supplied sequence.
#
def stateFilter(stable,seq):
queue = []
state = 0
for symbol in seq:
(state,action) = stable[state](symbol)
(queue,emit) = action(queue,symbol)
for e in emit: yield e
return
def stateFilterPass(q,n):
return ([],q+[n])
def stateFilterDrop(q,n):
return ([],[])
def stateFilterHold(q,n):
return (q+[n],[])
# State transition function to match the specified symbol and return
# 'eqval' if matched, otherwise 'neval'
def match1(sym,eqval,neval):
def m(sym,eqval,neval,next):
if next==sym: return eqval
return neval
return curry(m,sym,eqval,neval)
def curry(func, *args):
Curry multiple arguments:
See: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/229472
def curried(*args2):
args2 = args + args2
return func(*args2)
return curried
]]
and a test case:
[[
def testFilter02(self):
fullstr = !-abc- !--def-- !- -ghi--
trimstr = list(stripXmlComments(fullstr))
expstr = list(!-abc- !- -ghi--)
assert trimstr==expstr, \
stripSpaces, expected:\n+expstr+\nFound:\n+trimstr
]]
In thinking about this implementation, it seemed to me that this employed
patterns characteristic of a monadic type: each entry in the state table (in
this case, an instance of match1, a curried function) is like a step in a
monadic computation, updating the monadic value and also returning some value.
What I can't quite visualize is if the code in Python would actually look any
better if it were implemented with a monadic type, as one might readily choose
for a Haskell implementation. Or would there be no real benefit?
I have noticed that, while I like to use functional idioms in some of my Python
code, and the Python language is easily able to support these (even some lazy
evaluation, courtesy of generators), that the code doesn't always look as clean
as its Haskell equivalent. In Haskell, composition and currying are fundamental
patterns and are directly supported by the syntax. In Python, one has to work
harder to achieve these (e.g. the curry function above seems rather convoluted
to me, for such a fundamental notion).
Thoughts? Comments?
#g
--
Graham Klyne
For email:
http://www.ninebynine.org/#Contact
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell and JVM (was: EclipseFP (Haskell IDE) 0.9.1 released)
Thiago Arrais wrote: There is one issue, though, that touches a lot of sensitive areas. The Eclipse platform runs inside a Java Virtual Machine. Unfortunately, there isn't currently a way to compile Haskell to the JVM (at least I don't know of any, if someone knows, please let me know). This means the IDE has to be written in Java, not in Haskell. That's the price we are paying now. Writing a tool for a language in a different language. Ah, now there's a thing! I don't have any good answers, but I have a friend who is interested in such things, and may even be looking for a project in this area. In our discussions, a number of links came up, but I'm not sure if I can find them all. Here's an attempt: http://www.xoltar.org/languages/nice.html http://www.pugscode.org/ http://scala.epfl.ch/index.html Nothing very specific to your ideas goal, but there's some work on compiling functional code to JVM. I was also talking to someone from Cambridge Comlab the other week who has an FP-like system (for web service/portal creation) that uses JVM bytecode modification. maybe some useful experience to draw upon there? I'm also reminded of a project I was in discussion about some time ago, which was to explore use of Haskell program transformation techniques (hopefully adapting some ideas from BMF/Squiggol) for implementing aspects of a JIT runtime for JVM. Unfortunately, that never took off (and was maybe too ambitious for the effort contemplated). There is some related work at the kestrel Institute [http://www.kestrel.edu/home/projects/] #g -- Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] EclipseFP (Haskell IDE) 0.9.1 released
Thiago Arrais wrote: EclipseFP 0.9.1 has been released since last Friday. It is an open-source development environment for Haskell code. EclipseFP integrates GHC with an Haskell-aware code editor and also supports quick file browsing through an outline view, automatic building/compiling and quick one-button code execution. Downloads and more information are available on the project home page http://eclipsefp.sourceforge.net/ We are open for comments and general discussion. Actually we would really appreciate comments from both newbie and veteran Haskell programmers. This is open-source development and everyone on the Haskell community is welcome to participate. More of a meta-comment than a comment... [I should say that I haven't yet actually tried this software, though I'd like to do so when I get some time.] One of the features of Haskell that I like is that it doesn't require lots of IDE support to write complex programs... the compact syntax and clean separation of concerns that can be achieved make it iasy enough to program using nothing more than a regular text editor, and no long wait for the development environment to start up. I can imagine programming Haskell on a palm-top device. So is there a compelling feature in this Eclipse plugin that isn't easily achieved using simpler tools? (Please don't take this as a negative response to your efforts -- I can imagine things that would really help Haskell development based on this kind of framework, such as features in quickly inspect intermediate results in complex programs without visible recompilation, and instrumentation of intermediate results for creating regression tests, though I don't know how such might be provided.) #g -- Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Scripting language: is Haskell a good choice?
I used Haskell to implement a kind of scripting language, and it seemed most usable to me. I particular, I liked the fact that it was possible to write a Parsec parser that compiles script language expressions directly into executable Haskell functions, avoiding the need for a separate interpretation layer, and because of this I think performance is probably quite respectable. Higher order functions are, I believe, a real boon for this kind of work. My work in this area is a bit stale, but can be found at: http://www.ninebynine.org/RDFNotes/Swish/Intro.html The particular module that compiles script language to functions is here: http://www.ninebynine.org/Software/Swish-0.2.1/HaskellRDF/SwishScript.hs The parser assembles a list of function that uses the SwishState helper functions as primitives, and operate in the SwishStateIO monad - an I/O monad that also incorprates some specific state that is used by my interpreter. Upper-level functions are 'parseScriptFromString' and 'script'. #g -- Jules Jacobs wrote: Hi, I would like to create a scripting language, similar to Ruby, Perl and Python. Pugs, written in Haskell, is a Perl6 implementation. Is Haskell a good choice for me? I have no experience with Haskell (yet), but I like the concept of functional programming. Because Haskell will probably be too slow for the final implementation, I will have to rewrite it in C or maybe D. Haskell can be very useful as a test/prototype implementation, where speed is not very important. But will I be able to create a clean, and easy to understand implementation in Haskell? The scripting language will be object oriented, and imperative. Is that a problem because Haskell is functional, or is there be an obvious and nice way to implement an imperative scripting language? The language is very dynamic, and the source-tree needs to be in memory because it is modifiable at run-time. Would it be good to do this in Haskell, and port it to C if I like the implementation, or start in C? Keep the parser/lexer for the source code in Haskell, but port only the interpreter to C? What would be a good place to start? I am reading Yet Another Haskell tutorial, and I've read the first 6 of two dozen lessons in Haskell. What to do next, practice/read more/start with the implementation of the scripting language? Thanks in advance, Jules ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell -- Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] FunctionalJ - a library for Functional Programming in Java
A colleague alerted me to this, which I thought might be of interest here: http://www.theserverside.com/news/thread.tss?thread_id=38430 (I have already found that my Haskell experiences have influenced my Python programming; maybe there's also hope for my Java?) #g -- Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] W3C discussion: Principle of Least Power
There's a possibly-interesting thread running on the W3C TAG mailing list [2] about the Principle of Least Power [1], in which Haskell gets a mention. The debate gets kind-of interesting around discussion of analyzability of language expressions vs expressibility, with passing reference to Turing completeness. Intuitively, I've felt that expressions in a pure functional language are easier to analyze than expressions in (say) C or Java, despite them all being fully Turing complete (so no difference in expressive power there). Can it truly be said that it's easier to analyze a functional expression than a C program? What could that actually mean? I feel the discussion is (so far) missing a trick, but I'm not sure what it is. #g -- [1] http://lists.w3.org/Archives/Public/www-tag/2005Dec/0101.html http://lists.w3.org/Archives/Public/www-tag/2005Dec/0113.html http://lists.w3.org/Archives/Public/www-tag/2005Dec/0115.html (etc.) [2] http://web3.w3.org/2001/tag/ http://lists.w3.org/Archives/Public/www-tag/ -- Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Making Haskell more open
Simon Peyton-Jones wrote: * We don't have a plausible way of annotating GHC's user manual. One suggestion is a tree of Wiki pages, each linked from the corresponding section of the manual. We'd need an automated way to generate such a tree, and it's not clear what to do when moving from one release of GHC to the next. I don't know if it's worth looking at W3C's Annotea [1]. Last time I looked, it needed a special client (e.g. Amaya web browser [2]), but I don't know if anyone's thought about using a gateway to allow annotation/viewing using a regular web client (e.g. as Wikis do for web pages); e.g. [3]? #g -- [1] http://www.w3.org/2001/Annotea/ [2] http://www.w3.org/Amaya/ [3] http://ncyoung.com/entry/106 -- Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] Haskell and other languages (was: Learning Haskell)
Jimmie Houchin wrote: Haskell looks like a very interesting language. I am only so-so with Python and I thought that maybe if instead of spending sufficient time to get proficient with Python, I could invest a similar time (more or less) and get reasonably (pragmatically speaking) proficient with Haskell. I know I may never understand the theory and maths behind the design, but I believe I can appreciate the design and be a decent user of the tools it provides. FWIW, I learned Haskell a couple of years ago, having previously programmed in Python and (many) other languages. Recently, I've been using Python for a project (the choice being determined by both technical and non-technical issues), and find my Python programming style is now heavily influenced (for the better, I hope ;-) by my Haskell programming experience. A drawback of using Haskell is the limited availability of support libraries, although many people here are working hard to improve that situation. I'm doing Python work with a web application framework (Turbogears - in the same general space as Ruby/Rails, but different), and as yet I don't see anything like it in Haskell. It would be great to see a lightweight full stack web application framework for Haskell: I believe many of the pieces exist, and Haskell could be a supremely effective language for tying them together. #g -- Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Annotating calculations
At 18:48 15/06/05 +0200, Rene de Visser wrote: From: Henning Thielemann [EMAIL PROTECTED] On Wed, 15 Jun 2005, Rene de Visser wrote: I have a somewhat complicated calculation programmed in Haskell. This calculation is coded without using monads. I want to also produce a report describing the details of this calculation for each particular set of inputs. On the other hand replicating the calculation source code twice, once without reporting and once without seems bad. smaller parts. If you have more breaks you have more chances to get temporary results. You can put temporary values into a data structure. E.g. if you have an iteration don't write a recursion with a fixed abort criterion but write a function which maps the old value to the new one, then apply 'iterate' on it. Now you can inspect the temporary values and you can later apply a function which decides when to stop the iteration. Thankyou for the reply, The calculation is for the mostly already structured as you have suggested. The trouble is there are lots of little pieces that need to be put together. Do I need to put these pieces together twice? Once to put the whole calculation together? And once to do the reporting? This is what I'd like to avoid. (A good deal of the complexity comes from that the calculation has a complex structure). It would be nice to describe the structure once (at the moment the structure of the calculation is describe impliciitly in the Haskell functions) and use it both for the calculation and for the reporting. I think your instinct that the structure of the calculation not be repeated is sound. Furthermore, I think that Haskell is well suited to avoiding such duplication. Without knowing details of your problem it is difficult to be certain how to proceed, but it seems to me that you maybe have some kind of structure (or traversal pattern) over your data that can be separated from the computation. A starting point might be to separate the traversal from the computation, and code the traversal as a higher order function (taking a parameter which is a function that performs the data specific operations). If there are many different internal data types, it might be worth considering using a type class rather than a function parameter. (Or to go the whole hog, look up the technique described in SPJ/Ralf Laemmel's Generic Haskell work -- look for Scrap Your Boilerplate -- but that may be more than you need.) Staying with non-monadic functions, the computation and the formatting could be handled as simple functions, where formatting returns something like a StringS value, which can be output separately, but this might require some creativity for the type of the traversal function. Another approach would be to declare your basic traversal structure type as an extended Functor that supports an fmapM function which allows a monadic function to be applied over the structure collecting values in some way -- this being used to collect or perform output. There's a thread about this idea starting here: http://www.mail-archive.com/haskell@haskell.org/msg12757.html Bear in mind that, with Haskell, you can design your algorithm as if it generates an intermediate data structure without necessarily having to store the entire structure in memory. So if you have a list of values, each of which you require to subject to some transformation, followed by another operation that (say) formats the list, then you could: (a) use 'map' to apply the transformation to each element, creating a new list, then (b) use something like 'concatMap show' to format and concatenate the values. Doing this, it appears you need space the intermediate list, but lazy evaluation can mean that the entire list is never required all together. In such cases, I tend to think of the intermediate list or data structure as describing a traversal sequence or pattern, rather than as a concrete data value. I touch briefly on some of these issues in Learning Haskell Notes: http://www.haskell.org/tmrwiki/LearningHaskellNotes#programming-idioms #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] About ($)
At 20:53 02/06/05 +0200, Frank-Andre Riess wrote: So, well, my first question on this list is admittedly somewhat simple, but I managed to delay it long enough and now I think I should ask about it: Does ($) have any relevance at all except for being a somewhat handier version of parentheses? In addition to the other responses, I add this: The section expression ($v) -- for some value v appropriate appropriate to the source code context -- is sometimes very useful. (I think the other feature -- lower precedence of $ w.r.t normal function application -- is covered by your question.) #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Processing a file with HaXml without invoking processXmlWith?
It certainly *is* possible to process XML directly. I have a test module for a modified version of HaXml that do this... maybe this helps? The text program is: http://www.ninebynine.org/Software/HaskellUtils/HaXml-1.12/test/TestXml.hs with supporting data files in the same directory: http://www.ninebynine.org/Software/HaskellUtils/HaXml-1.12/test/ which is all part of my modified version of HaXml at: http://www.ninebynine.org/Software/HaskellUtils/HaXml-1.12/ You may also need to check out my 'Traverse' module: http://www.ninebynine.org/Software/HaskellUtils/HaXml-1.12/src/Text/XML/HaXml/Traverse.hs This code is all heavily refactored from the original HaXml for improved XML entity handling, namespace, xml:lang and xml:base support, but I'm fairly sure I didn't actually add anything else that you couldn't reasonably get at using the original HaXml API. #g -- At 01:23 02/06/05 -0700, Echo Nolan wrote: Hi all, I've an application which needs to process some XML, but the only way I can see in the Haddock-generated documentation is using the processXmlWith wrapper, which reads it's input and output arguments from the command line. I'd prefer a pure function which took a Document or a String and returned the same, processed. I hope I've overlooked something. Regards, Echo Nolan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: Existing Haskell IPv6 Code
At 12:03 15/05/05 +0200, Peter Simons wrote:
Graham Klyne writes:
The longer I think about this whole thing, the more I am
convinced that using URIs is the answer.
FWIW, the revised URI parsing code [2][3] in the latest
libraries includes support for IPv6 literals, as
specified by RFC 3986 [1].
Thanks for the pointer, Graham. I knew that the URI code had
been written a while ago, but never realized how extensive
the changes were! Great job.
Thanks! (It's essentially a complete rewrite.)
Now the only problem is that the module doesn't expose the
functions we would need; such as Network.URI.host, for
instance. Would it be possible to factor those parser out
into a
Text.ParserCombinators.Parsec.Rfc3986
This seems a reasonable idea.
module? Maybe we could even merge those parsers with the
ones I have here:
http://cryp.to/hsemail/docs/index.html
RFC grammars are often very similar after all.
I think it could be useful to have a collection of RFC parsers along these
lines. I'm not entirely sure what you mean my merge -- I think the RFC
distinctions should be maintained.
One might also consider that my unit test code (see ../tests directory)
contains some framework functions that might be used to create a test case
library.
One thought: in some cases, my URI parser code depends on the URI data
types that I declare (for the return values), so it might not separate as
cleanly as one might like -- I think it would be confusing if the data type
declarations were separated from the URI module. I suppose the parser
combinators might return tuples that are assembled by the URI code.
Also, if separating the combinators, one might want to make the monadic
parser type more general. Hmmm I did something like this for another
bit of code somewhere, but I forget where. I think I made the parser
polymorphic in the state value, which was not referenced. This way, the
parsers can be referenced by other, more specific combinators that do use
the state value. Currently, the state type is ().
P.S.: In the definition
host = ipLiteral | try ipv4address | regName
it looks as if the 'try' modifier should be given for the
first alternative; not for the second. I may be wrong
though.
My initial (lame) answer is that it passes all the available test
cases. More seriously, if you think there's something that breaks the
current code then a test case should be created.
Looking at the production (copy below), the first case doesn't need a 'try'
because if the initial character is a '[' then no other parse is
possible. But for the ipv4literal production backtracking may be needed;
consider:
111.222.333.mydomain.org
#g
--
*
Selected host productions:
[[
host :: URIParser String
host = ipLiteral | try ipv4address | regName
ipLiteral :: URIParser String
ipLiteral =
do { char '['
; ua - ( ipv6address | ipvFuture )
; char ']'
; return $ [ ++ ua ++ ]
}
? IP address literal
:
ipv4address :: URIParser String
ipv4address =
do { a1 - decOctet ; char '.'
; a2 - decOctet ; char '.'
; a3 - decOctet ; char '.'
; a4 - decOctet
; return $ a1++.++a2++.++a3++.++a4
}
]]
Graham Klyne
For email:
http://www.ninebynine.org/#Contact
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] APIs (was: Unexported functions are evil)
At 17:20 19/05/05 -0400, [EMAIL PROTECTED] wrote: One of the best bad example is the use of boolean as arguments. Oh, yes. That's a pet peeve of mine. About 99% of boolean arguments should be meaningful two-valued enumerated types. It's literally a one-liner to create such an enumerated type, so there's no excuse. While I see your point in the case of Booleans, I note that, in other circumstances, not using a pre-existing data type can be sub-optimal; cf. use of Maybe noted at [1]. #g -- [1] http://www.ninebynine.org/Software/Learning-Haskell-Notes.html#UseStandardTypes Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: APIs (was: Unexported functions are evil)
At 19:39 18/05/05 -0400, [EMAIL PROTECTED] wrote: G'day all. Quoting Graham Klyne [EMAIL PROTECTED]: I think you raise an important point. Reading this, I realize that I have no principled basis for deciding what makes a good API, in any language. Me neither. Though I have short reading list. First off, this series of articles by Ken Arnold. They are a bit Java- centric, but it's all good: http://www.artima.com/intv/perfect.html http://www.artima.com/intv/taste.html http://www.artima.com/intv/distrib.html http://www.artima.com/intv/sway.html http://www.artima.com/intv/decouple.html http://www.artima.com/intv/issues.html Looks interesting. Thanks. Some of the modern C++ books like Modern C++ Design and Generative Programming are worth a skim in lieu of a decent book on how to deal with true parametric polymorphism and typeclasses. In a similar vein, I think Martin Fowler's book on refactoring has some interesting insights. #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] APIs (was: Unexported functions are evil)
At 21:42 15/05/05 -0400, [EMAIL PROTECTED] wrote: Continuing on from the previous thought, part of the problem here is that we teach people to write code (e.g. how to implement a sort), but we don't teach people to write APIs. APIs are both trickier to get right AND are more important in larger programs. I think you raise an important point. Reading this, I realize that I have no principled basis for deciding what makes a good API, in any language. I do, of course, have lots of personal ideas and feelings about what APIs should be like, but not that I could defend as coherent and rational strategy. So I ask myself: are there any good papers or books on this topic that outline a coherent and principled approach to API design? #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Text search
At 10:27 16/05/05 +0200, Gracjan Polak wrote: Hi, Simple question: I need a function that matches string in another string. Something like: find (isSuffixOf needle) (inits haystack) This one is beautiful, but not very practical. Could anybody point me to some haskell library that does some searching, using KMP for example? [[ import List foo = isPrefixOf (reverse needle) (reverse haystack with needle) bar = isPrefixOf (reverse needle) (reverse haystack with pins) ]] Seems to work. And (by inspection) is linear in size of haystack. #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell for non-mathematicians (was: Specify array or list size?)
At 13:08 07/05/05 -0400, David Roundy wrote: On Sat, May 07, 2005 at 12:40:55PM -0400, Daniel Carrera wrote: In your opinion, do you think Haskell is appropriate for someone with zero math background? I can't imagine how I'd explain something like currying to someone who doesn't know math. I'd think it'd be pretty easy for a non-mathy non-programmer person to learn (based on pure speculation--I've never taught haskell). There is a sort of basic core of haskell that is pretty easy, and most of the higher level concepts are a sort of nicer way to say the same thing. For example, while lambda expressions are very nice, it's always possible to do the same thing by declaring a named function in a let or where clause. I'm reminded of something mentioned by Alan Kay in a recent interview published in ACM Queue magazine: [[ AK [...] One of the things that people realized from these extensible languages is that there is the unfortunate difficulty of making the meta-system easy to use. Smalltalk-72 was actually used by children. Youre always extending the language without realizing it when you are making ordinary classes. The result of this was that you didnt have to go into a more esoteric place like a compiler compilerYacc or something like thatto add some extension to the language. But the flip side of the coin was that even good programmers and language designers tended to do terrible extensions when they were in the heat of programming, because design is something that is best done slowly and carefully. SF And late-night extensible programming is unsupportable. AK Exactly. So Smalltalk actually went from something that was completely extensible to one where we picked a syntax that allowed for a variety of forms of what was fixed, and concentrated on the extensibility of meaning in it. This is not completely satisfactory. One of the things that I think should be done today is to have a fence that you have to hop to forcibly remind you that youre now in a meta-areathat you are now tinkering with the currency system itself, you are not just speculating. But it should allow you to do it without any other overhead once youve crossed this fence, because when you want to do it, you want to do it. ]] -- http://www.acmqueue.com/modules.php?name=Contentpa=showpagepid=273 When I read the above, I found myself thinking of two styles of Haskell programming: on one hand there are some, many on these mailing lists, but I pick Oleg as an exemplar, who continue to baffle me with the amazing tricks they can do with (say) the Haskell type system. And there are ordinary programmers (like myself) who want to use Haskell's small core and (not-so-small) type system to find more elegant ways to write application software (e.g. http://www.cs.kent.ac.uk/projects/vital/ - if IO were added). I find that higher order functions and currying provide powerful tools to isolate different aspects of a program's functionality, but I'm not sure I'd want to explain them to a complete novice programmer. So, responding to the original comment, I think there's a core of Haskell that's probably quite suitable for non-mathematical programmers, but there's a lot of potential to build application frameworks that requires a mathematical kind of abstract and analytical approach, if not specifically a mathematical background. A challenge that I think a little about, sometimes, is how to keep them distinct, which is a point to which Alan Kay seems to be alluding (above). #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Newbie : What does the sequence function make?
At 19:42 02/05/05 +0200, [EMAIL PROTECTED] wrote: Please,can anyone explain it to me? Cheers! This may be a bit late, and others have responded, but just in case it helps you might peek at: http://www.ninebynine.org/Software/Learning-Haskell-Notes.html#Sequence #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell with Apache?
I'm interested in running Haskell code invoked from an Apache web server request. I discovered the mod_haskell project [1] which looks prima facie v. promising. Does anyone have any recent experience of using this (there apparently being no recent activity on this project)? I wonder if there's any other project or activity in this area I should be aware of? #g -- [1] http://losser.st-lab.cs.uu.nl/mod_haskell/ Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] predicates in XML toolboxes
At 13:48 12/04/05 +0100, Malcolm Wallace wrote:
Henning Thielemann [EMAIL PROTECTED] writes:
predicates a - Bool
selectors, transformatorsa - a
list-valued functionsa - [a]
What about providing combinators for the most common cases and provide
lifting functions for the uncommon cases, such as
liftPred :: (a - Bool) - (a - [a])
liftPred p x = if p x then [x] else []
liftTrans :: (a - b) - (a - [b])
liftTrans f x = [f x]
Looks good. If you want to come up with a concrete design for an fuller
set of alternative combinators, I'd be happy to include it into HaXml as
a further choice of facility.
Obliquely related to this thread:
When I added namespace support and other stuff to HaXml, I added (a) and
infoset type parameter to the XML document type [1], and (b) a new
transformation type [2] so that I could create new document types with
additional information in the Haskell data to support features like XML
namesspaces and xml:base.
I think your proposals could also be added into this framework, with the
additional wrinkle that using a 'newtype' in the infoset value type, one
could maybe achieve a degree of type safety, but at the cost of losing some
of the algebraic properties of a 'CFilter'.
My version is on my web site (sorry I'm offline and can't find the actual
URI right now).
#g
--
[1] From my version of Text.XML.HaXml.Types:
[[
data DocumentI i = Document Prolog (SymTab EntityDef) (ElementI i)
data ElementI i = Elem QName i [Attribute] [ContentI i]
data ElemTag = ElemTag Name [Attribute] -- ^ intermediate for parsing
type Attribute = (QName, AttValue)
data ContentI i = CElem (ElementI i)
| CString Bool CharData -- Bool flags whitespace significance
| CRefReference
| CMisc Misc
| CErrString-- Fudge to get error diagnostics
-- from a filter
data ElementInfoset = EI
{ eiNamespaces :: [Namespace]
, eiBase:: String
-- Non-infoset values
-- (in xml namespace: http://www.w3.org/XML/1998/namespace)
, eiLang:: String
, eiSpace :: Bool -- True=preserve, False=default
-- ? , eiIdent :: String -- xml:id, or other ID value?
} deriving Show
]]
So that:
[[
type Document = DocumentI ()
type Element = ElementI ()
type Content = ContentI ()
]]
Provide compatibility with existing HaXml, but I can use
[[
DocumentI ElementInfoset
ElementI ElementInfoset
ContentI ElementInfoset
]]
...
[2] From my version of Text.XML.HaXml.Combinators:
[[
type CTransform i1 i2 = ContentI i1 - [ContentI i2]
type CFilterI i = CTransform i i
type CFilter = CFilterI ()
]]
Graham Klyne
For email:
http://www.ninebynine.org/#Contact
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] URLs in haskell module namespace
Switching to -cafe... At 12:14 22/03/05 +, Malcolm Wallace wrote: import http://domain.org/package-1.0.cabal#Network.HTTP as HTTP import http://hage.org/package-2.1.cabal#Network.HTTP as HTTP2 --note use of HTTP fragment identifier for module name I cannot see any of the Haskell compilers ever implementing this idea as presented. It would introduce an enormous raft of requirements (networking client, database mapping, caching, etc) that do not belong in a compiler - they belong in separate (preprocessing/packaging) tools. Furthermore, these tools already exist, albeit they are young and have a long maturation process still ahead of them. Well, I'd agree the networking stuff don't belong in the compiler. In the operating system, I'd suggest, as part of the I/O and file system. In the long, I believe the distinction between local and networked resources will fade away (other than for practical purposes, as today with specific networked file systems), and URIs are an effective and standardized way to identify all kinds of resources. #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] URLs in haskell module namespace
At 15:47 21/03/05 -0500, S. Alexander Jacobson wrote: As I move from machine to machine, it would be nice not to have to install all the libraries I use over and over again. I'd like to be able to do something like this: import http://module.org/someLib as someLib If the requested module itself does local imports, the implementation would first try to resolve the names on the client machine and otherwise make requests along remote relative paths. I think this is an interesting idea, that has some interesting implications for possible evolution of Haskell as an integrated scripting language for the web. One of the principles of web architecture is, roughly, that anything worth naming is worth naming with a URI [1][2]. I think a logical consequence of using URIs for module names is that module exports can become URI references with fragment identifiers. Thus, given: module http://example.org/modules/foo( func1, func2, val3 ) where ... Also introduces URI references: http://example.org/modules/foo#func1 http://example.org/modules/foo#func2 http://example.org/modules/foo#val3 This exactly where web services and SOAP are going, using URIs to identify processing services in the Web. Some other points to note... Concerning dependency on http: http: is just one URI scheme among many. It just happens to be very widely used, and provides a uniform naming and resource location framework [3] [6]. Within the Web technical community, there is a strong sense that *all* URIs should be stable [4] [5], or breakage occurs. This is illustrated by the concern for dependence on changeable URIs expressed in another message in this thread, but I think that when persistence is needed (for technical reasons) then it can be arranged. #g -- [1] http://www.w3.org/TR/webarch/#uri-benefits [2] http://www.w3.org/DesignIssues/Webize.html [3] http://www.w3.org/2002/Talks/www2002-tbl/ http://www.w3.org/2002/Talks/www2002-tbl/slide12-0.html (I spent a little while looking for a more definitive view on this idea of the less-than-absolute distinction between identification and location in the web. Although this topic is much-discussed in web circles, this was the best I could find quickly.) [4] http://www.w3.org/Provider/Style/URI [5] http://www.w3.org/DesignIssues/PersistentDomains [6] http://www.w3.org/DesignIssues/Naming Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] Using -main-is with GHC 6.4/Windows
At 09:29 18/03/05 +, Simon Peyton-Jones wrote: [Redirecting to GHC users, which is where GHC-specific questions belong] OK (but I'm not subscribed to that list, so pls copy me on any further comment, if any.) | OK, it's not so bad. If I delete the AffyDataCalc.o file before compiling | AffyDataCalcTest, it all works fine. ... | Hmmm... is there something the GHC --make feature can do to force | recompilation of the other modules previously compiled as main | modules? Just a thought. We're always wary of adding too much magic! I can appreciate that. It did strike me as a little strange (magic, even?) that the result of compiling a module named explicitly on the GHC command line is different from the implicit compilation performed when chasing imports. (I think I understand *why* it happens, but it still seems a little strange.) By way of exploring the issue, rather than actually asking for any of the following to be done, some thoughts I had are: (a) generate the program initialization/finalization entry points in a separate .o file from the compiled module, and include that in the link. (b) use a different output filename (e.g. module_main.o) when compiling a module as a program entry point. (c) combination of (a) and (b) - compile base module as non-main, and a separate output file for the program startup magic with a name based on but different from the corresponding source module. I'll add a note to the -main-is documentation though. Thanks. #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] Using -main-is with GHC 6.4/Windows
I've been trying to use the -main-is option with GHC 6.4 on Windows. In isolation it works fine, but it still doesn't achieve what I hoped it would. Consider this compilation output frgament: [[ Compiling AffyDataCalcTest ( AffyDataCalcTest.hs, AffyDataCalcTest.o ) Linking ... ./AffyDataCalc.o(.data+0xa70):fake: multiple definition of `ZCMain_main_srt' AffyDataCalcTest.o(.data+0x1fc):fake: first defined here ./AffyDataCalc.o(.data+0xa78):fake: multiple definition of `ZCMain_main_closure' AffyDataCalcTest.o(.data+0x204):fake: first defined here ./AffyDataCalc.o(.text+0x9158):fake: multiple definition of `ZCMain_main_info' AffyDataCalcTest.o(.text+0x1ff0):fake: first defined here ./AffyDataCalc.o(.text+0x9408):fake: multiple definition of `__stginit_ZCMain' AffyDataCalcTest.o(.text+0x20c0):fake: first defined here ]] The module 'AffyDataCalc' contains a function called 'main', which is the topo-level function of the target program I have under development. The module AffyDataCalcTest also has top-level function called runtest, which, you guessed it, runs a test of the program functions. It seems that the top-level functions still interfere with each other. [later] OK, it's not so bad. If I delete the AffyDataCalc.o file before compiling AffyDataCalcTest, it all works fine. [[ E:\OxfordCVS\DTGED\AffyDataghc --make -fglasgow-exts -iD:\Cvs\DEV\HaskellUti C:\Dev\Haskell\Lib\HUnit;C:\Dev\Haskell\Lib\Parsec;C:\Dev\Haskell\MyLibs\ -o yDataCalcTest.exe -main-is AffyDataCalcTest.runtest AffyDataCalcTest Chasing modules from: AffyDataCalcTest Compiling ParseCSV ( ./ParseCSV.hs, ./ParseCSV.o ) Compiling FormatCSV( ./FormatCSV.hs, ./FormatCSV.o ) Skipping ListHelpers ( D:\Cvs\DEV\HaskellUtils/ListHelpers.hs, D:\Cvs\D HaskellUtils/ListHelpers.o ) Compiling AffyDataCalc ( ./AffyDataCalc.hs, ./AffyDataCalc.o ) Skipping HUnitLang( C:\Dev\Haskell\Lib\HUnit/HUnitLang.lhs, C:\Dev\H ell\Lib\HUnit/HUnitLang.o ) Skipping HUnitBase( C:\Dev\Haskell\Lib\HUnit/HUnitBase.lhs, C:\Dev\H ell\Lib\HUnit/HUnitBase.o ) Skipping HUnitText( C:\Dev\Haskell\Lib\HUnit/HUnitText.lhs, C:\Dev\H ell\Lib\HUnit/HUnitText.o ) Skipping HUnit( C:\Dev\Haskell\Lib\HUnit/HUnit.lhs, C:\Dev\Haske Lib\HUnit/HUnit.o ) Skipping TestHelpers ( D:\Cvs\DEV\HaskellUtils/TestHelpers.hs, D:\Cvs\D HaskellUtils/TestHelpers.o ) Compiling AffyDataCalcTest ( AffyDataCalcTest.hs, AffyDataCalcTest.o ) Linking ... E:\OxfordCVS\DTGED\AffyDataaffydatacalctest Cases: 2 Tried: 0 Errors: 0 Failures: 0AffyDataCalc done. Cases: 2 Tried: 1 Errors: 0 Failures: 0AffyDataCalc done. Cases: 2 Tried: 2 Errors: 0 Failures: 0 E:\OxfordCVS\DTGED\AffyDataghcc AffyDataCalc ]] Hmmm... is there something the GHC --make feature can do to force recompilation of the other modules previously compiled as main modules? Just a thought. #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] GHC: Setting default +RTS options at compile time?
Is there any way to specify at compile/link time default options for GHC program +RTS options? I'm using the latest release (6.4). #g -- aside Why do I want this? I'm using GHC to write a program that will be used by non-comp uting people to preprocess some data in conjunction with an 18Mb database file. To load the database into a Data.Map value requires more than GHC's default 256Mb of heap, and I'd like to increase the program's default heap size, rather than telling users to use the +RTS -M100M option, as its one less thing to get wrong. There are of course other possible solutions, but in this case specifying a default heap size at compile time seems to be the most natural. /aside Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: GHC version 6.4
Some minor documentation feedback... At 12:25 11/03/05 +, Simon Marlow wrote: = The (Interactive) Glasgow Haskell Compiler -- version 6.4 = I've just been browsing the release notes at: http://haskell.org/ghc/docs/6.4/html/users_guide/release-6-4.html and I notice some broken links about the end of section 1.4.3: [[ Network.URI has been completely rewritten, and now conforms to RFC2732. New module: System.Posix.Error. New module: System.Posix.Signals.Exts. ]] Specifically: http://haskell.org/ghc/docs/6.4/html/libraries/base/Network.URI.html http://haskell.org/ghc/docs/6.4/html/libraries/base/System.Posix.Error.html http://haskell.org/ghc/docs/6.4/html/libraries/base/System.Posix.Signals.Exts.html #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Re: Strange HTTP module behavior [PATCH]
Hmmm... FWIW, I've been using a lightly modified version of Bjorn's version of HTTP in a modified HaXml parser, and it worked fine for accessing external entities. But that almost certainly did not involve receiving zero bytes. #g -- At 16:58 18/02/05 -0600, John Goerzen wrote: On Fri, Feb 18, 2005 at 11:36:57PM +0100, Bjorn Bringert wrote: John Goerzen wrote: It turns out that Network.Socket.recv raises an EOF error when it gets back 0 bytes of data. HTTP is expecting it to return an empty list for some reason. The below patch fixed it for me. [...] Hmm, strange. Is that recv behavior a bug or a feature? I don't know, but it's explicitly there whatever it is. From ghc 6.2.2: let len' = fromIntegral len if len' == 0 then ioError (mkEOFError Network.Socket.recv) else peekCStringLen (ptr,len') It appears this change was committed to fptools in version 1.26 of Socket.hsc on July 15, 2002. http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/network/Network/Socket.hsc.diff?r1=1.25;r2=1.26;f=h Which arguably is not what one would expect recv to do, and in any case is undocumented at http://www.haskell.org/ghc/docs/latest/html/libraries/network/Network.Socket.html#v%3Arecv Still, 2002 was awhile back, so I'm still surprised nobody else noticed. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsec online resource
There's a very simple example of using Parsec, complete with some test cases, here: http://www.ninebynine.org/Software/HaskellUtils/RegexParser.hs #g -- At 22:07 21/02/05 +0800, Edwin Eyan Moragas wrote: HI Guys, i'm trying to use parsec to do some data creation for me. was reading the online user documentation and all seems well. however, i can't dig how i can use the result of the parsing. any ideas/resources you can point out would be of very big help. just in case you're interested. i'm trying to implement a YAML parser. that is: 1) read a YAML file containing data (say a list of names) 2) parse the YAML file (this is where parsec comes in) 3) come out with a list (int haskell) after parsing the YAML source. kind regards, eyan -- http://www.eyan.org Object-oriented programming offers a sustainable way to write spaghetti code. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RDF and stuff (was: Point-free style ...)
At 23:00 10/02/05 -0500, David Menendez wrote: Here's another one: addTriple (s,p,o) = addArc s p o . addNode s . addNode p . addNode o It looks like you're playing around with RDF here. A quick check of your web site shows a Semantic Web angle to some of your workings. I also see you show up in some of the ESW work. You may be interested that I have a full RDF/XML parser in Haskell (based on a modified version of HaXML) (and also a reasonably competent Notation3 parser).It passes all of Dave Beckett's RDF parser test cases, which include all the W3C RDF core WG test cases, (except one to do with I18N handling). I haven't yet found time to wrap it all up neatly, but the code is available here: RDF/XML parser and test code: http://www.ninebynine.org/Software/HaskellRDF/RDF/Harp/ Supporting code for RDF node handling: http://www.ninebynine.org/Software/HaskellRDF/RDF/Label/ Modified HaXML parser: http://www.ninebynine.org/Software/HaskellUtils/HaXml-1.12/ URI parser (above should also work with library version in next GHC): http://www.ninebynine.org/Software/HaskellUtils/Network/ Possibly uses some other support modules from: http://www.ninebynine.org/Software/HaskellUtils/ I had been meaning to wrap all this into my Swish package (http://www.ninebynine.org/RDFNotes/Swish/Intro.html), but real work intervened. I do intend to return to this when I can find an excuse to make it part of the new day job. #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Point-free style (Was: Things to avoid)
[I drafted this response some time ago, but didn't send it, so apologies if I am re-covering old ground...] At 09:23 10/02/05 -0500, Jan-Willem Maessen wrote: If you're trying to avoid obscurity, why advocate point-free style? Some time ago, I asked an experienced Haskell programmer about the extent to which they used point-free style in day-to-day programming, and the response I got was to the effect that they use point-full style a fair amount. The ...er... point, I think, is that it is easier to reason equationally with point-free programs, even if the intended computation is often easier for mere mortals to see when named values are used. So point-free style helps when trying to apply program transformation techniques, and translation to make greater use of point-free idioms may be a useful precursor to transforming a program. Something I have noticed is that, as one gets more used to using higher order functions, it is often more elegant to express a computation by composition of functions, but in so doing one has to discard preconceived notions of what makes an efficient program. I think it comes down to this: learn to be comfortable with both styles, and be prepared to use the one that best expressed the intended solution (and is easiest to understand) in any given context. #g -- At 09:23 10/02/05 -0500, Jan-Willem Maessen wrote: If you're trying to avoid obscurity, why advocate point-free style? I ask this question to be deliberately provocative; I'm not trying to single you out in particular. So, to everybody: What's so great about point-free style? Is it really clear or obvious what map . (+) means? Contrast this with \n - map (+n) or \n xs - map (+n) xs I submit that, while it is possible to develop a reading knowledge of point-free style, non-trivial use of point-free computations---compositions of functions with arity greater than 1, as above, compositions of sections of composition or application, arrow notation without the sugar, and so forth---will always be more difficult to read and understand than the direct version. I submit that this is true even if one is familiar with point-free programming and skilled in its use. Even something as simple as eta-reduction (as in the second and third functions above) can seriously obscure the meaning of program code by concealing the natural arity of a function. -Jan-Willem Maessen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsing in Haskell
I've used Parsec for small and more complex parsing tasks, and found it works well for both. In the past, I've used parser generators (not with Haskell), but now I find that I prefer to express a parser directly in the main programming language I'm using ... that way, it's easier to escape the grammar and do the things that aren't always so easy to do within the BNF-and-stuff formalisms. I find my code using Parsec is close enough to the BNF that the syntax production logic is easy enough to see. A very useful feature of Parsec is that, within what is broadly an LL(1) parsing framework, it provides a controlled limited lookahead capability. Another useful little trick I've found using Haskell+Parsec is that for an interpreted little language, instead of returning a data structure describing the input sentence, I can return a function that can be applied to appropriate values to execute it directly. #g -- At 11:36 15/02/05 +0100, Johan Glimming wrote: Hi I want to implement a little algebraic specification language in Haskell, and I have a working C implementation available which uses yacc/flex. What is the best way of replacing yacc/bison and (f)lex when migrating the project into Haskell? Best Wishes, Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Top 20 ``things'' to know in Haskell
It's not exactly what you ask for, but I wrote down some of the things I learned in my early days with Haskell: http://www.ninebynine.org/Software/Learning-Haskell-Notes.html #g -- At 10:31 07/02/05 -0500, Jacques Carette wrote: The recent post of Graham Klyne (below) reminds me that I have meant to ask: is there a ``top 20'' things a serious programmer should know when writing code in Haskell? Of course there is a lot of programming language theory that would be great to know, but I mean really down-to-earth things like the 2 items below (module Maybe, the 'maybe' function). The Haskell libraries are quite large, and it is unrealistic to try to get familiar with all of them right away. But getting a ``small'' list would be very useful - I think of this as step 2 after one learns to get comfortable with a language. I had done this (for Maple) for training new hires at Maplesoft, and I definitely noticed that they became more idiomatic programmers faster this way. Jacques PS: of course, this could already exist on haskell.org and/or the Wiki, but not in an 'obvious' enough place as I missed it... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Klyne Sent: February 7, 2005 10:09 AM To: Yuri D'Elia; haskell-cafe@haskell.org Subject: [Haskell-cafe] Re: [Haskell] [newbye] 'Just a' You might also be interested in the library function 'maybe': http://www.haskell.org/onlinereport/standard-prelude.html#$vmaybe or maybe (sic) Maybe.fromMaybe in: http://www.haskell.org/onlinereport/maybe.html #g -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] [newbye] 'Just a'
[I've switched my response to the Haskell-cafe list] What do you intend if both (get a) and (get b) return Nothing? You might also be interested in the library function 'maybe': http://www.haskell.org/onlinereport/standard-prelude.html#$vmaybe or maybe (sic) Maybe.fromMaybe in: http://www.haskell.org/onlinereport/maybe.html Using one of these, I think your function could reasonably be expressed as a simple one-liner. #g -- At 19:33 04/02/05 +0100, Yuri D'Elia wrote: Hi all. I'm experimenting with haskell and its type system. I've done a function which scans a list, and returns Just a value if the element is found, or Nothing. get :: a - Maybe a and implemented getAorB :: Maybe a - Maybe a - a getAorB a b = ... a function which returns Just (get a) or Just (get b) if (get a) is Nothing (excluding failures in both). By now, I've implemented it in terms of pattern matching: getAorB a b = f (get a) (get b) where f (Just a) Nothing = a f Nothing (Just a) = a but I'd like to know if there are other possible ways to do it, possibly without enforcing an evaluation order like pattern matching does. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] File paths and internationalization/localization
I don't offer any answers, but the problems raised on this list concerning file paths using local language characters would appear to have some parallels in the world of URIs. Martin Duerst and others at W3C have been working on the problem of internationalization (I18N) of URIs, and their proposals were recently published as a Proposed Standard RFC [1]. If this area is being considered in the design of Haskell libraries, there may be some lessons there to be copied. #g -- [1] ftp://ftp.rfc-editor.org/in-notes/rfc3987.txt Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Newbie : How come that cyclic recursive lists are efficient ?
Notice that 'hamming' *is* a list of integers, not a function to produce them: hamming :: [Integer] Thus, the magic here is that you can define this list as a value, without having to actually evaluate any element until it's needed, either by direct reference from another function, or indirectly by the recursive definition to obtain a value directly required. But once evaluated, the deferred evaluation is replaced by the resulting value. This is the power of lazy evaluation. Even fixed values (as opposed to function calls) aren't evaluated until they're needed. #g -- At 10:38 24/01/05 +0100, Francis Girard wrote: Hi, The classical Hamming problem have the following solution in Haskell : *** BEGIN SNAP -- hamming.hs -- Merges two infinite lists merge :: (Ord a) = [a] - [a] - [a] merge (x:xs)(y:ys) | x == y= x : merge xs ys | x y= x : merge xs (y:ys) | otherwise = y : merge (x:xs) ys -- Lazily produce the hamming sequence hamming :: [Integer] hamming = 1 : merge (map (2*) hamming) (merge (map (3*) hamming) (map (5*) hamming)) *** END SNAP I just love these algorithms that run after their tail (they make my brain melt) but I don't know how is it that they are efficient. Here, the hamming recursively calls itself three times. For this algorithm to be efficient, the Haskell system, somehow, has to remember the already generated sequence THROUGH RECURSION (i.e. not only intermediate local results) otherwise it would end up regenerating the beginning of the sequence over and over again. Obviously, Haskell does remember what had already been generated THROUGH RECURSION since executing the program with GHCI runs quite smoothly and responsively. That Haskell manages to do that is for me magnifique. But I need to know (if only a little) about how it achieves this in order to know what I, as a lambda programmer, can do, and how to compute the Big-Oh complexity of the algorithm. Thank you, Francis Girard FRANCE ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] File path programme
At 15:17 20/01/05 -0500, Mark Carroll wrote: I tried writing a little command-line utility to find the relative path of one thing from another thing (with Unix-like systems in mind). ... FWIW, there's logic to do something like this in my URI module [1]. Bear in mind that there is not, in general, a unique solution (e.g. in extremis, the absolute path of the target might be a legitimate solution, regardless of the base). [1] http://www.ninebynine.org/Software/HaskellUtils/Network/URI.hs There's also a slightly later copy in the Haskell libraries CVS, which I believe is due to ship with the next GHC release. Look for function relativeFrom. See also module URITest.hs [2], for examples of relative paths created by this algorithm (look for function testRelSplit). [2] http://www.ninebynine.org/Software/HaskellUtils/Network/URITest.hs #g -- At 15:17 20/01/05 -0500, Mark Carroll wrote: I tried writing a little command-line utility to find the relative path of one thing from another thing (with Unix-like systems in mind). For example, $ ./pathfromof /etc/init.d/ /etc/X11/XF86Config-4 ../X11/XF86Config-4 $ ./pathfromof /tmp/baz/ /tmp/foo/ . $ ls -l /tmp/baz lrwxr-xr-x 1 markc markc 8 2005-01-20 12:01 /tmp/baz - /tmp/foo It turned out surprisingly complex, though, and doesn't feel very neat or tidy at all, nor is it very portable given that I couldn't find generic library functions for manipulating bits of filepaths. Anyhow, it's at http://www.chiark.greenend.org.uk/~markc/PathFromOf.hs and may yet have egregious bugs. It seems to me like it could certainly be improved in various ways. If anyone has any thoughts, as to how I could improve my style, make more use of standard libraries, etc., I'd certainly appreciate them. Thanks, Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hugs for Zaurus
At 20:15 21/01/05 +, John Goerzen wrote: Hello, I have built a fixed Hugs for the Zaurus PDA running the OpenZaurus distribution. Download here: http://quux.org/devel/zaurus/hugs_hugs98-Nov2003-r1_arm.ipk Cool! I've often thought Haskell should be a good language for programming PDA functions, as a kind of super-calculator. Now I've seen versions mentioned for two PDAs, but no Palm yet. #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HaXmL and the IO Monad
At 14:53 21/01/05 +, John Goerzen wrote: I've been playing with HaXmL lately. I've had a need to convert one XML document to another, and HaXmL was very nice for that. Along the way, I've discovered that I need to do some I/O as part of the conversion (specifically due to timezone-related calculations). Much of HaXML is based around the CFilter type: later I just saw David Roundy's response, and think that's way better than my approach (below). /later In my modifications to HaXml [1], in re-working the external entity inclusion, I did indeed resort to using unsafePerformIO (which may be original HaXml, I don't recall). Later, I thought of a cleaner approach which would be to make the XML parsing parameterized (somehow, I forget the details right now) on a monadic function for entity retrieval. For calling functions that don't want to be forced into the IO monad, use an identity monad, which in turn would not allow external entities, otherwise use an IO function. This approach is specialized to a particular use of IO, and requires modifying the HaXml code. When I get time (not in the foreseeable future), it's a change I'd like to apply to get rid of the unsafePerformIO. I already have alternative parsing functions with/without external entity support to distinguish internal and external XML subset cases. I haven't actually worked out the details for using a monad, so I could be completely deluded here. [1] http://www.ninebynine.org/Software/HaskellUtils/HaXml-1.12/ Specifically: http://www.ninebynine.org/Software/HaskellUtils/HaXml-1.12/src/Text/XML/HaXml/SubstitutePE.hs which currently has alternative functions peNullResolver and peExtResolver to handle cases that are permitted/not permitted to perform IO, calling in turn: http://www.ninebynine.org/Software/HaskellUtils/HaXml-1.12/src/Text/XML/HaXml/EntityHelpers.hs http://www.ninebynine.org/Software/HaskellUtils/HaXml-1.12/src/Text/XML/HaXml/ExtEntity.cpphs #g -- At 15:17 20/01/05 -0500, Mark Carroll wrote: I tried writing a little command-line utility to find the relative path of one thing from another thing (with Unix-like systems in mind). For example, At 14:53 21/01/05 +, John Goerzen wrote: I've been playing with HaXmL lately. I've had a need to convert one XML document to another, and HaXmL was very nice for that. Along the way, I've discovered that I need to do some I/O as part of the conversion (specifically due to timezone-related calculations). Much of HaXML is based around the CFilter type: type CFilter = Content - [Content] That is, most of the stuff one does in HaXML is a function with that type. Try as I might, I could not figure out a nice way to integrate I/O into this system. A simple IO CFilter wouldn't work, since there has to be input available when it runs. Content - IO [Content] didn't work either, since the IO ripples up all the way to the top, messing up the nice code everywhere. I finally resorted to unsafePerformIO to get it done. But I'd like to know the proper solution. I do hope that this is not it :-) Thanks, John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Implementation of Functional Programming Languages
I think this is most welcome... I have the original printed version and have found it to be of great inspiration at various times. #g -- At 18:04 07/01/05 +, you wrote: I'm happy to announce that my out-of-print 1987 book, The Implementation of Functional Programming Languages is now available online at http://research.microsoft.com/%7Esimonpj/papers/slpj-book-1987/index.htm Very many thanks to Marnie Montgomery, who did all the work. Happy reading Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell as data manipulation language?
I'm struggling to keep up with this list, so I'll make two brief responses here. Sorry to not be more forthcoming: 1. The lack of variables in Haskell isn't a problem so much as an opportunity to think in new and interesting ways. 2. I think that when you talk about versioning, you come close to a useful way of thinking about mutable data in Haskell. My understanding is that the classical way (i.e. pre-monads) to think of mutable values in functional languages was to model them as a time-sequence of intermediate values, where a function to update a state returns the next value in that sequence. Expressed this way, a practical problem arises that the intermediate values don't (necessarily) go away, creating a potential for exploding storage requirements. (If, as with document versioning, you want to keep the intermediate values, then you need to figure a way to live with this; value sharing in pure functional languages is a big help here.) But often one is only interested in the latest or current value in the time-sequence. Monads provide a way of capturing this: the state is implicitly threaded through a sequence of computations (e.g. the expressions in a do-list), with old versions thrown away as new ones are created (unless the state is explicitly saved, which is not always possible). #g -- At 00:50 04/12/04 -0500, Dimitry Golubovsky wrote: Hi, I am probably not the first to think about this, yet I was unable to find any signs of activities in this direction, so maybe I will be able to know something from this list. First of all, reading multiple messages about global and mutable variables desired in Haskell, I was thinking: isn't the root of the problem in the fact that there are no variables in Haskell at all? Indeed (and my experience of digging in Hugs sources confirms) Haskell program (function) is just a description of some memory structure which being completed by the bindings of its arguments, is further transformed by the evaluator into some other data structure, etc. Now imagine a data storage with structure similar to one of a Haskell program. I. e. a storage having metadata-objects like data constructor functions, data types which are parents to data constructors (like in data X = Foo Int | Bar Float), classes, instances, modules, etc. Also data objects themselves, i. e. precompiled and serialized functions along with their type information. Data objects do not differ from functions i. e. they are stored the same way. Now quoting Graham Klyne Subject was: [HAskell-Cafe] Mutable and persistent values (was: Top Level TWI's again) posted 2004-11-23 05:11:25 PST: (I tried to post reply via Google Groups, but it did not make it back to the list): It is my view that use a functional language effectively, it is necessary to think differently about its structure than one would for a conventional imperative program. Global values become parameters and return values; mutable values become input values and new (separate) return values. If you're used to writing imperative programs that do not use global state, but rather use parameters to pass values, the difference isn't always quite as great as might be imagined. For complex values, this sounds horribly inefficient, but because values are pure (not mutable), very high levels of sharing can (sometimes, with good design!) be extensively shared. Thus, a return value may well consist mostly of a copy of the input value, with differences, rather than actually being a complete new copy. (Chris Okasaki's book shows well how to design to obtain these benefits.) Also, because Haskell is lazy, complex structures passed between functions don't necessarily ever exist in their entirety. Sometimes, I think of a data structure as describing a computational traversal through some data, rathert than something that actually exists. (This leads to very elegant expression of things like Prolog search-and-backtrack algorithms.) So, if there is a data object (say, a list) stored with version number N, and another value is cons'ed to the list, then version N+1 will be stored as an application of cons to the value added, and the version N. Thus, via versioning, some kind of mutability may be achieved (and of course these check-in and check-out must belong to IO monad). These stored functions must be visible to the compiler, and when compiling some function f which calls g (compiled earlier and stored as version N), the code of this version of f (say, M) is built to call version N of g further on. So, all the type checks are done during compilation, and are not necessary during runtime, and yet the functions are compiled and stored separately (trying to address the issue with too large monolithic programs). Newer version of f (say M+1) may be compiled against newer (at that time) version of g (N+1). So different versions of the same function may demonstrate different behaviors
RE: [Haskell-cafe] Classes in type declarations in Hugs
At 10:15 06/12/04 +, Simon Peyton-Jones wrote: | This is where I find ghc's newtype deriving to be incredibly useful. | | newtype CPError a = CPError (Either Error a) | deriving(Monad,MonadError) | | now CPError is a monad and an instance of MonadError and you are free to | override or inherit more interesting instances at will without | conflicting with the basic types for Either :) Aha! I've always wondered whether anyone uses this feature, which I implemented at John Hughes's suggestion. I'd be interested to know if you are alone, or whether others do so too. Not a user, but sounds maybe interesting. Can you point to documentation? #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Non-technical Haskell question
I find myself agreeing with the implied likely response to all of the points you raise below. I'd say that any attempt to proselytize Haskell (or any new technology) needs to start from a clear view of one kind of application that it is particularly good for. Then, focus on building a bridgehead for that narrow application area. For example, I've been using Haskell to experiment with reasoning tasks on Semantic Web data -- it's an application for which Haskell seems to be eminently well-suited, for the following reasons, among others: * functional expression (as opposed to imperative) means that the reasoning programs are more closely related to the reasoning tasks being performed. * its type system ensures that necessary formalities of mapping concepts to representations are fully expressed. * lazy evaluation makes search-and-backtrack patterns very easy to program. * Higher order functions facilitate separation of concerns. In short, for this kind of application, I find that I spend most of my time thinking about the problem space, relatively little time programming supporting scaffolding, and very little time debugging (once I've got the types to match up). This is my story. I don't know if there's anything here you can use. #g -- At 10:45 03/12/04 -0500, Jason Bailey wrote: Here are some questions that I would expect to get from business. Q:What have I heard about this technology? A: Probably nothing. Haskell isn't very well known in the programming community (out of 6 co-workers asked, one had used Haskell in a single college class), let alone the business community. Business has become very wary about accepting technologies that are obscure. Q:What can I do with this language that I can't do now? A:Well nothing. It can certainly do some things better then the current languages out there, but its just another general purpose language. Q:Will it require training? A: Oh yes, we're talking about a different way of looking at programs. On the surface level it should be fairly easy to pick up but it will take some time before the engineers are able to produce decent work. Oh and there are no training classes we can send people to. They will have to learn on their own. Q:Whats the market like for Haskell programmers? A: Well there isn't one. Which means that if business was going to advertise for someone with haskell programming knowledge they are going to end some spending a premium on them. Q:Why should we support yet another programming language? A: Because this is a better language. (Wouldn't work as an answer but I would give it a try. ) And this is just the business side. I kinda shudder at the thought of telling a room full of engineers that they need to abandon their current status as object level gurus and learn some language that the majority of them have never heard of. :) I think the most important aspect of getting haskell acceptance is mind share. Both from a programming perspective and a business perspective. People need to have heard of haskell and be familiar with the concepts behind it before they will be willing to give it a try. Also the larger the corporation the less likely this is going to happen. But with mind share I can see smaller corps and smaller IT departments moving over to it. Jason ___ 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
Why does RandomIO need the unsafePerformIO hack? (was: [Haskell-cafe] Top-level state debate on the wiki)
Looking at the wiki summary [1] (very good, BTW), I have a question (I've skipped much of the debate, so please just give a message pointer if I missed something). Why does RandomIO need to use the unsafePerformIO hack if its already in the IO monad? BTW, if the goal is to have a random number generator as a pure (non-IO) function, I *do* think there's a reasonable semantic objection here. I'd also like to request that some reference links are added for some of the proposed solutions: 2b - reference to stToIO 3 - reference to Data.Dynamic, and how a dictionary of types can be used to provide global variables. #g -- [1] http://haskell.org/hawiki/GlobalMutableState Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Non-technical Haskell question
At 10:54 03/12/04 +, Keean Schupke wrote: Jason Bailey wrote: I mean I think its a really cool idea, and I'm having fun learning it. But I would be hard pressed to come up with a justification to introduce this into our business environment. How about increased productivity, and more stuff right first time... I agree, but... to carry weight in this snake-oiled world, such a claim needs to be backed by clear evidence. #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] HaXml
Dominic, I use (an extended version of) the CFilter framework to perform namespace, xml:lang and xml:base processing in my revised version of HaXml. Maybe my code [1] might provide some clues for you? Look for function 'applyNamespaces'. The function 'buildNamespaces' illustrates my extension to the CFilter framework, which allows an XML document to be transformed into a new document type containing additional information about the XML elements. 'processNamespaces' actually applies the transformations, using function 'docReplaceContent' which is defined in [2]. Maybe this module has the clues you're after? #g -- [1] http://www.ninebynine.org/Software/HaskellUtils/HaXml-1.12/src/Text/XML/HaXml/Namespace.hs [2] http://www.ninebynine.org/Software/HaskellUtils/HaXml-1.12/src/Text/XML/HaXml/Traverse.hs At 15:33 27/11/04 +, Dominic Steinitz wrote: 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 Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] Non-blocking for reactive programs (was: Objects in Haskell)
At 00:39 29/11/04 +0100, Benjamin Franksen wrote: One problem remains: to preserve reactivity, the programmer must make sure that methods don't execute IO actions that may block indefinitely. Unfortunately there is no way in Haskell to enforce this, because (indefinitely) blocking IO actions have the same type as non-blocking ones. Too late to change that, I guess... I was somewhat intrigued by this comment. Maybe I'm missing the point or simply too detached from the thrust of this thread to make any sense here, but wondered if anything really needs to be changed to be able to express this idea of non-blocking IO. Suppose we define a new type, say NBIO, which, like IO, allows any interaction with the external world, but with the proviso that it never blocks (I shalln't attempt to try and define exactly what this means, but hope that the intent is clear). A key function associated with this type would have type: forall a. NBIO a - IO a Thus any non-blocking I/O activity can be implemented in NBIO, and its IO-equivalent is always available. But not the converse, of course. ... I think I now see the problem: while functions can be implemented in NBIO, and thereby convey an intended guarantee to the caller, there's no way I can see for the Haskell type system to stop a programmer to write a function of this type that actually uses (but does not return a value from) an IO value. Without this, how can facilities like Debug.Trace be provided? But then again, if no value from an IO is ever actually used or referenced outside the IO code, doesn't lazy evaluation mean that there's never any need to evaluate the value within IO? Now getting hopelessly out of my depth, but interested in any comments you may have... #g -- Btw, here is one of my all-time favourite quotes: The view of indefinite blocking as a transparent operational property dates back to the era of batch-oriented computing, when interactivity was a term yet unheard of, and buffering operating systems had just become widely employed to relieve the programmer from the intricacies of synchronization with card-readers and line-printers. Procedure-oriented languages have followed this course ever since, by maintaining the abstraction that a program environment is essentially just a subroutine that can be expected to return a result whenever the program so demands. Selective method filtering is the object-oriented continuation of this tradition, now interpreted as ``programmers are more interested in hiding the intricacies of method-call synchronization, than preserving the intuitive responsiveness of the object model''. Some tasks, like the standard bounded buffer, are arguably easier to implement using selective disabling and queuing of method invocations. But this help is deceptive. For many clients that are themselves servers, the risk of becoming blocked on a request may be just as bad as being forced into using polling for synchronization, especially in a distributed setting that must take partial failures into account. Moreover, what to the naive object implementor might look like a protocol for imposing an order on method invocations, is really a mechanism for reordering the invocation-sequences that have actually occurred. In other words, servers for complicated interaction protocols become disproportionately easy to write using selective filtering, at the price of making the clients extremely sensitive to temporal restrictions that may be hard to express, and virtually impossible to enforce. (see http://www.cs.chalmers.se/~nordland/ohaskell/rationale.html) Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] A puzzle and an annoying feature
At 19:14 25/11/04 +0100, Lennart Augustsson wrote: Graham Klyne wrote: I have a concern with this, if I understand the issue correctly. Suppose I have a source module that compiles and runs correctly. Now suppose I add a restricted (selective) import statement to the file, explicitly introducing a name that I know does not clash with anything in my module. I expect the module to continue to compile and run correctly. If I understand Lennart's proposal correctly, adding such an import could cause the compilation to fail, by adding new instance options that then needs to be disambiguated. Not in my particular case. The class is local to the module. Any instance declaration would have to be in that module. OK, I missed that. But, it seems to me, that adding export of the class concerned to the module heading could raise a similar scenario to that mentioned. It's less clear-cut, but it seems surprising to me that the choice of whether or not to export something from a module should (potentially) change its meaning or validity. #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] A puzzle and an annoying feature
I have a concern with this, if I understand the issue correctly. Suppose I have a source module that compiles and runs correctly. Now suppose I add a restricted (selective) import statement to the file, explicitly introducing a name that I know does not clash with anything in my module. I expect the module to continue to compile and run correctly. If I understand Lennart's proposal correctly, adding such an import could cause the compilation to fail, by adding new instance options that then needs to be disambiguated. Under the present regime, this is not a problem, because information to disambiguate the instance selection needs to added even if there's only one visible instance, so adding the restricted import cannot introduce this failure. Similar concerns might apply if new instances are added to a module that is already a restricted import. I suspect that the proper fix to this is that a selective import should also name the instances that are imported. Then disambiguation of instances can reasonably be based on just the visible imports. The automatic import of instances, even when the restricted form of import is used, has often seemed a little odd to me. #g -- At 14:36 25/11/04 +, Keean Schupke wrote: I have already asked Simon PJ if this can be implemented in GHC... So if more people ask for it, it might get done! Keean Lennart Augustsson wrote: Here is a small puzzle. -- The following generates a type error: f :: Char - Char f c = let x = g c in h x -- But this definition does not: f :: Char - Char f c = let x :: Bool x = g c in h x Furthermore, replacing Bool by any other type in the latter definition will always give a type error. How is this possible? Scroll down for the answer. Here is the module: module Puzzle(f) where f :: Char - Char f c = let x = g c in h x class C a where g :: Char - a h :: a - Char instance C Bool where g c = c == 'T' h b = if b then 'T' else 'F' The error message from ghc is Puzzle.hs:5:12: Ambiguous type variable `a' in the top-level constraint: `C a' arising from use of `g' at Puzzle.hs:5:12 I know the technical reason why this is happening. But it's hard for me to motivate why this is reasonable. The type variable `a' is not ambiguous at all, the only type it can possibly have is Bool; any other type is an error. Furthermore, there can never be any other instance of the class C added to any program using the module Puzzle since the class C is not exported. So in what sense is this really ambiguous? I think it would be quite reasonable to allow the Puzzle module to compile, resolving `a' to be Bool. I.e., if there is only one instance that can satisfy a constraint and there is no possibility of adding instances outside the compiled module, I think resolving the overloading makes sense. -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ 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] Better Exception Handling
I, too, had a gripe about this, and was pointed to an excellent paper that explains all: A Semantics for Imprecise Exceptions (1999) Simon Peyton Jones, Alastair Reid, Tony Hoare, Simon Marlow, Fergus Henderson SIGPLAN Conference on Programming Language Design and Implementation http://citeseer.ist.psu.edu/peytonjones99semantics.html #g -- At 16:12 23/11/04 +0100, Johannes Waldmann wrote: The other annoying thing is forcing it to run in the IO monad. necessarily so, since Haskell has non-strict semantics so it's not so clear when an exception is actually raised (you might have left the block that textually contained the offending expression , and the exception handler, a long time ago) -- -- Johannes Waldmann, Tel/Fax: (0341) 3076 6479 / 6480 -- -- http://www.imn.htwk-leipzig.de/~waldmann/ - ___ 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-cafe] Problem with overlapping class instances
At 21:40 22/11/04 +0100, Ralf Laemmel wrote: Instance selection and thereby overlapping resolution is *independent* of constraints. It is defined to be purely syntactical in terms of instance heads. See the HList paper for some weird examples. That explains it. Thanks! #g -- Ralf Graham Klyne wrote: The reported overlapping instance is [Char], which I take to be derived from the type constructor [] applied to type Char, this yielding a form that matches (cw c). But the instance ConceptExpr (cw c) is declared to be dependent on the context ConceptWrapper cw c, which has *not* been declared for the type constructor []. GHCi with -fglasgow-exts is no more informative. What am I missing here? Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Top Level TWI's again was Re: [Haskell] Re: Parameterized Show
I think this is a useful debate, because it touches on how Haskell meets real-world programming needs, so I shall continue in that spirit... At 22:22 22/11/04 +, Keean Schupke wrote: Obviously without knowing the details I am speculating, but would it not be possible to do a first pass of the XML and build a list of files to read (a pure function) this returns its result to the IO monad where the files are read and concatenated together, and passed to a second (pure functional) processing function. If written well this can take advantage of lazy execution, so both functions end up running concurrently. In an ideal world, it is certainly possible to separate the pure and non-pure aspects of the code, and do something like you suggest. But my position was that I was working with an existing codebase (HaXml) which had not been structured with this requirement in mind, and I absolutely did not want to start from scratch (as it was, I was forced into some substantial refactoring). This was one case where, in order to get any result at all with the time/effort available to me, I needed to hide the I/OI within an otherwise pure function. Yes, there are better ways but, being a Bear of Very Little Brain, I have to work with the tools, intellectual and otherwise, that are at my disposal. Most software is not built in the optimum fashion, or even anything close to it. I would suggest that one of the challenges for functional programming is to maker it easy to do the right thing. I came to functional programming with quite a strong bias to make it work for me, inspired many years ago by John Backus' famous paper, and a presentation by David Turner about KRC, and a few other things. Many programmers I've spoken to who have tried functional programing have given up on it because it's too hard. It seems to me that as unsafePerformIO is not in the standard and only implemented on some compilers/interpreters, that you limit the portability of code by using it, and that it is best avoided. Also as any safe use of unsafePerformIO can be refactored to not use it I could certainly live without it. Well, I am concerned about portability. I insist on using Hugs when many people use just GHC, and one of the reasons is that I don't want to get locked into one compiler's extensions. But sometimes it is necessary to use extensions: there are many features of Haskell-98++ that are almost essential (IMO) to practical software development. Including, I think, unsafePerformIO (on rare occasions). My touchstone is that I'll use language extensions when I have to, provided they are supported by both Hugs and GHC. What's my point in all this? I supposed it might be summed up as: The best is the enemy of the good. #g -- Graham Klyne wrote: [Switching to Haskell-cafe] I have used it once, with reservations, but at the time I didn't have the time/energy to find a better solution. (The occasion of its use was accessing external entities within an XML parser; by making the assumption that the external entities do not change within any context in which results from a program are compared, I was able to satisfy the proof obligation of not causing or being sensitive to side effects.) The reason this was important to me is that I wanted to be able to use the parser from code that was not visibly in the IO monad. For me, treating Web data transformations as pure functions is one of the attractions of using Haskell. (Since doing that, I had an idea that I might be able to parameterize the entity processing code on some Monad, and use either an Identity monad or IO depending on the actual requirements. This way, I could keep pure XML processing out of the IO monad, but use IO when IO was needed.) In short: I think it's usually possible to avoid using unsafePerformIO, but I'd be reluctant to cede it altogether, if only for sometimes quick-and-dirty pragmatic reasons. #g Graham Klyne For email: http://www.ninebynine.org/#Contact Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell-cafe message-length restriction
To the list Haskell-cafe admin... May I suggest that the maximum message length for postings to the haskell-cafe list without moderation be raised from its current 5K limit? It seems to me that a value of (say) 20K would reduce the moderator's workload without obviously allowing too many undesirables ... (though I allow the moderator surely knows more about what is thrown at the list that most of us don't see.) Just a thought. #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Mutable and persistent values (was: Top Level TWI's again)
of years. #g -- [1] Simon Peyton-Jones and John Launchbury, State in Haskell, linked from: http://research.microsoft.com/Users/simonpj/Papers/papers.html#monads, document at: http://research.microsoft.com/Users/simonpj/Papers/state-lasc.ps.gz, also at: http://www.cse.ogi.edu/~jl/Papers/stateThreads.ps. Introduces monads as a general technique for handling state, and then introduces a concept of the world as a state manipulated by IO. I found this to be one of the more illuminating introductions to Monads (which are central to Haskell I/O). [2] Chris Okasaki, Purely Functional Data Structures, Cambridge University Press, 1998 [3] Philip Wadler, The essence of functional programming, linked from http://homepages.inf.ed.ac.uk/wadler/topics/monads.html, paper at http://homepages.inf.ed.ac.uk/wadler/papers/essence/essence.ps . [4] http://www.ninebynine.org/Software/Learning-Haskell-Notes.html [5] http://ninebynine.org/Links.html#Programming-Haskell At 15:34 22/11/04 -0800, John Velman wrote: On Mon, Nov 22, 2004 at 07:27:44PM +0100, Lennart Augustsson wrote: [snip] I admit there are proper uses of global variables, but they are very rare. You have not convinced me you have one. -- Lennart It's with some trepidation I bring a problem as a total newbie, but I've been obsessed with this and hung up on it ever since I decided a couple of weeks ago to learn Haskell by using it. Some brief background: A while back I decided I wanted a simple 'concept mapping' program that would work the way I work instead of the way someone else works. I envisioned a GUI with a canvas and an entry box (TK/tcl). I type a concept name into the entry box, and it shows up on the canvas (initially in a slightly randomized position), in a box, with a unique sequenced identifier. The identifier is also used as a canvas tag for the item. Similar input for relations between concepts. I think that's enough description for now. Initially, I started programming this with PerlTK, but that effort was interrupted for a few weeks. When I got back to it, I decided to do it in Python instead. But that effort also got interrupted for a few weeks. Before I got back to it, I ran across some material on Haskell I've had in my files for a few years, and decided that I'd use this as a vehicle to actually learn Haskell. (This all sounds a bit unfocused, and it is: I'm retired, sometimes describe myself as an ex mathematician or an ex-PhD having spent years in the aerospace industry instead of academia. Anyway, I have both the luxury and lack of focus of no deadlines, no pressure to publish. I hope to use Haskell to further my main hobby of knowledge representation.) In perl, my labels/tags were very easy: In the initialization code: my @taglist = (); my $nextag = a; and in the callback for the entry box: push(@taglist,$nextag); $nextag++; (With the starting tag of a this results in a,z,aa,ab,...) Also, ultimately, I want to be able to save my work and restart the next day (say) picking up the tags where I left off. I'm darned if I can see how to do this in a callback without a global variables (and references from other callbacks, by the way). In looking for a method, I've discovered that Haskell is a lot richer than I thought (or learned when I tinkered with it back in the late '90s ). I've found out about (but don't know how to use properly) implicit parameters, linear implicit parameters, unsafePerformIO, safe and sound implementation of polymorphic heap with references and updates (Oleg Kiselyov, (http://www.haskell.org/pipermail/haskell/2003-June/011939.html), implicit configurations, phantom types, ... I've also found warnings against many of these. I'm inclined to try the unsafePerformIO route as being the simplest, and most commonly used, even though perhaps the least haskell-ish. I like implicit configurations, but couldn't begin to say I understand them yet, and it's a bit heavy for a novice. In a nutshell: I want to use the old value of a tag to compute the new value, in a callback, I want to access the tag from other callbacks, and I want to the value to a mutable list from within the callback. I'd certainly be interested in doing without global variables, and would appreciate any advice. (By the way, I'm using Linux, and so far it looks like HTk is my choice for the GUI interface.) Best, John Velman ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problem with overlapping class instances
At 22:05 22/11/04 +, Keean Schupke wrote: The trick here is to use a type to represent the constraint rather than a class, if possible. Keean Hmmm, I'm not sure that I understand what you mean. Considering my example (repeated below), is it that 'AtomicConcept' should be an algebraic datatype rather than just a type synonym? Or is there more? Or... I just found John Hughes 1999 paper on Restricted Data Types in Haskell [1], which talks about representing class constraints by the type of its associated dictionary. Is this is what you mean? #g -- [1] http://www.cs.chalmers.se/~rjmh/Papers/restricted-datatypes.ps spike-overlap-ConceptExpr.lhs - type AtomicConcepts a = [(AtomicConcept,[a])] type AtomicRoles a = [(AtomicRole ,[(a,a)])] type TInterpretation a = ([a],AtomicConcepts a,AtomicRoles a) class (Eq c, Show c) = ConceptExpr c where iConcept :: Ord a = TInterpretation a - c - [a] ... type AtomicConcept = String -- named atomic concept Declare AtomicConcept and AtomicRole as instances of ConceptExpr and RoleExpr (AtomicRole is used by AL, and including AtomicConcept here for completeness). instance ConceptExpr AtomicConcept where iConcept = undefined ... To allow a common expression to support multiple description logics, we first define a wrapper class for DLConcept and DLRole: class ConceptExpr c = ConceptWrapper cw c | cw - c where wrapConcept :: c - cw c - cw c getConcept :: cw c - c Using this, a ConceptWrapper can be defined to be an instance of ConceptExpr: This is line 30: instance (ConceptWrapper cw c, ConceptExpr c) = ConceptExpr (cw c) where iConcept = iConcept . getConcept Error message: Reading file D:\Cvs\DEV\HaskellDL\spike-overlap-conceptexpr.lhs: ERROR D:\Cvs\DEV\HaskellDL\spike-overlap-conceptexpr.lhs:30 - Overlapping inst ances for class ConceptExpr *** This instance : ConceptExpr (a b) *** Overlaps with : ConceptExpr AtomicConcept *** Common instance : ConceptExpr [Char] Ralf Laemmel wrote: Instance selection and thereby overlapping resolution is *independent* of constraints. It is defined to be purely syntactical in terms of instance heads. See the HList paper for some weird examples. Ralf Graham Klyne wrote: The reported overlapping instance is [Char], which I take to be derived from the type constructor [] applied to type Char, this yielding a form that matches (cw c). But the instance ConceptExpr (cw c) is declared to be dependent on the context ConceptWrapper cw c, which has *not* been declared for the type constructor []. GHCi with -fglasgow-exts is no more informative. What am I missing here? ___ 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
[Haskell-cafe] Re: Top Level TWI's again was Re: [Haskell] Re: Parameterized Show
At 10:02 23/11/04 +, you wrote: Off topic, but interesting, Sure... that's why its in 'cafe, right? Someone else keeps quoting this at me... I prefer Knuth - paraphrased as I cant remember the quote - The best software projects are the ones where the source code has been lost about half way through the development and started from scratch. The point is programmers start by exploring a problem space without understanding it. Poor programmers just accept the first solution they put down. Good programmers re-implement. Great programmers have a sixth sense of when things are about to get ugly, and start again (and the better you are the less you actually have to implement before you realise things can be refactored for the better)... Graham Klyne wrote: What's my point in all this? I supposed it might be summed up as: The best is the enemy of the good. Hmmm... I take your point, and I think my attempted pithy summary missed its intended target. What I was trying to convey was a sense that a great language has to let merely average (or worse) programmers do a halfway decent job. There aren't enough great programmers to go round. And even great programmers sometimes have to work with someone else's codebase (which even if written by a great programmer may have had diffent goals in mind). (FWIW, I think Python is a language that scores pretty highly on this count.) #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problem with overlapping class instances
At 16:16 23/11/04 +, Keean Schupke wrote: The problem is that (cw c) overlaps with String. It will still ovarlap if you use data decl. it is the CW that needs to be a datatype. See Below: Thanks. I've massaged that into something that compiles (copy below). I think I see why this works, but I still can't say that I find the revised structure entirely intuitive. I think the key feature is that wrapped instances of ConceptExpr are distinguished from native instances by the type constructor CW. That is, each instance type is distinguished by different known type constructor -- in this case, [] and CW. I need to noodle on the a while to see if the pattern fits my application, but I think I get the general idea. Of all the combinations I thought about making the type constructor part of the class method signatures was not one I'd tried. Also, I think declaring CW as a 'newtype' rather than 'data' captures the intent more directly. #g -- spike-overlap-ConceptExpr-datatyped.lhs --- Some given type and class declarations: type AtomicConcepts a = [(AtomicConcept,[a])] type AtomicRoles a = [(AtomicRole ,[(a,a)])] type TInterpretation a = ([a],AtomicConcepts a,AtomicRoles a) class (Eq c, Show c) = ConceptExpr c where iConcept :: Ord a = TInterpretation a - c - [a] type AtomicConcept = String -- named atomic concept type AtomicRole= String -- named atomic role Declare AtomicConcept as base instance of ConceptExpr. instance ConceptExpr AtomicConcept where iConcept = undefined To allow a common expression to support multiple description logics, define a wrapper type and class for DLConcept and DLRole: newtype CW cw c = CW cw deriving (Eq,Show) class ConceptWrapper cw c | cw - c where wrapConcept :: c - (CW cw c) - (CW cw c) getConcept :: (CW cw c) - c Using this, a ConceptWrapper can be defined to be an instance of ConceptExpr: instance (Eq cw, Show cw, ConceptWrapper cw c,ConceptExpr c) = ConceptExpr (CW cw c) where iConcept i = iConcept i . getConcept Now declare a pair containing a ConceptExpr to be an instance of ConceptWrapper: type Wrap d c = (c,d) instance ConceptWrapper (Wrap d c) c where wrapConcept c (CW (_,d)) = CW (c,d) getConcept(CW (c,_)) = c Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Problem with overlapping class instances
Once again, the Haskell class system is proving rather subtle for me. On this occasion, I'm getting an overlapping class instance error which I think should be fully disambiguated by the supplied class context. The code below (end of message) is a .lhs file that reproduces the problem in Hugs, with external dependencies from my working codebase stripped out. It should be possible to simply load it (or this whole email) to get the same error: [[ Reading file D:\Cvs\DEV\HaskellDL\spike-overlap-conceptexpr.lhs: ERROR D:\Cvs\DEV\HaskellDL\spike-overlap-conceptexpr.lhs:30 - Overlapping inst ances for class ConceptExpr *** This instance : ConceptExpr (a b) *** Overlaps with : ConceptExpr AtomicConcept *** Common instance : ConceptExpr [Char] ]] The line referred to as this instance is: instance (ConceptWrapper cw c, ConceptExpr c) = ConceptExpr (cw c) where The reported overlapping instance is [Char], which I take to be derived from the type constructor [] applied to type Char, this yielding a form that matches (cw c). But the instance ConceptExpr (cw c) is declared to be dependent on the context ConceptWrapper cw c, which has *not* been declared for the type constructor []. GHCi with -fglasgow-exts is no more informative. What am I missing here? #g -- [Source code follows] spike-overlap-ConceptExpr.lhs - type AtomicConcepts a = [(AtomicConcept,[a])] type AtomicRoles a = [(AtomicRole ,[(a,a)])] type TInterpretation a = ([a],AtomicConcepts a,AtomicRoles a) class (Eq c, Show c) = ConceptExpr c where iConcept :: Ord a = TInterpretation a - c - [a] ... type AtomicConcept = String -- named atomic concept Declare AtomicConcept and AtomicRole as instances of ConceptExpr and RoleExpr (AtomicRole is used by AL, and including AtomicConcept here for completeness). instance ConceptExpr AtomicConcept where iConcept = undefined ... To allow a common expression to support multiple description logics, we first define a wrapper class for DLConcept and DLRole: class ConceptExpr c = ConceptWrapper cw c | cw - c where wrapConcept :: c - cw c - cw c getConcept :: cw c - c Using this, a ConceptWrapper can be defined to be an instance of ConceptExpr: This is line 30: instance (ConceptWrapper cw c, ConceptExpr c) = ConceptExpr (cw c) where iConcept = iConcept . getConcept Error message: Reading file D:\Cvs\DEV\HaskellDL\spike-overlap-conceptexpr.lhs: ERROR D:\Cvs\DEV\HaskellDL\spike-overlap-conceptexpr.lhs:30 - Overlapping inst ances for class ConceptExpr *** This instance : ConceptExpr (a b) *** Overlaps with : ConceptExpr AtomicConcept *** Common instance : ConceptExpr [Char] Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Top Level TWI's again was Re: [Haskell] Re: Parameterized Show
[Switching to Haskell-cafe] At 11:26 22/11/04 +, you wrote: I would ask an alternative question - is it possible to live without unsafePerformIO? I have never needed to use it! I have used it once, with reservations, but at the time I didn't have the time/energy to find a better solution. (The occasion of its use was accessing external entities within an XML parser; by making the assumption that the external entities do not change within any context in which results from a program are compared, I was able to satisfy the proof obligation of not causing or being sensitive to side effects.) The reason this was important to me is that I wanted to be able to use the parser from code that was not visibly in the IO monad. For me, treating Web data transformations as pure functions is one of the attractions of using Haskell. (Since doing that, I had an idea that I might be able to parameterize the entity processing code on some Monad, and use either an Identity monad or IO depending on the actual requirements. This way, I could keep pure XML processing out of the IO monad, but use IO when IO was needed.) In short: I think it's usually possible to avoid using unsafePerformIO, but I'd be reluctant to cede it altogether, if only for sometimes quick-and-dirty pragmatic reasons. #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Parameterized Show? was Re: [Haskell] Conceptual overloading of show?
Shae, Thank you for noticing the Python parallel... I'd forgotten about that. I like the principle of parameterizing Show to allow for different encoding environments (indeed, I had wondered as I was writing my earlier message if the two cases were really sufficient). Indeed, in the application area that interests me (Semantic Web) it could be beneficial to have different encoding options corresponding to different serializations of RDF (e.g. RDF/XML and Notation3). But I also wonder if this adds complexity (of ideas, of not implementation) that really doesn't belong in a very widely used generic library facility. #g -- At 17:27 11/11/04 +0100, Shae Matijs Erisson wrote: Graham Klyne [EMAIL PROTECTED] writes: I raise a topic that has occurred to me repeatedly during my time with Haskell. I am prompted to do so by a discussion in another place, where a significant (and, apparently, recurring) concern about the use and abuse of Java's toString() function is being raised. It seems to me that there are (at least) two important uses for a function like 'show', which may sometimes have very different requirements: (1) creation of some human-readable representation of a value, which may or may not contain sufficient information to reconstruct the value, and (2) creation of a textual serialization of a value from which the value can subsequently be recreated. Where this leads is that I think there should be *two* common value-to-string type classes, one of which is reversible (in the sense that the output of show is intended to be consumable by read), and another that is not required to be reversible and provides output for human consumption. E.g., let's call the new class 'Format': This is similar Python's str() (string) vs repr() (representation) functions. Python's repr is designed to work like read . show = id such that eval(repr(x)) == x and repr also makes a string (only ASCII as far as I know). But maybe this doesn't have to be limited to strings? I've wanted deriving WebPublish and at some level that also involves a show as html/xml My WebPublish ideas would be easier with readXML.showXML == id Dominic Steinitz' ASN.1 code might be easier with readASN1/showASN1 I get the feeling there's a higher-level pattern here, but I don't how to capture it with Haskell's Read/Show classes. Some discussion on #haskell turned up: Björn Bringert mentioned the THDeriveXmlRpcType module in his XmlRpc library. So maybe Show can be parameterized on various 'transports' ? Philippa Cowderoy suggested Show signal carrier instead of the present Show signal [implicit String] Maybe deriving (Show Transport) like deriving (Show XmlRpc)? Any thoughts along these lines? -- Shae Matijs Erisson - Programmer - http://www.ScannedInAvian.org/ I will, as we say in rock 'n' roll, run until the wheels come off, because I love what I do. -- David Crosby Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] Re: [Haskell] Re: About Random Integer without IO
At 00:10 12/11/04 +0100, karczma wrote: But it was MUCH more important to repeat the same sequence, e.g., after making fast some nice fractal sketch, I relaunched the program with bigger size/precision, but exploiting the same random sequence. I repeat, such is my philosophy. I agree. I've used similar randomization techniques for software testing, having similar requirements for repeatability. (E.g., finding a seed that generates an error after several million iterations, with a specific iteration number, and then re-running the test to enable tracing at exactly the required iteration number.) #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] One-shot? (was: Global variables and stuff)
At 16:07 11/11/04 +, Keith Wansbrough wrote: Graham Klyne wrote: At 12:27 11/11/04 +, Ben Rudiak-Gould wrote: [..] going to be safe, because it's just not the case that x = once (newIORef ()) y = x has the same intended meaning as x = once (newIORef ()) y = once (newIORef ()) No amount of compiler-specific magic is going to fix this. Ah, yes, I take the point now. Isn't this generally the case for any value in the IO monad? (Brushing a murky area of equivalence; the same IO computation used twice may yield different results, so I'm not clear to what extent it is meaningful to say that any IO value is the same as any other, including itself, in any observable sense.) No. getChar is always the IO operation that reads a character from stdin. You can always substitute one instance of getChar for another; you can even say foo = getChar and substitute foo for every occurrence of getChar. A value of type IO a is a *computation*; its result may change, but the computation itself cannot. So you say (and I do agree). But how can I *observe* that they are the same? #g -- Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO and State
At 10:35 10/11/04 -0800, Iavor S. Diatchki wrote:
Hello,
Concurrency in Haskell (technically GHC) is much like concurrency in other
languages,
in that you fork off threads and do stuff with them, etc. I think you are
perhaps thinking of another kind of concurrency, where different redexes in
a term are evaluted simultaneously?
Indeed, I was. I guess this begs the question of why one wants
concurrency. I can, offhand, see two reasons:
1. performance, especially in a multiprocessor environment. In this case,
simultaneous evaluation of redexes is the goal, without any visible change
in program semantics. (I see this as a possible way of achieving very high
degrees of concurrency in an application, as individual concurrent
activities can be very lightweight.)
2. coordination with multiple external processes, or between distinct
computations. In this case, I think all the concurrent activities would
need to be (explicitly) in an IO monad.
I'm not sufficiently familiar with the specific interfaces used in your
example to comment in detail, but when you say:
In GHC the whole program stops when the main thread exits.
So if the law I was talking about holds, this program should
never terminate, as it will forever loop in 'reader'.
However since there is a concurrent thread running that can modify
the state, if 'reader' is interrupted between the two readSTRefs
we will get different values for 'x' and 'y' and 'reader' will stop.
I tried that in GHC and it stops after a little while, so the law does not
hold.
I think there may be a problem with the interaction between forking
semantics. and (non-)strictness in Haskell. Essentially, (reader r) is a
non-terminating computation. If the main program requires the value of
(reader r) to be fully evaluated, then I think the value of program itself
must be undefined (_|_). But if it never actually needs the value, it
should be whatever the rest of the program does return.
If the state value is to be shared between the two branches of a fork, then
I think it MUST be embedded in IO for the expected language semantics to be
properly honoured. IO, as I understand it, is *the* mechanism provided by
Haskell that allows evaluation of an expression to depend on some activity
that occurs outside that evaluation.
#g
--
Here is an example to illustrate what I was talking about
(the point about stToIO making that one law unsafe)
import Control.Monad.ST
import Data.STRef
import Control.Concurrent
import Control.Monad(when)
reader :: STRef r Int - ST r ()
reader r= do x - readSTRef r
y - readSTRef r
when (x == y) (reader r)
writer :: Int - STRef r Int - ST r ()
writer n r = do writeSTRef r n
writer (n+1) r
main :: IO ()
main= do r - stToIO (newSTRef 0)
forkIO (stToIO (writer 1 r))
stToIO (reader r)
In GHC the whole program stops when the main thread exits.
So if the law I was talking about holds, this program should
never terminate, as it will forever loop in 'reader'.
However since there is a concurrent thread running that can modify
the state, if 'reader' is interrupted between the two readSTRefs
we will get different values for 'x' and 'y' and 'reader' will stop.
I tried that in GHC and it stops after a little while, so the law does not
hold.
What is interesting is that I think the law does hold if
we execute an ST computation using runST, so at least in principle
GHC could perform this optimiziation in such situations.
I think the law holds then, as I think no reference can escape to
concurrent threads,
as if they did their region parameter would become RealWorld, and so the
computation
could not be runSTed.
-Iavor
Graham Klyne wrote:
At 10:38 08/11/04 -0800, Iavor S. Diatchki wrote:
... Now the above law already doesn't hold when all GHC extensions are used,
as when concurrency is present we cannot assume that nobody modified the
state concurrently.
As a result all pointers in GHC probably behave as if they were
volatile, which is not very nice.
Eek! I find this most worrisome. And I'm not sure that I agree.
I thought that part of the reason for having a monad that it was threaded
in a useful way through the path of a *single* computation (expression
evaluation). If concurrent activities can change that, then I sense that
they're breaking something quite fundamental in the way Haskell should work.
e.g. in a sequence like:
v :: SomeMonad
v = do { e1 ; e2 ; e3 }
Then I think that exactly the monad created by e1 is passed to e2, and
the result of e2 passed to e3, without any visible external interference
under any circumstance. Concurrency, as I understand it should apply to
Haskell, would allow different elements of that computation to be
performed in different threads/processes, but the overall result of the
computation should not be changeable. Put another way, the graph
reduction model
[Haskell] Conceptual overloading of show?
I raise a topic that has occurred to me repeatedly during my time with Haskell. I am prompted to do so by a discussion in another place, where a significant (and, apparently, recurring) concern about the use and abuse of Java's toString() function is being raised. It seems to me that there are (at least) two important uses for a function like 'show', which may sometimes have very different requirements: (1) creation of some human-readable representation of a value, which may or may not contain sufficient information to reconstruct the value, and (2) creation of a textual serialization of a value from which the value can subsequently be recreated. I find it's not always entirely clear which of these 'show' is intended to be: its pairing with 'read', and the way that String values are formatted including quotes suggests that it is intended to be a case of (2). Language in the Haskell report also strongly gives this impression. But in other situations, 'show' is commonly used in the sense of (1). For example, in the Haskell report, section 7.1, (print function) the Show class is used to create output that is specifically intended for user consumption (the standard output device (this is normally the user's terminal)). Where this leads is that I think there should be *two* common value-to-string type classes, one of which is reversible (in the sense that the output of show is intended to be consumable by read), and another that is not required to be reversible and provides output for human consumption. E.g., let's call the new class 'Format': class Format a where format :: a - String formatList :: [a] - String instance Format Int where format = show formatList x = showList x [] instance Format Char where format c = [c] formatList = id In many cases, format and show might be the same, built there would be no requirement for an instance for an instance of Format to be an instance of Show, or vice versa. A practical version of format should probably provide for operation via ShowS values, but I don't currently think an equivalent to showsPrec would be necessary. #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] One-shot? (was: Global variables and stuff)
At 11:31 11/11/04 +, Keean Schupke wrote: Wouldn't it be easier to simply define once as a common Haskell library function? Erm, it is a library function (I provided the NamedSem library as an attachment)... Are you suggesting it would be nice to be able to do this without talking to the OS? OK, I didn't sufficiently emphasize *common* library function. Maybe I should have said standard. I'm not suggesting that the calling program should not use the operating system, but that it should be insulated from the details of said OS. Not all OSes have process IDs or named semaphores. This discussion has shown many ways to implement once, and which is best may depend upon the underlying OS. #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] One-shot? (was: Global variables and stuff)
At 12:27 11/11/04 +, Ben Rudiak-Gould wrote: Graham Klyne wrote: Wouldn't it be easier to simply define once as a common Haskell library function? Depends on the type and the expected semantics. As Adrian Hey already pointed out, (once :: IO a - IO a) with the obvious semantics is never going to be safe, because it's just not the case that x = once (newIORef ()) y = x has the same intended meaning as x = once (newIORef ()) y = once (newIORef ()) No amount of compiler-specific magic is going to fix this. Ah, yes, I take the point now. Isn't this generally the case for any value in the IO monad? (Brushing a murky area of equivalence; the same IO computation used twice may yield different results, so I'm not clear to what extent it is meaningful to say that any IO value is the same as any other, including itself, in any observable sense.) #g -- On the other hand, these are perfectly safe: once' :: IO a - IO (IO a) oncePerString :: String - IO a - IO a oncePerType :: Typeable a = IO a - IO a once' seems virtually useless unless you have top-level -, but the other two don't need it. I'm not sure which would be preferable. I lean toward oncePerString as more flexible and predictable, though it requires a certain discipline on the part of its users. In any case there would need to be support for different scopes: perProcess :: String - IO a - IO a perThread :: String - IO a - IO a perMachine :: String - IO a - IO a I suppose you could add perType :: Typeable a = IO a - IO a with the stipulation that types in different processes are distinct (which seems like the only safe assumption). -- Ben Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO and State (was Re: [Haskell] Re: Global Variables and IO initializers)
At 10:38 08/11/04 -0800, Iavor S. Diatchki wrote:
It is not (should not be?) the case that IO = ST RealWord, as IO is not a
state monad as we understand it.
In a state monad, the changes to the state are all in the program, i.e.
one can always
point to the part of the program that modified the state.
On the other hand, the state of the RealWorld can change on its own,
without anything in the program affecting it.
I guess this is similar to volatile state in C.
For example, one might expect the following rule in a state monad:
do x - readSTRef r
y - readSTRef r
f x y
=
do x - readSTRef r
f x x
But this is not true for the IO monad, as for example reading a file twice
does not guarantee
that you will get the same result, even if no part of the program ever
wrote to the file.
Now the above law already doesn't hold when all GHC extensions are used,
as when concurrency is present we cannot assume that nobody modified the
state concurrently.
As a result all pointers in GHC probably behave as if they were
volatile, which is not very nice.
Eek! I find this most worrisome. And I'm not sure that I agree.
I thought that part of the reason for having a monad that it was threaded
in a useful way through the path of a *single* computation (expression
evaluation). If concurrent activities can change that, then I sense that
they're breaking something quite fundamental in the way Haskell should work.
e.g. in a sequence like:
v :: SomeMonad
v = do { e1 ; e2 ; e3 }
Then I think that exactly the monad created by e1 is passed to e2, and the
result of e2 passed to e3, without any visible external interference under
any circumstance. Concurrency, as I understand it should apply to Haskell,
would allow different elements of that computation to be performed in
different threads/processes, but the overall result of the computation
should not be changeable. Put another way, the graph reduction model for
evaluating a Haskell program should not change, just the mechanics actual
processes (or processors) actually perform the reduction steps.
Or am I really overlooking something here?
#g
Graham Klyne
For email:
http://www.ninebynine.org/#Contact
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] One-shot? (was: Global variables and stuff)
I've not been following the Global variables debate too closely, it seeming to have something of a religious wars flavour, but I noticed that an example being proposed was how to achieve a one shot execution. Here's something I did when working on modifications to the HaXML parser: [[ -- Memoization of withSocketsDo to prevent multiple calls. -- (cf. http://tangentsoft.net/wskfaq/articles/lame-list.html) socketsInitialized :: Bool socketsInitialized = unsafePerformIO ( withSocketsDo ( return True ) ) ]] Does it work as I think it does? ARe there any problems I'm overlooking? #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Currying and errors
I just found myself writing a function that looked like this: isSubsumedByWith :: TBox c - c - c - Bool isSubsumedByWith [] c d = isALSubsumedBy c d isSubsumedByWith _ _ _ = error TBox reasoning not supported for AL and immediately noticed that I might also write this: isSubsumedByWith :: TBox c - c - c - Bool isSubsumedByWith [] = isALSubsumedBy isSubsumedByWith _ = error TBox reasoning not supported for AL which led me to thinking about the difference between these two functions (I reason there must be a difference, because the call of 'error' is required to fulfil (terminology?) values of different types). I think it is this: Suppose I evaluate an expression: let s = isSubsumedByWith [foo] in seq s e then I think the first case will return a legitimate function, albeit one that returns error when it is applied, and the second will cause an error to be returned immediately. Am I right? Is this all? #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] FiniteMap-like module for unordered keys?
Is there a module that provides functionality similar to that of Data.FiniteMap for keys that do not have a defined ordering relation? (I looked at Data.HashTable, but I couldn't figure why it needs to be implemented in the IO monad, except to optimize the internal implementation. Also, it's not clear to me how it behaves when a key is inserted that already exists.) #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Literate Haskell and piecewise construction of classes/instances
I'm experimenting with a Literate Haskell style to construct a tutorial about Description Logics [1][2]. I'm developing the material in small sections, and using examples in the document to test the code as I go along . I therefore find that I want to introduce the components of class and instance declarations in pieces, rather than having the entire declaration in a single place. Am I right in thinking this is not possible? For example, I find myself resorting to tricks like this: [[ So far, a single Description Logic (AL) has been considered. My next step is to generalize the function interface to a collection of type classes that can handle arbitrary description logics. The basic ideas of concepts, roles and interpretations are common to all description logics, so these are used as defined above. It is the concept descriptions, role descriptions and associated operations that need to be further abstracted: - class ConceptExpr c where - iConcept :: Ord a = TInterpretation a - c - Set a (The full and final definition of ConceptExpr is given later.) : ]] and later... [[ The class interface for concept expressions is therefore extended thus: class ConceptExpr c where iConcept :: Ord a = TInterpretation a - c - Set a isSatisfiableWith :: TBox c - c - Bool isSatisfiableWith t c = not (isSubsumedByWith t c emptyClass) isSubsumedByWith :: TBox c - c - c - Bool isSubsumedByWith t c d = not $ isSatisfiableWith t (intersectClass c (complementClass d)) emptyClass:: c complementClass :: c - c intersectClass:: c - c - c ]] What this suggests to me is that for Literate Haskell it is desirable to have multiple appearances of a class/instance declaration, constrained so that one version contains all of the definitions contained in any other appearance, and no two appearances contain differing definitions for any component (using a fairly strict syntactic comparison to determine difference here). Does this strike any chords with anyone? #g -- [1] http://dl.kr.org/ (Description Logics web page) [2] http://www.ninebynine.org/Software/HaskellDL/DLExploration.lhs (My tutorial, work-in-progress - implements structural subsumption for a simple Description Logic.) Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] HaXML incorrect interpretation of XML spec!
Looking at the before-and-after versions of HaXml code that I have modified [1] (with the primary goal of adding namespace support, but also numerous other changes), it seems that the parser always allowed PIs to appear before and after the DTD, but did not store them in the resulting data structure. (That is still the situation with my code.) Here's the original code for the prolog parser that I have: [[ prolog :: XParser Prolog prolog = do x - maybe xmldecl many misc dtd - maybe doctypedecl many misc return (Prolog x dtd) ]] It's clear from this that the PIs (and comments) are parsed and discarded, so your change to capture these in the prolog makes sense. #g -- [1] http://www.ninebynine.org/Software/HaskellUtils/HaXml-1.12/ (My modified version.) At 00:44 28/10/04 -0400, S. Alexander Jacobson wrote: I modified the Prolog type to be data Prolog = Prolog (Maybe XMLDecl) [Misc] (Maybe DocTypeDecl) [Misc] and then modified the Prolog parser (which actually was correct) to actually use the misc values in constucting the Prolog. I replace the prolog function in pretty.hs with prolog (Prolog x m1 dtd m2) = maybe xmldecl x $$ vcat (map misc m1) $$ maybe doctypedecl dtd $$ vcat (map misc m2) and did a few more similar things in Haskell2XML and XML2Haskell (about a 5 min operation) and it all seems to work properly. Implementation question: Why is there so much replicated code in HaXML/Html (parse.hs and pretty.hs) Given that this fix was so very easy and given that the parser was already spec consistent, I now have to assume that there was good reason for the Prolog to be spec inconsistent, but I don't know what it is... Thoughts? -Alex- On Wed, 27 Oct 2004, S. Alexander Jacobson wrote: The XML spec defines the prolog(1) as follows: [22]prolog ::= XMLDecl? Misc* (doctypedecl Misc*)? In other words you can have Misc before AND after the doctype declaration! HaXml defines the prolog(2) as: data Prolog = Prolog (Maybe XMLDecl) (Maybe DocTypeDecl) HaXml therefore does not allow PIs before the beginning of the top level element. This is a problem in practice for people who want to use e.g. XML-Stylesheets(3) where if one is using XSL to produce HTML it is necessary to put the stylesheet declaration BEFORE the root element (if the root element is not HTML). e.g. ?xml version=1.0? ?xml:stylesheet type=text/xsl href=style.xsl? foo id=57 category=2/ Is there some way to puta PI before the root element in combinators? -Alex- (1) http://www.w3.org/TR/REC-xml/#sec-prolog-dtd (2) http://www.cs.york.ac.uk/fp/HaXml/HaXml/Text.XML.HaXml.Types.html#Prolog (3) http://www.w3.org/TR/xml-stylesheet/ __ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell __ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com ___ 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] understanding HaXml and escaping
Hmmm... it's not strictly an entry to the mainstream HaXml, but I have unit test code for my modified version of HaXml, which might be of some use: http://www.ninebynine.org/Software/HaskellUtils/HaXml-1.12/test/ http://www.ninebynine.org/Software/HaskellUtils/HaXml-1.12/test/TestXml.hs The test cases include some round-tripping, e.g. using doXmlParseFormat. #g -- At 08:48 28/10/04 -0400, S. Alexander Jacobson wrote: Is there a good entry point into HaXml? I've now spent some time trying to understand it and feel like I've gotten nowhere. The Haddock documentation enumerates what each function does, but I still don't know how to produce a valid XML document? For example, this is obviously the wrong way to go: simp2 = document $ Document (Prolog Nothing [] Nothing []) [] $ Elem root [(attr,AttValue [Left v\al])] [CString False ] Because, it produces the obviously wrong: root attr=val/root I assume/hope that the combinators properly encode/escape attribute values and CDATA, but can't figure out how to generate even the simple XML above. And once I've done so, is there a way to put PIs in via the combinators or do I have to import Types and risk have unescaped stuff in my document? -Alex- On Thu, 28 Oct 2004, Malcolm Wallace wrote: S. Alexander Jacobson [EMAIL PROTECTED] writes: I modified the Prolog type to be data Prolog = Prolog (Maybe XMLDecl) [Misc] (Maybe DocTypeDecl) [Misc] and then modified the Prolog parser Thanks for spotting this bug and providing a fix. I also note that the XML spec allows misc* to follow the document top-level element: document ::= prolog element Misc* and this too is incorrect in HaXml. There may well be other occurrences of the same omission. Given that this fix was so very easy and given that the parser was already spec consistent, I now have to assume that there was good reason for the Prolog to be spec inconsistent, but I don't know what it is... I originally assumed that Misc's were unimportant and could be discarded, like comments are discarded by a compiler. I failed to notice that PI's should be passed through to the application. Implementation question: Why is there so much replicated code in HaXML/Html (parse.hs and pretty.hs) The HTML parser does some correction of mal-formed input, which is not otherwise permitted by the XML spec. Likewise, the HTML pretty-printer makes some wild and unjustified assumptions about the way that humans like to format their documents, whereas the XML pp is more strictly-conforming. Once XHTML becomes common, the HTML parser/pp will be obsolete. Regards, Malcolm __ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com ___ 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
[Haskell-cafe] Python?
At 20:55 25/10/04 +0200, Remi Turk wrote: P.S. Why do so many people (including me) seem to come to Haskell from Python? It can't be just the indentation, can it? ;) I did. (Or: from Java via Python.) I don't think it's the indentation. At least, not *just* that. FWIW, I speculate: 1. Python users have already chosen expressivity over efficiency 2. For all that it's a rapid development language, and being dynamically typed, Python doesn't completely abandon discipline in program construction. #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
