Re: syntactic sugar for "arrows"
>Ross Paterson wrote: >> >> John Hughes has defined a new abstract view of computation, in his >> (currently draft) paper "Generalising Monads to Arrows", at >> >> http://www.cs.chalmers.se/~rjmh/Papers/arrows.ps > >Has anyone else read this paper? I'm interested in hearing comments, if >only to point out some things that I may have missed. I'll admit, I >haven't read the entire paper. I gave up after the 16th page, because it >was so conceptually unwieldy. It's not that I had difficulty >understanding how the system works, it's just that I found it difficult >to believe that such a complex system would be useful in general >practice. I've only skimmed it, but it sure looks useful to me. (Thanks for making us aware of it, Ross.) I've been wondering for a long time about how to make the LL parsers fit into the monadic framework, and now we have not only a way to do that, but a more general method for making parts of any suitable monadic library static. I think once we see some more examples using Ross's notation rather than John's point-free one, the uses of the technique will become more obvious. The thing to remember is that you can write your library and application using monads first, then, once you're sure the semantics are right, you can go back and optimize it with arrows by stratifying the computation. Even better, you could write your library in monadic form, but write the application using arrows. You can use the coercions in the paper to transform your monad into an arrow type (Kleisli arrows), and if you use Ross's notation in your application, you could more or less get away with thinking of it as just the usual monadic stuff. That way you can go back and optimize the library without needing to change the application. (Of course, you need to make sure that the application doesn't use all the inherent power of the monad.) >(Also, I'm not a mathematician who does a significant amount >of work in category theory, so that may contribute to its apparent >awkwardness to me. --FC
Re: Haskell Object
Hi, >I'm using HaskellObject inside Visual Basic 6.0. If I create only 1 object >(or 2 objects that have the same source), no problem happen. But when I >create 2 objects (different source), Visual Basic 6.0 was crashed. > >Do you know why? Would you please reply as soon as possible ! HaskellObject is part of ongoing research. Its first release was just two weeks ago so it probably contains some bugs. Its design has already changed somewhat and my current build runs more objects in differents sources without problems. I hope to put a new build on the web in a week or two. All the best, Daan. ps. HaskellObject is part of a research project at Utrecht. Please do not use the Haskell mailing list for questions, but write to us personally. We are interested in you experiences.
Haskell Object
Hello ! I'm using HaskellObject inside Visual Basic 6.0. If I create only 1 object (or 2 objects that have the same source), no problem happen. But when I create 2 objects (different source), Visual Basic 6.0 was crashed. Do you know why? Would you please reply as soon as possible ! Thank you very much !
Re: Haskell Object
> Where can I find out more about HaskellObject? I am very interested >in this. All you ever want to know about H/Script, H/Direct, H/Object, H/DB can be found at the haskell.org website (http://haskell.systemsz.cs.yale.edu/haskellscript/). Stay tuned for more useful products in the near future. Erik "Haskell, the world's best scripting language" Meijer
Re: Haskell Object
Where can I find out more about HaskellObject? I am very interested in this. THanks! +++ Ron Legere Caltech Quantum Optics MC 12-33 Pasadena CA 91125 626-395-8343 FAX: 626-793-9506 +++
Re: Haskell 98 final stuff
Simon writes: > 2. The data and type constructors > (), (,), (,,), etc > [] > (->) > are all regarded as "syntax", not as identifiers. They always mean > their standard meaning (tuples, empty list or list type constructor). > [No change here.] > > The question is: what about the list constructor ":". In principle > we could regard it as an ordinary identifier, and therefore allow someone > to redefine it... but [there are problems.] > > I have concluded that it is simpler to treat ":" as syntax, exactly > uniformly with the others. It always means list construction, and > it cannot be hidden or redefined. > Section 2.4. Clarify that : is reserved solely for Haskell > list construction. What does this mean? Will there only be a remark, or will the syntax be changed? The other constructors are explicitely handled by the syntax, so I guess this should be done in this case also. Doing that 'exactly uniformly' would mean productions for expressions e:e, patterns (p:p) and the constructor (:). But we surely don't want to loose the sections (e:) and (:e). Please don't forget them! All the best, Christian Sievers
Re: syntactic sugar for "arrows"
Ross Paterson <[EMAIL PROTECTED]> writes: > Time to ditch all those dusty old monads and upgrade to arrows. > However the point-free style of that paper won't appeal to everyone. > I've placed a proposal for a Haskell extension with a do-notation-style > syntax for arrows at > > http://www.soi.city.ac.uk/~ross/notes/ArrowsInHaskell.html > > Comments welcome. I'd like to point out one thing about the implementability of your new syntax. Implementing the layout rule in Haskell requires a tricky dance of passing information back and forth between the lexer and parser. One thing that can ease the implementation is that the lexer can know when a layout group starts, using the rule that the next token after a 'let', 'do', 'where', or 'of' (did I miss any?) starts layout, unless it's an open brace. That is, the layout openers are all reserved words, and are always layout openers wherever they appear. Your syntax breaks this, since it makes '->' be a layout opener in some but not all places it can appear. Carl Witty [EMAIL PROTECTED]
RE: syntactic sugar for "arrows"
interface for libraries (rather than monads). It seems like he would supply a monad interface to arrow libraries for those libraries which are expressible as monads and for which the user prefers the monad primitives. The monad interface to arrows would be completely generic. The library writer would still expose the library using arrows not monads. As a library user, I think I would prefer the arrow interface to the Monad interface. For example, even for basic stuff like IO programming, the arrow interface seems to give you more power. Speculatively (e.g. I am guessing here), arrows could make Haskell an extremely powerful shell programming language as you could easily pipe I/O to/from various Haskell libraries with arrow interfaces (pipes). If I understand correctly, Monads require you to do some extra homework to get concurrency working properly in this context. Hence the point in the paper about arrows being a generalization of the fudgets concurrency abstractions. More generally you could access any external unix process in the same way you access arrow libraries so that rather than using a regexp library written in Haskell, you just pipe your Haskell String through unix grep. e.g. > foo = catFile myFile >>> sys ["grep",mystring] >>> someArrowLib And other much more complex stuff involving multiple input and output files. -Alex- PS. Notationally, pointfree works fine for much shell programming of this type ___ S. Alexander Jacobson i2x Media 1-212-697-0184 voice1-212-697-1427 fax On Thu, 28 Jan 1999, David Bakin (Exchange) wrote: > Except that he does say in the conclusion of the paper: "This paper > proposes the replacement of monads as a structuring tool for combinator > libraries, by arrows." > > I don't think he made that argument though; I think the argument he made was > that arrows could be an alternative structuring tool for combinator > libraries that supply additional power at some cost in convenience. The > second paragraph of the conclusion pretty much describes when arrows could > and should be used. And he ends the paper with "In short, we believe that > arrows offer a useful extension to the generality of generic library > interfaces", a reasonable (and understated) claim. > > -- Dave > > -Original Message- > From: David Barton [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 28, 1999 7:44 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: syntactic sugar for "arrows" > > > Michael Hobbs writes: > >Yes, I can see how the arrow paradigm would work very well for >things such as parsing LL(1) grammars, but I could not see how such >a scheme could become a _replacement_ for monads in general purpose >programming. Perhaps I was expecting the wrong thing from the >concept... > > I agree, and (not to speak for John Hughes, but I will anyway) I > suspect John would as well. >
Hugs Logo Contest
Attention graphic designers! We need a logo for Hugs! See haskell.org/hugs/logo.html for details about the Hugs logo contest. Win prizes!! John
