Re: [Haskell-cafe] Question about the Monad instance for Iteratee (from the enumerator package)
You wouldn't be so confused if you had actually looked at Lato's implementation and compared it to Oleg's most recent version. Regards, John A. De Goes Twitter: @jdegoes LinkedIn: http://linkedin.com/in/jdegoes On Apr 21, 2011, at 6:27 PM, Jason Dagit wrote: On Thu, Apr 21, 2011 at 8:36 AM, John A. De Goes j...@n-brain.net wrote: This is a much cleaner definition of Iteratee and I'm happy to see it. I'm confused by this comment. Isn't John Lato's implementation of Iteratee (on hackage) is based on the example implementation that Oleg pointed you towards? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Question about the Monad instance for Iteratee (from the enumerator package)
This is a much cleaner definition of Iteratee and I'm happy to see it. When are you going to move from your FTP site to Github, by the way? :) Regards, John A. De Goes Twitter: @jdegoes LinkedIn: http://linkedin.com/in/jdegoes On Apr 21, 2011, at 12:32 AM, o...@okmij.org wrote: Daniel Schuessler wrote: The thing I don't understand yet is the last line: Why is it OK to discard the leftover input from the (f x) Iteratee and yield just the leftover input from the first one (m0)? First of all, the question is about an older version of Iteratee. For example, the following code http://okmij.org/ftp/Haskell/Iteratee/Iteratee.hs defines Iteratee a bit differently so the question does not apply. data Iteratee a = IE_done a | IE_cont (Maybe ErrMsg) (Stream - (Iteratee a,Stream)) instance Monad Iteratee where return = IE_done IE_done a = f = f a IE_cont e k = f = IE_cont e (docase . k) where docase (IE_done a, stream) = case f a of IE_cont Nothing k - k stream i - (i,stream) docase (i, s) = (i = f, s) No left-over is discarded any more. Your question is about the previous design, called `The second design' described in Iteratee.hs. The corresponding comment block answers your question, please search for ``Justification for the case IE_done x s = f''. Please see http://okmij.org/ftp/Haskell/Iteratee/IterateeM.hs for the `production' case of Iteratee in a base monad. The file IterateeM.hs talks about one more design, and its drawbacks. It's all about finding the optimal trade-off, I guess. ___ 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] Question about the Monad instance for Iteratee (from the enumerator package)
It's not OK and it's an artifact of the weak-typing and ill-defined semantics that pervade iteratee libraries. It's possible to do a lot of bad stuff, including binding with an iteratee yielding a remainder without consuming input. Regards, John A. De Goes Twitter: @jdegoes LinkedIn: http://linkedin.com/in/jdegoes On Apr 19, 2011, at 6:27 AM, Daniel Schüssler wrote: Hello, for reference, said instance is: instance Monad m = Monad (Iteratee a m) where return x = yield x (Chunks []) m0 = f = ($ m0) $ fix $ \bind m - Iteratee $ runIteratee m = \r1 - case r1 of Continue k - return (Continue (bind . k)) Error err - return (Error err) Yield x (Chunks []) - runIteratee (f x) Yield x extra - runIteratee (f x) = \r2 - case r2 of Continue k - runIteratee (k extra) Error err - return (Error err) Yield x' _ - return (Yield x' extra) The thing I don't understand yet is the last line: Why is it OK to discard the leftover input from the (f x) Iteratee and yield just the leftover input from the first one (m0)? Cheers, Daniel ___ 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: enumerator 0.4.8
Now THATs what I'm talking about. Augment such a solution with interruptible resumable data producers, and I'd have everything I need. Regards, John A. De Goes Twitter: @jdegoes LinkedIn: http://linkedin.com/in/jdegoes On Mar 27, 2011, at 10:54 PM, wren ng thornton wrote: In an ideal framework the producers, transformers, and consumers of stream data would have a type parameter indicating the up-stream communication they support or require (in addition to the type parameters for stream type, result type, and side-effect type). That way clients can just define an ADT for their communication protocol, and be done with it. There may still be issues with the Expression Problem, but at least those are pushed out of the stream processing framework itself which really shouldn't care about the types of communication used. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: enumerator 0.4.8
This isn't quite what I'm after. I want to pull chunks on demand (i.e. have control over both the input and the output). Enumeratees don't allow me to do that. Regards, John A. De Goes Twitter: @jdegoes LinkedIn: http://linkedin.com/in/jdegoes On Mar 27, 2011, at 7:58 PM, John Millikin wrote: If the receiver can only accept very small chunks, you can put a rechunking stage in between the compression and iteratee: --- verySmallChunks :: Monad m = Enumeratee ByteString ByteString m b verySmallSchunks = sequence (take 10) --- Resending is slightly more complex -- if the other end can say resend that last chunk, then it should be easy enough, but resend the last 2 bytes of that chunk you sent 5 minutes ago would be much harder. What is your use case? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: enumerator 0.4.8
Enumeratees solve some use cases but not others. Let's say you want to incrementally compress a 2 GB file. If you use an enumeratee to do this, your transformer iteratee has to do IO. I'd prefer an abstraction to incrementally and purely produce the output from a stream of input. Regards, John A. De Goes Twitter: @jdegoes LinkedIn: http://linkedin.com/in/jdegoes On Mar 26, 2011, at 3:12 PM, wren ng thornton wrote: On 3/26/11 4:33 PM, John A. De Goes wrote: 4. Iteratees cannot incrementally produce output, it's all or nothing, which makes them terrible for many real world problems that require both incremental input and incremental output. For this one, enumeratees are the proposed solution. But for some reason enumeratees are oft overlooked. -- Live well, ~wren ___ 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: enumerator 0.4.8
On Mar 26, 2011, at 4:24 PM, Mario Blažević wrote: On 11-03-26 04:33 PM, John A. De Goes wrote: Out of curiosity, have you looked at the monad-coroutine library? It's a more generic and IMO much cleaner model, though I wouldn't recommend it as a replacement because the enumerator and iteratee libraries come with more predefined plumbing. I think your point #1 still stands, but others can all be made to disappear - as long as you define your suspension functors properly. I haven't looked at it. I will take a look. Do you mean a sort of a transducer monad transformer or an actual finite state machine? The latter would seem rather restrictive. Yes, I mean transducer monad transformer, especially if you equate mealy machine with finite state machine. I equate mealy machine with two-taped transducer. Regards, John A. De Goes Twitter: @jdegoes LinkedIn: http://linkedin.com/in/jdegoes ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: enumerator 0.4.8
This formulation does not let me control the production of compressed chunks independently from the provision of input; a receiver may only be capable of consuming a tiny amount at a time, and I may have to resend some chunks. Which is the whole point: iteratee friends are lopsided. They provide excellent control of an input stream to the iteratee, but there is no structure permitting equivalent control of the output stream. Regards, John A. De Goes Twitter: @jdegoes LinkedIn: http://linkedin.com/in/jdegoes On Mar 27, 2011, at 3:22 PM, wren ng thornton wrote: On 3/27/11 11:38 AM, John A. De Goes wrote: Enumeratees solve some use cases but not others. Let's say you want to incrementally compress a 2 GB file. If you use an enumeratee to do this, your transformer iteratee has to do IO. I'd prefer an abstraction to incrementally and purely produce the output from a stream of input. I don't see why? In pseudocode we could have, enumRead2GBFile :: FilePath - Enumerator IO ByteString enumRead2GBFile file iter0 = do fd - open file let loop iter = do mline - read fd case mline of Nothing - return iter Just line - do iter' - feed iter line if isDone iter' then return iter' else loop iter' iterF - loop iter0 close fd return iterF compress :: Monad m = Enumeratee m ByteString ByteString compress = go state0 where go state = do chunk - get let (state',hash) = compressify state chunk put hash go state' compressify :: Foo - ByteString - (Foo,ByteString) it's just a pipeline like function composition or shell pipes. There's no reason intermediate points of the pipeline have do anything impure. -- Live well, ~wren ___ 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: enumerator 0.4.8
I noticed this problem some time ago. Beyond just breaking monadic associativity, there are many other issues with standard definitions of iteratees: 1. It does not make sense in general to bind with an iteratee that has already consumed input, but there's no type-level difference between a virgin iteratee and one that has already consumed input; 2. Error recovery is ill-defined because errors do not describe what portion of the input they have already consumed; 3. Iteratees sometimes need to manage resources, but they're not designed to do so which leads to hideous workarounds; 4. Iteratees cannot incrementally produce output, it's all or nothing, which makes them terrible for many real world problems that require both incremental input and incremental output. Overall, I regard iteratees as only a partial success. They're leaky and somewhat unsafe abstractions. I'm experimenting with Mealy machines because I think they have more long-term promise to solve the problems of iteratees. Regards, John A. De Goes Twitter: @jdegoes LinkedIn: http://linkedin.com/in/jdegoes On Mar 26, 2011, at 1:03 PM, John Millikin wrote: On Mar 26, 10:46 am, Michael Snoyman mich...@snoyman.com wrote: As far as the left-over data in a yield issue: does that require a breaking API change, or a change to the definition of = which would change semantics?? It requires a pretty serious API change, as the definition of 'Iteratee' itself is at fault. Unfortunately, Oleg's new definitions also have problems (they can yield extra on a continue step), so I'm at a bit of a loss as to what to do. Either way, underlying primitives allow users to create iteratees with invalid/undefined behavior. Not very Haskell-y. All of the new high-level functions added in recent versions are part of an attempted workaround. I'd like to move the Iteratee definitions themselves to a ``Data.Enumerator.Internal`` module, and add some words discouraging their direct use. There would still be some API breaks (the == , $$, and == operators would go away) but at least clients wouldn't be subjected to a complete rewrite. Since the API is being broken anyway, I'm also going to take the opportunity to change the Stream type so it can represent EOF + some data. That should allow lots of interesting behaviors, such as arbitrary lookahead. ___ 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] new focus for Happstack
Although you are joking, I've said it before and I'll say it again: server-side web development is dead. Everything that can be pushed to the client will be. Which leaves the server mainly for low-level persistence, data analysis, and anything requiring security. Static template-driven web frameworks are obsolete. Regards, John On Apr 1, 2010, at 8:31 AM, Jeremy Shaw wrote: Hello, I've been thinking a lot recently about the direction and future of the Happstack project. These days we hear a lot about technologies to allow servers to push data, such as Comet, Ajax Push, Reverse Ajax, Two-way-web, HTTP Streaming, and HTTP server push among others. HTML 5 includes something called 'Web Sockets'. In short, it seems that the 'stateless' web model is a complete failure. People want sockets! Furthermore, the big sites of the day are 'social media' sites such as Facebook, Twitter, Youtube, Four Square, etc. Well, it's clear to me where the industry is headed, and I think this is a great chance for Haskell to be the leader. persistent connection + social web site == BBS That's right! The return of the BBS is upon us. So, without further ado, I would like to announce the happstack-bbs project: darcs get http://src.seereason.com/happstack-bbs/ You can connect right now to the world's newest Haskell BBS. Simple open a terminal which supports ansi utf-8, and run: telnet hacketeria.com 2525 Patches welcome (and sorely needed!) - jeremy ___ 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] Parsec-like parser combinator that handles left recursion?
X-Saiga. Regards, John On Dec 8, 2009, at 7:10 AM, Adam Cigánek wrote: Hello there, Is there some other parser library, with similar nice API than Parsec, but which somehow handles left-recursive grammars? Ideally if it has at least rudimentary documentation and/or tutorial :) ___ 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] Status of TypeDirectedNameResolution proposal?
GTDNR is what I really want anyway... whether or not it's possible. :-) At any given time, importing everything unqualified from every module used by a typical hs leads only to a handful of ambiguities. While the general case might be intractable, real-world cases might be trivial. Regards, John On Nov 19, 2009, at 11:13 PM, wren ng thornton wrote: Twan van Laarhoven wrote: My point is that desugaring x.f to (f x) and treating some instances of (f x) as (ModuleToGuess.f x) are two separate things. In the current proposal these two are combined, but I see no reason to do so. To be a bit more concrete, I would propose: * General Type Directed Name Resolution (GTDNR): For every function application f x in the program where f is a name, f is resolved based on the type of the argument x. Note that I am not saying that this is necessarily a good idea, it is just a possible alternative to the current TDNR proposal. I'm not a big fan of any of the TDNR proposals I've seen (I think we still haven't found the right way to do it without it being just a hack), but I can give one good reason for why these two parts of the proposal are grouped together. You suggest that GTDNR might not be a good idea, well why not? One reason is that it can potentially lead to a whole lot of guessing, slowing the compiler down dramatically and maybe even so much guessing that there are multiple whole-program resolutions (oh noes!). So how can we control that combinatorial exploration of alternatives? One way would be to restrict the places where we allow guessing. There's still potential room for combinatorial explosions but they're greatly reduced, both because we reduce the number of variables in the problem (so the combinatorics are smaller), and because we (generally) will have a good deal of non-variable context to anchor the disambiguation process and hopefully resolve the variables easily. -- Live well, ~wren ___ 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] Re: Libraries for Commercial Users
On Oct 9, 2009, at 10:37 PM, Curt Sampson wrote: So this makes me wonder, if cross-platform support is so necessary, why have these PHP, Ruby and Python folks not switched to Java, rather than remain suffering doing their development on Linux boxes? PHP runs on all platforms (it's common for developers to test locally on Windows/Mac, and deploy to a Linux server), and has such an extensive library that most other libraries a developer might need are likely to be pure PHP, built on top the base. So while not cross platform in the sense that Java is, the approach taken by PHP achieves much of the benefit.[1] Moreover, PHP is a perfect example of the principle that libraries are essential to language success. PHP's standard library is so immense, it includes just about everything the average web developer needs. And many functions it provides are very high-level -- for example, file_get_contents() works seamlessly across local files, http files, https files, etc. PHP never would have achieved the success it has if it weren't for the immense library available for it (of course, it's not the sole factor in its success). And if libraries are the issue, why would not just creating a SWIG for GHC make all of these people move to Haskell? Making it possible and making it easy are two different things. It's already _possible_ to do Haskell interop with any other language, it's just difficult and cumbersome. Moreover, Haskell will never attract the following of a mainstream language like PHP. But there are numerous applications where Haskell is clearly a superior choice assuming library equality. I agree it's a nich market, too. So I guess our point of disagreement is that you believe that it's lack of libraries keeping it a nich market, Haskell will never be popular, because it's too hard for the masses. But I could see big companies like Yahoo, Facebook, Google, etc., using Haskell extensively to develop web infrastructure -- _if_ there were no longer a significant penalty to doing so. Right now the barrier of entry is too high, because too much infrastructure would have to be developed from scratch, and then maintained at cost. That just seems pointless to me, because those looking for real improvements can't use that sort of stuff. When I need RDBMS access, libraries like Hibernate and Active Record are useless to me, because they force me to work in a stupid manner. For web sites, Rails is useless because again, it deals with stuff in a stupid, unproductive way. Well, I don't know much about Rails, but I do know some Rails developers can build a fully-functional, database-backed Web 2.0 site in a matter of hours.[2] That level of productivity is not available in Haskell yet. Put another way, it would cost me far more to hire you to develop a Haskell site than a good Rails developer,[3] and what a Rails developer produces can be deployed at numerous Rails hosting sites at no upfront cost to me. So why should I hire you? [1] The Haskell Platform could eventually take Haskell in a similar direction, it it provides a broad enough base that developers can built nearly any other library directly on top of it. [2] http://www.readwriteweb.com/archives/rails_rumble_92_web_apps_created_in_48_hours.php [3] The difference in cost is strictly due to libraries. If you had some killer Haskell libraries at your disposal, I have no doubt you could do it for less than a Rails developer. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Libraries for Commercial Users
I don't have any research, but anecdotally, I know numerous startups, and most of them are producing web applications (usually client and server, but sometimes server only). Those doing desktop and mobile apps usually do server development, too, because in the age of ubiquitous network connectivity, applications that cannot take advantage of the Internet are few and far between. Most internal development is in the form of web apps (it's rare to see a company that produces desktop applications for in-house use), and most job postings today are for client-side developers (JavaScript, CSS/HTML, Flash) or server-side developers (Java, PHP, Ruby, etc.). Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Oct 10, 2009, at 12:11 PM, John Melesky wrote: On 2009-10-09, at 7:53 PM, John A. De Goes wrote: The vast majority of applications being built today are web apps. I'm not convinced this is the case. There are still a great many enterprise desktop apps and mobile apps being built, and the selection bias towards internet-based applications on a mailing list (not to mention the selection bias in blogs, reddit, etc). I'm not saying you're wrong, just that i'd love to see some research into it. -johnnn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Libraries for Commercial Users
On Oct 10, 2009, at 12:47 PM, Brad Larsen wrote: With this hypothetical ``import foreign jvm'' mechanism, what would the be type of imported Java stuff? Would it all be done in IO? Yes, that's a good first-start. The more I think about it, the trickier it seems. Beside the purity mismatch of Haskell and Java, there is an OO/functional mismatch. That just means an extra argument to every function and some unsafe downcasts; and maybe some funky mechanism for subclassing, for those libraries that require it (deprecated in modern OOP but not uncommon). Haskell / Java interop could be a huge boon; I just have trouble seeing how it could be so simple as a one-line import in your Haskell code. I'm not saying the one-line import would give you anything more than purely imperative wrappers around Java code. But that's a start. It's good enough. If it existed, I could transition two companies over to Haskell, and likely more in the future. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Libraries for Commercial Users
Here's a list of libraries that are quite significant to commercial software development in 2009, but which either do not exist in Haskell, or if they exist, are hard to find, undocumented, unstable, or perhaps uncompilable: * A drop-in comet server, with JavaScript bindings (or compatible with existing JavaScript bindings). * A library for producing RESTful APIs, which does much of the work in mapping URLs into operations on a database. * Speaking of database, a robust, well-documented, cross-platform interface to popular databases, with a commercial-friendly license. * A scalable, fault-tolerant, distributed data store in the mold of BigTable, which provides map reduce. Or at least Haskell bindings for one, and a Haskellized wrapper around the binder. * A Haskell client for AMQP or other message broker, ideally reactive but anything's better than nothing. And while I'm at it, how about a 100% Haskell message broker that takes advantage of Haskell's functional nature to deliver something of Erlang quality. * A scalable, fault-tolerant, distributed graph database that can be used for building and maintaining social networks. * A networking library that supports peer-to-peer communication, authentication, encryption, and other features via plug-ins, with seamless multicasting when possible. * Infrastructure for building Haskell cloud computing clusters that are scalable and fault-tolerant. * Search and other data mining libraries, with robust indexing features, and the capacity to scale indefinitely. * Haskell interfaces to Twitter, Facebook, MySpace, Google, etc. * etc. In any one of these categories, Java has multiple implementations, sometimes 20 or more (yes, it's absurd at times, but it's also comforting because it means choosing Java is not risky). Many are meticulously documented with extensive Javadoc and tutorials. And this just scratches the surface. Most apps today are web apps, meaning they have client and server portions. Some modern languages natively support cross-compilation (Haxe, Fan), and others such as Java can be cross-compiled with the aid of third-party packages (gwt, java2script), but not Haskell. Reusing code, and using a single language across different platforms opens up many new possibilities and greatly improves productivity and efficiency. Let me ask you this question. How long would it take you to write a scalable first-pass Twitter clone? A good Java developer could do it in a week, maybe a day, and deploy it on AppEngine, where it will scale indefinitely with no effort. That's power. The syntax of a language, no matter how beautiful or high-level, cannot compete with the billions of dollars worth of resources freely available for inferior languages like Java. Haskell on the JVM with seamless Java interop (no need for method-by- method foreign import of information that's freely available via reflection) would go a long way towards leveling the playing field. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Oct 7, 2009, at 5:41 PM, Curt Sampson wrote: On 2009-10-02 09:03 -0600 (Fri), John A. De Goes wrote: [Haskell] is missing many key libraries that would be of great commercial value. Just out of curiousity, can you give me some examples of what you feel these are? cjs -- Curt Sampson c...@starling-software.com+81 90 7737 2974 Functional programming in all senses of the word: http://www.starling-software.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Market Place for Haskell development teams?
I don't dismiss Haskell in business. I only maintain it's a niche market. There are some domains where the infrastructure in more established languages is minimal, and in such cases, I think Haskell can be more efficient than those languages. I should note, too, the the agile development momement over the past ten years has had and still does have exactly the same sort of attacks on it, and yet has successfully moved into the mainstream and is well-accepted by many parts of it. What has moved into mainstream is unfortunately connected chiefly to agile by virtue of the word itself. Agile means more than getting software out the door quickly, a fact many businesses have yet to learn. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Oct 7, 2009, at 5:49 PM, Curt Sampson wrote: On 2009-10-02 09:04 -0600 (Fri), John A. De Goes wrote: I'm not saying Haskell is unstable. I'm saying that the attitude expressed in the following quote is at odds with the needs of business: And as far as something like dealing with a changing language and libraries, the mainstream already has well-established and popular techniques for doing just: agile development. I don't know how much commercial experience you have, but I've been a founder of two companies, CTO or CEO of several businesses, a chief architect in a couple more, and consider myself as much a businessman and manager as a developer. The attitude you express is certainly common in many businesses, but it's not the only way to run a successful business. I won't go further here, since this kind of argument generally leads into a, no, what you do isn't possible kind of flamewar, but I did want to point this out here, so that others can know that, the attitude John De Goes expresses, while comon, is not the only way busineses look at the world. I should note, too, the the agile development momement over the past ten years has had and still does have exactly the same sort of attacks on it, and yet has successfully moved into the mainstream and is well-accepted by many parts of it. cjs -- Curt Sampson c...@starling-software.com+81 90 7737 2974 Functional programming in all senses of the word: http://www.starling-software.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Libraries for Commercial Users
Exactly, it's things like this that are so frustrating and which reduce efficiency. In a mature library, you don't need to handle details like this for yourself. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Oct 7, 2009, at 6:44 PM, Erik de Castro Lopo wrote: Curt Sampson wrote: On 2009-10-02 09:03 -0600 (Fri), John A. De Goes wrote: [Haskell] is missing many key libraries that would be of great commercial value. Just out of curiousity, can you give me some examples of what you feel these are? A version of Network.HTTP that accepts HTTPS URLs and does the right thing instead of attempting to do a HTTP connection instead. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ 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] Re: Libraries for Commercial Users
Some of these are not ready for production use; e.g.: RESTng: RESTng is still experimental and incomplete. It has no documentation and doesn't even compile. Sadly typical. It's a bit of a chicken and egg thing. I'd switch to Haskell in a commercial setting if there were more good libraries, yet the act of switching would lead to the production of more good libraries. The latter, though, is cost-prohibitive, given all the components that would need to be developed. A few years from now, or post Haskell-on- JVM, I might be singing a different tune. I do greatly admire the work you and your company have done for Haskell. What has the Industrial Haskell group done so far? I haven't seen any announcements. The work I'd be most interested in helping co-sponsor is Haskell on JVM (biggest bang for the buck). Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Oct 8, 2009, at 11:24 AM, Don Stewart wrote: john: * Haskell interfaces to Twitter, Facebook, MySpace, Google, etc. This one is fine: twitter hs-twitter library: Haskell binding to the Twitter API del.icio.us delicious library: Accessing the del.icio.us APIs from Haskell (v2) friendfeed ffeed library and programs: Haskell binding to the FriendFeed API LiveJournal feed2lj program: Cross-post any RSS/Atom feed to LiveJournal flickr flickr library and programs: Haskell binding to the Flickr API amazon hS3 library and program: Interface to Amazon's Simple Storage Service (S3) mediawiki mediawiki library and programs: Interfacing with the MediaWiki API google pubsub pubsub library and programs: A library for Google/SixApart pubsub hub interaction Speaking of REST, RESTng library: A framework for writing RESTful applications. And auth: WindowsLive windowslive library and program: Implements Windows Live Web Authentication and Delegated Authentication OpenID openid library: An implementation of the OpenID-2.0 spec. OAuth hoauth library and program: A Haskell implementation of OAuth 1.0a protocol. We've obviously not all there yet, but we have a way to get there -- write and improve code on Hackage. Galois is doing its part (we've released dozens of web packages), but the other commercial users need to help out too. Join the Industrial Haskell Group and fund open source work. Or, if you can, release some of the non-IP-encumbered things you work on! -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Libraries for Commercial Users
Yes. C is the language of operating systems and browsers and low-level system utilities -- not, by and large, the backbone of today's web applications. Projects written in C/C++ tend to be ignored in favor of those written in Java (Hypertable versus HBase, for example). There are exceptions, but there are fewer of them over time. Java's spot in the middle tier has overflowed into the bottom tier, as performance and community size have increased. Moreover, C libraries are seldom cross-platform (leading to wasteful fiddling and endless frustration), and they are painful to interface with due to the requirement for detailed type annotations, which are easy to get wrong. JVM is cross-platform, and contains sufficient typing information to permit one to write something like, import foreign jvm java.list.Collection, and have typed access to the whole class and all of its methods. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Oct 8, 2009, at 1:00 PM, Gregory Crosswhite wrote: Out of curiosity, why do you think that porting Haskell to the JVM would make such a large difference? Haskell can already interface with C libraries; are there really so many commercially vital libraries that are JVM-only? Cheers, Greg On Oct 8, 2009, at 11:08 AM, John A. De Goes wrote: Some of these are not ready for production use; e.g.: RESTng: RESTng is still experimental and incomplete. It has no documentation and doesn't even compile. Sadly typical. It's a bit of a chicken and egg thing. I'd switch to Haskell in a commercial setting if there were more good libraries, yet the act of switching would lead to the production of more good libraries. The latter, though, is cost-prohibitive, given all the components that would need to be developed. A few years from now, or post Haskell-on-JVM, I might be singing a different tune. I do greatly admire the work you and your company have done for Haskell. What has the Industrial Haskell group done so far? I haven't seen any announcements. The work I'd be most interested in helping co- sponsor is Haskell on JVM (biggest bang for the buck). Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Oct 8, 2009, at 11:24 AM, Don Stewart wrote: john: * Haskell interfaces to Twitter, Facebook, MySpace, Google, etc. This one is fine: twitter hs-twitter library: Haskell binding to the Twitter API del.icio.us delicious library: Accessing the del.icio.us APIs from Haskell (v2) friendfeed ffeed library and programs: Haskell binding to the FriendFeed API LiveJournal feed2lj program: Cross-post any RSS/Atom feed to LiveJournal flickr flickr library and programs: Haskell binding to the Flickr API amazon hS3 library and program: Interface to Amazon's Simple Storage Service (S3) mediawiki mediawiki library and programs: Interfacing with the MediaWiki API google pubsub pubsub library and programs: A library for Google/SixApart pubsub hub interaction Speaking of REST, RESTng library: A framework for writing RESTful applications. And auth: WindowsLive windowslive library and program: Implements Windows Live Web Authentication and Delegated Authentication OpenID openid library: An implementation of the OpenID-2.0 spec. OAuth hoauth library and program: A Haskell implementation of OAuth 1.0a protocol. We've obviously not all there yet, but we have a way to get there -- write and improve code on Hackage. Galois is doing its part (we've released dozens of web packages), but the other commercial users need to help out too. Join the Industrial Haskell Group and fund open source work. Or, if you can, release some of the non-IP-encumbered things you work on! -- Don ___ 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] better way to do this?
On Oct 7, 2009, at 3:13 AM, Ketil Malde wrote: Peter Verswyvelen bugf...@gmail.com writes: So yes, without using IO, Haskell forces you into this safe spot One could argue that IO should be broken down into a set of sub- monads encapsulating various subsets of the functionality - file system, network access, randomness, and so on. This could extend the safe spot to cover much more computational real estate, and effectively sandbox programs in various ways. Good idea in theory, in practice I suspect it would lead to unmanageable boilerplate. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] better way to do this?
It's a complex area not a lot of people are working in. Similar (actually worse than) dependent typing. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Oct 7, 2009, at 3:32 AM, Eugene Kirpichov wrote: Or you can use an effect system (however that doesn't give you the opportunity of overriding IO functions, but I think that providing such an opportunity with the means you suggest (splitting IO into many sub-monads) is not going to be usable in the large scale) By the way, I am surprised that there seems to not exist any non-purely-academic language at all that supports effect systems! (except for Java's checked exceptions being a poor analogue). The only language with an effect system *and* a compiler that I know of is DDC, but it seems to be purely experimental. 2009/10/7 Ketil Malde ke...@malde.org: Peter Verswyvelen bugf...@gmail.com writes: So yes, without using IO, Haskell forces you into this safe spot One could argue that IO should be broken down into a set of sub- monads encapsulating various subsets of the functionality - file system, network access, randomness, and so on. This could extend the safe spot to cover much more computational real estate, and effectively sandbox programs in various ways. So instead of 'main :: IO ()', a text processing program using stdin and stdout could have type 'main :: MonadStdIO m = m ()'. For testing, you could then define your own monad implementing 'putStrLn' and 'readLn' etc, and a function 'runStdIO :: MonadStdIO m = m () - String' that you are free to use in your quickcheck properties. (ObAttribution: I think it was a posting by Lennart Augustsson on unique names that brought this to my mind, but a quick googling didn't find that exact mail.) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Eugene Kirpichov Web IR developer, market.yandex.ru ___ 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] dsl and gui toolkit
This is the right approach to a GUI toolkit. Note that personally, I believe the details of the presentation should be separate from Haskell, stored in a separate file that is machine- friendly, so designers can work in concert and in parallel with developers. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Oct 6, 2009, at 10:22 AM, Andrew U. Frank wrote: thanks for the connection to the gui runner - it is interesting and worthwile, but a different approach. my approach is strictly declarative and does not describe sequences of process. it describes screens and links operations to buttons. then it takes inputs from the screen and runs the operations and posts the result on the screen. some operations open new screens etc. i started with the idea that ontologies describe the semantics of data in a static way; this should be (nearly) enough to create the user interface - which is all about semantics of the data. of course, you have to include in the ontology the semantics of the operations (as class with functions). the implementation is close to a reactive framework - adding a representation of all what is visible on the screen (the universer of discourse) in a format usable by the operations. then you have only to connect this 'universe of discourse' to the programs which operate on the data and post their reaction in the UoD and map the UoD to the screen the details are messy as i attempted to construct the internal data structures etc. as automatically as possible and with minimal designer input I did not use template haskell, yet, but will need to (i think). i am happy to share it with interested parties and hear the comments and perhaps somebody can help me with using templates to reduce the . it is IMHO not yet ready for posting in a library - but this is certainly the goal. ___ 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] dsl and gui toolkit
CSS is a good start by it's beset by all the problems of a 1st generation presentation language, and is not particularly machine- friendly. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Oct 6, 2009, at 10:44 AM, Colin Paul Adams wrote: John == John A De Goes j...@n-brain.net writes: John This is the right approach to a GUI toolkit. John Note that personally, I believe the details of the John presentation should be separate from Haskell, stored in a John separate file that is machine- friendly, so designers can John work in concert and in parallel with developers. Like CSS? -- Colin Adams Preston Lancashire ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Num instances for 2-dimensional types
That's not gonna happen until when/if Haskell supports name/operator overloading. There's a scarcity of good symbols/function names and everyone wants to use them. So naturally, type class abuse follows. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Oct 5, 2009, at 7:12 AM, Miguel Mitrofanov wrote: Sönke Hahn wrote: I used to implement fromInteger n = (r, r) where r = fromInteger n , but thinking about it, fromInteger n = (fromInteger n, 0) seems very reasonable, too. Stop pretending something is a number when it's not. ___ 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] killer app sought
With few exceptions, no such thing as a killer server-side app. The Web 3.0 paradigm is simple: all work except sharing and persistence of data is done on the client. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Oct 3, 2009, at 9:08 PM, Mark Wotton wrote: Hi, I've been writing a little binding from Ruby to Haskell called Hubris (http://github.com/mwotton/Hubris) which I think has some potential both for making Haskell web apps easier to write, and also for bringing the more adventurous Ruby programmers into the Haskell community. Code-wise it's coming along nicely, and once 6.12 is out it'll run without modifications at least on Linux (remains to be seen how long it'll take to get the Mac patches into shape). My real problem is marketing: I need a killer app that shows it's easy either to 1. wrap a kickarse Haskell library in a convenient Ruby web app shell 2. speed up a poorly performing Ruby web app I've been badgering the Ruby guys in Sydney that I know on the second point, but either none of them have performance problems, or none of them want to admit it. The first is entirely possible - if you only attack the subset of problems where your runtime is dominated by the database and network latency, language performance is moot. Conversely, if that's your worldview, the other problems that could be attacked won't ever come to mind (to monstrously abuse the Sapir-Whorf hypothesis). So, I'm asking you guys. What are some really nice Haskell libraries or apps that could benefit from being shown off in one of the plethora of slick, mature web frameworks that exist in Ruby? Manuel Chakravarty suggested something with vector operations in order to take advantage of his 'accelerate' library (once it gets a GPU backend, of course), and more generally, something taking advantage of Haskell's support for multicore would be cool. (The standard edition of Ruby is still unicore, I believe.) Parenthetically yours, Mark ___ 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] Market Place for Haskell development teams?
On Oct 1, 2009, at 12:13 AM, Curt Sampson wrote: And as far as something like dealing with a changing language and libraries, the mainstream already has well-established and popular techniques for doing just: agile development. A project manager's worst nightmare: Sorry boss, but we're just not going to be able to meet that deadline, because, well, a language extension we were using was dropped from the language, and the syntax for some core operators was changed. Not only is our code broken, but many of the libraries we were using are broken. Don't worry, though, we're 'agile', so our unit tests will tell us when our code is working again. Big business demands stability. Regards, John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Market Place for Haskell development teams?
On Oct 1, 2009, at 9:56 AM, Curt Sampson wrote: The main whinging seems to be about libraries, of which we have only 1585 on hackage. It's not just about the _number_ of libraries, but the _usefulness_ of them for solving real-world problems. Haskell has a large number of libraries that are of no interest whatsoever to commercial software developers (new numerical hierarchies, category theory libraries, etc.), and is missing many key libraries that would be of great commercial value. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Market Place for Haskell development teams?
I'm not saying Haskell is unstable. I'm saying that the attitude expressed in the following quote is at odds with the needs of business: And as far as something like dealing with a changing language and libraries, the mainstream already has well-established and popular techniques for doing just: agile development. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Oct 2, 2009, at 9:03 AM, minh thu wrote: 2009/10/2 John A. De Goes j...@n-brain.net: On Oct 1, 2009, at 12:13 AM, Curt Sampson wrote: And as far as something like dealing with a changing language and libraries, the mainstream already has well-established and popular techniques for doing just: agile development. A project manager's worst nightmare: Sorry boss, but we're just not going to be able to meet that deadline, because, well, a language extension we were using was dropped from the language, and the syntax for some core operators was changed. Not only is our code broken, but many of the libraries we were using are broken. Don't worry, though, we're 'agile', so our unit tests will tell us when our code is working again. Big business demands stability. Hi, Of course, the haskell community is that immature. People keep dropping extensions without a thought for potential problems. And the package versioning policy is just a joke written for next april fools day. Sorry for the spoiler. Cheers, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Market Place for Haskell development teams?
The cross-platform features have been extremely important to the success of Java, because they have greatly expanded the number of libraries available to developers. On Haskell Cafe, not a week goes by that Windows (and sometimes Mac) developers don't complain about not being able to use some Hackage library because of cross-platform issues. The actual number of people encountering these issues is orders of magnitude larger than the number of posts you see here. These issues impede the growth of Haskell significantly. Moreover, the importance of cross-platform libraries on the Java platform is evinced by the fact that developers of major native libraries _always_ make their libraries cross-platform (Jogl, jmonkeyengine, swt, etc.). They wouldn't go to this trouble if it weren't something the community was demanding. From a risk management perspective, a manager really likes the ability to seamlessly move across platforms and architectures without recompilation. 32 - 64? No problem. Linux - BSD? Sure, why not? Yes, I'm sure even Amazon, Yahoo, and Google make these kinds of considerations. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Sep 30, 2009, at 5:28 AM, Alberto G. Corona wrote: Nobody consider the runtime download of Java code important nowadays. Not even the cross-platform features. but it was marketeed at his time as such. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments requested: succ Java
You misunderstood my point. The browser, BigTable clone, and peer-to- peer networking libraries are starting points for applications -- ones that I've actually needed at various points in my career. You can grab them and start developing with them in a few minutes. If you want these components (or 100 others) in Haskell, you're going to have to write them yourself (at a cost of several to dozens of man years), or at least write sucky imperative wrappers around existing C libraries, compile those libraries, develop a cross-platform build process, be prepared to fix bugs in multiple languages, etc. Hackage is great, except when it's not, which is most of the time. No one's bit off the really big projects. In fact, they get voted down on the Reddit Haskell proposals, because somehow really practical software like an AMQP client isn't cool enough. Haskell's great for small applications that don't need specialized libraries (and apparently, for small segments of the financial industry). For other applications, it usually cannot compete economically with other, vastly technically inferior languages like Java. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Sep 28, 2009, at 10:56 AM, Curt Sampson wrote: Ok, my last post on this for real this time. On 2009-09-28 08:13 -0600 (Mon), John A. De Goes wrote: Let me ask you this question: how long would it take you to get an HTML/CSS, W3 compliant browser in Haskell? A long time. On the other hand, by grabbing a copy of Mozilla, I'll have one far faster than you'll have yours in Java, mine will work a lot better, run more quickly, and work better with most sites. While I advocate using Haskell, I don't advocate being silly. (Incidently, I have direct experience with an almost exactly parallel situation. I replaced a system that was thousands of lines of difficult-to-maintain Java code with a few hundred lines of Haskell that feed Microsoft Excel. The user is very pleased that he can now can do far more extensive tweaking of the UI himself, including major features he never had at all before, such as real-time graphing of the data.) Or how about a peer-to-peer networking system with seamless scaling and automatic failover? Can you give me an example of a real-life system using this you've set up in a few minutes? My experience building systems with similar things (the very mature and proven MogileFS suite of tools) has been that the libraries were nice, but did not solve the majority, or even a large minority, of the problem. Libraries are _everything_. In many cases, they can increase your effective budget by 10x or even 100x. Or the other way around, as I've seen by ripping out thousands of lines of Hibernate code, and all of the work done to adapt a system to that model, and replace it with a few hundred lines of SQL and JDBC calls. That library has probably wasted more man-years than anything else I've seen in the Java world. cjs -- Curt Sampson c...@starling-software.com+81 90 7737 2974 Functional programming in all senses of the word: http://www.starling-software.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments requested: succ Java
It's the early adopters who develop the first libraries that pull in ever wider audiences. Yes, the early adopters are drawn by the syntax of the language, but commercial adoption doesn't come until it's economically competitive to do so. And that doesn't happen until the library market is booming and/or they can seamlessly reuse existing assets (that's what the JVM languages discovered: if you allow people to use what they already have, in a seamless fashion, incrementally building new stuff using the new language, then you can dramatically shorten the time between early adoption and mass adoption). Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Sep 28, 2009, at 11:01 AM, Jason Dusek wrote: 2009/09/28 John A. De Goes j...@n-brain.net: Libraries are _everything_... Not exactly. Python would never have gotten a foothold over Perl, nor Java over C, if cleaner language semantics weren't enough for some shops or certain applications. -- Jason Dusek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments requested: succ Java
Interop between Haskell and Java is too difficult to be practical. And I stand by my statement that no Java shop is going to switch over to Haskell, precisely because they cannot afford to abandon either their existing investment, or the _billions of dollars_ worth of commercial- friendly open source libraries available for the Java platform. But I do agree on this: the JVM does indeed need a Haskell-like language. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Sep 27, 2009, at 8:10 PM, Curt Sampson wrote: On 2009-09-27 10:36 -0600 (Sun), John A. De Goes wrote: I'm not sure what the point of your series is. No one who is using Java now commercially can move to Haskell because Haskell doesn't run on the JVM. That's a rather strong statement, and I don't accept it. I can not only think of many possible circumstances where it would be possible for a Java-using shop to write a piece of software that doesn't run on the JVM, but I have sween many of these. There are lots of shops out there using, e.g., C++ code as well as Java code, who are already obviously able to use non-JVM languages. Given that, one point would be to show that there are more benefits to be gained by switching from Java to Haskell than there are from switching from Java to one of the other languages mentioned. This may be enough to tip some shops into Haskell. Second, it might inspire people to have a look at bringing a more Haskell-like language to the JVM, or add more Haskell-like features to existing JVM languages. Third, even if a shop is not going to switch, having people understand what's out there, and where many of these ideas come from, is a good thing, I feel. cjs -- Curt Sampson c...@starling-software.com+81 90 7737 2974 Functional programming in all senses of the word: http://www.starling-software.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments requested: succ Java
CAL is interesting, but unfortunately dead, and has no community. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Sep 27, 2009, at 3:38 PM, Peter Verswyvelen wrote: That's not really true. Just use CAL from the Open Quark framework... It's almost Haskell 98, with some extras, and compiles to fast JVM code. http://openquark.org/Open_Quark/Welcome.html They even seem to do all kinds of advanced optimizations - like converting tail calls to loops - to get good Java performance. And they have a better record system, a graphical environment to learn it, etc. So I think CAL should be in the list, and since it's basically Haskell... On Sun, Sep 27, 2009 at 6:36 PM, John A. De Goes j...@n-brain.net wrote: I'm not sure what the point of your series is. No one who is using Java now commercially can move to Haskell because Haskell doesn't run on the JVM. It makes sense to discuss Clojure, Groovy, JRuby, Scala, Fan, etc., as next Java's, because they all run on the JVM and have seamless interop with Java. Haskell is not in this category. It's stuck in a different world, wholly inaccessible to the masses. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Sep 27, 2009, at 10:16 AM, Curt Sampson wrote: No, it's not quite what it sounds like. :-) Stuart Halloway recently posted a series of blog entries entitled Java.next[1], discussing the benefits of four other languages that compile to JVM bytecode and interoperate with Java: Clojure, Groovy, JRuby, and Scala. I thought I'd put my oar in and write a parallel series comparing Haskell to these. I've finished a draft of the first posting, started on the third, and made a couple of notes on the second and fourth, and I thought I'd post the drafts[2] and solicit comments here. If you have time to read and comment, I'd greatly appreciate the help; feel free either to e-mail me privately or post here. Also feel free to forward this to anybody else you feel might be interested in commenting. I'll probably be posting these about one per week, starting some time next week. [1]: http://blog.thinkrelevance.com/2008/9/24/java-next-overview [2]: http://www.starling-software.com/en/blog/drafts/2009/09/27.succ-java-summary.html cjs -- Curt Sampson c...@starling-software.com+81 90 7737 2974 Functional programming in all senses of the word: http://www.starling-software.com ___ 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Market Place for Haskell development teams?
It's very difficult to find information on: 1. How many Haskell developers are out there; 2. What a typical salary is for a Haskell developer; 3. Whether or not the skills of a typical Haskell developer scale to large applications (most Haskell developers are hobby Haskellers and have only written tiny to small Haskell apps); 4. How many shops are capable of handling Haskell development maintenance. These are the kinds of information one needs to make an informed decision about whether to introduce Haskell into the workplace. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Sep 28, 2009, at 7:01 AM, Jörg Roman Rudnick wrote: In the last months, I made the experience it seems difficult to find commercial Haskell developer teams to take responsibility for projects in the range of $ 10.000 - 100.000. The Industrial Haskell Group does not seem to be the appropriate place for this, while harvesting Haskell team at general market places appears to be tedious. I would be very interested in others' experiences, and inhowfar my opinion is shared that there should be a demand for such a market place, for developer teams as well as those sympathizing with introducing Haskell somewhere. Nick ___ 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] Comments requested: succ Java
If you have counterexamples, then perhaps you can name them. I'm looking for Java shops with 5+ developers and code bases of 100k converting over to Haskell. I don't know _any such shop_ that has switched to Haskell, and I doubt any exist, but I'd be delighted to learn I'm wrong. Let me ask you this question: how long would it take you to get an HTML/CSS, W3 compliant browser in Haskell? Or how about a peer-to-peer networking system with seamless scaling and automatic failover? How about a scalable BigTable implementation? In Java, the answer to these questions -- and just about any others you can think of -- is a few minutes, because the code has already been written. Libraries are _everything_. In many cases, they can increase your effective budget by 10x or even 100x. That means instead of having $100k for a project, you suddenly have $1 - 10 million worth of resources at your disposal. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Sep 28, 2009, at 7:49 AM, Curt Sampson wrote: On 2009-09-28 07:01 -0600 (Mon), John A. De Goes wrote: And I stand by my statement that no Java shop is going to switch over to Haskell I have counterexamples. So pt! ...or the _billions of dollars_ worth of commercial- friendly open source libraries available for the Java platform. Right; the library myth. I rank this one up there with, Haskell can never be an effective programming language, because it doesn't have objects. I've been hearing that having lots of libraries is an insurmountable advantage, and you're doomed if you give them up, since long before I took up Haskell. It's mostly myth promulgated by people driven by fear. I'm sure it's the case in some shops that they have lots of people who can glue libraries together but can't program, and they somehow manage to produce applications this way, but even that I suspect is not so frequent a situation as you'd think. Nonetheless, since all of this is rather missing the point of my articles, anyway, I think I'll leave that as my last word on the topic. cjs -- Curt Sampson c...@starling-software.com+81 90 7737 2974 Functional programming in all senses of the word: http://www.starling-software.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments requested: succ Java
I think they made a mistake choosing a syntax so close to Haskell: 1. It's close enough to Haskell to attract Haskellers; 2. It's far enough away from Haskell to push Haskellers away; 3. It's not the language one would design if one were prioritizing easy interop with Java in a modern lazy, functional language. If CAL were 100% Haskell 98 + extensions, it would be a success (Haskell + all Java libraries, trivial cross-platform library development, Haskell on Android AppEngine, etc.). If it were nothing like Haskell, but had the features of Haskell plus strong, seamless, and easy Java interop, then it would be a success. Having neither, I'm not surprised it has no community and development has ceased. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Sep 28, 2009, at 9:59 AM, Peter Verswyvelen wrote: That's a really shame. Any idea why? On Mon, Sep 28, 2009 at 3:02 PM, John A. De Goes j...@n-brain.net wrote: CAL is interesting, but unfortunately dead, and has no community. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Sep 27, 2009, at 3:38 PM, Peter Verswyvelen wrote: That's not really true. Just use CAL from the Open Quark framework... It's almost Haskell 98, with some extras, and compiles to fast JVM code. http://openquark.org/Open_Quark/Welcome.html They even seem to do all kinds of advanced optimizations - like converting tail calls to loops - to get good Java performance. And they have a better record system, a graphical environment to learn it, etc. So I think CAL should be in the list, and since it's basically Haskell... On Sun, Sep 27, 2009 at 6:36 PM, John A. De Goes j...@n-brain.net wrote: I'm not sure what the point of your series is. No one who is using Java now commercially can move to Haskell because Haskell doesn't run on the JVM. It makes sense to discuss Clojure, Groovy, JRuby, Scala, Fan, etc., as next Java's, because they all run on the JVM and have seamless interop with Java. Haskell is not in this category. It's stuck in a different world, wholly inaccessible to the masses. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Sep 27, 2009, at 10:16 AM, Curt Sampson wrote: No, it's not quite what it sounds like. :-) Stuart Halloway recently posted a series of blog entries entitled Java.next[1], discussing the benefits of four other languages that compile to JVM bytecode and interoperate with Java: Clojure, Groovy, JRuby, and Scala. I thought I'd put my oar in and write a parallel series comparing Haskell to these. I've finished a draft of the first posting, started on the third, and made a couple of notes on the second and fourth, and I thought I'd post the drafts[2] and solicit comments here. If you have time to read and comment, I'd greatly appreciate the help; feel free either to e-mail me privately or post here. Also feel free to forward this to anybody else you feel might be interested in commenting. I'll probably be posting these about one per week, starting some time next week. [1]: http://blog.thinkrelevance.com/2008/9/24/java-next-overview [2]: http://www.starling-software.com/en/blog/drafts/2009/09/27.succ-java-summary.html cjs -- Curt Sampson c...@starling-software.com+81 90 7737 2974 Functional programming in all senses of the word: http://www.starling-software.com ___ 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 ___ 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] Comments requested: succ Java
I'm not sure what the point of your series is. No one who is using Java now commercially can move to Haskell because Haskell doesn't run on the JVM. It makes sense to discuss Clojure, Groovy, JRuby, Scala, Fan, etc., as next Java's, because they all run on the JVM and have seamless interop with Java. Haskell is not in this category. It's stuck in a different world, wholly inaccessible to the masses. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Sep 27, 2009, at 10:16 AM, Curt Sampson wrote: No, it's not quite what it sounds like. :-) Stuart Halloway recently posted a series of blog entries entitled Java.next[1], discussing the benefits of four other languages that compile to JVM bytecode and interoperate with Java: Clojure, Groovy, JRuby, and Scala. I thought I'd put my oar in and write a parallel series comparing Haskell to these. I've finished a draft of the first posting, started on the third, and made a couple of notes on the second and fourth, and I thought I'd post the drafts[2] and solicit comments here. If you have time to read and comment, I'd greatly appreciate the help; feel free either to e-mail me privately or post here. Also feel free to forward this to anybody else you feel might be interested in commenting. I'll probably be posting these about one per week, starting some time next week. [1]: http://blog.thinkrelevance.com/2008/9/24/java-next-overview [2]: http://www.starling-software.com/en/blog/drafts/2009/09/27.succ-java-summary.html cjs -- Curt Sampson c...@starling-software.com+81 90 7737 2974 Functional programming in all senses of the word: http://www.starling-software.com ___ 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] ANN: haskell-src-exts-1.1.4
Roundtrip is an important milestone for automated refactoring tools.
Nice work!
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Sep 3, 2009, at 2:57 PM, Niklas Broberg wrote:
Fellow Haskelleers,
I'm pleased to announce the release of haskell-src-exts-1.1.4!
* On hackage: http://hackage.haskell.org/package/haskell-src-exts
* Via cabal: cabal install haskell-src-exts
* Via darcs: darcs get http://code.haskell.org/haskell-src-exts
* Report bugs: http://trac.haskell.org/haskell-src-exts
haskell-src-exts is a package for Haskell source code manipulation. In
particular it defines an abstract syntax tree representation, and a
parser and pretty-printer to convert between this representation and
String. It handles (almost) all syntactic extensions to the Haskell 98
standard implemented by GHC, and the parsing can be parametrised on
what extensions to recognise.
haskell-src-exts-1.1.4 follows version 1.1.3 in being a mostly
experimental release. From a PVP perspective, the version number
indicates that no incompatible changes have been made to the *stable*
portion of the package, i.e. anything that doesn't contain Annotated
in its module name. The experimental stuff in
Language.Haskell.Annotated{.*} has changed quite a lot, but those of
you who depend on it already must obviously know what you're doing.
;-)
haskell-src-exts-1.1.4:
===
* For the stable part, the only new thing in haskell-src-exts-1.1.4 is
a bug fix that allows declaration headers surrounded by parentheses to
be parsed, e.g. data (a : b) =
* For the experimental part, the new and cool feature is a full
exact-printer, allowing full round-tripping of parsing plus printing.
In other words, using the parser and the exact-printer in conjunction
gives the same result back: exactPrint . parse == id . (Well, that's
half a lie since you need to use parseWithComments and some uncurrying
if you want to so easily compose, but that's the gist of it anyway.
:-))
* There have also been a number of further changes to the (annotated)
AST to allow it to retain enough source information to allow for said
exact-printing. In particular there have been changes to the way
contexts and declaration heads are treated, and literals have been
embellished to remember just how they were given (e.g. did we use 0xFF
or 255? \BEL or \a?).
* With a few small caveats, the round-tripping works over the full
(alas somewhat small) test suite that comes with (the darcs version
of) haskell-src-exts:
- Trailing whitespace on a line is not retained. (The test suite
uses reverse . dropWhile (isSpace) . reverse on each line to disregard
that issue.)
- Tab characters in the source are converted to (8) spaces (except
when they appear inside comments or literals). (The test suite doesn't
contain tabs.)
- Exact specification of literals is only remembered for literals
used as literals :-). What I mean is, source literals appearing in
other positions in the source than as Haskell literals will be
converted to a basic form. E.g. 'infixl 0x02 %%' will become 'infixl 2
%%'. Apart from infix declarations (tell me you never considered
writing them that way!) this mostly matters for various pragmas.
- Parentheses used around the function symbol in a function
declaration will not be remembered (I can't figure out how to make a
non-outrageous change to the AST to cope with them). E.g. '(foo a) b =
...' will be printed as 'foo a b = ...'. If anyone has an idea for a
neat (or at least non-outrageous) AST fix that could handle these
cases, drop me a line.
- Literate source files are not handled by the exact-printer (can't
re-literate them).
Please, help me test this on your source code! If you grab a darcs
version of the package from the repository, you can put any and all
source files you want to test in the haskell-src-exts/Test/examples
directory and then just run 'cabal test'. Please report any failing
cases to my trac! :-)
Cheers and Happy Haskelling,
/Niklas
___
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] Re: DDC compiler and effects; better than Haskell?
I forgot about links. In that case, consider: getUniqueFilesInDirRecursive. Attacking irrelevant details in an argument is often called a strawman attack. Such attacks are pointless because they do not address the real substance of the issue. My example is easily modified to avoid the issues you raise. Consider the fact that many file-based operations _can and are parallelized manually by developers_. The challenge for next generation language and effect system designers is to figure out _how_ such operations can be automatically parallelized, given sufficient constraints, high-level constructs, and a powerful effect system. Saying, I don't know exactly how it will look, is quite a bit different from saying It can't be done. I claim the former. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Aug 16, 2009, at 12:38 AM, Artem V. Andreev wrote: John A. De Goes j...@n-brain.net writes: On Aug 15, 2009, at 6:36 AM, Jason Dusek wrote: 2009/08/14 John A. De Goes j...@n-brain.net: Hmmm, my point (perhaps I wasn't clear), is that different effects have different commutability properties. In the case of a file system, you can commute two sequential reads from two different files. I think this is a bad example -- it's not something that's safe in general and discredits your idea. How would the compiler even know that two files are not actually the same file? I don't think the file system is the best example. However, I do think it's a reasonable one. Let's say the type of the function getFilesInDir is annotated in such a way as to tell the effect system that every file in the returned array is unique. Further, let's say the type of the function makeNewTempFile is annotated in such a way as to tell the effect system that the function will succeed in creating a new temp file with a name unique from any other existing file. Sorry, but this example is ridiculuous. While file *names* in this case might be reasonably assumed to be unique, the *files* themselves may not. Any modern filesystem does support file aliasing, and usually several forms thereof. And what does makeNewTempFile function do? Does it create a new file like POSIX mktemp() and return its name, or does it rather behave as POSIX mkstemp()? The first case is a well known security hole, and the second case does not, as it seems to me, fit well into the rest of your reasoning. However, let's consider further file system tree traversal. In some cases you might not care, whether some of the directories you descend into are actually the same directory, so your proposed optimization would be `safe'. However, in other cases sequential traversal would work, while a parallelized version would not, unless special additional measures are taken. E.g. consider a case of a build system. It traverses a source tree, finds sources files and if corresponding object files are non-existent or outdated, does something to regenerate them. Now if you have a directory that's actually a link to another directory, and you do sequential traversal, everything is fine: you descend into the directory the first time, build everything there and when you descend into it the second time, there's just nothing to do. If you do parallel traversal, you may well end up in the situation where two threads check simultaneously for an object file, discover it's outdated and run two build processes simultaneously, with the most likely effect of corrupted object file. Then if you write a recursive function that loops through all files in a directory, and for each file, it parses and compiles the file into a new temp file, then a sufficiently sophisticated compiler should be able to safely transform the recursion into parallel parsing and compilation -- in a way that's provably correct, assuming the original program was correct. The promise of a language with a purely functional part and a powerful effect system for everything else is very great. And very important in the massively concurrent world we are entering. Well, yes -- which sounds like, there are no guarantees in general. Something that works half the time leaves you with two responsibilities -- the old responsibility of the work you did when you didn't have it and the new responsibility of knowing when it applies and when it doesn't. In the other thread, I brought up the example of buffering reads. Library authors make the decision to buffer for one reason: because if some other program is messing with the data, you're screwed no matter what. And yeah, they might be screwing with the data in just the way you need it to be screwed with, (Sebastian), in which case my advice is use C and hope for the best. :-) Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101
Re: [Haskell-cafe] Re: DDC compiler and effects; better than Haskell?
I chose this example specifically because parsing/compiling is not IO- bound. Many build systems today achieve multi-core scaling by parallelizing all the phases: parsing, semantic analysis, and compilation. Your question is a good one and one we face already in auto- parallelization of purely functional code: how do you know when the cost of doing something in another thread is overwhelmed by the benefit? I think JIT compilation provides the ultimate answer to these types of questions, because you can make guesses, and if you get them wrong, simply try again. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Aug 16, 2009, at 2:46 AM, Marcin Kosiba wrote: Hi, IMHO, provided with a flexible effect system, the decision on how to do read/write operations on files is a matter of libraries. But I'd like to ask another question: is the effects system you're discussing now really capable of providing significant performance improvements in case of file I/O? Even if we assume some consistency model and transform one correct program to another one -- how do you estimate efficiency without knowledge of physical media characteristics? I kinda see how this could be used to optimize different kinds of media access (reordering socket/ file operations or even running some of those in parallel), but I don't see how can we benefit from reordering writes to the same media. Another thing is that not every kind of r/w operation requires the same consistency model -- like when I'm writing a backup for later use I only care about my writes being in the same order. I imagine that such an effect system could help write software for CC-NUMA architectures or shared-memory distributed systems. -- Thanks! Marcin Kosiba ___ 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: DDC compiler and effects; better than Haskell? (was Re: [Haskell-cafe] unsafeDestructiveAssign?)
On Aug 15, 2009, at 5:32 PM, Sebastian Sylvan wrote: On Sun, Aug 16, 2009 at 12:18 AM, John A. De Goes j...@n-brain.net wrote: You must think I'm arguing for some kind of low-level analog of C, augmented with an effect system. I'm not. You can't do that. No, I don't. I think you're arguing for making access to mutable state commutative. Are you not? There are many cases when mutation to state _is_ commutative. I can't argue that certain operations are _always_ commutative without talking about the language. Pretend I'm arguing for a mostly functional language and effect system that maximize the opportunities for parallelizing code. I'm not saying you shouldn't parallelise them in very specific circumstances *where it's safe*, I'm just saying that you shouldn't assume that it's safe unless you know it is. If you want to do a transformation that's unsafe in general, but safe in a specific circumstance, then of course, go ahead! To my reading it seems like you're arguing that memory/file access should *always* be considered commutative though, which is what I'm objecting too. In the right language, many times of memory (and possibly file) operations _always_ commute. In the wrong language, they _sometimes_ commute or _never_ provably commute. I'm not arguing for the assumption in any language where it is false. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: DDC compiler and effects; better than Haskell? (was Re: [Haskell-cafe] unsafeDestructiveAssign?)
In the presence of _uncontrolled concurrency_, you are correct, but uncontrolled concurrency is a failed paradigm littered with defective software. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Aug 16, 2009, at 5:32 PM, Richard O'Keefe wrote: On Aug 15, 2009, at 2:55 PM, John A. De Goes wrote: If you don't like the file system, consider mutable memory. An effect system will tell me I can safely update two pieces of non- overlapping, contiguous memory concurrently, even in different threads if the complexity so justifies it. The IO monad is a poor man's solution to the problem of effects. In the presence of out-of-order memory writes, write buffers, caches, c, I'm not going to contradict you, but it certainly isn't as _obvious_ as it used to be. I've come across an experimental microprocessor where I _think_ it isn't safe if you have +- data 1 | data 2 ++ cache line whether that's so on any other processor is beyond my expertise. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: DDC compiler and effects; better than Haskell? (was Re: [Haskell-cafe] unsafeDestructiveAssign?)
On Aug 14, 2009, at 9:07 PM, Sebastian Sylvan wrote: That's a separate issue. The problem is that if you *do* depend on outside interference, then the sequence of operations matters. You're example is highly contrived. Were I designing an effect system, I would not design for programs that require outside interference through a medium as uncontrolled as the file system, because (1) if there are applications requiring such measures, they are few and far between, and (2) you cannot make any guarantees about the correctness of programs depending on interference through an uncontrolled medium. Effect system optimizations are about taking programs that are correct, and transforming them to faster but equivalent programs that are still correct. That said, your reasoning precludes the use of file read buffering, and other similar operations that are routinely done. It's only an illusion that such programs are safe, with or without transformation of sequential read operations. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: DDC compiler and effects; better than Haskell? (was Re: [Haskell-cafe] unsafeDestructiveAssign?)
On Aug 14, 2009, at 9:34 PM, Sebastian Sylvan wrote: On Sat, Aug 15, 2009 at 3:55 AM, John A. De Goes j...@n-brain.net wrote: If you don't like the file system, consider mutable memory. An effect system will tell me I can safely update two pieces of non- overlapping, contiguous memory concurrently, even in different threads if the complexity so justifies it. I'd like to point out that this relaxation of sequencing for memory operations is already in effect in C on many CPUs. Even though you write things sequentially, it doesn't actually happen sequentially unless you explicitly say so with memory barriers. This causes massive head-aches and horrible bugs that are almost impossible to track down whenever you actually do depend on the order (usually in multi-threading scenarios, e.g. lockless data structures). That's because C has no effect system and is too low-level for an effect system. That's no argument against one in a high-level language similar in syntax to Haskell. The point is, the safer option is to enforce a sequential model (like Haskell does), since that way you can always rely on ordering even if you don't even realise you need to, and there's plenty of practical experience indicating that the other option (explicit barriers to indicate when something isn't commutative) is sheer madness. Your point about safety in C has no relation to safety in a functional language with a sophisticated effect system. Haskell enforces a sequential model not because it's safer (it's NOT), but because it's simpler and because it's the best Haskell monads can do. Unfortunately, it doesn't fly in a world with dozens of cores. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: DDC compiler and effects; better than Haskell? (was Re: [Haskell-cafe] unsafeDestructiveAssign?)
On Aug 15, 2009, at 6:36 AM, Jason Dusek wrote: 2009/08/14 John A. De Goes j...@n-brain.net: Hmmm, my point (perhaps I wasn't clear), is that different effects have different commutability properties. In the case of a file system, you can commute two sequential reads from two different files. I think this is a bad example -- it's not something that's safe in general and discredits your idea. How would the compiler even know that two files are not actually the same file? I don't think the file system is the best example. However, I do think it's a reasonable one. Let's say the type of the function getFilesInDir is annotated in such a way as to tell the effect system that every file in the returned array is unique. Further, let's say the type of the function makeNewTempFile is annotated in such a way as to tell the effect system that the function will succeed in creating a new temp file with a name unique from any other existing file. Then if you write a recursive function that loops through all files in a directory, and for each file, it parses and compiles the file into a new temp file, then a sufficiently sophisticated compiler should be able to safely transform the recursion into parallel parsing and compilation -- in a way that's provably correct, assuming the original program was correct. The promise of a language with a purely functional part and a powerful effect system for everything else is very great. And very important in the massively concurrent world we are entering. Well, yes -- which sounds like, there are no guarantees in general. Something that works half the time leaves you with two responsibilities -- the old responsibility of the work you did when you didn't have it and the new responsibility of knowing when it applies and when it doesn't. In the other thread, I brought up the example of buffering reads. Library authors make the decision to buffer for one reason: because if some other program is messing with the data, you're screwed no matter what. And yeah, they might be screwing with the data in just the way you need it to be screwed with, (Sebastian), in which case my advice is use C and hope for the best. :-) Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: DDC compiler and effects; better than Haskell? (was Re: [Haskell-cafe] unsafeDestructiveAssign?)
On Aug 15, 2009, at 4:59 PM, Sebastian Sylvan wrote: Your point about safety in C has no relation to safety in a functional language with a sophisticated effect system. I'm sorry, but I think it does. You're advocating that modifications to mutable state shouldn't have sequential semantics, You must think I'm arguing for some kind of low-level analog of C, augmented with an effect system. I'm not. You can't do that. To maximize the potential for optimization, you need a high-level language, mostly functional, with a very sophisticated and carefully controlled effects system for expressing imperative actions. If you have threads and shared mutable state, then you might require that any access to shared state be done through an atomic block (STM). The type system would encode if mutable variables can be shared between threads, and if so, the compiler would mandate they be accessed from inside an atomic block. In such conditions, multiple sequential writes can be safely parallelized, in addition to a host of other optimizations. I'm pointing out that this is the case today in C on many CPUs and it's a royal pain to work with in practice (causing many almost- impossible-to-debug crashes). I would not want functional languages to adopt something that's proven to be insanity-inducingly difficult to use. Please don't ever bring up C again. You can't do anything interesting in C. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: DDC compiler and effects; better than Haskell? (was Re: [Haskell-cafe] unsafeDestructiveAssign?)
Hmmm, my point (perhaps I wasn't clear), is that different effects have different commutability properties. In the case of a file system, you can commute two sequential reads from two different files. This has no effect on the result of the computation, assuming no interference from other programs -- and if there _is_ interference from other programs, then guarantees go out the window, _with or without_ commuting. Monads are an insufficient structure to capture the fine semantics of effects. Something more powerful is needed. And in general, the way effects combine and commute is quite complicated and needs to be baked into the effect system, rather than being the responsibility of a lowly developer. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Aug 13, 2009, at 12:24 PM, Sebastian Sylvan wrote: On Thu, Aug 13, 2009 at 2:19 PM, John A. De Goes j...@n-brain.net wrote: What if you have another program, written in C or something, that monitors a file for changes, and if so changes the contents of another file? Surely to catch that you must mark *all* file system access as interefering? Even worse, another program could monitor the state of a file and conditionally disable thet network driver, now file access interferes with network access. A compiler or runtime system can't know about these kinds of things -- unless perhaps you push the effect system into the operating system (interesting idea). The best you can do is ensure the program itself is correct in the absence of interference from other programs I think the best you can do is make sure any code which is vulnerable to such interference won't be subject to unsafe transformations (like changing the order of evaluation). So I do think pretty much anything that relies on the outside world needs to go into one big effects category so the compiler/runtime will stay out and let the programmer explicitly define the ordering of those operations, precisely because the compiler has no way of knowing anything about what kind of assumptions are in effect. -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: DDC compiler and effects; better than Haskell? (was Re: [Haskell-cafe] unsafeDestructiveAssign?)
On Aug 14, 2009, at 8:21 PM, Sebastian Sylvan wrote: But you can't! I can easily envisage a scenario where there's a link between two pieces of data in two different files, where it's okay if the data in file A is newer (in a versioning sense, not a timestamp sense) than the corresponding data in file B, but the opposite doesn't hold. So if you have another program writing that data it will write first to A, and then to B. The program reading this *must* then read the files in the correct order (B then A, to ensure the data from A is always newer or at the same version as the data in B). That's nonsense. Because what happens if your program reads A while the other program is writing to A, or reads B just after the other program has written to A, but before it has written to B? As I said before, you cannot make any guarantees in the presence of interference, _with or without_ commuting. So any sensible effects system will assume no interference (perhaps with unsafeXXX functions for when you're OK with shooting yourself in the foot). Anytime you talk to the outside world, there may be implicit ordering that you need to respect, so I really think that needs to be serialized. Of course, there may be things in the IO monad that doesn't talk to the outside world that could be commutative. If you don't like the file system, consider mutable memory. An effect system will tell me I can safely update two pieces of non-overlapping, contiguous memory concurrently, even in different threads if the complexity so justifies it. The IO monad is a poor man's solution to the problem of effects. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cleaner networking API - network-fancy
Thank goodness for a cleaner networking API. I almost chose Haskell's socket API as an example of what _not_ to do in my series on Good API Design (http://jdegoes.squarespace.com/journal/2009/5/11/good-api-design-part-3.html ). Ended up going with Java though. :-) Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Aug 13, 2009, at 2:14 AM, Taru Karttunen wrote: Hello network-fancy offers a cleaner API to networking facilities in Haskell. It supports high-level operations on tcp, udp and unix sockets. I would like some feedback on the API http://hackage.haskell.org/packages/archive/network-fancy/0.1.4/doc/html/Network-Fancy.html In particular: * Does the type of the server function in dgramServer make sense? or would (packet - Address - (packet - IO ()) - IO ()) be better? * Does the StringLike class make sense? * Any other suggestions? - Taru Karttunen ___ 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: DDC compiler and effects; better than Haskell? (was Re: [Haskell-cafe] unsafeDestructiveAssign?)
What if you have another program, written in C or something, that monitors a file for changes, and if so changes the contents of another file? Surely to catch that you must mark *all* file system access as interefering? Even worse, another program could monitor the state of a file and conditionally disable thet network driver, now file access interferes with network access. A compiler or runtime system can't know about these kinds of things -- unless perhaps you push the effect system into the operating system (interesting idea). The best you can do is ensure the program itself is correct in the absence of interference from other programs, but there's no way to obtain a guarantee in the presence of interference. Either with an effect system, or without (think of all the sequential imperative code that gets broken when other programs concurrently tamper with the file system or networking, etc.). Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Aug 13, 2009, at 2:42 AM, Sebastian Sylvan wrote: On Thu, Aug 13, 2009 at 4:56 AM, John A. De Goes j...@n-brain.net wrote: The next step is to distinguish between reading file A and reading file B, between reading file A and writing file A, between reading one part of file A and writing another part of file A, etc. When the effect system can carry that kind of information, and not just for files, but network, memory, etc., then you'll be able to do some extremely powerful parallelization optimization. What if you have another program, written in C or something, that monitors a file for changes, and if so changes the contents of another file? Surely to catch that you must mark *all* file system access as interefering? Even worse, another program could monitor the state of a file and conditionally disable thet network driver, now file access interferes with network access. -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: DDC compiler and effects; better than Haskell? (was Re: [Haskell-cafe] unsafeDestructiveAssign?)
Hmmm, bad example. Assume memory instead. That said, reordering/ parallelization of *certain combinations of* writes/reads to independent files under whole program analysis is no less safe than sequential writes/reads. It just feels less safe, but the one thing that will screw both up is interference from outside programs. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Aug 13, 2009, at 3:45 AM, Jason Dusek wrote: 2009/08/12 John A. De Goes j...@n-brain.net: The next step is to distinguish between reading file A and reading file B, between reading file A and writing file A, between reading one part of file A and writing another part of file A, etc. When the effect system can carry that kind of information, and not just for files, but network, memory, etc., then you'll be able to do some extremely powerful parallelization optimization. I am challenged to imagine optimizations that would be safe in the case of File I/O. -- Jason Dusek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: DDC compiler and effects; better than Haskell? (was Re: [Haskell-cafe] unsafeDestructiveAssign?)
On Aug 13, 2009, at 4:09 AM, Alberto G. Corona wrote: Maybe, in Haskell, the coarse IO monad can be divided in smaller monads as well I don't even want to imagine how that would obfuscate otherwise straightforward looking monadic code. The root problem is that monads don't capture enough information on the nature of effects, which limits composability. What's needed is something richer, which gives the compiler enough information to do all those things that make life easy for the developer, whilst maximizing the performance of the application. DDC is an interesting experiment in that direction. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: DDC compiler and effects; better than Haskell? (was Re: [Haskell-cafe] unsafeDestructiveAssign?)
On Aug 12, 2009, at 7:34 AM, Derek Elkins wrote: Again, it is purity, not laziness, that allows compositional reasoning. Effects destroy compositional reasoning in a strict language just as much. Yes, but that's just as much true in the IO monad as in effectful code in DDC. I think the point is that a functional language with a built- in effect system that captures the nature of effects is pretty damn cool and eliminates a lot of boilerplate. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: DDC compiler and effects; better than Haskell? (was Re: [Haskell-cafe] unsafeDestructiveAssign?)
So what, because effect systems might not eliminate *all* boilerplate, you'd rather use boilerplate 100% of the time? :-) Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Aug 12, 2009, at 3:28 PM, Dan Doel wrote: On Wednesday 12 August 2009 10:12:14 am John A. De Goes wrote: I think the point is that a functional language with a built- in effect system that captures the nature of effects is pretty damn cool and eliminates a lot of boilerplate. It's definitely an interesting direction (possibly even the right one in the long run), but it's not without its faults currently (unless things have changed since I looked at it). For instance: what effects does disciple support? Mutation and IO? What if I want non-determinism, or continuations, etc.? How do I as a user add those effects to the effect system, and specify how they should interact with the other effects? As far as I know, there aren't yet any provisions for this, so presumably you'll end up with effect system for effects supported by the compiler, and monads for effects you're writing yourself. By contrast, monad transformers (for one) let you do the above defining of new effects, and specifying how they interact (although they're certainly neither perfect, nor completely satisfying theoretically). Someone will probably eventually create (or already has, and I don't know about it) an extensible effect system that would put this objection to rest. Until then, you're dealing in trade offs. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: DDC compiler and effects; better than Haskell? (was Re: [Haskell-cafe] unsafeDestructiveAssign?)
Fair enough, but keep in mind an effect system does more than just eliminate boilerplate: it provides richer information on the precise nature of the interaction of a function with the real world. With the right insight, you can reorder and parallelize all kinds of effectful computations. Something that dumb monads can't provide. I haven't played with DDC, but I do believe some new FPL with a powerful effect system is going to take off in the next 5 years. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Aug 12, 2009, at 8:13 PM, Dan Doel wrote: On Wednesday 12 August 2009 9:27:30 pm John A. De Goes wrote: So what, because effect systems might not eliminate *all* boilerplate, you'd rather use boilerplate 100% of the time? :-) For most of my Haskell programs, the majority of the program is not made up of straight IO or ST functions, so how much boilerplate is it really eliminating? And since all the fooM functions have to exist for all the other monads, how much more boilerplate is it really to use them for IO and ST as well? Off hand, I'd say I don't write foo and fooM versions of functions much in actual programs, either. Such duplication goes into libraries, and that would be the case for Disciple as well (until there's a way to extend the effect system outside the compiler). So it's more of effect systems eliminate 2% of my boilerplate; who (currently) cares? And is it worth having situations like 'you use monads for these effects, and the effect system for these other effects' in the language to do so? But, as I said, it's not that I don't think it's a fruitful area of research, I just don't think it's going to yield significantly nicer code than Haskell _yet_. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: DDC compiler and effects; better than Haskell? (was Re: [Haskell-cafe] unsafeDestructiveAssign?)
The next step is to distinguish between reading file A and reading file B, between reading file A and writing file A, between reading one part of file A and writing another part of file A, etc. When the effect system can carry that kind of information, and not just for files, but network, memory, etc., then you'll be able to do some extremely powerful parallelization optimization. But for now providing course grained information on the class to which an effect belongs is pretty interesting in its own right. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Aug 12, 2009, at 9:41 PM, Ben Lippmeier wrote: Dan Doel wrote: For instance: what effects does disciple support? Mutation and IO? You can create your own top-level effects which interfere will all others, for example: effect !Network; effect !File; readFile :: String -(!e) String :- !e = !File Now any function that calls readFile will also have a !File effect. What if I want non-determinism, or continuations, etc.? How do I as a user add those effects to the effect system, and specify how they should interact with the other effects? As far as I know, there aren't yet any provisions for this, so presumably you'll end up with effect system for effects supported by the compiler, and monads for effects you're writing yourself. Yep. In Disciple, a computation has an effect if its evaluation cannot safely be reordered with others having the same effect. That is, computations have effects if they might interfere with others. One of the goals of the work has been to perform compiler optimisations without having to use IO-monad style state threading. IO is very coarse grained, and using the IO monad for everything tends to introduce more data-dependencies than strictly needed, which limits what optimisations you can do. Non-determinism and continuations are tricker things than the simple notion of effects-as-interference, which I haven't got a good solution for. Ben. ___ 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] Re: Thinking about what's missing in our library coverage
Tom is exactly right here. GPL is the kiss of death in the commercial world. Haskell Platform exists in part to encourage industry use of Haskell -- and to encourage braindead use of blessed libraries. GPL libraries have no place in HP. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Aug 5, 2009, at 9:03 AM, Tom Tobin wrote: On Wed, Aug 5, 2009 at 10:46 AM, Colin Paul Adamsco...@colina.demon.co.uk wrote: Tom == Tom Tobin korp...@korpios.com writes: This can surely be tackled by cabal, as it already has the license information. Tom I don't see this as a real solution; why would a package be It should be done anyway, irrespective of the platform. Yes, that would be handy option for cabal-install in general. Tom added to the platform in the first place if a large Tom proportion of developers couldn't make use of it? Anyone can make use of it. You may choose not to (or your boss may choose for you), but that doesn't mean you can't. The benefit of a standard library is that you can say I need a library to handle X and if a library addressing X is in the standard library, you're set. If you then need to worry about the GPL — and this is a reality that can't be written off as a mere choice — why bother with the platform in the first place? Non-GPL developers would be better off sticking with hackage in that case. ___ 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] Proposal: TypeDirectedNameResolution
I've spoken in favor of this many times before. But there are many who think, Every function you write should have a unique name. Talk about needless clutter. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Jul 27, 2009, at 10:29 AM, Cale Gibbard wrote: What do people think of this idea? Personally, it really annoys me whenever I'm forced to give explicit module qualifications, and I think this would really help. It would also subsume the DisambiguateRecordFields extension rather handily. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell on JVM
JVM 7 has tail calls, and if you don't want to wait for that, goto works perfectly well for self-recursive functions. Other techniques can deal with mutual recursion, albeit at the cost of performance. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Jun 26, 2009, at 6:26 AM, Maarten Hazewinkel wrote: On 26 Jun 2009, at 14:09, Timo B. Hübel wrote: And here comes my question: If there is anybody with proper knowledge about this issue, I would really like to know what are those things that are missing? For example, Clojure lacks proper tail recrusion optimization due to some missing functionality in the JVM. But does anybody know the details? Basically, the JVM lacks a native ability to do tail calls. It does not have an instruction to remove/replace a stack frame without executing an actual return to the calling method/function. With the heavy use of recursion in functional programs, this is an important feature in a language implementation to avoid stack overflows. Some language implementations (Scala) can do partial workarounds by turning the generated code into a loop in the compiler, but this is frequently limited to only deal with self-recursive calls, and does not deal with the general case (X-calls-Y-calls-Z-calls-X...), which a proper implementation of tail-calls at the JVM level would allow. At the JIT level (below the JVM spec level) some implementations may actually do the tail call optimization anyway, but this is beyond the control of a language implementation, and would result in a situation where the behaviour of your program depends on particular implementations/versions/parameters of the JVM running it. That is something to be avoided if possible. Maarten Hazewinkel maarten.hazewin...@gmail.com ___ 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] Haskell on JVM
I don't have a source, but I know tail calls have been implemented (in a patch) and tested, and at the JVM Summit everyone was saying this was definitely going to be released in JVM 7. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Jun 26, 2009, at 11:27 AM, Claus Reinke wrote: JVM 7 has tail calls, Source, please? JSR-292 seems the most likely candidate so far, and its draft doesn't seem to mention tail calls yet. As of March this year, the people working on tail calls for mlvm [1], which seems to be the experimentation ground for this, did not seem to expect any fast route: http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-March/000405.html There have been years of rumours and plans, so it would be nice to have concrete details, before any fp-on-jvm implementation design starts to rely on this. Claus [1] http://openjdk.java.net/projects/mlvm/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell on the iPhone
That sounds sufficient -- basically, just tell the sponsored developer where to look to get started, give him a rough idea of what needs to be done, and let him sort out the rest. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Jun 24, 2009, at 10:00 AM, Simon Peyton-Jones wrote: Advice, yes; leadership, no. [“guidance” is ambiguous between those two!] Simon From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org ] On Behalf Of John A. De Goes Sent: 23 June 2009 15:24 To: Simon Peyton-Jones; Haskell Cafe Subject: Re: [Haskell-cafe] Haskell on the iPhone How about setting up some sort of Summer of Code-type project, where companies can pledge dollars toward a certain goal, which will cover the cost of the work? Is there someone at GHC HQ who could provide guidance to a sponsored developer working on getting additional targets into HEAD? Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Jun 23, 2009, at 8:16 AM, Simon Peyton-Jones wrote: Good news about the iPhone port! There seems to be quite a bit more interest now in supporting platforms other than win/*nix on x86 these days*. Maybe now there will be sufficient motivation to make the fundamental changes required. Caveat: I have absolutely no idea of the scope or complexity of said changes. I will look through the LambdaVM code (and iPwn when available) to get an idea. There is definitely an opportunity here for someone to make an impact. There is no reason in principle why Haskell can’t run on a JVM or .net or other platform. But it’s not just a simple matter of absorbing some patch or other. Here’s a summary I wrote a little while ago: http://haskell.org/haskellwiki/GHC:FAQ#Why_isn.27t_GHC_available_for_.NET_or_on_the_JVM.3F The short summary is: · There is interesting design work to do; and then interesting engineering work to make it a reality. · We (at GHC HQ) would love to see that happen, but are not likely to drive it. · If someone, or a small group, wanted to take up the cudgels and work on it, we’d be happy to advise. · We’d certainly consider folding the results into the HEAD, provided the author(s) are willing to maintain it, and we feel that the result is comprehensible and maintainable. · But another viable route might well be to use the GHC API, which means that the result wouldn’t be part of GHC at all, just a client of the API. That would make it much easier to distribute upgrades etc, just as a Cabal package. Simon From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org ] On Behalf Of Rick R Sent: 23 June 2009 14:53 To: Haskell Cafe Subject: Re: [Haskell-cafe] Haskell on the iPhone There seems to be quite a bit more interest now in supporting platforms other than win/*nix on x86 these days*. Maybe now there will be sufficient motivation to make the fundamental changes required. Caveat: I have absolutely no idea of the scope or complexity of said changes. I will look through the LambdaVM code (and iPwn when available) to get an idea. Perhaps we can devote a section of Haskell Wiki to generalizing Haskell for multiple targets? The industry has been clamoring for a unified solution to all of the mobile platforms out there. If Haskell can provide that, it would be a huge win for its popularity. * Thanks primarily to the iPhone and Android systems. I think currently iPhone is swaying the most votes but Android is due to be on a dozen phones and possibly even a netbook. (I have heard two announcements and one cancellation with regards to the netbooks). On Tue, Jun 23, 2009 at 8:34 AM, John A. De Goes j...@n-brain.net wrote: I have strong interest in Haskell on the JVM. Not for Android, however. Seems like every time this topic comes up, the consensus is that it's not easy to support new targets with GHC, but that work is underway to make such developments easier. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Jun 22, 2009, at 11:23 PM, Ryan Trinkle wrote: Rick, I know some work has been done on JVM - iirc, Don Stewart did some work back in the day, www.cse.unsw.edu.au/~pls/thesis/dons-thesis.ps.gz , but I'm not sure how comprehensive it is. Is anyone else interested in JVM-based Haskell targets? Ryan On Mon, Jun 22, 2009 at 20:42, Rick R rick.richard...@gmail.com wrote: This is definitely good news! So... who's doing the Android/JVM target? ;) On Mon, Jun 22, 2009 at 7:37 PM, Daniel Peebles pumpkin...@gmail.com wrote: How exciting! I fully support the creation of a new mailing list about iphone+haskell :) On Mon, Jun 22, 2009 at 6:30 PM, Ryan Trinkleryant5...@gmail.com
Re: [Haskell-cafe] Haskell on the iPhone
I have strong interest in Haskell on the JVM. Not for Android, however. Seems like every time this topic comes up, the consensus is that it's not easy to support new targets with GHC, but that work is underway to make such developments easier. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Jun 22, 2009, at 11:23 PM, Ryan Trinkle wrote: Rick, I know some work has been done on JVM - iirc, Don Stewart did some work back in the day, www.cse.unsw.edu.au/~pls/thesis/dons-thesis.ps.gz , but I'm not sure how comprehensive it is. Is anyone else interested in JVM-based Haskell targets? Ryan On Mon, Jun 22, 2009 at 20:42, Rick R rick.richard...@gmail.com wrote: This is definitely good news! So... who's doing the Android/JVM target? ;) On Mon, Jun 22, 2009 at 7:37 PM, Daniel Peebles pumpkin...@gmail.com wrote: How exciting! I fully support the creation of a new mailing list about iphone+haskell :) On Mon, Jun 22, 2009 at 6:30 PM, Ryan Trinkleryant5...@gmail.com wrote: Dear Haskellers, Recently, there's been a groundswell of activity in the Haskell community regarding the Haskell's use in developing iPhone games. The iPhone is a powerful, innovative platform (with a great monetization scheme, to boot), and it's not surprising that many of us would want to develop apps for it in our favorite language. I am proud to announce today that my company, iPwn Studios Inc., is currently preparing to release an open source patch to GHC that allows it to output binaries for iPhone OS. The patch will be released under a BSD license as soon as possible and hopefully integrated into the GHC main-line in the near future. As the first (to my knowledge) Haskell-based game studio, iPwn Studios is committed to giving back to the Haskell community through open source - contributing to a rising tide that lifts us all. I would like to take this opportunity to propose the creation of a haskell-iphone mailing list, so that all Haskellers working with the iPhone - whether for profit or for pleasure - can come together to make Haskell a force to be reckoned with in the burgeoning iPhone App marketplace. Best wishes, Ryan Trinkle President, iPwn Studios Inc. P.S.: If you wish to be involved in the preparation of the GHC patch or in the creation of iPwn Studios' first game, don't hesitate to contact me by email (ryant5...@gmail.com), AIM (RyanT5000), or IRC (RyanT5000 on irc.freenode.net). ___ 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 -- The greatest obstacle to discovering the shape of the earth, the continents, and the oceans was not ignorance but the illusion of knowledge. - Daniel J. Boorstin ___ 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell on the iPhone
How about setting up some sort of Summer of Code-type project, where companies can pledge dollars toward a certain goal, which will cover the cost of the work? Is there someone at GHC HQ who could provide guidance to a sponsored developer working on getting additional targets into HEAD? Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Jun 23, 2009, at 8:16 AM, Simon Peyton-Jones wrote: Good news about the iPhone port! There seems to be quite a bit more interest now in supporting platforms other than win/*nix on x86 these days*. Maybe now there will be sufficient motivation to make the fundamental changes required. Caveat: I have absolutely no idea of the scope or complexity of said changes. I will look through the LambdaVM code (and iPwn when available) to get an idea. There is definitely an opportunity here for someone to make an impact. There is no reason in principle why Haskell can’t run on a JVM or .net or other platform. But it’s not just a simple matter of absorbing some patch or other. Here’s a summary I wrote a little while ago: http://haskell.org/haskellwiki/GHC:FAQ#Why_isn.27t_GHC_available_for_.NET_or_on_the_JVM.3F The short summary is: · There is interesting design work to do; and then interesting engineering work to make it a reality. · We (at GHC HQ) would love to see that happen, but are not likely to drive it. · If someone, or a small group, wanted to take up the cudgels and work on it, we’d be happy to advise. · We’d certainly consider folding the results into the HEAD, provided the author(s) are willing to maintain it, and we feel that the result is comprehensible and maintainable. · But another viable route might well be to use the GHC API, which means that the result wouldn’t be part of GHC at all, just a client of the API. That would make it much easier to distribute upgrades etc, just as a Cabal package. Simon From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org ] On Behalf Of Rick R Sent: 23 June 2009 14:53 To: Haskell Cafe Subject: Re: [Haskell-cafe] Haskell on the iPhone There seems to be quite a bit more interest now in supporting platforms other than win/*nix on x86 these days*. Maybe now there will be sufficient motivation to make the fundamental changes required. Caveat: I have absolutely no idea of the scope or complexity of said changes. I will look through the LambdaVM code (and iPwn when available) to get an idea. Perhaps we can devote a section of Haskell Wiki to generalizing Haskell for multiple targets? The industry has been clamoring for a unified solution to all of the mobile platforms out there. If Haskell can provide that, it would be a huge win for its popularity. * Thanks primarily to the iPhone and Android systems. I think currently iPhone is swaying the most votes but Android is due to be on a dozen phones and possibly even a netbook. (I have heard two announcements and one cancellation with regards to the netbooks). On Tue, Jun 23, 2009 at 8:34 AM, John A. De Goes j...@n-brain.net wrote: I have strong interest in Haskell on the JVM. Not for Android, however. Seems like every time this topic comes up, the consensus is that it's not easy to support new targets with GHC, but that work is underway to make such developments easier. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Jun 22, 2009, at 11:23 PM, Ryan Trinkle wrote: Rick, I know some work has been done on JVM - iirc, Don Stewart did some work back in the day, www.cse.unsw.edu.au/~pls/thesis/dons-thesis.ps.gz , but I'm not sure how comprehensive it is. Is anyone else interested in JVM-based Haskell targets? Ryan On Mon, Jun 22, 2009 at 20:42, Rick R rick.richard...@gmail.com wrote: This is definitely good news! So... who's doing the Android/JVM target? ;) On Mon, Jun 22, 2009 at 7:37 PM, Daniel Peebles pumpkin...@gmail.com wrote: How exciting! I fully support the creation of a new mailing list about iphone+haskell :) On Mon, Jun 22, 2009 at 6:30 PM, Ryan Trinkleryant5...@gmail.com wrote: Dear Haskellers, Recently, there's been a groundswell of activity in the Haskell community regarding the Haskell's use in developing iPhone games. The iPhone is a powerful, innovative platform (with a great monetization scheme, to boot), and it's not surprising that many of us would want to develop apps for it in our favorite language. I am proud to announce today that my company, iPwn Studios Inc., is currently preparing to release an open source patch to GHC that allows it to output binaries for iPhone OS. The patch will be released under a BSD license as soon as possible and hopefully integrated into the GHC main-line in the near future
Re: [Haskell-cafe] Darcs as undo/redo system?
Una Merge does real-time merging and has per user undo. And it can do lots of stuff that seems darcs-like, though I don't know enough about darcs to say for sure (e.g. moving a user's own edits after other edits). http://www.n-brain.net/una_merge.html Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On May 8, 2009, at 1:35 PM, Jeremy Shaw wrote: At Fri, 8 May 2009 17:33:25 +0200, Peter Verswyvelen wrote: [1 multipart/alternative (7bit)] [1.1 text/plain; ISO-8859-1 (7bit)] If you work with a text editor like Microsoft Visual Studio (maybe also Eclipse, don't know), each text editor has its own undo/redo history. However, when you perform refactoring - like renaming a function - this becomes an undo/redo on multiple files together, so in a sense these changes are part of a global history. If you read this paper, you will find an undo system for a colloborative editor complete with a theory that looks like a primitive version of darcs patch theory (complete with the dreaded merge bug of darcs 1): Undoing actions in collaborative work: Framework and experience by Prakash and Knister http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.48.6443rep=rep1type=pdf You will probably find these papers informative as well: Recognizing creative needs in user interface design by Terry and Mynatt http://www.cc.gatech.edu/fce/ecl/projects/openEnded/pubs/creativeInterfaces-creativecog2002.pdf A Selective Undo Mechanism for Graphical User Interfaces Based On Command Objects (1994) by Thomas Berlage http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.31.755 Flexible Conflict Detection and Management In Collaborative Applications (1997) by Keith Edwards http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.49.5439 Undo Any Operation at Any Time in Group Editors (2000) by Chengzheng Sun http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.32.6266 And, of course, you can use citeseer to find more papers that reference those. - jeremy ___ 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] Haskell/JS -- better through typeclasses?
I can't speak for Jason, but for me, this is not very useful. I don't want to write in a Haskell DSL, I want to write in Haskell. And not the whole program, either, just the parts that really lend themselves to functional programming (parsers, numeric computations, code generators, various algorithms). Which means I need to be able to call Haskell functions from JavaScript. I'm not particularly concerned with non-strict evaluation, either. Strict is preferable wherever it would not alter the outcome. There is no good Haskell solution for this (though your own work in this area is clearly the best available). What I'd really like is something like SMLtoJS (possibly without the reactive library), but for Haskell. And that does not exist. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Apr 26, 2009, at 7:44 AM, Dimitry Golubovsky wrote: Jason and everybody interested, Please check out a package I recently (just by coincidence: I haven't seen this topic on the list until after I uploaded it) uploaded to Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/jsmw-0.1 This is a basic monadic interface to Javascript code generator (based on WebBits), providing sort of a macro (like in macro-assembler) facility. HJScript was used as a (sort of) prototype, but I chose slightly different notation for EDSL. From here, I think two directions may be taken: 1. Some techniques are described in the GRIN thesis [1] how to convert a Haskell core to monadic form. These may be explored for this case. 2. Similarly to how the Web Consortium defined interfaces to its components using IDL *, Haskell modules converted to Javascript may expose their interfaces same way, thus providing a basis for a reusable component-based approach. Any discussions and suggestions are welcome. From my own impressions, EDSL approach is better for interactive/AJAX parts of a Javascript application, as translation of non-strict evaluation (like it was done in the Yhc/Javascript project) just causes a lot of code generated, and does not improve the user interaction performance at all. For other (internal) components, translation from Haskell may be more appropriate, just to be able to reuse the existing libraries. One of experiments with Yhc involved a user-exposed form, and a parser to validate user's input. With this hybrid approach, the user interface part might be coded using an EDSL, and the parser could be translated from Haskell core. An IDL might be generated for the parser interface, thus making the parser module a reusable component. These are of course just thoughts and ideas for now. * See the DOM package: this is an auto-generated Haskel approximation of IDL specs provided for the basic DOM components. [1] http://www.cs.chalmers.se/~boquist/phd/index.html [2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/DOM-2.0.1 -- Dimitry Golubovsky Anywhere on the Web ___ 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] Haskell/JS -- better through typeclasses?
On Apr 26, 2009, at 10:18 AM, Jason Dusek wrote: This was what I was originally writing in about, yeah. However, thinking it over I realize there are some serious problems. We really do want to work with a restricted subset of Haskell that is more amenable to translation -- one with finite arrays and most every type translatable to JSON. For purposes of cross-platform development, it's important the subset be minimally restricted (at least in my case). I fear that requires us to know, statically, whether potentially infinite structures like lists are finite or infinite. I'm not sure about this but I suspect that's a major stumbling block. I think it's easy to determine if something is definitely finite (certainly any list passed into an exported Haskell function must be finite, since JS doesn't have infinite lists). Determining if something is definitely infinite is not as easy, but it might be sufficient to use lazy evaluation whenever there is a possibility that a structure might be infinite. Any function exported to JavaScript must return a finite list. Annotations would be another way of handling this. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell/JS -- better through typeclasses?
I'd like this functionality, as well, but it doesn't exist, at least for Haskell. If you don't need a 100% pure functional language, and don't need the bells and whistles of the Haskell type system, you might be interested in SML -- a purer relative of the more widely-known Ocaml. There's a tool for converting SML to JavaScript: http://www.itu.dk/people/mael/smltojs/ It allows you to export SML functions so they can be called by JavaScript. Moreover, it has a reactive library built in, does pretty decent optimization, lets you manipulate the DOM, and is up to version 4.3.5. Haskell doesn't have anything close! Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Apr 25, 2009, at 11:53 AM, Jason Dusek wrote: I'd like to be able to translate Haskell to JavaScript. Many Haskell/JS bridges provide libraries for writing complete JavaScript programs in Haskell; some of them even include jQuery. However, my goals are more limited -- I'd like to be able to take a Haskell module and turn it into a JavaScript object. For example, I'd like to write a nice parser in Haskell and then reuse it on the client side. No need to handle all the DOM events or implement multi-threading. Of course, the place to start is by reading the commentary. A little bit of browsing suggests some questions of strategy: . Maybe a new backend is not the right thing? All the backends seem to be for real computers with real instruction sets. . Is it better to just work on transforming Core into JS directly? It seems that External Core is still in limbo. . Some translations strike me as baffling in principle. For example, a value like `ones`: ones = 1 : ones We'd want to avoid most native JavaScript containers, it seems; however, we are then unable to leverage the speed of native containers. It's entirely possible that translating Haskell to JavaScript may turn out not to be the best idea; maybe it is better to have a type class for types (for example, `Parser Char`) to provide their own translators? The it would be straightforward to prevent translation of programs that use concurrency libs, native ops or `IO`. -- Jason Dusek ___ 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] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
On Apr 22, 2009, at 11:30 PM, Richard O'Keefe wrote: so any decision on what features to exclude from future versions of Haskell must necessarily look at publicly accessible source code. Wrong. There is no necessarily about it. People made decisions about what to deprecate in the Fortran and COBOL standards without looking at publicly accessible source code. I'm talking about the only rational way to do it. It's irrational for language maintainers to remove features that are widely used in publicly available source code, as such changes are detrimental to the success of the language. Thus, rational language maintainers will decide what features to exclude from future versions of Haskell by looking at publicly accessible source code. And the decision to remove n+k patterns from Haskell', wrong though I think it was, was NOT made on a nose-counting basis. Or if it was, there is not the slightest evidence of it in http://hackage.haskell.org/trac/haskell-prime/wiki/RemoveNPlusK Numerous people have contributed to that discussion, and the consensus is that too few people are using them to justify the feature. Indeed, in this very discussion, you are the only one advocating them. What does that tell you? It's also a straw man argument. Nobody says that. I certainly don't. What I DO say is that - MY code contains n+k Why should this matter? The contents of your code are not relevant to the future of Haskell. n = 1 is meaningless. Is there a simple way to download everything from Hackage? One would need to write a script to do this. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
Let's turn this around. You invest 4 months of your life coming out with your own experimental Haskell compiler designed to easily test new language features. Then a bunch of ungrateful wretches on Haskell Cafe demand that you stop distributing your compiler until you have full support for Haskell 98. :-) Do you think that's fair? Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Apr 23, 2009, at 3:18 AM, Jon Fairbairn wrote: John A. De Goes j...@n-brain.net writes: That's absurd. You have no way to access private source code, so any decision on what features to exclude from future versions of Haskell must necessarily look at publicly accessible source code. This is all entirely beside the point. The question is not whether n+k patterns should be in the language, it's whether an implementation of Haskell 98 should include them. The only alternative is to continuously add, and never remove, features from Haskell, even if no one (that we know) uses them. But we can remove them in future language versions. The point I was trying to make at the beginning of this subthread was that implementations should follow the definition, because having a core language (Haskell 98) that can be relied on is simpler and wastes less time than the alternative. -- Jón Fairbairn jon.fairba...@cl.cam.ac.uk http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2009-01-31) ___ 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] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
That's absurd. You have no way to access private source code, so any decision on what features to exclude from future versions of Haskell must necessarily look at publicly accessible source code. The only alternative is to continuously add, and never remove, features from Haskell, even if no one (that we know) uses them. Moreover, the odds that everyone who is using n + k patterns are doing so only in private is an untestable hypothesis (i.e. unscientific) and extremely unlikely to be true. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Apr 21, 2009, at 9:34 PM, Richard O'Keefe wrote: It *is* true that things that *are* used in the commonly available sources should continue to be supported in order to preserve the value of those commonly available sources. It is *not* true that things that are *not* used in the commonly available sources are therefore of no value and safely to be discarded. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Is 78 characters still a good option? Was: breaking too long lines
Another reason for the 80 character limit: some developers have very poor eyesight, which can be overcome with large monitors and large fonts. This won't work if you have to scroll the code. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Apr 22, 2009, at 8:32 AM, Achim Schneider wrote: Jason Dusek jason.du...@gmail.com wrote: Really, the whole thing makes me wish we had blasphemy laws. If any person, in speaking or in writing, shall indicate a preference for column widths other than 80 or indent characters other than spaces (`0x20`) they shall be compelled to present some science or be subject to imprisonment. I'll definitely add it to the list of questions should I ever conduct a job interview. Just to test how much backing people have for their zeal. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ 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] General function to count list elements?
Two functions are equal iff they have the same domain and range and the same outputs for the same inputs. Simple to state, but extremely difficult to implement in a useful way, and impossible to implement in a perfect way. If you had a compiler or algorithm capable of determining function equality, you could use it to prove or disprove arbitrary theorems in mathematics. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Apr 18, 2009, at 9:39 AM, Eugene Kirpichov wrote: Could you then provide an example of two functions that *are* equal, or, even better, a definition of equality for arbitrary functions? Since Haskell may be compiled into C, this must be a definition that is implementable in C. 2009/4/18 michael rice nowg...@yahoo.com: Though I haven't tried it out, it's trying to use my function to count functions. The first argument is the identity function. The second argument is a list of a different form of the identity function. Though the two identity functions, given the same input, would produce the same output, I doubt they would be equal. So my guess at an answer would be zero. Michael --- On Sat, 4/18/09, Eugene Kirpichov ekirpic...@gmail.com wrote: From: Eugene Kirpichov ekirpic...@gmail.com Subject: Re: [Haskell-cafe] General function to count list elements? To: michael rice nowg...@yahoo.com Cc: haskell-cafe@haskell.org Date: Saturday, April 18, 2009, 11:03 AM What should count (\x - x) (replicate 10 (\y - if 1==1 then y else undefined)) return? 2009/4/18 michael rice nowg...@yahoo.com: Is there a general function to count list elements. I'm trying this count :: a - [a] - Int count x ys = length (filter (== x) ys) with this error upon loading = [mich...@localhost ~]$ ghci count GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( count.hs, interpreted ) count.hs:2:29: Could not deduce (Eq a) from the context () arising from a use of `==' at count.hs:2:29-32 Possible fix: add (Eq a) to the context of the type signature for `count' In the first argument of `filter', namely `(== x)' In the first argument of `length', namely `(filter (== x) ys)' In the expression: length (filter (== x) ys) Failed, modules loaded: none. Prelude = Not sure what it's trying to tell me other than I need an (Eq a) somewhere. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Eugene Kirpichov Web IR developer, market.yandex.ru -- Eugene Kirpichov Web IR developer, market.yandex.ru ___ 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] Re: Hugs on iPhone
Go ahead sell your GPL application. I'll get your code, build the application, and sell it for less than half of what you're selling it for. How exactly will you make your money, then? When people say, You can't make commercial software with GPL code, they don't mean it's not legally possible to sell GPL code, only that it's not commercially viable. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Mar 24, 2009, at 1:27 AM, Jules Bean wrote: Rick R wrote: The agreement doesn't specifically prohibit the use of interpreters (just those than run external code). It also doesn't say anything about machine generated code. The only thing one would have to ensure is that the dependencies of JHC are all compiled in, or statically linked. Shared libs are disallowed in any app. If it has a runtime dependency on gcc (is there such a thing?) Then you would have to statically link it and therefore couldn't sell your application. (gotta love GPL) Not true. GPL doesn't forbid selling and never has. RMS used to make money selling emacs tapes. All it requires is that you accompany your sale either with a copy of the source code, or a promise to make source available. Posting the source on a public web site would meet this requirement. Does anything in the iPhone SDK forbid you from posting your source? ___ 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] Re: Hugs on iPhone
Like I said, go ahead and try that with an iPhone application. If the iPhone app is so buggy or complicated so as to require support, no one will buy it. If it's not, I'll make all the money by selling it for half the price you sell it for. In any case, the examples you mention involve companies selling the labors of others. Joe Schmoe who contributed patch #2345235 to fix a critical bug never sees a cent from RedHat. So your examples don't support your case as much as you seem to think. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Mar 24, 2009, at 6:58 AM, Karel Gardas wrote: John A. De Goes wrote: Go ahead sell your GPL application. I'll get your code, build the application, and sell it for less than half of what you're selling it for. How exactly will you make your money, then? Ask RedHat how they make money from RHEL while Oracle and CentOS are exact copies of it. Ask RedHat/JBoss how they make money from JBoss AS when all the source code is available in their repository. Probably, it's not only about the software anymore, but also about the service you get with the software subscription... Although I agree that this applies only to software which crossed some kind of complexity already (hence service is needed) and that majority of phone apps might not fall into this category yet especially if they are not tied to some kind of server based services. Karel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hugs on iPhone
Again, go ahead and write your GPL app -- i.e. put your money where your mouth is. After you spend a year developing some cool app, I'll take your code and sell it -- maybe under a different name, with different screenshots, and a different description. Or maybe I'll just list it in the free section so no one makes any money. You can't make money selling tapes of iPhone apps because no one wants tapes and iPhone apps come exclusively from the iPhone store (unless you're an iPhone developer). You simply can't make a living selling GPL software. If the software's complicated enough and you know your way around it, then you can sell support maintenance. However, those conditions doesn't apply to consumer software, because consumers don't want complicated software. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Mar 24, 2009, at 7:00 AM, Achim Schneider wrote: John A. De Goes j...@n-brain.net wrote: Go ahead sell your GPL application. I'll get your code, build the application, and sell it for less than half of what you're selling it for. I don't think you can go below 0.79 in the Apple store, and I guess you'll have a hard time convincing Apple to list your identical program alongside with the original version. How exactly will you make your money, then? Selling tapes, not software. Unless you invent something like the internet that gets rid of time needed write tapes and packageshipment costs, you're going to have a very, very hard time being cheaper than anybody else unless you live on a different continent, and an incredibly hard time financing the advertisement you need to place your product more prominently than RMS can do simply by being himself. When people say, You can't make commercial software with GPL code, they don't mean it's not legally possible to sell GPL code, only that it's not commercially viable. Oh, it is. Id is still selling Quake I data files, and you'll be surprised how much you're allowed to do since the GPL isn't the Affero GPL. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ 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] least fixed points above something
A JIT compiler can easily know. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Mar 19, 2009, at 10:29 AM, Neil Mitchell wrote: CSE is tricky and a potential space leak in general. I'd love it if the compiler could pick the best option, but I'm afraid its unlikely to know. On Thu, Mar 19, 2009 at 4:25 PM, Edsko de Vries devri...@cs.tcd.ie wrote: I always feel that the compiler should do such optimizations for me :) On 19 Mar 2009, at 16:21, Neil Mitchell wrote: I've used a similar function myself, but why write it in such a complicated way? How about lfp :: Eq a = (a - a) - a - a lfp f x | f x == x = x | otherwise = lfp f (f x) I've used a similar function too, but your version computes f x twice per iteration, I wrote mine as: fix :: Eq a = (a - a) - a - a fix f x = if x == x2 then x else fix f x2 where x2 = f x I find this fix much more useful than the standard fix. Thanks Neil ___ 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] DSLs with {in,}equalities
Workarounds for the lack of linguistic overloading. :-) Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Mar 3, 2009, at 12:52 AM, Lennart Augustsson wrote: I often hide the Prelude and import my own Prelude which reexports the old Prelude, but with these changes. It's still not ideal, by far. -- Lennart class Boolean b where false, true :: b (), (||) :: b - b - b not :: b - b instance Boolean Bool where false = False true = True () = (P.) (||) = (P.||) not = P.not class (Boolean b) = Eq a b where (==), (/=) :: a - a - b x /= y = not (x == y) instance (P.Eq a) = Eq a Bool where (==) = (P.==) (/=) = (P./=) class (Eq a b) = Ord a b where (), (=), (), (=) :: a - a - b instance (P.Ord a) = Ord a Bool where () = (P.) (=) = (P.=) () = (P.) (=) = (P.=) class (Boolean b) = Conditional a b where (?) :: b - (a, a) - a instance Conditional a Bool where c ? (t, e) = if c then t else e On Tue, Mar 3, 2009 at 4:13 AM, Andrew Hunter ahun...@cs.hmc.edu wrote: Several times now I've had to define an EDSL for working with (vaguely) numeric expressions. For stuff like 2*X+Y, this is easy, looking pretty much like: data Expr = Const Integer | Plus Expr Expr | Times Expr Expr instance Num Expr where fromInterger = Const (+) = Plus (*) = Times c. This lets me get a perfectly nice AST, which is what I want. When I want to be able to express and work with inequalities and equalities, this breaks. Suppose I want to write 2*X + Y 3. I either have to: a) Hide Prelude.() and define a simple that builds the AST term I want. b) Come up with a new symbol for it that doesn't look totally awful. Neither of these work decently well. Hiding Eq and Ord operators, which is what I effectively have to do for a), is pretty much a nonstarter--we'll have to use them too much for that to be practical. On the other hand, b) works...but is about as ugly as it gets. We have lots and lots of symbols that are already taken for important purposes that are syntactically near ,=,==, and the like: and and = for monads, for arrows, etc. There...are not good choices that I know of for the symbols that don't defeat the purpose of making a nice clean EDSL for expressions; I might as well use 3*X + Y `lessthan` 3, which is just not cool. Does anyone know of a good solution, here? Are there good substitutions for all the six operators that are important (,,=,=,==,/=), that are close enough to be pretty-looking but not used for other important modules? Better yet, though a little harder, is there a nice type trick I'm not thinking of? This works for Num methods but not for Ord methods because: (+) :: (Num a) = a - a - a () :: (Ord a) = a - a - Bool i.e. the return type of comparisons is totally fixed. I don't suppose there's a good way to...well, I don't know what the *right* answer is, but maybe define a new typeclass with a more flexible type for that lets both standard types return Bool and my expressions return Expr? Any good solution would be appreciated. Thanks, AHH ___ 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Left fold enumerator - a real pearl overlooked?
Lazy IO is a complete disaster for interactive IO, such as network and process IO. Moreover, it's somewhat of a failure even for non- interactive IO such as the use case you described, because it's very easy for partial evaluation to lead to unclosed files and lazy evaluation to lead to delayed resource acquisition. I can imagine a few use cases that might benefit from it, but the evidence suggests that most developers trying to solve real world problems work extra hard to get their programs working properly with lazy IO. Elsewhere, laziness can be a real boon, so I don't understand your question, Why have laziness in Haskell at all? Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Mar 2, 2009, at 6:03 PM, Henning Thielemann wrote: On Mon, 2 Mar 2009, John Lato wrote: Hello, I am not a super-geek (at least, not compared to others on this list), but I'll take a try at this anyway. The benefits of iteratees mostly depend on differences between lazy and strict IO (see ch. 7 of Real World Haskell for more on this). Maybe a good text for http://www.haskell.org/haskellwiki/Enumerator_and_iteratee ? While I think that the Iteratee pattern has benefits, I suspect that it can't be combined with regular lazy functions, e.g. of type [a] - [a]. Say I have a chain of functions: read a file, parse it into a tag soup, parse that into an XML tree, transform that tree, format that into a string, write that to a file, and all of these functions are written in a lazy way, which is currently considered good style, I can't use them in conjunction with iteratees. This means, almost all Haskell libraries have to be rewritten or extended from lazy style to iteratee style. The question for me is then: Why having laziness in Haskell at all? Or at least, why having laziness by default, why not having laziness annotation instead of strictness annotation. ___ 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] Re: base-4 + gtk2hs-0.10.0 licensing
The Mozilla Public License is superior to LGPL for this purpose: it still forces you to release any modifications, while clearly allowing bundling and commercial sales of software that includes MPL code. MPL is a good fit if you want to ensure improvements get contributed back to the community, but don't want to discourage commercial uses of the software. So if you've released LGPL software, please consider re-licensing it as MPL. Companies don't go near LGPL, except (in rare instances) for dynamically linked libraries (but many companies won't even do that). Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 26, 2009, at 1:17 AM, Ketil Malde wrote: Peter Hercek pher...@gmail.com writes: Relinking against newer Gtk2Hs versions might not work. You have the option of recompiling the new Gtk2Hs with the old GHC and relinking, don't you? I want to repeat what I’ve said earlier on this list: For Haskell, there is no real difference between LGPL and GPL, as far as I understand it. Of course there is a difference and a *significant* one. * A GPL library will force commercial users of the library to release their code under GPL. * An LGPL library will force commercial users to release their source code only to the users of their program (which already bought it) and only for the purpose of recompiling with a newer version of the LGPL library. Am I missing something? Yes. At least in my jurisdiction, the *intent* of the licensing matters. I think it is fair to say that the intent of the LGPL is maintaned as long as you redistribute any modifications you make to the LGPL library. An easy thing to do here would be to get a written statement from the author about the interpretation with regard to what you intend to do - like Duncan posted. If you don’t want to force the users of your library to use an open source license for their work then use BSD3 or a similar license for your library There is also a rather significant difference for open source software - if I use BSD, somebody might modify and ship closed versions of my library. If I use LGPL, somebody can combine it with other open source code, with licenses that may not be GPL-compatible. So I believe LGPL is less viral than GPL. This is just opinion, but if you wanted guarantees, you'd talk to a lawyer, and not post on a mailing list. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ 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] Re: Hoogle and Network.Socket
On Feb 25, 2009, at 7:49 PM, Achim Schneider wrote: John A. De Goes j...@n-brain.net wrote: The problem is that PL research is probably not going to stop evolving in our lifetimes. Yes, that research needs a venue, but why should it be Haskell? Haskell is a good language and it's time to start benefiting from the research that's already gone into it. That means some tradeoffs. Why shouldn't it be Haskell? More, why *can't* it be Haskell. Haskell is already constrained by backwards compatibility, which limits future directions. Partial functions and dependent typing do not seem to play well together, for instance. Moreover, look at the packages being uploaded to Hackage: they're almost all trying to do useful stuff. The direction of Haskell has already changed, and I don't see it reverting to its old course. Not really, look at e.g. type families, which give you much of the power dependently typed languages give you while saying nah, not yet to the question of how to deal with non-terminating typechecking. *Some*, not *much*, and there are dependently typed languages that have guaranteed terminating type checking. About the H' progress... It's hard to tell how many drops are needed to make a bucket overflow, especially if you've got no idea what the bucket looks like. What certainly isn't happening is people taking a house, trying to overflow a badly leaking bucket. As far as I know, H' was supposed to be completed many years ago. Likely, it won't be completed for many more years. H2 is probably more than a decade away, if it happens at all. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] statep haskell-lang [was: Re: Hoogle and Network.Socket]
On Feb 26, 2009, at 12:12 PM, Achim Schneider wrote: I think that arguing that Haskell is _obsolete_ because it isn't yet fully dependently typed is vastly mistaken. I never said it was obsolete. Far from it. But I did say that choices already made and codified into H98 have implications on the future evolution of Haskell, because Haskell is unlikely to deviate in ways that significantly break backward compatibility. One thing is for sure: All progress will be stopped dead if the community starts to listen to people who demand enterprise- readiness. What do you mean by progress? I noted before that there are tradeoffs. Constraining the evolution of the language in backward compatible ways leads to substantial improvements in tools, libraries, and the speed of compiled code. That's progress in several dimensions -- just not along the dimension of language. I seriously doubt that backwards compatibility will ever be broken to the point of non-inoperation, but I certainly expect -- and do, in some sense, hope -- it to be broken, to the point where you can't mix H98 and H' source because they are mutually incompatible, either in syntax, semantics, or both, as long as you can still comparably painlessly link them. We'll see. First we have to know what H' is going to look like, which is a long ways off. If your business is fine with that, you shouldn't have any problems. I can imagine a lot of companies currently using Haskell wouldn't be happy with freezing Haskell, at all: They don't mind updating their code to the state of the art. The problem with completely fluid languages is that they impose arbitrarily high costs on those who choose them. That's why companies prefer well-defined standards and strong backwards compatibility. And that's why such languages eventually die, from lack of innovation -- even if 40 years later there are still developers forced to maintain software written in them. An intermediate solution is providing a source-to-source translator that flawlessly converts older source code into newer source code. Add binary compatibility, and then the only real disadvantage in language evolution becomes retraining and tools. Which are both significant costs, to be sure, but not as significant as the former. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: statep haskell-lang [was: Re: Hoogle and Network.Socket]
Are you saying has been no progress since KR C in the number of libraries available to C programmers? And that C programmers still have to edit files with vi and compile and link by specifying all files on the command-line? You may disagree, but the evidence points in the opposite direction. There are tens of thousands of robust C libraries available to suit any particular programming need. Many of Haskell's own libraries are based on C versions. Tool support for the C language (not for some successor you might think would exist if the language continued evolving) can detect memory leaks, detect memory overwrites, apply dozens of automatic refactorings to C large-scale C programs, etc. Library and tool support for the C language is light years beyond Haskell. It wouldn't be there if we had been through 20 iterations of C each completely breaking backward compatibility. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 26, 2009, at 1:08 PM, Achim Schneider wrote: John A. De Goes j...@n-brain.net wrote: What do you mean by progress? I noted before that there are tradeoffs. Constraining the evolution of the language in backward compatible ways leads to substantial improvements in tools, libraries, and the speed of compiled code. That's progress in several dimensions -- just not along the dimension of language. I disagree. Backwards compatibility can be the very reason no progress _can_ be made in the areas you mention. The C toolchain was and is a mess for anything but small, uniform, single-platform programs, things like valgrind of course outperform plain lint in a variety of ways, but are still hacks around the language's major flaws (And I'm speaking as a C-fan, here). Further breakthroughs in C compiler technology will require stalin-like brute force and library support... well, did you ever use yacc or libxml and compared them to Haskell solutions? Java generics are broken by design, for the questionable benefit of backwards compatibility. Leave those Bad Decisions to language communities who don't care about Doing It Right. Right being a technological measure here, not how well politics sell to accountants. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ 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] Re: statep haskell-lang [was: Re: Hoogle and Network.Socket]
No, I hate C and will never use it again in my entire life unless forced to at the point of a gun. You're point? :-P Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 26, 2009, at 1:17 PM, Jonathan Cast wrote: On Thu, 2009-02-26 at 13:18 -0700, John A. De Goes wrote: Are you saying has been no progress since KR C in the number of libraries available to C programmers? And that C programmers still have to edit files with vi and compile and link by specifying all files on the command-line? You may disagree, but the evidence points in the opposite direction. There are tens of thousands of robust C libraries available to suit any particular programming need. Many of Haskell's own libraries are based on C versions. Tool support for the C language (not for some successor you might think would exist if the language continued evolving) can detect memory leaks, detect memory overwrites, apply dozens of automatic refactorings to C large-scale C programs, etc. Library and tool support for the C language is light years beyond Haskell. It wouldn't be there if we had been through 20 iterations of C each completely breaking backward compatibility. Maybe you should use C then? jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: statep haskell-lang [was: Re: Hoogle and Network.Socket]
On Feb 26, 2009, at 1:36 PM, Jonathan Cast wrote: On Thu, 2009-02-26 at 13:25 -0700, John A. De Goes wrote: No, I hate C and will never use it again in my entire life unless forced to at the point of a gun. Why? Its libraries are far better, its editors are far better [1], its compilers are far better, its tool support is far better, it's incomparably superior in every possible way to Haskell. There are better languages than C with more libraries and better tools (e.g. Java). I would chose one of those over Haskell for a commercial product needing short time-to-market and a long shelf life. Even though Haskell is a superior language, there are other, often more important considerations for anything but hobby coding. Except the relatively narrow criterion of the *language itself*. Maybe making languages better is a worthwile pursuit, then? Or do you still think languages should be frozen in time[2] so the tools, compilers, editors, libraries, etc. can undergo vast improvements? I think to reap the benefits of a language, it must necessarily stop evolving in ways that impose high costs on its user base. [2] For the record: I'd be content to see a frozen production language, like Haskell, frozen in time; as long there's a credible other evolveable language --- preferably one with zero backward- compatibility requirements w.r.t. Haskell 98 or current or past GHC. Let me ask you this question: If I wanted a language like Haskell, but which is Enterprise ready, where should I turn? My answer: Haskell. It's maturing and its slowed rate of evolution is already having beneficial effects on other dimensions. Re-designing a purely function research language from the ground up would be neat --- but then it wouldn't be Haskell at all, and I wouldn't use Haskell, I'd use the new language. If I thought I could realistically leave the Haskell community, I wouldn't be nearly so opposed to Haskell's continued slide into practicality. Why do you think you'll have no where else to go if Haskell continues moving away from being a research language? There are plenty of people who would join you. I think you'd have far more company than you seem to believe. And a fresh start, with absolutely zero requirements for any backward compatibility, would open up many new directions. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hoogle and Network.Socket
It's a chicken-egg thing. A Linux or OS X developer tries Haskell and finds he can write useful programs right away, with a minimum of fuss. But a Windows user tries Haskell and finds he has access to very few of the really good libraries, and even the cross-platform libraries won't build without substantial effort. As a result, I bet it's easier for a Linux or OS X developer to like Haskell than a Windows developer. I use OS X exclusively myself, but I'll ensure my first published Haskell library is cross-platform compatible, because I think it's good for the community. The more people using Haskell, the more libraries that will be written, the more bugs that will be fixed, the more creativity that will be poured into development of libraries and the language itself. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 25, 2009, at 5:29 PM, Achim Schneider wrote: John Lato jwl...@gmail.com wrote: I really don't see anything wrong with using Hoogle to increase awareness (although I would appreciate it if platform-specific packages were searched as an option). You won't hear me argue against it, in fact, I argued in favour of it. Increasing awareness of cross-platform solutions, as well as providing them, is a very different thing than demanding cross-platform support. If 80% of all computer users use Windows, there shouldn't be any problems recruiting a decent number of volunteers to care about Haskell's Windoze support, should there? -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ 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] Re: Hoogle and Network.Socket
I don't think it's that black and white. At the lower end, when the language is controlled by a few, there's not much innovation poured into the language or libraries, and there are no tools to support development. As the community grows, you see much more innovation in language and libraries, and maybe a few primitive tools. With much greater, the community demands backward compatibility, so the language itself may only evolve in highly constrained ways (ways that are usually detrimental to consistency), but the library space explodes with innovation, and the tools become extremely powerful. Personally, I'd be happy to see that explosion of innovation in the library and tool spaces, even if it means the language itself stops evolving (for the most part). It will make it a lot easier do use Haskell commercially, and the innovators in the language space will find or invent a new target to keep themselves occupied. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 25, 2009, at 5:52 PM, Jonathan Cast wrote: On Wed, 2009-02-25 at 17:54 -0700, John A. De Goes wrote: It's a chicken-egg thing. A Linux or OS X developer tries Haskell and finds he can write useful programs right away, with a minimum of fuss. But a Windows user tries Haskell and finds he has access to very few of the really good libraries, and even the cross-platform libraries won't build without substantial effort. As a result, I bet it's easier for a Linux or OS X developer to like Haskell than a Windows developer. I use OS X exclusively myself, but I'll ensure my first published Haskell library is cross-platform compatible, because I think it's good for the community. The more people using Haskell, the more libraries that will be written, the more bugs that will be fixed, the more creativity that will be poured into development of libraries and the language itself. I don't think this is founded in experience. The experience of the last 5 years is that the more people use Haskell, the more important backward-compatibility concerns become, and the harder it becomes for Haskell to continue evolving. Creativity being poured into a language doesn't do much good if the result is the language moving sideways, still less the language growing sideways. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hoogle and Network.Socket
The problem is that PL research is probably not going to stop evolving in our lifetimes. Yes, that research needs a venue, but why should it be Haskell? Haskell is a good language and it's time to start benefiting from the research that's already gone into it. That means some tradeoffs. Haskell is already behind state-of-the art in PL research and it seems unlikely to catch up (witness the slow evolution of Haskell' and the non-existent progress on Haskell2). Of course, I could be wrong. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 25, 2009, at 6:19 PM, Achim Schneider wrote: John A. De Goes j...@n-brain.net wrote: Personally, I'd be happy to see that explosion of innovation in the library and tool spaces, even if it means the language itself stops evolving (for the most part). It will make it a lot easier do use Haskell commercially, and the innovators in the language space will find or invent a new target to keep themselves occupied. And this is why we must avoid success: It would mean instant failure. There are already enough hype-languages around, there's not too much of a point to add one to them. Haskell won't stop evolving and (conservatively) keeping up with PL research until that's done, or Dependent Typing is well-understood, whatever comes first. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ 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
[Haskell-cafe] jhc speed
Is there any conceivable factoring of GHC that would allow you to sandwich the core of jhc in between the front and back ends of GHC? Or are the architectures so fundamentally incompatible as to make this impossible? Such a factoring would be one way the community could help, and if successful, it would allow you to better focus on the really important stuff. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 20, 2009, at 4:14 PM, John Meacham wrote: On Fri, Feb 20, 2009 at 11:52:27PM +0100, Thomas Davie wrote: On 20 Feb 2009, at 23:44, Bulat Ziganshin wrote: Hello John, Saturday, February 21, 2009, 1:33:12 AM, you wrote: Don't forget jhc: i was pretty sure that jhc will be as fast as gcc :) unfortunately, jhc isn't our production compiler Why not? There's nothing stopping you from choosing any Haskell compiler you like. If jhc gives you the performance you need – use it. Heh. He probably meant something more like jhc is not a production compiler which is true for a lot of projects. For projects of substantial size or that require many extensions, jhc falls somewhat short. It is getting better though. Of course, help is always appreciated. :) John -- John Meacham - ⑆repetae.net⑆john⑈ ___ 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] jhc speed
I think doing this work would improve the design of GHC by improving modularity and factoring out generalized abstractions. The richest possible core language makes the most sense for a common core, because what's not needed can always be discarded. From your description, it sounds like such a common core language would be a hybrid of jhc and ghc core, because each contains more information for particular subsets of the language. Layering higher-level primitives on lower-level primitives also makes sense, as it's a very flexible approach. How much support and direction can you provide if we get enough people interested in this? Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 22, 2009, at 7:45 AM, John Meacham wrote: On Sun, Feb 22, 2009 at 07:25:26AM -0700, John A. De Goes wrote: Is there any conceivable factoring of GHC that would allow you to sandwich the core of jhc in between the front and back ends of GHC? Or are the architectures so fundamentally incompatible as to make this impossible? Well, it wouldn't really be useful sandwiched between the front and back end of ghc, the main advantages jhc has over ghc's model are in its lower level optimizations closer to the back end. Feeding ghc core into jhc shouldn't be impossible. Oddly enough, I have written a ghc back end for jhc, mainly for testing purposes rather than a serious back end. The tricky part isn't so much the translation of ghc to jhc core, the type system and representation are quite similar, but the difference in the primitives that the two systems expect to exist. for instance, ghc has high level primitives, such as operations on Integers and primitive types that high signedness. While jhcs primitives are much lower level, it has no special concept of Integer for instance, you implement Integer either in pure haskell code or FFI bindings to GMP or some other way, and jhc's primitive numerical types are simply bit patterns with no interpretation, for instance data Int = I Bits32_ data Word = W Bits32_ and the only thing that makes Int signed and Word not is in the 'Num' instances for those types. That said, i don't see any reason a ghc-core front end for jhc wouldn't be possible, an adapter library could be written to provide ghc style primitives on top of the jhc ones. It would certainly be an interesting project. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ 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] Hoogle and Network.Socket
I think the (valid) concern is that too many people are choosing platform-specific packages when there are alternatives available (albeit not as convenient in some cases), and this really hurts the Windows community because Windows is so radically different from all the other operating systems. Not showing platform-specific packages by default *might* make package writers more likely to develop cross-platform packages. We've heard many times someone say, I don't know if it works on Windows, never really thought of that. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 21, 2009, at 3:55 AM, Martijn van Steenbergen wrote: Hi Neil, Neil Mitchell wrote: If a function isn't available on all OS's then all Hoogle would be encouraging you to do is break compatibility and stop me from using your software. If a function is only available on one OS you will certainly have to deliberately choose to search for that, and it will never show up by default. For what shows up by default I more meant other packages. Should Gtk2hs show up by default? What about tagsoup? What about base? Things like Win32 will never show up by default. How about allowing an extra search flag +windows that reveals windows-specific APIs? Likewise for other OS's. Being able to enable API for a specific package requires me knowing in what package I want to look, while an OS flag doesn't, all the while still making very explicit I want to look for OS-specific API. Thanks, Martijn. ___ 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: Re[5]: [Haskell-cafe] Re: speed: ghc vs gcc
It's not practical at all. It's monstrously more complicated than C. It would be much simpler to do it in C and use FFI. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 21, 2009, at 4:55 PM, Sebastian Sylvan wrote: B) A reasonably practical way to produce fast code for the critical parts of a Haskell app, ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hoogle and Network.Socket
Maybe because one Haskeller generally tries to help another one. That's what what it means to be a community, no? Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 21, 2009, at 6:47 PM, Jonathan Cast wrote: On Sat, 2009-02-21 at 07:25 -0700, John A. De Goes wrote: I think the (valid) concern is that too many people are choosing platform-specific packages when there are alternatives available (albeit not as convenient in some cases), and this really hurts the Windows community because Windows is so radically different from all the other operating systems. Not showing platform-specific packages by default *might* make package writers more likely to develop cross-platform packages. We've heard many times someone say, I don't know if it works on Windows, never really thought of that. Um, why *should* I think of that? jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell.org GSoC
Unfortunately the proofs in dependently typed languages are extremely long and tedious to write. Some kind of compiler proofing tool could ease the pain, but I do not think it has low enough complexity for a GSoC project. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 19, 2009, at 1:37 AM, Wolfgang Jeltsch wrote: Am Donnerstag, 19. Februar 2009 02:22 schrieb sylvain: Haskell is a nice, mature and efficient programming language. By its very nature it could also become a nice executable formal specification language, provided there is tool support. Wouldn’t it be better to achieve the goals you describe with a dependently typed programming language? Best wishes, Wolfgang ___ 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] Haskell.org GSoC
Yes, this is indeed the point. Right now we express properties that a type class should obey, but there is no compiler assistance to prove or verify them. A compiler aware of properties can do additional symbolic manipulation to increase performance. Surely there has been some research in this area already. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 19, 2009, at 3:35 AM, Alberto G. Corona wrote: 2009/2/19 Wolfgang Jeltsch g9ks1...@acme.softbase.org Am Donnerstag, 19. Februar 2009 02:22 schrieb sylvain: Haskell is a nice, mature and efficient programming language. By its very nature it could also become a nice executable formal specification language, provided there is tool support. Wouldn't it be better to achieve the goals you describe with a dependently typed programming language? But I wonder how a dependent typed language can express certain properties, for example, the distributive property between the operation + and * in a ring or simply the fact that show(read x)==x. As far as I understand, a dependent type system can restrict the set of values for wich a function apply, but it can not express complex relationships between operations. My knowledge on dependent types is very limited. I would like to be wrong on this. The point is that permits the automatic checking of such properties at the class level (or module level) are critical, to make sure that derived instances agree with that. This would be very good to feel confident and program at higuer levels of abstraction. ___ 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] Re: Overloading functions based on arguments?
On Feb 14, 2009, at 2:29 PM, Luke Palmer wrote: To me, typeclasses are at their best when you have a real abstraction to encode. I agree. If you are having trouble using a typeclass and need C++-style ad- hoc overloading, it's likely you are trying to encode a fake abstraction -- one that has only linguistic, rather than mathematical meaning. I don't think what you're calling a linguistic abstraction is fake. Words and operators have connotations in the minds of those reading them. There's a reason I choose the word, 'flatten' rather than 'sdj834' to name a function -- because the word 'flatten' suggests what I am trying to accomplish with the function. Let's try a little test: 1. If the parameter is a tree, what do you think flatten would do? 2. If the parameter is a list, what do you think flatten would do? 3. If the parameter is a Style (possible a composite Style consisting of other styles), what do you think flatten would do? 4. If the parameter is a Bezier curve, what do you think flatten would do? My guess is that we would come to the same conclusions for (1) - (4). The name flatten is a perfectly good name for all of these operations, because the domains are distinct, and because using that name suggests the correct meaning to you. (Note use of the word suggests -- like an analogy or parable, you're likely not going to know exactly what the function does just by reading its name, but you'll be in the ballpark and have an intuition about it, which is extremely valuable.) In the current world, flatten will be appended with (usually non- informative) suffixes, or alternate, less-descriptive names chosen. Informative coding is about drawing upon our common pool of experience to mold the form and function of programs to suggest our intentions to others. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Overloading functions based on arguments?
On Feb 14, 2009, at 11:28 PM, wren ng thornton wrote: John A. De Goes wrote: On Feb 13, 2009, at 2:11 PM, Jonathan Cast wrote: The compiler should fail when you tell it two mutually contradictory things, and only when you tell it two mutually contradictory things. By definition, it's not a contradiction when the symbol is unambiguously typeable. Do you think math textbooks are filled with contradictions when they give '+' a different meaning for vectors than matrices or real numbers??? Yes. Yes, I do. If you really think you have discovered a contradiction in tens of thousands of mathematical textbooks, then you should write a paper and submit it to the AJM. Now me, I DON'T think you've discovered a contradiction. I don't even think YOU believe that. Rather, you're fixated on using a unique, precise meaning for each symbol. Somehow this is associated for you with some notion of purity. But I'm guessing, if I take a look at all the source code you have ever written in your entire life, you will not have as many unique symbols as you have functions and operators. You probably reuse names and operators just like the rest of us. It is precisely this abuse of notation which makes, for instance, statistics textbooks impossible to read (without already knowing the material). Hmmm, I don't find statistics books difficult to read. Scalars, vectors, and matrices are fundamentally different here and the operations on them should be unambiguous, regardless of context. It's customary to use a unique typeface and/or font for each domain. So you know the type of the variables by inspection, and the meaning of the operators flows from that. Matrices, for example, are generally denoted in all uppercase (smallcaps), with an italic font, and often with the letters 'M' or 'N' and subscripts. Vectors are usually all lower-case and italic, sometimes with tiny arrows above them, and usually they're represented with the letters u, v, and w (and subscripted versions thereof). With unique domains, reuse of the symbols such as '+' for vector and matrix addition is unambiguous and perfectly sensible because it suggests that at some level, the operation reduces to scalar addition (which is correct). Compare that to using unique symbols for every possible operator and function. That would be brain overload because you would have to memorize each symbol and function separately. For another example, consider matrices vs their transposes. Many folks can't be bothered to type a single character to clarify when things should be transposed before multiplying. Now that's just plain sloppiness, and is quite orthogonal to this discussion. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Overloading functions based on arguments?
I agree that type classes should not be used for this purpose. That's part of the reason I support linguistic overloading -- to stop the type class abuse. Type classes should be used, as you say, when there are algorithms that work for arbitrary members -- i.e. the type class encodes structure and associated properties. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 19, 2009, at 7:33 AM, Luke Palmer wrote: On Thu, Feb 19, 2009 at 7:09 AM, John A. De Goes j...@n-brain.net wrote: On Feb 14, 2009, at 2:29 PM, Luke Palmer wrote: To me, typeclasses are at their best when you have a real abstraction to encode. I agree. If you are having trouble using a typeclass and need C++-style ad- hoc overloading, it's likely you are trying to encode a fake abstraction -- one that has only linguistic, rather than mathematical meaning. I don't think what you're calling a linguistic abstraction is fake. Please ignore the word fake. I don't want to get into any subjective arguments based on the connotation of that word. What I mean to say is, the theory of typeclasses is good at encoding mathematical abstractions, and bad at encoding linguistic ones. Take that as you will, but I conjecture that trying to cram linguistic overloading into a typeclass is generally going to be painful. A good rule of thumb is: are there any algorithms which work for an arbitrary member of this class? I certainly cannot see any for your flatten example. I'm not saying that linguistic overloading is a bad thing. You make good arguments for it, and I find it cleans up code sometimes. Typeclasses just aren't the right tool for it, and Haskell has no good tool for it. In fact, I think it a very interesting research question to come up with a mechanism that supports linguistic overloading, and interacts with typeclasses and inference cleanly. The obvious solution (just look in your namespace for one that matches) has serious drawbacks, and nothing else is jumping to mind. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Overloading functions based on arguments?
On Feb 13, 2009, at 6:31 PM, Krzysztof Skrzętnicki wrote: On Fri, Feb 13, 2009 at 22:37, John A. De Goes j...@n-brain.net wrote: On Feb 13, 2009, at 2:11 PM, Jonathan Cast wrote: The compiler should fail when you tell it two mutually contradictory things, and only when you tell it two mutually contradictory things. By definition, it's not a contradiction when the symbol is unambiguously typeable. Do you think math textbooks are filled with contradictions when they give '+' a different meaning for vectors than matrices or real numbers??? I can easily imagine a book which uses some operator in ambiguous way yet relies on readers' intelligence in solving that issue. It is OK to do that as long as it is easy. However: it can get arbitrarily worse. Don't overlook the advantages of using familiar operators and names: you have some intuition about '+' and 'map', so if you see them, then you'll have some idea what they do (assuming the author is neither stupid nor malicious). However, if you see some operator like '$+' or some name like 'pp3', then you probably won't have any intuition about it. Writing good software is about conveying intentions, and part of the way we can do that is relying on what other people already know. Which means using familiar names and operators when it is helpful to do so. I would consider any book which is hard to read because of that badly written. Things are quite similar with the code. I consider the current state of affairs quite poor: namely, abuse of type classes and alternate names and operators that aren't very suggestive, but were chosen purely to avoid conflicts. Programming language should be easy to reason about for both computers and humans. Compiler should therefore disallow programming style that is inaccessible for potential readers. Want to overload something? Well, use typeclasses to be explicit about it. Type classes were not designed for name overloading. They're designed to factor out common patterns in programming. You shouldn't use a type class just because you want to use a name or operator. And as I said before, if you want to disallow programming style that is inaccessible for potential readers, then you should disallow the current state of affairs. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Overloading functions based on arguments?
Take, for example, this function: f :: [Char] - Char f [] = chr 0 f (c:cs) = chr (ord c + ord (f cs)) [] is typed as [Char], even though it could be typed in infinitely many other ways. Demonstrating yet again, that the compiler *does* use the additional information that it gathers to assist with typing. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 13, 2009, at 6:31 PM, Robert Greayer wrote: -- John A. De Goes wrote: Adding information cannot remove a contradiction from the information set available to the compiler. But it can and often does, for example, for [] or 4. What's the type of either expression without more information? [] :: [a] 4 :: Num a = a Do I win something? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
