[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-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-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-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-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-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
[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
[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-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-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-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
[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-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
[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
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
[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
Re: [Haskell-cafe] Relational Algebra post
Cool! That goes on my list for further study. (I have a work-in-progress of something similar for description logics.) #g -- At 15:01 22/10/04 -0700, Brian Beckman wrote: Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary=_=_NextPart_001_01C4B882.A1CF3A2A on my blog (http://weblogs.asp.net/brianbechttp://weblogs.asp.net/brianbec) , i've posted a couple of Haskell gadgets. One is a simulator for the relational algebra of database theory. The other is just an expansion of one of Paul Hudak's derivations of State monads. ___ 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
Re: [Haskell-cafe] Haskell's overlooked object system: was OO idioms redux
At 22:17 13/10/04 +0200, Ralf Laemmel wrote: John Goerzen wrote: One of the best features of OO programming is that of inheritance. ... Oleg, Keean and me have lying around a draft that adds to this discussion. We reconstruct OCaml's tutorial in Haskell The short paper version is online and under consideration for FOOL: http://homepages.cwi.nl/~ralf/OOHaskell/ This work takes advantage of the HList library. I'll attach some code related to inheritance. So Haskell is an OOPL. I think that's interesting as a theoretical exercise, but I don't currently see myself using that framework in practice, in the form presented. As you say Simply syntactic sugar would make OOP more convenient in Haskell. It is encouraging to see that the OO structures can be constructed within the Haskell type system. Would it simplify your approach significantly to focus on non-mutable objects? (In recent discussions with a colleague who implements complex systems in Java, he has observed that their systems are easier to understand and maintain when they elect to use non-mutable objects.) #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] OO idioms redux
Haskell type classes don't really behave as one might expect coming from an OO perspective; cf. http://www.ninebynine.org/Software/Learning-Haskell-Notes.html#type-class-misuse That commentary doesn't say anything about interface inheritance. I don't offhand have a good answer for that question. In my own code, I guess I kind-of work around that issue. As for inheritamnce of implementation, I guess that can be done by hand, by building a new type that contains the base type. #g -- At 18:32 12/10/04 +, John Goerzen wrote: OK, recently I posed a question about rethinking some OO idioms, and that spawned some useful discussion. I now have a followup question. One of the best features of OO programming is that of inheritance. It can be used to slightly alter the behavior of objects without requiring modification to existing code or breaking compatibility with existing APIs. As an example, say I have a ConfigParser class. This class can read in configuration files, provides various get/set methods to access them, and can write them back out. Now say I would like to make this a little more powerful. Maybe I want to support the use of environment variables in my config file, so if there's a reference to $FOO in the file, it will be replaced by the contents of $FOO in the environment. In OO, I would make a new EnvConfigParser class. I'd override the read() method. My new read() would probably start by calling the parent's read() method, to get parsing for free. Then it could iterate over the data, doing its environment variable substitution. Now, in Haskell, we obviously have no objects like this. We do have something that provides some of the same benefits -- typeclasses. However, from what I can determine, they don't support algorithm inheritance like objects do in an OOP. Specifically, it seems impossible to have two instances of a single typeclass that work on the same type, while having one share most of the code with the other. I'm wondering if there is a Haskell design pattern that I'm missing that would provid ethe kind of benefits that one gets from inheritance in the OO world. -- John -- John Goerzen Author, Foundations of Python Network Programming http://www.amazon.com/exec/obidos/tg/detail/-/1590593715 ___ 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: [Haskell] is $ a no-op?
[Switched to haskell-cafe] At 13:24 13/10/04 -0400, Jacques Carette wrote: -- It's kind of like an converse map. I have attempted, unsuccessfully, to write flist above in a point-free manner. Is it possible? Of course it is, but why? flist = flip (map . flip ($)) Some functions are simpler point-free, others are simpler with points. I was curious about this one (I like the pointwise version better). Also, the statement It's kind of like a converse map becomes quite clear from the point-free way to write it, while still not so obvious in the pointwise version. The point-free form can be deduced thus, I think: flist fs a = map ($ a) fs (flip flist) a fs = map ($ a) fs-- swap flist args (flip flist) a = map ($ a) -- redundant arg (flip flist) a = map ((flip ($)) a) -- expand section (flip flist) a = (map . (flip ($))) a -- definition of . (flip flist) = map . (flip ($)) -- redundant arg flist = flip (map . (flip ($))) -- move flip to RHS #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] Being Compatible
At 10:47 08/10/04 +0100, Malcolm Wallace wrote: John Goerzen [EMAIL PROTECTED] writes: My initial thought was to use the cpp-style ifdefs I've seen elsewhere to mask those unsupported features on those particular systems. But Hugs at least doesn't support that, and I've found it extremely difficult to find a list of predefined macros for the other systems anyway. I thought Hugs does support preprocessing, with the -F option? Yes, but it requires an external preprocessor program to be available. (Enter cpphs.) #g -- The usual cpp macros are: __HASKELL98__ # supports at least the '98 standard __GLASGOW_HASKELL__ = 504, 602, etc __HUGS__ __NHC__ __HBC__ You might also occasionally see __HADDOCK__ # for documentation-only preprocessing __HAT__ # for the Hat tracer Regards, Malcolm ___ 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] Space leaks (was: How do I get a long iteration to run in constant space)
I've been starting to take note of discussion about space leaks in Haskell. So far, it's not a topic that's bothered me, other than obvious programming errors, and I've never found the need to force strict evaluation of my Haskell programs. I find myself wondering why this is. Your comment about arithmetic expressions is telling: the kind of program I have been writing (parsers, symbolic processing, etc.) performs almost no arithmetic. (So far, I've used lists instead of arrays, so a usual source of arithmetic functions is missing.) I've also worked with datasets that fit in memory, so failure to stream data hasn't been a problem. I suspect that's the more pernicious case for space leaks, since the causes aren't always so obvious. Are there any guidelines or warning signs to look out for that may be indicative of potential space-leak problems? So far, I can think of: - arithmetic results - multiple uses of a large data value #g -- At 00:44 05/10/04 -0700, [EMAIL PROTECTED] wrote: I added two lines to your code: iterate2 f x n | seq f $ seq x $ seq n $ False = undefined iterate2 f x n = --- as before rk4Next f h (x, y) | seq f $ seq h $ seq x $ seq y $ False = undefined rk4Next f h (x, y) = -- as before I also increased ten times the number of steps for the last iteration, to make the example more illustrative. putStr (show (rk4 stiff 0 1 (exp (-1)) 100)) The rest of the code is unchanged. The program now runs on GHCi *Foo main Begin (1.0007,-6.503275017254139) (0.9062,-6.497717470015538) (1.0007918,-6.497716616653335) on on hugs Begin (1.0,-6.50327501725414) (0.906,-6.49771747001554) (1.000792,-6.49771661665334) with the default stack size for both interpreters. It seems the code does run in constant space now. The added lines are meant to turn the relevant functions from lazy to strict. When you see something like '(n-1)' and 'y + a1/6', it is a red flag. These are exactly the kinds of expressions that lead to memory exhaustion. Perhaps it is because the size of an unevaluated thunk for (n-1) is so much bigger than the size of the evaluated thunk. It seems that arithmetic expressions are the best candidates for some opportunistic evaluation... ___ 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] Predicate logic (FOL) reasoning in Haskell
I was recently passed this reference, which I thought was worthy of sharing here... I've not yet read it myself in detail, but at a glance it looks very readable. http://staff.science.uva.nl/~bcate/core/rwt.pdf [[ Reasoning with Tableaux Jan van Eijck CWI and ILLC, Amsterdam, Uil-OTS, Utrecht ... The paper contains the full Haskell [5] code of a free variable tableau theorem prover for predicate logic, written in `literate programming' style. ]] #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] Re: Seeking reference(s) relating to FP performance
Thanks... it's interesting to see that functional languages in general, and especially ML derivatives, do show comparable performance to languages like Python, Perl and Java. But what I was really after was an indication of trends. The impression I have is that longer the term trend is to close gap between FPLs and (say) C, and it is for that I'd like some supporting evidence, or indications. #g -- At 19:00 29/09/04 +, John Goerzen wrote: On 2004-09-29, Graham Klyne [EMAIL PROTECTED] wrote: I've taken it as an article of faith that performance of FP language implementations has been improving quite steadily over the past few years. I'd like to assert this, but I can't find any clear evidence to One place to start is the Language Shootout at http://shootout.alioth.debian.org/. While it is a benchmark, and therefore subject to all sorts of standard disclaimers about rigged benchmarks, some interesting conclusions can be seen: 1. OCaml often performs better than g++ 2. OCaml sometimes even beats gcc. 3. ghc doesn't seem to do very well in terms of performance, though it does at least beat out Java in many cases. 4. ghc has some of the most concise programs out there There's not a lot of information there on historical trends, but the fact that a mostly-functional language like OCaml can beat out c++ is fairly impressive. -- John I'm looking for a reference -- informal will be enough -- that can give an perspective of progress in functional language implementation performance. I'm not looking for a single benchmark that shows a case of blindingly-fast functional code, but a pointer to trends of improving performance. It would also serve my purpose to have indications based on languages other than Haskell (e.g. ML and friends). Any ideas, please? #g Graham Klyne For email: http://www.ninebynine.org/#Contact -- John Goerzen Author, Foundations of Python Network Programming http://www.amazon.com/exec/obidos/tg/detail/-/1590593715 ___ 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
Simple example using Parsec (was: [Haskell-cafe] Rethinking OO idioms)
At 09:01 30/09/04 +0100, Bayley, Alistair wrote: Ben suggested using Parsec for reading the config file. Parsec is a fine library, but there is a learning curve, and you might find it quicker to do the parsing yourself, if it's very simple. Your call. Hmmm... Parsec *can* be simple too. Here's one I did earlier: http://www.ninebynine.org/Software/HaskellUtils/RegexParser.hs #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] OCaml list sees abysmal Language Shootout results
At 16:56 30/09/04 +0200, Tomasz Zielonka wrote:
Then how about a solution like this: I took your program but used
my fast fileIterate instead of ,,foldl over getContents''.
I also added {-# OPTIONS -funbox-strict-fields #-}, and played a bit
to get the best optimisations from GHC.
It's about 7 times faster this way, but it's still two times slower than
the solution I sent to shootout.
Devilish plan: Maybe we could have some variants of fileIterate in GHC's
libraries? ;-
Two responses:
1. I agree that providing the right kind of library functions (and material
explaining how to use them) maybe a key to getting efficient code without
losing high-level forms of expression.
2. Your fileIterator certainly looks nicer (to me) than your other
solution, but...
Tagging along with this debate, I found myself wondering if, in order to
get performance comparable to other languages, it is really necessary to
write code like code in other languages. E.g., I thought one of the
lessons of John Hughes' Why functional Programming matters was that one
can achieve greater efficiencies by climbing higher rather than dropping
down to the level of other languages. Your fileIterate looks to me like a
step in the right direction.
But I did wonder if it wouldn't be possible to also abstract out the I/O
element of your 'fileIterate', using instead something like:
streamIterate :: [b] - (a - b - a) - a - IO a
(I was originally thinking of something like:
streamIterate :: (c - (b,c)) - c - (a - b - a) - a - IO a
where the first argument is a function that takes a sequence generator and
returns the next member of the sequence+new generator, and the 2nd arg is
the initial generator.)
For such an approach to be useful, I think it would also be important to
have variations of functions like length, lines, words that can be combined
to make a function like your wc'.
#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] OCaml list sees abysmal Language Shootout results
At 19:39 30/09/04 +0200, Tomasz Zielonka wrote: What I like about GHC is that I can start from simple, high-level, sometimes slow solutions, but if there are efficiency problems, there is a big chance that I can solve them without switching the language. That's a very good point, I think. One to hang on to. But I did wonder if it wouldn't be possible to also abstract out the I/O element of your 'fileIterate', using instead something like: streamIterate :: [b] - (a - b - a) - a - IO a It seems to be a variant of foldl. You can eliminate IO from return type, or is there some reason for it? Doh! (Why didn't I spot that?) All roads lead to Rome, or something like that? There seems to be a recurring tension between how much to specialize and how much to generalize. Maybe it should be something like: streamIterate :: (Monad m) = [b] - (a - b - m a) - a - m a ? Er, but that's similarly a variation of foldM, right? Or maybe my earlier idea was closer: streamIterate :: (Monad m) = (c - m (b,c)) - c - (a - b - m a) - a - m a ? Hmmm... I feel like a (intellectual) bull-in-a-china-shop here. I'm blundering about on the trail of a delicate and elegant idea that I'm sure others could dissect far more clearly. What I'm trying to capture (I think) is that there's some baggage to do with accessing the raw data and emitting the desired result that needs to be carried along (or interleaved) with the required computation on that data. Does this make any sense, or am I descending into farce 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] Seeking reference(s) relating to FP performance
I've taken it as an article of faith that performance of FP language implementations has been improving quite steadily over the past few years. I'd like to assert this, but I can't find any clear evidence to support such an assertion. I note that the about Haskell page makes a similar assertion, but it doesn't offer any hint of supporting evidence: [[ Aren't functional programs very slow? They used to be, but the compilers have now caught up. Haskell programs run fast enough for all but the most performance-demanding applications. ]] -- http://www.haskell.org/aboutHaskell.html I'm looking for a reference -- informal will be enough -- that can give an perspective of progress in functional language implementation performance. I'm not looking for a single benchmark that shows a case of blindingly-fast functional code, but a pointer to trends of improving performance. It would also serve my purpose to have indications based on languages other than Haskell (e.g. ML and friends). Any ideas, please? #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] OCaml list sees abysmal Language Shootout results
At 10:55 28/09/04 +0100, Malcolm Wallace wrote: Keith Wansbrough [EMAIL PROTECTED] writes: I can't believe that a simple wc implementation should be 570 times slower in Haskell than OCaml - could someone investigate and fix the test? With code like this, I'm not surprised! main = do file - getContents putStrLn $ show (length $ lines file) ++ ++ show (length $ words file) ++ ++ show (length file) Space-leak or what? Er, please excuse a dumb question, but I'm struggling to see the problem here. I can see that this requires the original file to be kept for 3-time scanning, so enough memory for the entire file will be required. Is that *the* problem to which you allude? I can't see any other problem here. And why would this put Haskell at a disadvantage? #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] no dynamic binding
I think others have provided the immediate answers to your question, so
I'll skip that.
But, standing back, you seem to have fallen prey to a misunderstanding I
made when learning Haskell, thinking that a class is directly analogous
to a class in OO languages. While there are similarities, the Haskell
notion of a class is much more restrictive, as you have found.
I wrote a few more notes here:
http://www.ninebynine.org/Software/Learning-Haskell-Notes.html#type-class-misuse
#g
--
At 13:48 19/09/04 -0400, Andrew Harris wrote:
Hi -
I have another question. I am still working on a soccer server and
thought it would be neat to create command objects that had a
toString method. Then, I was going to keep a list of these command
objects and at the right time stringify them and send them to the
server. So I created a class with a toString method:
class ServerCommandClass a where
toString :: a - String
And then a few instances:
-- dash command
data DashCommand =
DashCommand { dashpower :: Double }
instance ServerCommandClass DashCommand where
toString c = (dash ++ show (dashpower c) ++ )\n
-- move command
data MoveCommand =
MoveCommand { x :: Double,
y :: Double }
instance ServerCommandClass MoveCommand where
toString c = (move ++ show (x c) ++ ++ show (y c) ++ )\n
The problem is, I am not quite sure how to describe a *list* of
command objects where the list could have both DashCommands and
MoveCommands in it. Ideally the list could contain both, and then for
each item in the list I could call the toString method.
I was reading Simon Thompson's Haskell: The Craft of Functional
Programming and I read that Haskell 98 does not support dynamic
binding, which (it seems) is what I'm trying to do. Does anyone have
a suggestion on an alternative approach?
thanks,
-andrew
___
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
Re: [Haskell-cafe] Writing binary files?
I've not been following this debate, but I think I agree with Ross. In particular, the idea of narrowing the Char type really seems like a bad idea to me (if I understand the intent correctly). Not so long ago, I did a whole load of work on the HaXml parser so that, among other things, it would support UTF-8 and UTF-16 Unicode (as required by the XML spec). To do this depends upon having a Char type that can represent the full repertoire of Unicode characters. Other languages have been forced into this (maybe painful) transition; I don't think Haskell can reasonably go backwards if it is to have any hope of surviving. #g -- At 12:31 15/09/04 +0100, [EMAIL PROTECTED] wrote: On Mon, Sep 13, 2004 at 12:01:58PM +0100, Glynn Clements wrote: My view is that, right now, we have the worst of both worlds, and taking a short step backwards (i.e. narrow the Char type and leave the rest alone) is a lot simpler (and more feasible) than the long journey towards real I18N. This being Haskell, I can't imagine a consensus on a step backwards. In any case, a Char type distinct from bytes and the rest is the most valuable part of the current situation. The rest is just libraries, and the solution to that is to create other libraries. (It's true that the Prelude is harder to work around, but even that can be done, as with the new exception interface.) Indeed more than one approach can proceed concurrently, and that's probably what's going to happen: The Right Thing proceeds in stages: 1. new byte-based libraries 2. conversions sitting on top of these 3. the ultimate I18N API The Quick Fix: alter the existing implementation to use the encoding determined by the current locale at the borders. When the Right Thing is finished, the Quick Fix can be recast as a special case. The Right Thing might take a very long (possibly infinite) time, because this is the sort of thing people can argue about endlessly. Still, the first stage would deal with most of the scenarios you raised. It just needs a group of people who care about it to get together and do it. The Quick Fix is the most logical implementation of the current definition of Haskell, and entirely consistent with its general philosophy of presenting the programmer with an idealized (some might say oversimplified) model of computation. From the start, Haskell has supported only character-based I/O, with whatever translations were required to present a uniform view on all platforms. And that's not an entirely bad thing. It won't work all the time, but it will be simple, and good enough for most people. Its existence will not rule out binary I/O or more sophisticated alternatives. Those who need more may be motivated to help finish the Right Thing. ___ 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
Re: [Haskell-cafe] Installing HaXML,(using Hugs and WindowsXP)
At 22:29 23/08/04 +0100, Tom Spencer wrote: Has anyone successfully installed HaXML to be used with winhugs in XP. Using the build.bat included with HaXML it seems that it can only be installed for GHC. Er, yes. (I did the original version of that batch file, which was pretty primitive, and only intended for GHC.) For use with Hugs, I just copy the files into an appropriate directory and make sure Hugs can see that directory: Here's an example of a batch file I use to run Hugs (not WinHugs, but a similar idea should work, I think) with access to the HaXml code: [[ rem Use Hugs version compiled with Unicode support set HUGS=C:\DEV\Hugs98\hugs-20040109.exe set LIBS=D:\Cvs\DEV\HaskellUtils\HaXml-1.12\src %HUGS% -P%LIBS%; %1 PAUSE ]] Ah, looking at that, I recall that HaXml needs Unicode support (or maybe it's just my modified version of HaXml), which isn't standard in the Nov-2003 release of Hugs for Windows. I've built versions of Hugs and RunHugs (but unfortunately not WinHugs) with Unicode support (you also need to use a later prelude.hs file), available via: http://www.ninebynine.org/Software/FatHugs.html (I think that's the right URI; I can't get to the server right now to confirm what's actually there.) #g -- At 22:29 23/08/04 +0100, Tom Spencer wrote: Has anyone successfully installed HaXML to be used with winhugs in XP. Using the build.bat included with HaXML it seems that it can only be installed for GHC. Any suggestions? Thanks Tom Spencer PS. Apologies that this is pretty vague ___ 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
Re: [Haskell-cafe] Combination-lock problem
At 06:01 10/08/04 +0200, Florian Boehl wrote: Hi, I'ld like to generate a list (of lists) that contains all combinations of natural numbers stored in another list. It should work like a combination-lock. E.g.: [2,2] - [[0,0],[0,1],[0,2],[1,0],[1,1],[1,2],[2,0],[2,1],[2,2]] If I know the length 'l' of the 'locklist', I can solve the problem via generators. E.g.: l = 2: [[a,b] | a - [0..locklist!!0], b - [0..locklist!!1]] But if the length is unknown (because it's dynamic) this solutions (of course) fails. Is it possible to solve this problem in haskell in an elegant way? I can think of one using 'sequence', 'map' and a lambda abstraction. [[ Main combo [2,3,4] [[1,1,1],[1,1,2],[1,1,3],[1,1,4],[1,2,1],[1,2,2],[1,2,3],[1,2,4],[1,3,1],[1,3,2] ,[1,3,3],[1,3,4],[2,1,1],[2,1,2],[2,1,3],[2,1,4],[2,2,1],[2,2,2],[2,2,3],[2,2,4] ,[2,3,1],[2,3,2],[2,3,3],[2,3,4]] ]] (It's a trivial to tweak the range to start from 0.) #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] exceptions vs. Either
Two observations: 1. When I recently modified the HaXml XML parser, this is one of the significant changes I made: providing (alterantive) return values based on Either, so that input errors could be handled by the invoking function, without forcing it into the IO monad. I guess that's a vote of agreement. 2. I like to distinguish between expected errors and unexpected errors. Having been burned in the past by using exceptions (not FP), I try to use them only for conditions that are truly unexpected; i.e. _exceptional_. Bad input, IMO, is something that is not unexpected, so I don't really like to handle that via exceptions. #g -- At 13:09 02/08/04 -0700, Evan LaForge wrote: Exceptions are convenient in that you can rely on libraries throwing them instead of prechecking for valid values yourself (for instance, why check that the argument to Char.digitToInt is valid if digitToInt does so already), and you don't have to modify a lot of function signatures. Unfortunately, in the face of lazy evaluation, they can get thrown in unexpected places. Even with Exception.evaluate, or code which is already explicitly sequenced in the IO monad, like t - Exception.evaluate (map Char.digitToInt ['a'..'g']) an exception will only be thrown when you inspect the last element of 't'. (digitToInt confusingly accepts hex digits---shouldn't it be higitToInt then?). So it seems to me that if you are, say, checking input, the options are to handle exceptions from the checking code but expect them to come from the processing code, or decorate all checking code with Rights and Lefts. Problems with the first option are that checking code could also trigger some exceptions, and Prelude functions throw undescriptive errors like user error or low level ones like refuted pattern match and catching them over the entire program means you could stifle a lot of real errors. This implies that you have to make specific exceptions and convert Prelude and library exceptions into yours as low down as possible, which is cluttering but maybe not as cluttering as Either. Problems with the second option are many of the problems that lead to us wanting exceptions in the first place. Using Either seems much simpler and functional-friendly. So then, in what contexts are exceptions appropriate in haskell? ___ 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
Re: [Haskell-cafe] exceptions vs. Either
At 15:28 03/08/04 +0100, MR K P SCHUPKE wrote: f (case xs of (x:_) - x; [] - error whoops) -- direct style Yup, this is how I do it... I never use head! As a general principle, this bothers me. In the longer term (i.e. if and when large-scale production Haskell systems become common), and as a matter of principle, I think it's better to use a prelude (or standard) function when one will do the job, because a widely-used industrial strength compiler might well have special knowledge of these and be able to apply special optimizations (as, e.g., some C/C++ compilers do for standard library functions like memcpy). As for head, I think it's fine that it throws an error because it is specified to be defined for only non-empty lists. (I remain silent on whether the prelude should contain a head-like function that returns a value for empty lists.) #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] Hello and help request
At 14:50 29/07/04 +0200, [EMAIL PROTECTED] wrote: Are type classes different from Java classes? I think so, but I guess this means that one should ask different things to type classes, respect to what is being asked to Java classes. It is this difference that's unclear to me. I made some notes about this, but they're in no sense authoritative: http://www.ninebynine.org/Software/Learning-Haskell-Notes.html#type-class-misuse There was also a little discussion of these notes, starting around: http://www.haskell.org//pipermail/haskell/2003-December/013269.html and subsequently transferring to Haskell-cafe. There was some discussion of classes and their relation to OO style, but that seems to have been off-list. Some of the comments received have been added to my notes. #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] Haskell error messages
At 11:19 26/07/04 -0700, John Meacham wrote: This would be a great idea for something to put on the wiki, a page for each error message produced by the various compilers and a more in depth description of what it means and some ideas on how to track down the problem. A starting point might be the page based on Hugs errors in Simon Thompson's book: http://www.cs.kent.ac.uk/people/staff/sjt/craft2e/errors.html #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] Data.Set subset function?
I don't see a subset function in Data.Set. What is the preferred way to define this? I currently have: a `subset` b = isEmptySet (a `minusSet` b) (Hmmm... does library style prefer `subset`, `subsetOf`, `isSubset`, `isSubsetOf` ?) #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
