Re: Here-docs in Haskell source
On Fri, Sep 22, 2006 at 11:54:42PM -0400, Ian Zimmerman wrote: > > John> indentation. > > Automatic indentation is only one aspect of Emacs modes, and as far as I > am concerned not nearly the most important one. > > Here's a quick test: put the cursor in front of a triple-quoted string, > then hit Control-Alt-F (forward-sexp). It should move just after the > whole string. Does it? Yes, it does. But I don't think we should be limiting our language by what Emacs does. > Any tool which assumes strings are delimited by a single front delimiter > and a single end delimiter, which they are in most reasonable languages, > will have trouble. Then the tools are buggy. What sort of tools are you thinking of here? ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Here-docs in Haskell source
On Fri, Sep 22, 2006 at 09:30:50PM -0400, Ian Zimmerman wrote: > > John> Why not just go the Python way and use """ ? That is, three > John> literal quotes at the beginning and end. After all, Python has > John> lifted quite a few things from Haskell. Time to return the > John> favor. ;-) > > Because it will confuse language-agnostic tools. I don't understand -- what language-agnostic tools would this confuse more than any other syntax? > Do you use Emacs? How does it handle the Python syntax? I am not a > Python programmer, so I can't answer that myself. But I'll hazard a > guess: badly. python-mode actually handles Python syntax a lot better than haskell-mode handles Haskell syntax, particularly regarding indentation. -- John ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Here-docs in Haskell source
On Fri, Sep 22, 2006 at 12:39:34PM -0400, Ian Zimmerman wrote: > If you do this at all, reuse the regular quotes, don't invent yet > another weird and wonderful lexical syntax. Haskell is already bad > enough that way, with \ used for lambda and so on. @" would be okay I > guess. Why not just go the Python way and use """ ? That is, three literal quotes at the beginning and end. After all, Python has lifted quite a few things from Haskell. Time to return the favor. ;-) ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Here-docs in Haskell source
On Fri, Sep 22, 2006 at 01:45:56PM +0100, Alistair Bayley wrote: > Apologies if this has been covered already... I've searched the > haskell-prime list archive and not found anything on this. > > I'd like to submit a request for a fairly trivial feature: multi-line > text literals in source, AKA here-docs. You know, like the > ruby/perl/bash
Re: A modest proposal
On Sat, Apr 15, 2006 at 07:15:28PM +1000, Hoan Ton-That wrote: > Hello Happy Haskellers, > > I would like to humbly suggest that we replace all Int > functions in the prelude with the corresponding generic > ones. These are: drop, take, length, splitAt, replicate and > (!!). > > If at all possible it would be grand if we replaced the ones > in Data.List (such as elemIndex) and other modules too! > > Irradicate Irritating Ints! There I said it! On the downside, this means that I couldn't just say: take 5 mylist I'd instead have to write: take (5::Int) mylist I don't like having to do that. -- John ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Exceptions
On Fri, Apr 07, 2006 at 03:49:40PM +0100, Simon Marlow wrote: > John, have you seen this? > > http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/Extensible > Exceptions Yes, and maybe I'm missing something, but I don't think it quite helps. I followed the link to the example page at: http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/browser/HaskellPrime/Exception.hs Down towards the bottom, there is a definition of ArithException, and an example where it is used to throw Control.Exception.DivideByZero. But here's my concern. Let's say that I wanted to, for some reason, create a MultiplyByZero exception. It should be broadly considered an ArithException, and any code that catches an ArithException should be able to catch my MultiplyByZero exception. But the ArithException type is limited to storing errors that are defined by Control.Exception.ArithException. My MultiplyByZero is not defined there, so I am out of luck. The best I could do is define a new MultiplyByZero, and catch it in my own code. But any code that others have written to catch ArithExceptions would be blind to MultiplyByZero. -- John ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Exceptions
Hello, One thing that bugs me about Haskell is that exceptions are not extensible. I don't know how to craft a good solution, but perhaps if I explain the problem well, someone would come up with one. In a language such as Python or Java, and exception is an object. Let's consider Python for a quick example. Python has an IOError exception. So if I want to write a handler that deals with IOErrors, that's easy enough. Now maybe I want to do something like report socket errors specially. I could define a SocketError class that subclasses IOError. I could take this further, and define a URLError that subclasses SocketError. Now the beauty of it is that I can: * Have a handler that catches URLErrors only and does nothing special with SocketErrors or IOErrors. * Have a handler -- perhaps not even mine -- that catches and works with IOErrors. Since SocketError and URLError are descendants of IOError, that handler will *automatically* work if I raise a SocketError or a URLError. I can see no such mechanism in Haskell. Haskell's I/O exceptions have a certain defined set of errors that they can report, and I can't subclass them and make them more specific for my purposes if I want. Ditto for all the others. The Dynamic exception support is necessary and good to have, but it also under-documented and can be complex. And of course, they still suffer from the same lack of extensibility Are there any suggestions on how we might improve this situation in Haskell? -- John ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Concurrency
On Fri, Mar 31, 2006 at 02:49:53PM -0800, John Meacham wrote: > > threading if it's available, but can degrade gracefully if not? Should > > I be forced to use something like cpphs to detect the presence of > > threading in advance? It would be better to detect this at runtime than > > fail to compile at all on a system that doesn't support threading, IMHO. > > Yeah, actually. cpphs (or something in cabal) seems like just the right > way to go. because it is set at compile time. you don't make run-time > decisions as to whether to use unboxed arrays, control.arrow or any > other library. it would seem very odd to do so for concurrency. Well then, this mechanism ought also to be standardized by Haskell'. To support concurrency (or not) but to not provide an automated way of graceful degradation is not, to me, a good solution. > Concurrency might be hidden deep in a library, you don't want to > suddenly get an unexpected "concurrency not supported" error because you > happened to use a library you didn't write in a new way. better to be > safe and catch those known errors at compile-time. That does make sense. I am concerned about the mechanism. AFAIK, Haskell98 didn't mandate cpphs or any tool like it. Will Haskell'? If not, then we are back to the original problem. -- John ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Concurrency
On Fri, Mar 31, 2006 at 01:51:14PM -0800, John Meacham wrote: > > If so, we should specify what exception is raised if, say, forkIO is > > called on such a system. We should also make it clear that > > single-threaded implementations are required of things such as MVars. > > Finally, we should add a function that indicates the level of threading > > support on the running system. > > routines that are guarenteed to fail becaues they arn't supported should > not exist, haskell tries hard to catch so many errors at compile time, > it would seem odd to delegate the error of missing a whole subsystem to > run-time :) Not really. What if I'm writing a program that can take advantage of threading if it's available, but can degrade gracefully if not? Should I be forced to use something like cpphs to detect the presence of threading in advance? It would be better to detect this at runtime than fail to compile at all on a system that doesn't support threading, IMHO. -- John ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: important news: refocusing discussion
On Fri, Mar 24, 2006 at 11:07:53AM +, Malcolm Wallace wrote: > threads, and I assume that since a non-concurrent implementation has > only one thread, that thread will be trying to MVar-synchronise with > something that does not exist, and hence be blocked for ever. I can Not necessarily. An MVar is a useful tool in place of an IORef. It works well when a given hunk of code is used in a threaded program, but it also works well in a non-threaded program. If they are used correctly, there is no problem. -- John ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Priorities
On Fri, Feb 03, 2006 at 05:56:41PM +0100, Tomasz Zielonka wrote:
> On Fri, Feb 03, 2006 at 10:03:08AM -0600, John Goerzen wrote:
> > I know, of course, that Java green threads and Haskell forkIO threads
> > are called "threads", but I personally believe its misleading to call it
> > concurrency -- they're not doing more than one thing at a time.
>
> Aren't you thinking about Parallellism?
No.
> http://en.wikipedia.org/wiki/Concurrency_%28computer_science%29
> In computer science, concurrency is a property of systems which
> consist of computations that execute overlapped in time
You're not doing anything simultaneously ("overlapped in time") when
you're using poll and select (only). To do something simultaneously in
Unix, you'd have to either use fork() or start a thread.
-- John
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
Re: Priorities
On Fri, Feb 03, 2006 at 12:00:23PM +0100, Tomasz Zielonka wrote: > > TZ> The design of Haskell was so great, that we could add concurrency as > > TZ> a library without introducing any problems... but we have > > TZ> concurrency in the standard anyway... > > > > concurrency should go into the Standard Library specification. there > > is just nothing to say about this in the _language_ standard > Agreed! We should be careful to not take too narrow a view of the meaning of the word "language", or at least not in the public output of this group. Many people would, for instance, consider the standard set of libraries in Java to be part of the language. The same could be said for Perl and Python. -- John ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Priorities
On Fri, Feb 03, 2006 at 01:00:32AM -0800, John Meacham wrote: > On Fri, Feb 03, 2006 at 08:40:27AM -, Simon Peyton-Jones wrote: > > The interface can be a library, but (a) what libraries are available is > > part of the language definition and (b) it's hard to build a good > > implementation without runtime support. And the nature of the runtime > > support depends on what the library interface is. > > If we had a good standard poll/select interface in System.IO then we > actually could implement a lot of concurrency as a library with no > (required) run-time overhead. I'd really like to see such a thing get Maybe this is just me being dense, but how is poll or select concurrency? There is no multiprocessing involved; it is simply a more efficient way to find which file descriptors are ready for some I/O action. I know, of course, that Java green threads and Haskell forkIO threads are called "threads", but I personally believe its misleading to call it concurrency -- they're not doing more than one thing at a time. > the ability to write thread-safe (but not thread using) libraries > portably. which means MVars and foreign annotations but nothing more. Yes. Plus, I'd say, the presence of threading primitives that return certain well-defined exceptions or something along those lines, so that it's not necessary to know whether multithreading is supported at compile time. > A nice, well thought out standardized poll/select/asynchronous IO > library as part of System.IO. this will fill a much needed gap between > full concurrency and synchronous IO which is currently a void and will > provide just enough run-time support for experimenting with portable > concurrency libraries. Well, I must admit to being confused at the present state of things. Right now, we have forkIO, which seems, to me, like a fancy wrapper around select or poll. It's very nice, really. I'm not clear, though, on how to integrate other C libraries that have their own async I/O systems into all of this. (For instance, LDAP or SQL libraries) The exact interaction between FFI, forkIO, forkOS, etc. is, to me, extremely vague right now. It also seems much more complex than in other languages, and perhaps varies from one Haskell implementation to the next. -- John ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Library Reform
On Thu, Feb 02, 2006 at 12:46:13PM -0800, Ashley Yakeley wrote: > If Haskell Prime is going to have certain type extensions rolled in, can > we make changes to the standard libraries that take advantage of these? I would hope so. But then, just what are the standard libraries anymore? The Haskell98 libraries are so very obsolete, IMHO. -- John ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
