[Haskell-cafe] Re: monads and groups -- instead of loops
Arie, Thanks for your thoughtful reply. Comments in-lined. Best wishes, --greg Date: Thu, 2 Aug 2007 03:06:51 +0200 (CEST) From: Arie Peterson [EMAIL PROTECTED] Subject: Re: [Haskell-cafe] Re: monads and groups -- instead of loops To: haskell-cafe@haskell.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain;charset=iso-8859-1 Math alert: mild category theory. Greg Meredith wrote: But, along these lines i have been wondering for a while... the monad laws present an alternative categorification of monoid. At least it's alternative to monoidoid. I wouldn't call monads categorifications of monoids, strictly speaking. A monad is a monoid object in a category of endofunctors (which is a monoidal category under composition). Sorry, i was being as fast and loose with the term as the rest of the communities concerned with 'categorification' seem to be. What do you mean by a 'monoidoid'? I only know it as a perverse synonym of 'category' :-). Indeed. In the spirit of this thought, does anyone know of an expansion of the monad axioms to include an inverse action? Here, i am following an analogy monoidoid : monad :: groupoid : ??? First of all, I don't actually know the answer. The canonical option would be a group object in the endofunctor category (let's call the latter C). This does not make sense, however: in order to formulate the axiom for the inverse, we would need the monoidal structure of C (composition of functors) to behave more like a categorical product (to wit, it should have diagonal morphisms diag :: m a - m (m a) ). It seems to me that there are two basic possibilities, here. One is that the ambient categories over which one formulates computational monads are almost always some type of Linear-Cartesian situation. So, you can possibly exploit the additional structure there. That's certainly been the general flavor of the situation that motivates me. Otherwise, you can go the route of trying to excavate structure that might give meaningful interpretations. This has appeal in that it is more general and might actually uncover something, but as you observe it's not immediate. i haven't wrestled with the idea in anger, yet, because i thought it such an obvious thing to try that someone would have already done the work and was hoping just to get a reference. Your note suggests that it might be worth digging a little. i wonder... does a Hopf algebra-like structure do the job? Maybe there is a way to get it to work, though. After all, what we (in FP) call a commutative monad, is not commutative in the usual mathematical sense (again, C does not have enough structure to even talk about commutativity). My intuition tells me this could be quite generally useful to computing in situation where boxing and updating have natural (or yet to be discovered) candidates for undo operations. i'm given to understand reversible computing might be a good thing to be thinking about if QC ever gets real... ;-) If this structure is to be grouplike, the inverse of an action should be not only a post-inverse, but also a pre-inverse. Is that would you have in mind? (If I'm not making sense, please shout (or ignore ;-) ).) Greetings, Arie -- L.G. Meredith Managing Partner Biosimilarity LLC 505 N 72nd St Seattle, WA 98103 +1 206.650.3740 http://biosimilarity.blogspot.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monad Description For Imperative Programmer
On Thursday 02 August 2007 15:57, ok wrote: It all depends on what you mean make sense to. I can tell my student that (an instance of Monad) is a type constructor applications of which support certain operations that must satisfy certain operations. They can memorise that. But it remains meaningless noise to them. What matters is not what monads *ARE* but what they are *FOR*. Why should anyone care what monads are until they know why monads matter? Well, i would argue that people learning Haskell come to quite quickly appreciate that these 'monad' things are very important in Haskell; that they have to learn about them in order to perform IO and maintain state[1]; and that it's for those reasons at least that they matter. In my experience, many programmers - including myself! :-) - then try to get their head around what a Haskell Monad is, and start asking questions of more experienced Haskellers, trying to get some sense of a possible answer. It's at this point that i feel there's an issue. Haskell Monads are used FOR many many things. And rather than get to the core of what a Monad is, many people provide two or three motivating examples - examples which merely serve to show /some/ of what Monads are about, but which will lead astray any person who incorrectly assumes that these two or three examples constitute the totality of the Monadic universe, and who makes inferences about Monads accordingly. (To me, the notion that a Monad is merely a kind of loop is an example of this.) This is why i feel it's important to provide an agreed-upon minimalist definition of a Monad - it can serve as a /correct/ starting point (to be elaborated on, of course - as Claus did), rather than forcing the programmer new to Haskell to /guess/ what a Monad might be. We keep trying to suggest that Monads aren't really that scary, but the fact that we can't seem to agree upon a straightforward definition of what a Monad is belies that - i feel it tends to convey that in fact Monads /are/ a very complex concept, that asking what Monads are is like asking what God is or something. :-P And in my opinion, feeling that a given topic is overwhelming complex can become a block to further learning. Alexis. [1] Yes, they're obviously used for many other things besides those two things; but it's these two cases that are often of most interest to programmers coming from a non-functional background. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some Haskell platformish questions
Hello David, Thursday, August 2, 2007, 12:48:07 AM, you wrote: about concurrency - necessarily read paper Tackling the awkward squad: monadic input/output, concurrency, exceptions, and foreign-language calls in Haskell http://research.microsoft.com/Users/simonpj/papers/marktoberdorf/marktoberdorf.ps.gz one of current GSOC projects is the binding to LibCurl about SHA256 - if it's missed in Crypto package, you can use FFI to import this function from any C library -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: monads and groups -- instead of loops
On 1 Aug 2007, at 21:23, Greg Meredith wrote: But, along these lines i have been wondering for a while... the monad laws present an alternative categorification of monoid. At least it's alternative to monoidoid. In the spirit of this thought, does anyone know of an expansion of the monad axioms to include an inverse action? Here, i am following an analogy monoidoid : monad :: groupoid : ??? I'm not sure that's the right question. A monoid is a category with one object. A group is a category with one object, where every arrow is an iso. A groupoid is a category (with potentially more than one object), where every arrow is an iso. A monad is monoid in the category of endofunctors. Your groupad, i.e. a group in the category of endofunctors, would boil down to having a monad m that has an unreturn :: m a - a. In the light of things like unsafePerformIO, this is maybe not what you want. More interesting, however, is generalizing a monad to a monoid in functor categories in general, as opposed to just endofunctors. You could call this a monadoid. I've heard Tarmo Uustalu talk about this once (Kan-extensions, coends, *mumble mumble mumble*). Mike Spivey's MSFP paper (http://spivey.oriel.ox.ac.uk/mike/msfp.pdf) mentions A-monads, which is a step in that direction. Anyhow, just a thought. Wouter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cartesian product of a Set
On Thu, Aug 02, 2007 at 04:15:35PM +1200, ok wrote: On the other hand, I've usually found that it pays to avoid explicitly constructing things like Cartesian products. Could that be the case here? Quite possibly, though for my purposes I don't _think_ it's worth routing around it. I'm using it in a naive (and intentionally so) algorithm to search for local top elements in a partial order. That is, we require that the PO satisfies the property: for all a,b,c in PO . a = b and a = c = exists d in PO . b = d and c = d where a is a local bottom element for b and c, and d is the corresponding local top element. Given a PO, for every such a, I want the set of corresponding d's. If any such set is empty, a big red NO lights up elsewhere in the program. My algorithm is the simplest thing I could think of that works: represent the PO as a Set of (a,a), then simply search its cartesian product, a Set of ((a,a),(a,a)), for elements of the right shape. It works, in only a few lines of code, and really looks a lot like the definition given above. It also seems to be fast enough for reasonably sized examples - for a PO with ~40 elements it's instantaneous. That's at the bottom end of realistic for my application, and I need to check it for ~100 elements (which is more like my reality), but I think it ought to be fine/usable. If, with real data, it turns out to be too slow then yes, I'll ditch this naive method and look at graph algorithms, which is of course the Smart thing to do. However, it's beautiful (to me) code right now, which strongly reflects the definition of the problem, so I'd be happy not to. :-) Cheers, -Andy -- Andy Gimblett Computer Science Department University of Wales Swansea http://www.cs.swan.ac.uk/~csandy/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monad Description For Imperative Programmer
On 02/08/07, Alexis Hazell [EMAIL PROTECTED] wrote:
It's at this point that i feel there's an issue. Haskell Monads are used FOR
many many things. And rather than get to the core of what a Monad is, many
people provide two or three motivating examples - examples which merely serve
to show /some/ of what Monads are about, but which will lead astray any
person who incorrectly assumes that these two or three examples constitute
the totality of the Monadic universe, and who makes inferences about Monads
accordingly. (To me, the notion that a Monad is merely a kind of loop is an
example of this.)
I agree with this very much. Monads are used for a great deal of
things, some of which seem related (IO/State, []/Maybe) while others
are utterly disconnected.
Simon Peyton Jones has jokingly said that warm fuzzy things would
have been a better choice of name. In seriousness, though, I think the
exact name is not the problem. I would suggest that *having a name* is
the problem.
In imperative programming there are many idioms we would recognise.
Take the do something to an array idiom:
for (int i = 0; i arr.length; i++) {
arr[i] = foo(arr[i]);
}
This is a pretty obvious pattern. Some might say it's so obvious that
it doesn't need a name. Yet we've got one in functional programming
because we can. Without higher-order functions it's not possible to
encapsulate and name such common idioms. It seems a bit superfluous to
name something if you can't do anything with the name.
But with higher-order functions we *can* encapsulate these ideas, and
that means we *must* name them. Add to that the insatiable
mathematical desire to abstract, abstract, abstract...
Intuitively it seems that monads are similar, except the instances are
much less obviously connected. It's easy to see the connection between
State and IO. But those two to []?
Do I have an suggestions? Well, maybe the right way would be to do as
we do with map and fold, etc: show the explicitly recursive example,
then generalise. So, show how we could we would thread state in
Haskell, or how we would do optional (Maybe-style) values, then
generalise, *slowly* coalescing the more similar monads first before
reaching the 'top' of the monadic phylogenetic tree.
Hmm, I can see that previous paragraph is not as clear as it could be.
But anyway: has anyone used this approach before?
Cheers,
D.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Some Haskell platformish questions
My answers apply to Windows/GHC. David Pollak wrote: * Can GHC generate stand-alone executables with all the dependencies linked in such that I can distribute the single file without worrying about including a bunch of DLLs/SOs? The answer seems to be yes, but I wanted to confirm. Yes. * How much of a distribution footprint is the Haskell runtime? If I have a Hello World app, roughly how big will the EXE be (if one includes the JRE in the runtime, a Java/Scala program has a minimum footprint of 20M... that's big.) A hello world application executable on Windows/GHC 6.6.1 is 592,385 bytes. But the size grows very quickly to 1-2 MB when you start including the basic libraries. * Same goes for the runtime... I've looked at the stats on the Language Shootout home page and these look encouraging, but I wanted to see if the reasonable footprint is a reality. The memory footprint of a well-written Haskell program seems to be very small. I once wrote a text parser that only used a maximum of 2 MB of memory while processing an infinite stream. This is much less than the minimum footprint of the JVM. One reason for this is that the GHC garbage collector officially kicks ass. However, it is exceedingly easy to write memory-leaking programs in Haskell. Fortunately memory leaks usually manifest themselves as a program crash (stack overflow) or very high heap usage (easy to monitor in task explorer). In any case, the memory usage is pretty easy to monitor with GHC's built-in profiling facilities. Now fixing Haskell memory leaks... a completely different story. It's nothing short of black magic. Performing the simplest program optimizations and fixing the simplest of memory leaks generally requires a level of gurudom that is not even possible to achieve just with Java/C/C++ programming. Fixing a Haskell program usually involves performing a couple of sacred rites, sacrifices, voodoo rituals (you can consult your preferred deity, it doesn't matter). When that doesn't help, approach the Gurus of this forun, place the ritual Offering and plead for help. If they are satisfied with you, they might, just might, throw you a scrap of wisdom from their infinite mental capacity, which upon receiving will shock and humble you for life. Usually it sounds like this: Here's a one line fold that replaces your entire program and doesn't have the memory leak. * I tend to do most of my coding in either Emacs or Eclipse... how's the Haskell support in either? Is there a preferred editor (I don't mean to start any wars here... :-) Yes, there's a plugin for Eclipse. It's actually slightly better than the Scala plugin you're probably familiar with :) There's also a good syntax highlighting file for jEdit. Niko ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [HOpenGL] renderString problems
On Wed, 1 Aug 2007, Dave Tapley wrote: Hi all, I'm having a lot of trouble using renderString from Graphics.UI.GLUT.Fonts. All my attempts to render a StrokeFont have so far failed. Using a BitmapFont I can get strings to appear but they demonstrate the odd behaviour of translating themselves a distance equal to their length every time my displayCallback function is evaluated. My requests are: * Does anyone know how to keep the position fixed? * Are there any good examples of (working) GLUT code available on the web, I'm finding it very hard to make any progress at the moment. Certainly not at Haskell speed :( I am using the following code: import Graphics.UI.GLUT main = do getArgsAndInitialize createWindow displayCallback $= update actionOnWindowClose $= ContinueExectuion mainLoop update = do clear [ColorBuffer] renderString Fixed8By13 $ Test string flush Cheers, Dave ___ HOpenGL mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/hopengl I had a similar problem with stroke fonts. Try scaling by a low number (such as 0.01) and see where that gets you. The problem was it was rendering them at a size much bigger than my coordinate space that I just couldn't see them. I'm not convinced you need that $ there either but I don't suppose it hurts. Charles ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: FW: RE [Haskell-cafe] Monad Description For Imperative Programmer
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of peterv However, one thing which I find annoying is that a classic pure function cannot evaluate an IO function unless you use unsafePerformIO; one must promote (?demote) the pure function into the IO monad. That's just a property of the IO monad, rather than monads in general: http://www.haskell.org/all_about_monads/html/laws.html#nowayout Any ways of promoting such a pure function into the monadic one automatically? I tried playing with liftM, without succes. This is where Claus plugs HaRe :-) (although liftM + friends is normally what one uses). You might find this relevant: http://www.cs.kent.ac.uk/projects/refactor-fp/catalogue/Monadification1. html Some people (but I'm not sure who) probably write most of their Haskell code in a monadic style, so as to make conversion between various monads less painful. It's still pure... Alistair * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monad Description For Imperative Programmer
On 8/2/07, Dougal Stanton [EMAIL PROTECTED] wrote: Do I have an suggestions? Well, maybe the right way would be to do as we do with map and fold, etc: show the explicitly recursive example, then generalise. So, show how we could we would thread state in Haskell, or how we would do optional (Maybe-style) values, then generalise, *slowly* coalescing the more similar monads first before reaching the 'top' of the monadic phylogenetic tree. Hmm, I can see that previous paragraph is not as clear as it could be. But anyway: has anyone used this approach before? These immediately came to mind: You Could Have Invented Monads! (And Maybe You Already Have.) http://sigfpe.blogspot.com/2006/08/you-could-have-invented-monads-and.html [http://tinyurl.com/ecqzl] Monads for Functional Programming http://citeseer.ist.psu.edu/wadler95monads.html [http://tinyurl.com/2foj46] I personally received my first monadic enlightenment from Bird's Introduction to Functional Programming using Haskell, which also uses the same approach. I think it's an excellent way to approach the topic. Stuart Cook ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] renderString problems
On 8/2/07, Dave Tapley [EMAIL PROTECTED] wrote: Using a BitmapFont I can get strings to appear but they demonstrate the odd behaviour of translating themselves a distance equal to their length every time my displayCallback function is evaluated. I've never used OpenGL from Haskell, but it sounds like renderString is modifying your modelview matrix with each call, presumably to make it easier to chain lots of text together in one frame. Since the matrix never gets reset, the translation effect accumulates each time the scene is redrawn. The quick fix would be to call loadIdentity (i.e. glLoadIdentity) each time you update, before drawing anything. Stuart ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] renderString problems
Hi Dave, everyone... Dave Tapley wrote: Hi all, I'm having a lot of trouble using renderString from Graphics.UI.GLUT.Fonts. All my attempts to render a StrokeFont have so far failed. Using a BitmapFont I can get strings to appear but they demonstrate the odd behaviour of translating themselves a distance equal to their length every time my displayCallback function is evaluated. My requests are: * Does anyone know how to keep the position fixed? One way is to wrap the drawing action with preservingMatrix : http://cvs.haskell.org/Hugs/pages/libraries/OpenGL/Graphics-Rendering-OpenGL-GL-CoordTrans.html#v%3ApreservingMatrix (re-exported from the main GLUT module, if I read the docs correctly) This pushes the transformation state to a stack, executes the action, and restores the transformation state from the stack. More useful when you have complex scenes/subscenes/subsubscenes etc, but should work here too. [snip] Claude -- http://claudiusmaximus.goto10.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] renderString problems
Your code is not rendering stroke font, but bitmap. Use the following code to render str at x and y position. GL.currentRasterPosition $= vertex4 x y 0 1 GLUT.renderString GLUT.Fixed8By13 str where vertex4 is defined as: vertex4 :: Float - Float - Float - Float - GL.Vertex4 Float vertex4 = GL.Vertex4 Note that the coordinate system for rasterization is different from GL's transformation matrix. If you really want the stroke font, you should use Roman or MonoRoman, then you may transform your position using GL.translate (GL.Vector3 x y 0). Regards, Paul L On 8/1/07, Dave Tapley [EMAIL PROTECTED] wrote: Hi all, I'm having a lot of trouble using renderString from Graphics.UI.GLUT.Fonts. All my attempts to render a StrokeFont have so far failed. Using a BitmapFont I can get strings to appear but they demonstrate the odd behaviour of translating themselves a distance equal to their length every time my displayCallback function is evaluated. My requests are: * Does anyone know how to keep the position fixed? * Are there any good examples of (working) GLUT code available on the web, I'm finding it very hard to make any progress at the moment. Certainly not at Haskell speed :( I am using the following code: import Graphics.UI.GLUT main = do getArgsAndInitialize createWindow displayCallback $= update actionOnWindowClose $= ContinueExectuion mainLoop update = do clear [ColorBuffer] renderString Fixed8By13 $ Test string flush Cheers, Dave ___ 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] Installing FreeGLUT
GHC as of now won't be able to recognize your change to the dynamic libraries on the fly. So if you want to use new features, you'll have to compile GLUT package for GHC freshly on top of your new freeglut. Get the GLUT source from hackage.haskell.org and do the cabal installation. GHC will then be able to recognize the freeglut, at least confirmed by experiments on my Linux box a few days ago. Regards, Paul L On 8/1/07, Ronald Guida [EMAIL PROTECTED] wrote: Hi, I am trying to use freeglut with GHCi 6.6.1, and I'm stuck. I downloaded freeglut 2.4.0 and compiled it. I am on a Windows XP machine, and I found that freeglut compiled out of the box in MS Visual Studio.Net 2003. My difficulty is that GHCi is finding GLUT 2.2.1 and not freeglut. How do I get GHC and GHCi to recognize and use freeglut instead? Note: I'm using Windows XP; an upgrade to Linux is not an option. Thank you -- Ron ___ 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] Exiting GLUT application
Are you trying it on Linux? I had exactly the same problem. I believe it's with with X11/OpenGL. I've written C programs using GLUT, freeGLUT and GLFW (another OpenGL Window Kit) to re-open window after first one is closed. Unfortunately all gave the same fault. So it leads me to believe the problem is not really GLUT specific. I've not tried other platforms. So I ended up using a trick that always keeps the first window and reuse it for GHCi session. Just hide it and show it would make no difference to the end user, at least true on both Windows and Linux. Mac now has a problem prevents getting GLUT event when loaded in GHCi. Regards, Paul Liu On 8/1/07, Dave Tapley [EMAIL PROTECTED] wrote: Unfortunately whilst the new code is returning me to a 'Main ' prompt as required another problem has come up. The issue here is found when the code is executed in both GHCi (6.6) and hugs (20050308). Once the code below is loaded evaluating main opens an unfilled window as required. However if this window is closed and main is evaluated again both GHCi and hugs die thus: GHCi: Illegal instruction (core dumped) hugs: Unexpected signal Any thoughts? On 31/07/07, Dave Tapley [EMAIL PROTECTED] wrote: Excellent, thank you Marc your advice worked perfectly. For reference the corrected code reads: import Graphics.UI.GLUT main = do getArgsAndInitialize createWindow actionOnWindowClose $= ContinueExectuion mainLoop Dave, On 31/07/07, Marc A. Ziegert [EMAIL PROTECTED] wrote: in old glut, the main loop was the core of the single threaded program. exiting it did mean to exit the program completely. in freeglut, you have alternatives. but for compatibility, it defaults to the old behaviour. http://haskell.org/ghc/docs/latest/html/libraries/GLUT/Graphics-UI-GLUT-Begin.html#v%3AExit - marc Am Dienstag, 31. Juli 2007 19:16 schrieb Dave Tapley: Hi everyone, I have the following skeleton GLUT code: import Graphics.UI.GLUT main = do getArgsAndInitialize createWindow mainLoop It loads into both hugs and ghci fine and when 'main' is evaluated an empty window opens as expected. However when closing the window (clicking the window manager's x button) both hugs and ghci exit with the window, as opposed to returning to the the 'Main' prompt. I suspect I need some callback to exit the GUI cleanly? Cheers, Dave ___ 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] Re: [Haskell] ANN: encoding-0.1 release
On Thu, 2007-08-02 at 18:44 +0200, Wolfgang Jeltsch wrote: Am Donnerstag, 2. August 2007 12:22 schrieb Henning Günther: […] ISO 8859-* (alias latin-*) Not every ISO-8859-* encoding is a Latin-* encoding. […] Wouldn’t it be good to use some already existing library like iconv or do you think, this is not feasible (because you want to support lazyness, for example)? Yes, I was talking to Henning about this. I've got an iconv binding[1] that use lazy bytestrings (so it does support lazyness of course) and is pretty quick. Henning has been thinking much more about what the appropriate api should be, I've just got: type Encoding = String convert :: Encoding - Encoding - Lazy.ByteString - Lazy.ByteString so we might be able to use iconv underneath (if it's available). Duncan [1] darcs get http://haskell.org/~duncan/iconv/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: how to see operators precedence in GHCi
Hmm. Good point. Fixed. Smion | -Original Message- | From: Stefan O'Rear [mailto:[EMAIL PROTECTED] | Sent: 26 July 2007 01:01 | To: Simon Peyton-Jones | Cc: Bulat Ziganshin; haskell-cafe@haskell.org; Jon Fairbairn | Subject: Re: [Haskell-cafe] Re: how to see operators precedence in GHCi | | On Thu, Jul 26, 2007 at 12:42:52AM +0100, Simon Peyton-Jones wrote: | | | Uhm... that didn't work :) | | | | Not quite as nice: | | | | [EMAIL PROTECTED]:~$ ghci -ddump-rn-trace | | You probably wanted -ddump-rn | | Seemed so, but that option has no effect (bug?): | | [EMAIL PROTECTED]:~$ ghci -ddump-rn | GHCi, version 6.7.20070712: http://www.haskell.org/ghc/ :? for help | Loading package base ... linking ... done. | Prelude 2 + 2 | 4 | Prelude | | Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Polymorphic variants
On Thursday 26 July 2007 00:07:23 Josef Svenningsson wrote: On 7/26/07, Jon Harrop [EMAIL PROTECTED] wrote: Does Haskell have anything similar to OCaml's polymorphic variants? No as such, but it's possible to simulate them. As always Oleg was the one to demonstrate how: http://okmij.org/ftp/Haskell/generics.html Thank you. Is there any interest in adding polymorphic variants to Haskell? I think it is fair to say that OCaml has shown them to be an extremely useful construct (more common than objects in OCaml, for example). -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. OCaml for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists/?e ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Primitive Recursive Algebraic Types
Alexteslin wrote: Hi, I am doing some simple exercises about recursive algebraic types and this particular exercise asks to define a function which counts the number of operators in an expression. I defined the function below, but i am not sure if on the second line changing from evalLength (Lit n) = n to (Lit n) = 0 is the right solution. although the function produces correct result. data Expr = Lit Int | Add Expr Expr | Sub Expr Expr deriving (Eq, Show) evalLength :: Expr - Int evalLength (Lit n) = 0 evalLength (Add e1 e2) = 1 + (evalLength e1) + (evalLength e2) evalLength (Sub e1 e2) = 1 + (evalLength e1) - (evalLength e2) Thank you It actually doesn't work. Initially i tested on Add operator only. But whith Sub operator it produces wrong result. -- View this message in context: http://www.nabble.com/Primitive-Recursive-Algebraic-Types-tf4207521.html#a11969804 Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Perfect example
Any suggestions for a perfect example that uniquely demonstrates the benefits of the Haskell language compared to other languages? -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. OCaml for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists/?e ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] positive Int
as far as i know, the haskell standard does not define a basic Int type that is limited to positive numbers. would a type of this kind not potentially allow us to make stronger verification statements about certain functions? for example, 'length' returns an Int, but in reality it must always return a value 0 or greater. a potential counter-argument would be the need to possibly redefine Ord etc for this more narrow type... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] positive Int
On Thu, Aug 02, 2007 at 12:17:06PM -0700, brad clawsie wrote: as far as i know, the haskell standard does not define a basic Int type that is limited to positive numbers. would a type of this kind not potentially allow us to make stronger verification statements about certain functions? for example, 'length' returns an Int, but in reality it must always return a value 0 or greater. a potential counter-argument would be the need to possibly redefine Ord etc for this more narrow type... i suppose one could also say that the range [0..] of return values is *implicit* in the function definition, so there is little value in explicitly typing it given all of the hassle of specifying a new typeclass etc sorry, yes i am talking to myself ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] monad subexpressions
I've heard Simon (Peyton-Jones) twice now mention the desire to be able to embed a monadic subexpression into a monad. That would be http://article.gmane.org/gmane.comp.lang.haskell.prime/2267 and in the recent OSCON video. Is someone working on implementing this? If no, I'll take a crack at it. If yes, I'd be slower than someone else, since I'm new to GHC. This seems like something a tad easier than type system extensions and the like since it's just desugaring... but a little harder than my remove the GHCi banner patch! In other words, a perfect step for me. Also, I got so frustrated that I ended up abandoning some code recently because STM is, in the end, so darn hard to use as a result of this issue. I'd love to see this solved, and I'm quite eager to do it. Proposals for syntax I've seen include: $( expr ) -- conflicts with template haskell ( - expr ) -- makes sense, and I think it's unambiguous Other ideas: ``expr`` -- back-ticks make sense for UNIX shell scripters (| expr |)-- I don't think anything uses this yet Thoughts? -- Chris Smith ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: Dimensional 0.6 -- Statically checked physical dimensions
Dear all,
I am pleased to announce version 0.6 of the Dimensional library.
Dimensional is a library providing data types for performing
arithmetic with physical quantities and units. Information about the
physical dimensions of the quantities/units is embedded in their types
and the validity of operations is verified by the type checker at
compile time. The boxing and unboxing of numerical values as
quantities is done by multiplication and division with units.
The library is designed to, as far as is practical, enforce/encourage
best practices [1] of unit usage.
Noteworthy changes/additions since the previous formal announcement
(version 0.4) are:
- All quantities and SI units from [1] have been added.
- A Prelude replacement with the SI units and dimensional operators
(+, *, ^...) is provided for convenience.
- Interface to Data.Time using 'fromDiffTime' and 'toDiffTime'.
- Phantom type tags make extended dimensions safer.
- Experimental CGS units with type safe conversions to/from SI. See
appended literate Haskell module for details.
Additional information and code is available from the project web site [3].
Thank you,
Bjorn Buckwalter
[1] http://physics.nist.gov/Pubs/SP811/
[2] http://www.haskell.org/pipermail/haskell/2007-May/019496.html
[3] http://code.google.com/p/dimensional/
~~ BEGIN 'Buckwalter/Dimensional/CGS.lhs' ~~
Buckwalter.Dimensional.CGS -- CGS system of units
Bjorn Buckwalter, [EMAIL PROTECTED]
License: BSD3
*** EXPERIMENTAL ***
= Introduction =
This module was prompted by an email from Chuck Blake[1]. He asked if
the Dimensional library could support other systems of units than
SI, in particular systems such as the centimeter-gram-second (CGS)
system where fractional exponents of dimensions occur. He also
wondered whether it was possible to convert quantities between
different systems while statically ensuring that a given conversion
was valid.
In this module we show that we can in a straight forward manner
support systems with rational exponents, provided that the rationals
that may be encountered are known a priori. As an example we provide
a rudimentary implementation of the CGS system.
We also show that we can indeed statically prohibit invalid conversions
between different systems.
= Caveats =
I'm ignorantly assuming that when working with the CGS (or MKS)
system you will only (meaningfully?) encounter half-exponents and
only of the length and mass dimensions. Of course, in other systems
other rational exponents may be encountered.
I am also assuming that the CGS system would not be employed when
working with temperature, amount or luminosity. This is evident in
the below type signatures where I have assumed zero extent in the
temperature, amount and luminosity dimensions. If this is incorrect
I would appreciate pointers to the CGS representation of these
dimensions.
Please correct and inform me if my assumptions are wrong!
= Preliminaries =
{-# OPTIONS_GHC -fglasgow-exts -fallow-undecidable-instances #-}
module Buckwalter.Dimensional.CGS where
import Prelude ( undefined, Num, Fractional, Floating, Show, recip, Double )
import qualified Prelude
import Buckwalter.Dimensional hiding ( DLength, DMass, DTime,
DElectricCurrent )
import Buckwalter.Dimensional.Quantities as SIQ
import qualified Buckwalter.Dimensional.SIUnits as SI
import qualified Buckwalter.NumType as N
import Buckwalter.NumType ( Neg2, Neg1, Zero, Pos, Pos1, Pos2,
Pos3, NumType )
import Buckwalter.NumType ( neg2, neg1, zero, pos1, pos2, pos3 )
import Data.Maybe (catMaybes)
= Dimensions =
Analogously with the SI we collect the base dimensions of the CGS
system in the data type 'CGSDim'.
data CGSDim lh mh t
In the above 'lh' and 'mh' represent the number of half-exponents
of length and mass respectively while 't' represents the number of
whole-exponents. The base dimensions illustrate this.
type DLength = CGSDim Pos2 Zero Zero
type DMass = CGSDim Zero Pos2 Zero
type DTime = CGSDim Zero Zero Pos1
We add a few non-base dimensions for the sake of example. Charge
is particularly interesting as it illustrates the need for
half-exponents as described in [2].
type DElectricCurrent = CGSDim Pos3 Pos1 Neg2
type DCharge = CGSDim Pos3 Pos1 Neg1
= 'Mul', 'Div', 'Pow' and 'Root' instances =
The 'Mul', 'Div', 'Pow' and 'Root' instances are strictly analogous
with the SI.
instance ( N.Sum lh lh' lh''
, N.Sum mh mh' mh''
, N.Sum t t' t'' ) = Mul (CGSDim lh mh t)
(CGSDim lh' mh' t')
(CGSDim lh'' mh'' t'')
instance ( N.Sum lh lh' lh''
, N.Sum mh mh' mh''
, N.Sum t t' t'' ) = Div (CGSDim lh'' mh'' t'')
(CGSDim lh' mh' t')
(CGSDim lh mh t)
instance ( N.Mul lh x lh'
Re: RE [Haskell-cafe] Monad Description For Imperative Programmer
Ok, I am guessing that if you were Neo in The Matrix, you would have taken the Blue Pill. Blue Pill people ask How. I suspect most people attracted to Haskell have already taken the Red Pill. Red Pill people ask Why. It is compulsion, not self-interest, that drives Red Pill people to look under the hood of their programming language. If you are a Blue Pill person, you will never understand. If you were a Red Pill person, you would never have written the following paragraph. ok wrote: If you've read the Science of Discworld books you will be familiar with the phrase 'lies-to-children'. You DON'T tell them the full truth, because it would take a long time, confuse the marrow out of their bones, and leave them feeling this was masturbatory mathematics, not real programming, having no connection with real world interests. Your students can choose for themselves whether to take the Blue Pill or Red Pill. The least you can do is offer them the choice. Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] positive Int
On Thu, Aug 02, 2007 at 12:29:46PM -0700, brad clawsie wrote: On Thu, Aug 02, 2007 at 12:17:06PM -0700, brad clawsie wrote: as far as i know, the haskell standard does not define a basic Int type that is limited to positive numbers. would a type of this kind not potentially allow us to make stronger verification statements about certain functions? for example, 'length' returns an Int, but in reality it must always return a value 0 or greater. a potential counter-argument would be the need to possibly redefine Ord etc for this more narrow type... i suppose one could also say that the range [0..] of return values is *implicit* in the function definition, so there is little value in explicitly typing it given all of the hassle of specifying a new typeclass etc This would be a very nice type to have (natural numbers), but is a tricky type to work with. Subtraction, for instance, wouldn't be possible as a complete function... or one might say that if you included subtraction you're even less safe: negative results either must throw an exception or be impossible to catch. You might point out that overflow in an Int is similar (uncatchable), but overflow is much harder to accidentally run into than negative values. A nicer option would be some sort of extra proof rather than a new type. But that sort of work is rather tricky, as I understand it. -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] positive Int
Of course, you can always do this: data Nat = Zero | Succ Nat but it's not very much fun to work with, and not very efficient. Mike David Roundy wrote: On Thu, Aug 02, 2007 at 12:29:46PM -0700, brad clawsie wrote: On Thu, Aug 02, 2007 at 12:17:06PM -0700, brad clawsie wrote: as far as i know, the haskell standard does not define a basic Int type that is limited to positive numbers. would a type of this kind not potentially allow us to make stronger verification statements about certain functions? for example, 'length' returns an Int, but in reality it must always return a value 0 or greater. a potential counter-argument would be the need to possibly redefine Ord etc for this more narrow type... i suppose one could also say that the range [0..] of return values is *implicit* in the function definition, so there is little value in explicitly typing it given all of the hassle of specifying a new typeclass etc This would be a very nice type to have (natural numbers), but is a tricky type to work with. Subtraction, for instance, wouldn't be possible as a complete function... or one might say that if you included subtraction you're even less safe: negative results either must throw an exception or be impossible to catch. You might point out that overflow in an Int is similar (uncatchable), but overflow is much harder to accidentally run into than negative values. A nicer option would be some sort of extra proof rather than a new type. But that sort of work is rather tricky, as I understand it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Primitive Recursive Algebraic Types
It seems you are confusing the notion of counting the number of operators in the expression with actually evaluating the expression. Your evalLength function does both. It may help to consider counting the number of operators in the expression to be the same as calculating the height of the syntax tree representing the expression. This is why when we are counting the operators in the expression, there is no need to distinguish Add and Sub; they are both just operators for this analysis and their different semantics are not yet a concern. The countOperators function need not distinguish between Add and Sub since we're not yet evaluating. Similarly, a literal is not an operator; the integer it contains is a value, not an operator. In this case the type Int is being used for two different reasons; you'll need to be able recognize it when this happens. Here's the correct version; you were quite close! In terms of types and recursive structure, you had it correct. By separating counting operators from evaluation, I think you'll clearly see the reasons for the definition. countOperators :: Expr - Int countOperators = heightOfTree heightOfTree (Lit n) = 0 heightOfTree (Add e1 e2) = 1 + (heightOfTree e1) + (heightOfTree e2) heightOfTree (Sub e1 e2) = 1 + (heightOfTree e1) + (heightOfTree e2) On 8/2/07, Alexteslin [EMAIL PROTECTED] wrote: Alexteslin wrote: Hi, I am doing some simple exercises about recursive algebraic types and this particular exercise asks to define a function which counts the number of operators in an expression. I defined the function below, but i am not sure if on the second line changing from evalLength (Lit n) = n to (Lit n) = 0 is the right solution. although the function produces correct result. data Expr = Lit Int | Add Expr Expr | Sub Expr Expr deriving (Eq, Show) evalLength :: Expr - Int evalLength (Lit n) = 0 evalLength (Add e1 e2) = 1 + (evalLength e1) + (evalLength e2) evalLength (Sub e1 e2) = 1 + (evalLength e1) - (evalLength e2) Thank you It actually doesn't work. Initially i tested on Add operator only. But whith Sub operator it produces wrong result. -- View this message in context: http://www.nabble.com/Primitive-Recursive-Algebraic-Types-tf4207521.html#a11969804 Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.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] positive Int
On Thu, Aug 02, 2007 at 02:08:33PM -0700, David Roundy wrote: This would be a very nice type to have (natural numbers), but is a tricky type to work with. Subtraction, for instance, wouldn't be possible as a complete function... Of course it would. It would just have the type Nat - Nat - Integer. This of course means that Nat wouldn't be an instance of Num. Tough luck, and one more reason for more fine-grained algebraic class hierarchy: Nat would be a semiring (as would booleans and finite sets and regular expressions and whatnot). Lauri ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Dimensional 0.6 -- Statically checked physical dimensions
On Thu, Aug 02, 2007 at 10:27:47PM +0200, Björn Buckwalter wrote: I am also assuming that the CGS system would not be employed when working with temperature, amount or luminosity. This is evident in the below type signatures where I have assumed zero extent in the temperature, amount and luminosity dimensions. If this is incorrect I would appreciate pointers to the CGS representation of these dimensions. Please correct and inform me if my assumptions are wrong! The temperature units are the same in CGS as in MKS (Kelvin). This is a very rudimentary implementation. To make it more practical a significant number of quantities and units, in particularly those commonly used with the CGS, would need to be added. In the mean time all units defined for the SI can be used with the CGS by applying 'fromSI' to quantities defined from the SI units. If anyone is willing to add quantities/units (or other enhancements) I will happily to accept patches. Personally I do not expect to use this module and therefore do not intend to invest much more time in it. If the module has other users I might reconsider. And of course, another direction of future work is to define additional systems (e.g. natural, relativistic) using this module as a template. I imagine this should be fairly straight forward. When atomic units are implemented, this could be useful for me... but alas I very seldom use Haskell for physics, and the effort to learn these modules seems unlikely to pay off soon. :( -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] monad subexpressions
Hi Chris, Simon mentioned this to me as a possible project when I started my internship here at MSR, so I'm pretty sure this is both on the wish-list and not already taken (but we should check with Simon to make sure). I've since wished for it a few times as I've been implementing view patterns, so I personally think it would be a great thing for you to implement! If you're interested in doing this, I'd be happy to give you an overview of what pieces of GHC you'll need to touch and to answer your questions (as best I can!) as you work on the implementation. I've gotten to know the front end of GHC a little over the past few weeks. Let me know, -Dan On Aug02, Chris Smith wrote: I've heard Simon (Peyton-Jones) twice now mention the desire to be able to embed a monadic subexpression into a monad. That would be http://article.gmane.org/gmane.comp.lang.haskell.prime/2267 and in the recent OSCON video. Is someone working on implementing this? If no, I'll take a crack at it. If yes, I'd be slower than someone else, since I'm new to GHC. This seems like something a tad easier than type system extensions and the like since it's just desugaring... but a little harder than my remove the GHCi banner patch! In other words, a perfect step for me. Also, I got so frustrated that I ended up abandoning some code recently because STM is, in the end, so darn hard to use as a result of this issue. I'd love to see this solved, and I'm quite eager to do it. Proposals for syntax I've seen include: $( expr ) -- conflicts with template haskell ( - expr ) -- makes sense, and I think it's unambiguous Other ideas: ``expr`` -- back-ticks make sense for UNIX shell scripters (| expr |)-- I don't think anything uses this yet Thoughts? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] positive Int
On Thu, Aug 02, 2007 at 12:17:06PM -0700, brad clawsie wrote: as far as i know, the haskell standard does not define a basic Int type that is limited to positive numbers. Haskell 98 doesn't have such a type, no, but in today's libraries there is Data.Word.Word. Operations like subtraction will just wrap around when they would otherwise go negative, though (All arithmetic is performed modulo 2^n). for example, 'length' returns an Int, but in reality it must always return a value 0 or greater. a potential counter-argument would be the need to possibly redefine Ord etc for this more narrow type... The main worry I can see with doing that is, would you need to keep explicitly converting between Int and Word? It might be possible to convert enough things to Word that it doesn't matter. You'd also break lots of programs, of course. Thanks Ian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: RE [Haskell-cafe] Monad Description For Imperative
I wrote: But please, let's keep one foot in the real world if possible. Monads were invented to solve the how do I do imperative programming in a pure functional language problem. On 2 Aug 2007, at 7:05 pm, Greg Meredith wrote: This is more than a little revisionist. Monads have been the subject of mathematical study before people had an inkling that they might apply to problems in computer science. Moggi didn't invent them, but noticed that they might have an application to issues of composition in computation. It is really intriguing that they do such a remarkable job of organizing notions of update and were not invented with this application in mind. So, revising history thus would be a real loss. I apologise for the unclarity of what I wrote. I should have said something like Monads-in-computing were adopted to solve... It is considerably more than a little revisionist to identify Haskell monads with Category Theory monads. Quoting the Wikipedia article on monads: If F and G are a pair of adjoint functors, with F left adjoint to G, then the composition G o F will be a monad. Note that therefore a monad is a functor from a category to itself; and that if F and G were actually inverses as functors the corresponding monad would be the identity functor. So a category theory monad is a functor from some category to itself. How is IO a a functor? Which category does it operate on? What does it do to the points of that category? What does it do to the arrows? Let's turn to the formal definition: If C is a category, a monad on C consists of a functor T : C → C together with two natural transformations: η : 1 → T (where 1 denotes the identity functor on C) and μ : T2 → T (where T2 is the functor T o T from C to C). These are required to fulfill [some] axioms: What are the natural transformations for the IO monad? I suppose there is a vague parallel to return and =, but that's about all you can claim for it. If we are not to be revisionist, then we must admit that Haskell monads were *inspired* by category theory monads, but went through a couple of rounds of change of notation before becoming the Monad class we know and love today. What we have *was* invented for functional programming and its category theory roots are not only useless to most programmers but quite unintelligible. We cannot (and I do not) expect our students to *care* about monads because of their inspiration in category theory but because they WORK for a problem that had been plaguing the functional programming community for a long time. This is why I say you must consider your audience. One of the unusual things about Haskell is the strength and breadth of its links to theory and the number of people who are *interested* in that theory as an aid to finding ways to make new kinds of programming thinkable. I don't suppose we'd have had Arrows without this kind of background. But few students in most Computer Science departments take category theory, and those people need monads explained in terms they will be able to understand and to grasp the *practical* significance of. Once they catch the Haskell spirit they may well become interested in the theory, but that stuff doesn't belong in tutorials. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Dimensional 0.6 -- Statically checked physical dimensions
David Roundy wrote: On Thu, Aug 02, 2007 at 10:27:47PM +0200, Björn Buckwalter wrote: I am also assuming that the CGS system would not be employed when working with temperature, amount or luminosity. This is evident in the below type signatures where I have assumed zero extent in the temperature, amount and luminosity dimensions. If this is incorrect I would appreciate pointers to the CGS representation of these dimensions. Please correct and inform me if my assumptions are wrong! The temperature units are the same in CGS as in MKS (Kelvin). Which implies that CGS is applicable to temperatures... what is the (conventional) dimension of temperature in CGS? Is it the same as for Energy (L^2 M^1 T^-2)? This is a very rudimentary implementation. To make it more practical a significant number of quantities and units, in particularly those commonly used with the CGS, would need to be added. In the mean time all units defined for the SI can be used with the CGS by applying 'fromSI' to quantities defined from the SI units. If anyone is willing to add quantities/units (or other enhancements) I will happily to accept patches. Personally I do not expect to use this module and therefore do not intend to invest much more time in it. If the module has other users I might reconsider. And of course, another direction of future work is to define additional systems (e.g. natural, relativistic) using this module as a template. I imagine this should be fairly straight forward. When atomic units are implemented, this could be useful for me... but alas I very seldom use Haskell for physics, and the effort to learn these modules seems unlikely to pay off soon. :( Learning to use the modules should require little effort. Learning enough to implement the atomic system of units would require significant effort though. Unfortunately I don't see myself implementing atomic units, at lease not anytime soon. Thanks, Bjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: RE [Haskell-cafe] Monad Description For Imperative
ok wrote: It is considerably more than a little revisionist to identify Haskell monads with Category Theory monads. So a category theory monad is a functor from some category to itself. How is IO a a functor? Which category does it operate on? What does it do to the points of that category? What does it do to the arrows? IO is a fully paid up Monad in the categorical sense. The category is the category whose objects are types and whose arrows are functions between those types. IO is a functor. The object a maps to IO a. An arrow f::a-b maps to (= return . f)::IO a - IO b and that can be used to make IO an instance of Functor. The natural transforms eta and mu are called return and join. I make no claim that beginners need to know this stuff, but it's useful to understand when you start having to compose monads and create new monads. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: RE [Haskell-cafe] Monad Description For Imperative
My category theory is pretty weak, but I'll take a stab (others can
correct me if I say something stupid):
ok wrote:
It is considerably more than a little revisionist to identify Haskell
monads with Category Theory monads.
Quoting the Wikipedia article on monads:
If F and G are a pair of adjoint functors, with F left adjoint to G,
then the composition G o F will be a monad.
Note that therefore a monad is a functor from a category to itself;
and that if F and G were actually inverses as functors the corresponding
monad would be the identity functor.
So a category theory monad is a functor from some category to itself.
How is IO a a functor?
It is an endofunctor in the category whose objects are Haskell types and
whose arrows are Haskell functions.
Which category does it operate on? What does it
do to the points of that category? What does it do to the arrows?
It maps objects (Haskell types) to boxed types (Haskell monads), i.e.
sets of values of a certain type to sets of computations resulting in a
value of that type.
It maps arrows (Haskell functions) to Kleisli arrows, i.e. it maps the
set of functions {f : a - b} into the set of functions {f : a - m b}.
Let's turn to the formal definition:
If C is a category, a monad on C consists of a functor T : C → C
together with two natural transformations: η : 1 → T (where 1
denotes the identity functor on C) and μ : T2 → T (where T2 is
the functor T o T from C to C). These are required to fulfill
[some] axioms:
What are the natural transformations for the IO monad?
η is the unit Kleisli arrow:
return :: (Monad m) = a - m a
μ : T2 → T is the join function
join :: (Monad m) = m (m a) - m a
I suppose there
is a vague parallel to return and =, but that's about all you can claim
for it.
There is more than a vague claim. From
http://www.haskell.org/haskellwiki/Monads_as_containers:
(=) :: (Monad m) = m a - (a - m b) - m b
xs = f = join (fmap f xs)
join :: (Monad m) = m (m a) - m a
join xss = xss = id
If we are not to be revisionist, then we must admit that Haskell monads
were *inspired* by category theory monads, but went through a couple of
rounds of change of notation before becoming the Monad class we know and
love today.
Apparently only some of use love Haskell monads! :) The notation seems
like a pretty straightforward mapping to me.
What we have *was* invented for functional programming and
its category theory roots are not only useless to most programmers but
quite unintelligible.
I would say applied rather than invented. Clearly useless and
unintelligible are predicates of the programmer.
We cannot (and I do not) expect our students to
*care* about monads because of their inspiration in category theory but
because they WORK for a problem that had been plaguing the functional
programming community for a long time.
Maybe you should raise your expectations?
This is why I say you must consider your audience.
On second thought, maybe I should have considered my audience before
replying to your email. The prior probability of persuasion occurring is
maybe somewhat small, but I'm a sucker for lost causes...
Dan Weston
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] positive Int
On 8/2/07, David Roundy [EMAIL PROTECTED] wrote: This would be a very nice type to have (natural numbers), but is a tricky type to work with. Subtraction, for instance, wouldn't be possible as a complete function... There is a subtraction-like operation for naturals, where a - b = 0 if a = b. This is analogous to the way that drop n xs returns [] if n = length xs, but using it in a Num instance would probably violate too many assumptions. The desire to support naturals was the motivation for including semirings in my Num refactoring thought-experiment. http://article.gmane.org/gmane.comp.lang.haskell.cafe/15141/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] positive Int
On Fri, Aug 03, 2007 at 01:45:03AM +0100, Neil Mitchell wrote:
Hi
Catch (www.cs.york.ac.uk/~ndm/catch) can infer that certain uses of
numbers fit into the {Neg, Zero, One, Pos} abstraction - so for
example it can infer that length returns {Zero, One, Pos}, but not
Neg. If you then do:
xs !! length ys
It will detect that length ys is natural, and will be safe. However,
if you pass any arbitrary value as the index to !! it will warn of a
possible pattern match error.
I hope catch doesn't actually think that's safe, because it's not - set
ys = xs = [1,2,3,4,5], you'll get an index out of range error. (Yes, I
deliberately chose a list longer than 4 elements).
Stefan
signature.asc
Description: Digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] positive Int
Hi
Catch (www.cs.york.ac.uk/~ndm/catch) can infer that certain uses of
numbers fit into the {Neg, Zero, One, Pos} abstraction - so for
example it can infer that length returns {Zero, One, Pos}, but not
Neg. If you then do:
xs !! length ys
It will detect that length ys is natural, and will be safe. However,
if you pass any arbitrary value as the index to !! it will warn of a
possible pattern match error.
You can of course use type Nat = Int, and write additional
documentation, even if this documentation isn't a static guarantee.
Thanks
Neil
On 8/2/07, brad clawsie [EMAIL PROTECTED] wrote:
as far as i know, the haskell standard does not define a basic Int
type that is limited to positive numbers.
would a type of this kind not potentially allow us to make stronger
verification statements about certain functions?
for example, 'length' returns an Int, but in reality it must always
return a value 0 or greater. a potential counter-argument would be the
need to possibly redefine Ord etc for this more narrow type...
___
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] Perfect example
Hi I know that Audrey Tang (the Pugs project) has used hamming numbers for this, see http://www.perl.com/lpt/a/959 Thanks Neil On 8/2/07, Jon Harrop [EMAIL PROTECTED] wrote: Any suggestions for a perfect example that uniquely demonstrates the benefits of the Haskell language compared to other languages? -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. OCaml for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists/?e ___ 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] monad subexpressions
Hi Chris, I've heard Simon (Peyton-Jones) twice now mention the desire to be able to embed a monadic subexpression into a monad. I think this is a fantastic idea, please do so! $( expr ) -- conflicts with template haskell ( - expr ) -- makes sense, and I think it's unambiguous Other ideas: ``expr`` -- back-ticks make sense for UNIX shell scripters (| expr |)-- I don't think anything uses this yet This final (| one |) looks way too much like template haskell, it has the feel of template haskell, even if it isn't yet in the syntax. Your (- proposal) feels a bit like an operator section - I'm not sure if that is a good thing or a bad thing, but for some reason feels slightly clunky and high-syntax overhead, perhaps because of the inevitable space between the - and expr, and that ()- are all fairly high semantic value currently in Haskell, while this extension should blend in, rather than stand out. The `` syntax is clever, and I like it, but I worry that its quite a long way from the current use of ` as infix, although I'm not sure if that is a particular issue given - (negation/subtraction) and -- (comment) couldn't be more different. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Perfect example
That's a tough one, If I want a small example to show to people I usually use zipWith. It is higher-order and lazy, and I include a discussion of lists as loops, which means zipWith is a loop combiner. When my audience is C programmers I ask them to implement it in C, which is always amusing. As an added bonus it has a lovely type signature, which can be used as a lead-in to a discussion on types. If I want a more realistic example, then I usually show people a piece of haskell gtk code, again comparing it to C or whatever language the audience knows. The Haskell gtk code tends to read very nicely, and it is type safe. It also emphasises the fact that Haskell is not only able to to real things, but able to do them really well. I doubt either are perfect, but maybe they will inspire you to dream up something which suits your needs. Cheers, Bernie. On 03/08/2007, at 5:02 AM, Jon Harrop wrote: Any suggestions for a perfect example that uniquely demonstrates the benefits of the Haskell language compared to other languages? -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. OCaml for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists/?e ___ 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] positive Int
Hi It will detect that length ys is natural, and will be safe. However, if you pass any arbitrary value as the index to !! it will warn of a possible pattern match error. I hope catch doesn't actually think that's safe, because it's not - set ys = xs = [1,2,3,4,5], you'll get an index out of range error. (Yes, I deliberately chose a list longer than 4 elements). Of course, it doesn't, I abstracted for the sake of simplicity :-) The !! operator has two entirely separate pattern match errors, one is negative index, one is ran off the end of the list. The length xs will satisfy the first one by proving that length is always a natural, but the only proof of the other condition is that either the list is infinite, or that the index is Zero/One, and the list is bigger than this. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: RE [Haskell-cafe] Monad Description For Imperative
I asked How is IO a functor? On 3 Aug 2007, at 11:50 am, Dan Piponi wrote: IO is a fully paid up Monad in the categorical sense. The category is the category whose objects are types and whose arrows are functions between those types. IO is a functor. The object a maps to IO a. An arrow f::a-b maps to (= return . f)::IO a - IO b and that can be used to make IO an instance of Functor. The natural transforms eta and mu are called return and join. Please go over this again, but slowly this time. You have convinced me, but I'd like to understand the details a little better. I see that any type constructor TC :: * - * is halfway to being a functor on this category of types. It acts on the objects in the obvious way, so the next step is to see about the arrows. If f :: a - b then we want TC f :: TC a - TC b such that TC (f . g) = TC f . TC g and TC (id::a-a) = id :: TC a - TC a Now this is precisely the Haskell Functor class, so TC is the object part and fmap is the arrow part. You say that (= return . f) can be used to make [a Monad] an instance of Functor. Try it... by golly it's true. I see: fmap f = (= return . f). So why *aren't* Monads already set up using the type class machinery to always *be* Functors in Haskell? Isn't it bound to confuse people if monads are functors but Monads are not Functors? This is especially puzzling because Maybe, [], and IO already *are* Functors, but the way this is done makes it look accidental, not like the fundamental property of Monads it apparently is. (By the way, I note that the on-line documentation for Control.Monad glosses = as Sequentially composes two actions) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: RE [Haskell-cafe] Monad Description For Imperative
On 8/2/07, ok [EMAIL PROTECTED] wrote: I asked How is IO a functor? Please go over this again, but slowly this time. Try it... by golly it's true. I'm not fibbing. I was surprised as you when I found out about this stuff! So why *aren't* Monads already set up using the type class machinery to always *be* Functors in Haskell? Isn't it bound to confuse people if monads are functors but Monads are not Functors? I think it's simply an uncorrected mistake in the prelude. Also, check out Eric Kidd's lesser known laws here: http://www.randomhacks.net/articles/2007/03/15/data-set-monad-haskell-macros These follow from the category theory. I personally find the join/return version of the monad laws easier to think about than any other formulation. BTW Natural transformations are particularly nice in the category of types and functions. They're essentially just polymorphic functions of a certain type. But this means that they're candidates for Theorems for Free! http://homepages.inf.ed.ac.uk/wadler/topics/parametricity.html so they have good properties. So there's a nice little collection of small but useful theorems about =, return, join, fmap and so on that you can deduce from a small amount of category theory. You can deduce them all without the category theory, but I find it useful to see these things in a wider context as they no longer seem like these random identities that hold for no apparent reason. I completely agree with you that beginners don't need to know the category theory. But I highly recommend the first couple of chapters of your favourite CT textbook (up to natural transformations at least, and up to adjoints if you can stand it) to Haskellers with a mathematics background as soon as they are beyond the beginnings. It really does give a bit of insight into a few areas of Haskell. (Oh, that Eric Kidd web page will also answer your earlier question about why Data.Set isn't a Haskell Monad even though the powerset functor is a monad in the category Set.) -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC, GLUT and OS X
Ok, after spending some time looking for a solution, here is a stroke of genius by wxHaskell folks at http://wxhaskell.sourceforge.net/building-macosx.html I've tried this enableGUI trick using GHCi, it works with my GLFW interface to Haskell which suffered from the same problem as GLUT on OS X, but then it still won't work with GLUT. So, does anyone have a clue of what's going on with GLUT on OS X? Regards, Paul Liu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: monad subexpressions
On Thu, 2007-08-02 at 21:29 -0600, Chris Smith wrote: Neil Mitchell [EMAIL PROTECTED] wrote: I think this is a fantastic idea, please do so! Okay, I'll do it then. If I have a good weekend, perhaps I'll volunteer a talk at AngloHaskell after all! :) So what about syntax? I agree with your objections, so we've got ( - expr ) -- makes sense, and I think it's unambiguous ``expr`` -- back-ticks make sense for UNIX shell scripters The first is something Simon Peyton-Jones came up with (probably on-the- fly) at OSCON, and I rather like it a lot; but I'm concerned about ambiguity. The latter seems sensible as well. Any other ideas? The latter is not sensible to me at all. It doesn't nest well. Neither does the former for that matter, but it forces parenthesizing. You will find that being clear on nesting is very important. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] When is waitForProcess not necessary?
bayer: If one is calling runInteractiveCommand for a sure-thing returning a small amount of output (say, ls for a modest directory), is it necessary to call waitForProcess? My waitForProcess calls came under scrutiny when I tried to GHC profile a threaded process, which isn't possible. It turns out that my programs run faster if they don't call waitForProcess, and it sure seems empirically that they never fail to run correctly. It would seem to me that in a lazy language, later code wouldn't presume it was looking at an entire string until the actual EOF came through, completing the string. So at the end of a program, with nothing else to do but wait, why not wait implicitly rather than via an explicit call to waitForProcess? What am I missing? (I've searched this forum; an interesting example is runCommand in http://happs.org/HAppS/src/HAppS/Util/Common.hs but I'm asking why this isn't overkill in my scenario. I'm actually calling Markdown.pl on tiny files (source code of lengths a human would read), and it is certainly sluggish enough to be a fair test.) ___ You might be interested in : http://www.cse.unsw.edu.au/~dons/code/newpopen/ In particular, readProcess :: FilePath -- ^ command to run - [String] -- ^ any arguments - String -- ^ standard input - IO (Either ExitCode String) -- ^ either the stdout, or an exitcode Strict String IO for processes, without the zombies. -- Don Stewart (Authorised by the People for System.IO.Strict party) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: monad subexpressions
Neil Mitchell [EMAIL PROTECTED] wrote: I think this is a fantastic idea, please do so! Okay, I'll do it then. If I have a good weekend, perhaps I'll volunteer a talk at AngloHaskell after all! :) So what about syntax? I agree with your objections, so we've got ( - expr ) -- makes sense, and I think it's unambiguous ``expr`` -- back-ticks make sense for UNIX shell scripters The first is something Simon Peyton-Jones came up with (probably on-the- fly) at OSCON, and I rather like it a lot; but I'm concerned about ambiguity. The latter seems sensible as well. Any other ideas? -- Chris Smith ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Re: monad subexpressions
Derek Elkins [EMAIL PROTECTED] wrote:
( - expr ) -- makes sense, and I think it's unambiguous
``expr`` -- back-ticks make sense for UNIX shell scripters
The latter is not sensible to me at all. It doesn't nest well.
Ah, excellent point! Okay, it's gone then. Everything will then need
some kind of bracketing -- (), [], or {}. I dislike [] out of hand,
simply because this has nothing to do with lists.
Neither does the former for that matter, but it forces parenthesizing.
I'm unclear on whether you still have an objection, given that yes it
does force parenthesizing.
--
Chris Smith
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Perfect example
Hello Jon, Thursday, August 2, 2007, 11:02:14 PM, you wrote: Any suggestions for a perfect example that uniquely demonstrates the benefits of the Haskell language compared to other languages? http://www.haskell.org/haskellwiki/Simple_unix_tools -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
