[Haskell-cafe] ANN: stm-chans: Additional types of channels for STM.
-- stm-chans 1.0.0 The stm-chans package offers a collection of channel types, similar to Control.Concurrent.STM.TChan but with additional features. In particular it offers these types: * Control.Concurrent.STM.TBChan: Bounded FIFO channels. When the channel is full, writers will block/retry. This ensures that the writers do not get too far ahead of the readers, which helps to make sure that memory and cpu resources are used responsibly. * Control.Concurrent.STM.TMChan: Closeable FIFO channels. This is like TChan (Maybe a) but with a monotonicity guarantee that once Nothing is returned all future reads will be Nothing as well. * Control.Concurrent.STM.TBMChan: Bounded Closeable FIFO channels. This combines the capabilities of TBChan and TMChan. In addition, the stm-chans package offers a (partial) compatibility layer for some API improvements still making their way into the stm package[1]. These new functions include: * tryReadTChan :: TChan a -> STM (Maybe a) A version of readTChan which does not retry. Instead it returns Nothing if no value is available. * peekTChan :: TChan a -> STM a Get the next value from the TChan without removing it, retrying if the channel is empty. * tryPeekTChan :: TChan a -> STM (Maybe a) A version of peekTChan which does not retry. Instead it returns Nothing if no value is available. [1] http://article.gmane.org/gmane.comp.lang.haskell.libraries/15507 -- Links Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/stm-chans Darcs: http://community.haskell.org/~wren/stm-chans Haddock (Darcs version): http://community.haskell.org/~wren/stm-chans/dist/doc/html/stm-chans -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HDF5 binding (was: why is ghci trying to load hsc file ??)
>>> I worked out a small hdf5 binding using cabal and bindings-DSL and >>> sqlite3 as my example. >> I just wanted to add that I also started an HDF5 binding recently >> (using hsc2hs only). It does more than enough for me ATM, so I don't >> develop it actively, but if you want to pursue this (and I think >> it would be a useful addition to Hackage), we may share experience >> and code. My binding is part of a bigger project, but I meant to >> split it out anyway. > What an interesting coincidence, that makes at least three of > us. Apparently it's an idea whose time has come. Mine is also an > incomplete low-level binding but is currently under semi-active > development and I aim to make it cover the entire hdf5.h interface. > If anyone is interested in it I've put it on github at: > > https://github.com/mokus0/bindings-hdf5 > Bindings to the full hdf5 were supposed to be in the example set for bindings-DSL. It doesn't use pkg-config, though, and hdf5 developers didn't like the idea of adding support. I wanted reference bindings-* libraries to be free of linking problems some users might not be able to solve or understand, so I gave up. Best, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] llvm package on Windows
I am trying to install llvm-0.9.0.1 on Windows (through cygwin), on top of a clean install of Haskell Platform 2010.2.0.0. I do cabal install llvm --configure-option --with-llvm-prefix="C:\\llvm" (which is where I unpacked llvm-gcc4.2-2.8-x86-mingw43.tar.bz2). This fails with .mingw\bin\ld.exe: cannot find -lLLVMXCoreAsmPrinter (which is indeed the first -l option on the gcc line). [I also tried the llvm-ht package, same issue; I can't tell which of the 2 packages is 'best' from the online doc] Perhaps I need to 'install' llvm more thoroughly? [Most of the instructions online seem to assume you want to use llvm-gcc, which is not my case] Any clues? Jacques ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: FreeType 2 Bindings
On Sun, Apr 3, 2011 at 4:21 PM, Jason Dagit wrote: > I'm excited to announce the immediate availability of FreeType 2 bindings > on hackage. These bindings are based off the 2.4.4 release of FreeType 2 > and use the BSD licensing option for FreeType 2. This package should be of > interest to OpenGL users as it provides a way to get nice looking fonts into > your OpenGL programs. I almost forgot to mention: An import feature of my cabalization of freetype2 is that NO external libraries are needed. Just install it with cabal or cabal-dev on linux, osx, or windows and you're ready to go. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: FreeType 2 Bindings
I'm excited to announce the immediate availability of FreeType 2 bindings on hackage. These bindings are based off the 2.4.4 release of FreeType 2 and use the BSD licensing option for FreeType 2. This package should be of interest to OpenGL users as it provides a way to get nice looking fonts into your OpenGL programs. This binding is still in its infancy, hence version 0.0.1, but enough of the API is exposed that I was able to convert the example1.c program in the FreeType tutorial to Haskell. Here are a few relevant links: * What is FreeType: http://www.freetype.org/freetype2/index.html * Example program and tutorial: * http://www.freetype.org/freetype2/docs/tutorial/step1.html * http://www.freetype.org/freetype2/docs/tutorial/example1.c * Haskell version of tutorial: * https://github.com/dagit/freetype2/blob/cabalization/Main.hs * Example program output (yes, their tutorial example really does draw the bitmap as a grid of text, scroll around to find the word "blah"), more interesting examples to come later: * http://hpaste.org/45239/aoeu The current API level is "raw" and makes no attempts to present a good Haskell-like interface to the library. My plan is to build a higher level interface on top once a sufficient portion of the API is available to Haskell. You can find the source on github in the cabalization branch: * https://github.com/dagit/freetype2 Patches welcome! Thanks, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell programs as specifications
> From: Patrick Browne > Sent: Sun, April 3, 2011 9:04:22 AM > ... > 2)My second question is more theoretical. It is stated by the author > that type checking and excitability provide verification. I don't know what "excitability" has to do with verification. Type checking in Haskell provides some degree of verification. Besides the basic guarantees that the function will actually return a value of the type the signature claims, more complicated types (often involving parametric polymorphism) can be used to enforce some higher level properties. Also, because Haskell is a pure language, which means all the arguments and results are explicit. In a language like Java, methods might also change variables elsewhere. This does not show up in the type, so just checking the types tells you less about whether a Java function might be correct. > In this case > verification probably means checking that an instance is consistent with > its type class. Does verification using these techniques in Haskell have > any firmer logical foundation than say doing the verification in Java? Yes. The type system in Java lacks parametric polymorphism, for one. The Haskell type system can often provide some guarnatees about correct operation of a function, especially through "free theorems" http://www-ps.iai.uni-bonn.de/cgi-bin/free-theorems-webui.cgi There are stronger type systems in languages/proof assistants such as Coq or Agda, which really do let you prove anything you like about functions. > I am aware that Haskell uses inference for type checking, but is the net > result superior to compilers that do not use inference? It's the design of the type system which produces good results. It would still tell you just as much about your program if there was no type inference, but it would be annoying to have to write out so many types. Even languages like C or Java do some type inference so you don't have to write down the type of every subterm of an expression - it's int x = f(12 * y + z); not int x = (int)f((int)((int)((int)12*(int)y)+(int)z); > Also, is Haskell execution based purely on logic? I'm not entirely sure what this means either. Evaluation expressions is pure and functional and can be done by rewriting or graph reduction. There are also things like threads and IO which are more imperative. Evaluation is certainly not based on logic in the same sense as Prolog - there's no unification or backtracing. Brandon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] fundeps => type family
Ryan, That did it! Thanks a lot for your help. Tad On Sun, Apr 3, 2011 at 1:14 PM, Ryan Ingram wrote: > > > On Sun, Apr 3, 2011 at 1:00 PM, Tad Doxsee wrote: >> >> "Equality constraints ... enable a simple translation of programs >> using functional dependencies into programs using family >> synonyms instead. >> >> So I tried: >> >> class (T s ~ a) => ShapeC a s where >> type T s :: * >> draw :: s -> String >> copyTo :: s -> T s -> T s -> s >> >> but got a compile error: >> >> Alas, GHC 7.0 still cannot handle equality superclasses: T s ~ a >> >> So my question is, how does one convert the above code to use type >> families instead of functional dependencies? Is one technique >> preferable over another? > > Sadly the documentation assumes the feature that you show is missing. That > said, you don't need that feature for the simple FD you have. > > Just do > > class ShapeC s where > type T s :: * > draw :: s -> String > copyTo :: s -> T s -> T s -> s > > > This code should work: > > data ShapeD a = forall s. (ShapeC s, a ~ T s) => MkShapeD s > > instance ShapeC (ShapeD a) where > type T (ShapeD a) = a > draw (MkShapeD s) = draw s > copyTo (MkShapeD s) x y = MkShapeD (copyTo s x y) > > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [ANNOUNCE] Data-flow based graph algorithms
Hi! Based on my Etage data-flow framework: http://hackage.haskell.org/package/Etage I have made a package to show how to implement graph algorithms on top of it: http://hackage.haskell.org/package/Etage-Graph I invite everybody to take a look and see how it is possible to implement known control-flow algorithms in a data-flow manner. For now, only shortest paths search is implemented (from all to all nodes). The nice feature is that such approach is easily parallelized. It quite heavily uses Haskell threads so it is also useful to benchmark and test them, especially for graphs with many nodes (> 300). There is documentation, but because of this bug it is not visible: http://hackage.haskell.org/trac/hackage/ticket/656 Mitar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] fundeps => type family
On Sun, Apr 3, 2011 at 1:00 PM, Tad Doxsee wrote: > "Equality constraints ... enable a simple translation of programs >using functional dependencies into programs using family >synonyms instead. > > So I tried: > > class (T s ~ a) => ShapeC a s where > type T s :: * > draw :: s -> String > copyTo :: s -> T s -> T s -> s > > but got a compile error: > > Alas, GHC 7.0 still cannot handle equality superclasses: T s ~ a > > So my question is, how does one convert the above code to use type > families instead of functional dependencies? Is one technique > preferable over another? > Sadly the documentation assumes the feature that you show is missing. That said, you don't need that feature for the simple FD you have. Just do class ShapeC s where type T s :: * draw :: s -> String copyTo :: s -> T s -> T s -> s This code should work: data ShapeD a = forall s. (ShapeC s, a ~ T s) => MkShapeD s instance ShapeC (ShapeD a) where type T (ShapeD a) = a draw (MkShapeD s) = draw s copyTo (MkShapeD s) x y = MkShapeD (copyTo s x y) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Ann: contstuff, dnscache, ihttp, ismtp, netlines, yesod-tableview
Hello fellow Haskellers, (once again posted to the cafe, because the Haskell mailing list rejects my mails.) I have released quite a few libraries over time on Hackage. I feel they are stable enough now to announce them here. * contstuff: Fast and flexible monad transformers based on the CPS concept. Mainly it helps getting rid of large transformer stacks, because it unifies some monad transformers (like StateT and ContT), and it is also faster than the naive approach. This library is comparable to a combination of the transformers package with Edward Kmett's monad-ran package, but without hiding the CPS transformation. In early benchmarks ChoiceT turned out to be twice as fast as normal Haskell lists, and it is also a proper list monad transformer. Finally in the Control.ContStuff.Classes module you find lots of useful utility classes, which seem to be unique to contstuff. * dnscache: Handy DNS caching library. This library automatically manages a set of resolver threads for you, which share a reply cache. This allows very fast mass-resolution. The library also comes with a handy command line utility called 'massdns' for quick resolution of even very large lists of entities. Call massdns without arguments to get usage help. * ihttp: This is an HTTP library based on enumerators giving you maximum flexibility and control over the connection. Using proper iteratees you can simply implement e.g. proxy clients (my main use case), but also HTTP servers. Using proper enumeratees you can also encapsulate the connection in an SSL/TLS layer, but unfortunately there doesn't seem to be such an SSL/TLS implementation yet. * ismtp: This is an advanced ESMTP library, which allows you to structure your sessions as you like. It also features an automated resolver for MX records using the dnscache library. Right now there is support for most of the base functionalities of the protocol as specified in RFC 821 (SMTP) and RFC 1425 (service extensions). An update to RFC 2821 is planned, but is not necessary for practical purposes. The new RFC mainly removes some unneeded features and unifies the two mentioned RFCs. Right now there is no support for SMTL (SASL) authentication, but it is planned for a near future release. For the time being you can implement your own iteratees for this purpose, if you depend on authentication. * netlines: This is a library for writing implementations of text-based protocols. In particular it allows reading lines safely from untrusted sources with a maximum length in constant space. * yesod-tableview: For web applications using Michael Snoyman's Yesod web framework this library implements an easy to use table renderer mainly for database records. It is in an early stage of development right now, but as the need arises, I will extend it. To use the networking libraries, you should be familiar with John Millikin's 'enumerator' package. If you're not, I recommend studying it, because it is a useful library for all kinds of stream processing like network connections, files and concurrent channels. All mentioned libraries have been tested extensively for correctness and safety. Especially the networking libraries have undergone a lot of penetration testing. However, I'm only one developer, so I would be glad to hear about any vulnerabilities and other shortcomings you find. Usually I have a very short response time to bugs in these libraries, so please don't hesitate to contact me. Feature requests are also welcome, of course. =) Please note that major version numbers specify interface versions in my libraries. In other words, a new major version of a package usually means that the API has changed in a way, which is likely to break dependent packages. I would like to use this opportunity to thank a few people in particular (alphabetically): - Cale Gibbard, - Edward Kmett, - John Millikin, - Bryan O'Sullivan and - Michael Snoyman. I appreciate your efforts both in libraries and support. Many thanks, guys! Thanks also to the rest of the innovative and helpful Haskell community. Greets, Ertugrul -- Key-ID: E5DD8D11 "Ertugrul Soeylemez " FPrint: 0F12 0912 DFC8 2FC5 E2B8 A23E 6BAC 998E CE40 2012 Keysrv: hkp://subkeys.pgp.net/ -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] fundeps => type family
Hi All,
Last week I asked a question with the subject "object oriented
technique". I got a lot very helpful answers and I thank all who
contributed. At the end of my question, I alluded to some problems
that I was having with what I wanted to do next, which was to add
additional polymorphism. I figured out a solution, which is:
-
{-# LANGUAGE ExistentialQuantification #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE FunctionalDependencies #-}
data Rectangle a = MkRectangle { rx, ry, rw, rh :: a }
deriving (Eq, Show)
drawRect :: Show a => Rectangle a -> String
drawRect r = "Rect (" ++ show (rx r) ++ ", " ++ show (ry r) ++ ") -- "
++ show (rw r) ++ " x " ++ show (rh r)
data Circle a = MkCircle {cx, cy, cr :: a}
deriving (Eq, Show)
drawCirc :: Show a => Circle a -> String
drawCirc c = "Circ (" ++ show (cx c) ++ ", " ++ show (cy c)++ ") -- "
++ show (cr c)
r1 = MkRectangle 0 0 3 2
r2 = MkRectangle 1 1 4 5
c1 = MkCircle 0 0 5
c2 = MkCircle 2 0 7
class ShapeC a s | s -> a where
draw :: s -> String
copyTo :: s -> a -> a -> s
{-
-- GADT version
data ShapeD a where
MkShapeD :: ShapeC a s => s -> ShapeD a
-}
-- Existential Quantification version
data ShapeD a = forall s . ShapeC a s => MkShapeD s
instance ShapeC a (ShapeD a) where
draw (MkShapeD s) = draw s
copyTo (MkShapeD s) x y = MkShapeD (copyTo s x y)
mkShape :: ShapeC a s => s -> ShapeD a
mkShape s = MkShapeD s
instance Show a => ShapeC a (Rectangle a) where
draw = drawRect
copyTo (MkRectangle _ _ rw rh) x y = MkRectangle x y rw rh
instance Show a => ShapeC a (Circle a) where
draw = drawCirc
copyTo (MkCircle _ _ r) x y = MkCircle x y r
r1s = MkShapeD r1
r2s = MkShapeD r2
c1s = MkShapeD c1
c2s = MkShapeD c2
shapes1 = [r1s, r2s, c1s, c2s]
drawing1 = map draw shapes1
shapes2 = map mkShape rs ++ map mkShape cs
drawing2 = map draw shapes2
-- copy the shapes to the origin then draw them
shapes3 = map (\s -> copyTo s 0 0) shapes2
drawing3 = map draw shapes3
-
The main difference with my previous version is that the above
is polymorphic in the type for the origin and dimensions.
(I used a Double previously.)
Also, the above version uses existential quantification instead
of GADTs, only because some said that that method is more
"standard".
I had to use functional dependencies in the defintion of class
ShapeC to get it to compile and run.
Ed Yang's excellent post
(http://blog.ezyang.com/2011/03/type-tech-tree)
says that type families are equivalent to multiparameter type classes
+ functional dependencies, so I tried to rewrite the above using
type families, but I got stuck. Also the GHC documentaton
(http://www.haskell.org/ghc/docs/7.0-latest/html/users_guide/type-families.html#id636192)
says that
"Equality constraints ... enable a simple translation of programs
using functional dependencies into programs using family
synonyms instead.
So I tried:
class (T s ~ a) => ShapeC a s where
type T s :: *
draw :: s -> String
copyTo :: s -> T s -> T s -> s
but got a compile error:
Alas, GHC 7.0 still cannot handle equality superclasses: T s ~ a
So my question is, how does one convert the above code to use type
families instead of functional dependencies? Is one technique
preferable over another?
Thanks,
Tad
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell programs as specifications
On Sunday 03 April 2011 21:25:34, Patrick Browne wrote: > Daniel, > I think that the definition of other in Link makes bi-directional travel > possible in prog1. The function other takes an edge and the first node > and returns the other (second) node of that edge. So we can begin our > journey at the end and arrive at the start > > other (Edge (Node "end") (Node "start")) (Node "end") > =gives=> Node "start" > > Or we can begin at the start and end at the end. > > other (Edge (Node "start") (Node "end")) (Node "start") > =gives=> Node "end" > > So prog1 allows a car to go in both directions. If you have edges in both directions, yes. But that's not the point for t1. In t1, you only have (Edge start end), and a car located at start. Then you (try to) move the car along that edge and check whether it is afterwards located at end. other (Edge start end) start =gives=> end, for both, one-way and two-way roads, so the move yields (Car end), its location is end and t1 == True. > > Pat > > On 03/04/2011 15:39, Daniel Fischer wrote: > > On Sunday 03 April 2011 16:04:22, Patrick Browne wrote: > >> Hi, > >> Attached are two programs that represent one-way and two-way traffic > >> on a road. I can get the programs to produce reasonable results that > >> match our intuitive ideas of roads. > >> However, I have 2 question about the programs: > >> > >> 1)I cannot get the result suggested by the author that t1 should give > >> true in prog1 and false in prog2. > > > > Only took a short look, but that'd probably be because it's wrong, t1 > > should give True for both. > > You have a road r from a to b and a car c at a. Then after you move > > the car along the road, it will be located at b, regardless of > > whether it's a one- way road or traffic may flow in both directions. > > This message has been scanned for content and viruses by the DIT > Information Services E-Mail Scanning Service, and is believed to be > clean. http://www.dit.ie ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unboxing CFloat and GLfloat
Jason Dagit schrieb: > While the GLfloat instances don't need to be in base, the CFloat > instance probably should be in base. Is this something I should make a > library proposal for and submit patches? Is there an easier way to get > these instances? Has someone already done this? Maybe the CFloat instance can be in the 'array' package. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell programs as specifications
Daniel, I think that the definition of other in Link makes bi-directional travel possible in prog1. The function other takes an edge and the first node and returns the other (second) node of that edge. So we can begin our journey at the end and arrive at the start other (Edge (Node "end") (Node "start")) (Node "end") =gives=> Node "start" Or we can begin at the start and end at the end. other (Edge (Node "start") (Node "end")) (Node "start") =gives=> Node "end" So prog1 allows a car to go in both directions. Pat On 03/04/2011 15:39, Daniel Fischer wrote: > On Sunday 03 April 2011 16:04:22, Patrick Browne wrote: >> Hi, >> Attached are two programs that represent one-way and two-way traffic on >> a road. I can get the programs to produce reasonable results that match >> our intuitive ideas of roads. >> However, I have 2 question about the programs: >> >> 1)I cannot get the result suggested by the author that t1 should give >> true in prog1 and false in prog2. > > Only took a short look, but that'd probably be because it's wrong, t1 > should give True for both. > You have a road r from a to b and a car c at a. Then after you move the car > along the road, it will be located at b, regardless of whether it's a one- > way road or traffic may flow in both directions. This message has been scanned for content and viruses by the DIT Information Services E-Mail Scanning Service, and is believed to be clean. http://www.dit.ie ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Call for contributions: Second edition of the Typeclassopedia
Hi all, It's time for a second edition of the Typeclassopedia [1], and I'd love to have your suggestions and contributions. You can send me suggestions and darcs patches [2] by email. For more detailed information, see my blog post [3]. -Brent [1] http://www.haskell.org/wikiupload/8/85/TMR-Issue13.pdf [2] http://code.haskell.org/~byorgey/typeclassopedia/ [3] http://byorgey.wordpress.com/2011/04/03/call-for-contributions-second-edition-of-the-typeclassopedia/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] error to Fail Conversion
On Sunday 03 April 2011 16:31:10, Anwar Bari wrote: > HI Cafe > I have problem with this function > value :: Theorm-> [(String,Int)] -> Tem -> Int > value _ env (Var s) = maybe (error "Unknown variable.") id > (lookup s env) value mdl env (OP s _ _ l) = maybe (error "Function not > defined.") id (lookup (map (value mdl env) l) (S.toList $ maybe (error > > "Uknown function.") id (fmap snd (multiLookup s (operations mdl) > > This function is working fine, but I want to change error function to > fail function to be able use it in my GUI application. For that, you have to change the type. If the result type is Int, you can only have it return a bona fide Int or an error. For more graceful failing, the result type needs to support some indication of failure, it could be Maybe Int Either String Int [Int] or others. Normally, using some MonadError would be the most convenient. value :: (Error e, MonadError e m) => Theorem -> Environment -> Term -> m Int replacing maybe (error "foo") id with maybe (throwError $ strMsg "foo") return > I can't change the output of value function to IO Int, If you can change it at all, changing it as above and making your GUI-monad suitable (i.e. providing a MonadError instance for it with a suitable error type) would probably be the simplest. > any idea will help. Thanks > Nour. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell programs as specifications
On Sunday 03 April 2011 16:04:22, Patrick Browne wrote: > Hi, > Attached are two programs that represent one-way and two-way traffic on > a road. I can get the programs to produce reasonable results that match > our intuitive ideas of roads. > However, I have 2 question about the programs: > > 1)I cannot get the result suggested by the author that t1 should give > true in prog1 and false in prog2. Only took a short look, but that'd probably be because it's wrong, t1 should give True for both. You have a road r from a to b and a car c at a. Then after you move the car along the road, it will be located at b, regardless of whether it's a one- way road or traffic may flow in both directions. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] error to Fail Conversion
HI Cafe I have problem with this function value :: Theorm-> [(String,Int)] -> Tem -> Int value _ env (Var s) = maybe (error "Unknown variable.") id (lookup s env) value mdl env (OP s _ _ l) = maybe (error "Function not defined.") id (lookup (map (value mdl env) l) (S.toList $ maybe (error "Uknown function.") id (fmap snd (multiLookup s (operations mdl) This function is working fine, but I want to change error function to fail function to be able use it in my GUI application. I can't change the output of value function to IO Int,any idea will help. Thanks Nour. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell programs as specifications
Hi, Attached are two programs that represent one-way and two-way traffic on a road. I can get the programs to produce reasonable results that match our intuitive ideas of roads. However, I have 2 question about the programs: 1)I cannot get the result suggested by the author that t1 should give true in prog1 and false in prog2. 2)My second question is more theoretical. It is stated by the author that type checking and excitability provide verification. In this case verification probably means checking that an instance is consistent with its type class. Does verification using these techniques in Haskell have any firmer logical foundation than say doing the verification in Java? I am aware that Haskell uses inference for type checking, but is the net result superior to compilers that do not use inference? Also, is Haskell execution based purely on logic? Regards, Pat This message has been scanned for content and viruses by the DIT Information Services E-Mail Scanning Service, and is believed to be clean. http://www.dit.ie-- Ontologies of One-way Roads by Sumit Sen -- http://ifgi.uni-muenster.de/~sumitsen/sen_Font05.pdf -- Two way roads class Link link object | link -> object where from, to::link -> object other::Eq object => link -> object -> object other link object | object == from link = to link | object == to link = from link | otherwise = error "not linked" class Path path object where move :: path -> object -> object class Named object name | object -> name where name :: object -> name class LocatedAt object link where location :: object -> link --Node type Name = String data Node = Node Name deriving (Eq, Show) -- Edge: "A sequence of line segments with nodes at each end" data Edge = Edge Node Node deriving Show -- Car data Car = Car Node deriving (Eq, Show) type Cars = [Car] -- a Node is a named object instance Named Node Name where name (Node n) = n -- an Edge as Link between Nodes instance Link Edge Node where from (Edge node1 node2) = node1 to (Edge node1 node2) = node2 -- a Car located at a Node instance LocatedAt Car Node where location (Car node) = node -- Road Element data RoadElement = RoadElement Edge deriving Show class (Path path conveyance ) => Conveyance conveyance path object where transport :: path -> conveyance -> object -> object -- RoadElements as Links between Nodes instance Link RoadElement Node where from (RoadElement edge) = from edge to (RoadElement edge) = to edge -- RoadElements as Paths for Cars instance Path RoadElement Car where move (RoadElement edge) (Car node) = Car (other edge node) -- Algebraic specifications usually depend on (automatic) theorem provers for verification of specifications. -- For our case however type checking and executablity form the basis of verification of our specifications in Haskell. -- This is done by executing test scripts such as -- As orignal paper start = Node "start" end = Node "end" theEdge = Edge start end theCar = Car start theRoadElement = RoadElement theEdge t1 = location (move theRoadElement theCar) == end -- Some additional tests -- If start end switched then no linked error theEdge2 = Edge start end theEdge3 = Edgeend start theCar2 = Car start theCar3 = Car end theRoadElement2 = RoadElement theEdge2 theRoadElement3 = RoadElement theEdge3 t2 = location (move theRoadElement2 theCar2) == end t3 = location (move theRoadElement3 theCar3) == start -- In prog2 -- other (Edge (Node "start") (Node "end")) (Node "end") -- gives start -- other (Edge (Node "start") (Node "end")) (Node "start") -- gives end -- Which is what we would expect for a two way street. -- I can get t1, t2 and t3 to give expected results, but I *cannot* get the following to work -- Thus t1 will be true if spec 1 is used and false if spec2 is used deciding if the road specification is of a one way road. -- Ontologies of One-way Roads by Sumit Sen -- http://ifgi.uni-muenster.de/~sumitsen/sen_Font05.pdf --One-way road class Link link object | link -> object where from, to::link -> object other::Eq object => link -> object -> object other link object | object == from link = to link | otherwise = error "not linked" class Path path object where move :: path -> object -> object class Named object name | object -> name where name :: object -> name class LocatedAt object link where location :: object -> link --Node type Name = String data Node = Node Name deriving (Eq, Show) -- Edge: "A sequence of line segments with nodes at each end" data Edge = Edge Node Node deriving Show -- Car data Car = Car Node deriving (Eq, Show) type Cars = [Car] -- a Node is a named object instance Named Node Name where name (Node n) = n -- an Edge as Link between Nodes instance Link Edge Node where from (Edge node1 node2) = node1 to (Edge node1 node2) = node2 -- a Car located at a Node instance
Re: [Haskell-cafe] Can't connect to local yackage server
I wrote: >> After running yackage -l, I cannot connect to it even directly >> from localhost. I get the message: >> This Yackage server only talks to local clients Michael Snoyman wrote: > ...it doesn't sound like your problem is caused by the mis-behaving > Yackage code: it *should* give you a "permission denied" error message. Does > the connection work if you just run yackage normally, i.e. without -l? Yes, as a work-around I'm running it without -l, with the firewall set to block incoming connections to the port. It's working fine that way. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't connect to local yackage server
On Sun, Apr 3, 2011 at 1:32 PM, Yitzchak Gale wrote: > On Mac OS X 10.6.7, after upgrading to yackage 0.1.0.1: > > After running yackage -l, I cannot connect to it even directly > from localhost. I get the message: > > This Yackage server only talks to local clients > > On a Linux server it seems to work fine though. > > On the Mac, when I do "telnet localhost" I get: > > Trying ::1... > > Could it be that yackage 0.1.0.1 doesn't recognize the > IPv6 notion of localhost? > > Thanks, > Yitz > Firstly, the checking-localhost-code in Yackage *is* broken for IPv6. I've just pushed some changes to Warp to make the situation a little better for specifying listening hosts, but that's not coming out most likely until Warp 0.4. However, it doesn't sound like your problem is caused by the mis-behaving Yackage code: it *should* give you a "permission denied" error message. Does the connection work if you just run yackage normally, i.e. without -l? Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Can't connect to local yackage server
On Mac OS X 10.6.7, after upgrading to yackage 0.1.0.1: After running yackage -l, I cannot connect to it even directly from localhost. I get the message: This Yackage server only talks to local clients On a Linux server it seems to work fine though. On the Mac, when I do "telnet localhost" I get: Trying ::1... Could it be that yackage 0.1.0.1 doesn't recognize the IPv6 notion of localhost? Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 7th Ghent Functional Programming Group meeting on Tuesday, April 26
We probably won't have a video camera, but we can always provide the slides. Cheers, Jasper On Sat, Apr 2, 2011 at 8:41 PM, oliver mueller wrote: > sounds like an interesting program... > you should think about making the talks available later for those who > can not attend. > br, > oliver > > On Apr 1, 7:20 pm, Jasper Van der Jeugt wrote: >> Dear all, >> >> We are very glad to announce an exciting program for the 7th meeting of the >> Ghent Functional Programming Group, especially since we are celebrating our >> first year of existence today. Our program features no less than three >> interesting functional programming languages: Erlang, Haskell and Scheme. >> >> The meeting will take place on Tuesday, April 26 in the Technicum building of >> Ghent University (Sint-Pietersnieuwstraat 41, 9000 Gent) at 19h30. As >> before, to >> enter the building, you should go to the automatic sliding door on the far >> left >> of the building and dial the phone number that is provided on the note taped >> to >> the door. Someone will then open the door for you. >> >> Our program is as follows: >> >> 1. Tom Van Custem - Experiments with MapReduce in Erlang >> >> MapReduce is a programming model for large data processing popularized by, >> and >> in daily use at Google. The MapReduce model builds strongly on key tenets of >> functional programming such as higher-order functions and side-effect free >> execution. In this talk, we summarize this programming model and describe a >> didactic implementation in Erlang. Invented at Ericsson's research labs, >> Erlang >> is known for its massively concurrent programming model, and itself builds >> on a >> functional core language. The talk will not focus on Erlang as such, but we >> will >> describe its key features as needed to understand the MapReduce abstraction. >> >> 2. Tom Schrijvers - How you could have won the VPW 2011 contest with Haskell >> >> We all know that Functional Programming is great for writing concise >> solutions >> for programming problems. With some skill this can even be done quickly! Yet, >> there was little evidence of this at the 3rd edition of the Flemish >> Programming Contest (VPW 2011) that took place on March 23. Not so before >> the contest: The jury stress-tested all questions by writing various >> solutions in different languages. Haskell was used to solve most problems >> and invariably produced short solutions. >> >> In this talk I present my own Haskell solutions to several of this year's >> problems and discuss alternative solution strategies with the audience. After >> the talk you will be all set for winning next year's edition -- or at least >> enjoying it -- using Haskell. >> >> 3. Pieter Audenaert - Functional Geometry and a Graphical Language >> >> We will discuss a simple language for drawing images. During the >> presentation we >> will illustrate the power of data abstraction and algebraic closure, >> meanwhile >> using higher order procedures in an essential manner. The language has been >> designed to easy experimenting with patterns such as those appearing in >> typical >> M.C. Escher drawings where the artist repeats the pattern both moving it >> across >> the drawing and scaling it when applicable. In the language we use >> procedures to >> represent the data objects that will be combined in the final drawing and we >> make sure that all operations conducted on these procedures are algebraically >> closed. These features allow generating patterns of any complexity. >> >> For our implementation, we use the LISP functional programming language -- >> more >> accurately, the Scheme dialect. The presentation is based on "Structure and >> Interpretation of Computer Programs", Abelson & Sussman >> >> Hope to see you there! >> >> The GhentFPG organizing committee, >> Andy Georges >> Jeroen Janssen >> Jasper Van der Jeugt >> >> ___ >> Haskell-Cafe mailing list >> Haskell-C...@haskell.orghttp://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
