March 2004 - Haskell - Haskell.org

GHC binary for Cygwin
by Thomas Hafner 19 Mar '04

19 Mar '04

Are somewhere GHC binaries for Cygwin available? I tried to cross compile from Linux, but didn't succeed. Maybe one want to answer me: ``Why is a cygwin port needed? There's already a great MS W port!'', but: * darcs, that I'm interested in, is available as Haskell sources. * For I can't use cmd.exe ... | CMD.EXE was started with '\\xxxxxxxxx\yyyy\zzzzzzz' as the current | directory path. UNC paths are not supported. Defaulting to Windows | directory. ... I would like to use rxvt/bash instead. * darcs record hangs when running in rxvt/bash while expecting interactive user input. * A person experienced in porting darcs to MS W recommended me to look for a pure Cygwin port of GHC. In a ``pure'' Cygwin port all system calls should go through the Cygwin libraries, of course. Regards Thomas

2 1

RE: [Haskell] COM port IO on a Windows machine?
by Peter Pudney 19 Mar '04

19 Mar '04

Axel, Thanks for your reply. But I am still having problems. I have written a short script to test the serial IO: > module SerialIO where > import IO > test :: IO () > test > = do > com2 <- openFile "COM2" ReadWriteMode > hSetBuffering com2 LineBuffering > isOpen <- hIsOpen com2 > putStrLn $ "hIsOpen = " ++ show isOpen > putStrLn "About to send..." > hPutStrLn com2 "l311" > putStrLn "Hoorah!" > hClose com2 Here is what I get when I run the test function using GHCi 5.04.2: *SerialIO> test hIsOpen = True About to send... *** Exception: failed Action: hPutChar Handle: {loc=COM2,type=duplex {read-write},binary=False,buffering=line} Reason: No error File: COM2 It appears to be connecting to COM2, but fails when it tries to output a character. The failure leaves the COM2 port connected, so I have to quit GHCi before I can use COM2 from HyperTerminal. I have also tried opening the file in WriteMode, and opening the port as "COM2:19200,8,N,1,P", but get the same failure each time? Do you have any other suggestions? Peter -----Original Message----- From: Axel Simon [mailto:A.Simon@kent.ac.uk] Sent: Thursday, 18 March 2004 4:54 AM To: Peter Pudney Cc: 'haskell(a)haskell.org' Subject: Re: [Haskell] COM port IO on a Windows machine? On Wed, Mar 17, 2004 at 05:46:25PM +1030, Peter Pudney wrote: > I have a microcontroller connected to the COM2 port on a Windows machine, and > want my Haskell program to interact with it. My Haskell program is working > nicely on my Mac, with interaction using stdin and stdout, but I am not > familiar with Windows and a quick Google search did not give me any information > on how to get Haskell IO happening through a Windows serial port. > > * How should I open the COM2 port? IO Mode? Buffering? > > * How do I write and read? > > > I presume I can set the port parameters fusing something like: > > ...; e <- system "MODE COM2 19200,*,N,1,P"; ... You can also set these default parameters somewhere in the Control Panel. In case the openFile function is implemented under Windows by calling "CreateFile" in the Windows API, then you can just call openFile with the name "COM2:19200,8,N,1,P" or simliar and use standard read and write functions on files. Maybe this helps, Axel

1 0

Re: Haskell performance
by Arjan van IJzendoorn 18 Mar '04

18 Mar '04

Hello S\'ebastien, > I am a Haskell newbie, but have been interested in Haskell (and > generally speaking ML-derivates) for some time. I am currently > evaluating different languages for implementing an application which > will have to manipulate large graphs representing the structure of > programs and their evolution. Maybe you should consider using a combination of Haskell and C++. I bet there are good graph libraries in C++ available so that would save a lot of work. Using Haskell for the front end is a lot more fun than C++ or Java, I think. As you say you are a Haskell newbie I must warn you that linking to a C++ library is not trivial and that's not a Haskell problem but more a compiler-options-problem. What I suggest is exactly what I am doing at the moment; I am building a tool to edit Bayesian networks and to apply inference algorithms to them. The GUI is written in Haskell (wxHaskell) and the inference is a C++ library I am reusing. The choice for C++ was not speed but reuse. I have never come across a problem for which Haskell was too slow, but maybe that depends on my choice of problems. The tool I am writing now runs smoothly on an ancient (700Mhz) computer. Good luck, Arjan

1 0

COM port IO on a Windows machine?
by Peter Pudney 17 Mar '04

17 Mar '04

I have a microcontroller connected to the COM2 port on a Windows machine, and want my Haskell program to interact with it. My Haskell program is working nicely on my Mac, with interaction using stdin and stdout, but I am not familiar with Windows and a quick Google search did not give me any information on how to get Haskell IO happening through a Windows serial port. * How should I open the COM2 port? IO Mode? Buffering? * How do I write and read? I presume I can set the port parameters fusing something like: ...; e <- system "MODE COM2 19200,*,N,1,P"; ... (The application is a little interesting---we have three large large bins in a Waste Education Centre. Kids present items such as cans, paper, garden waste and rubbish to the bins, and characters in the bin respond. The items are tagged with Dallas 1-wire ID buttons. A microcontroller in each bin sends a (BinID,ItemID) pair to the PC. The Haskell program then illuminates characters in the bins and plays an appropriate dialogue. The lights and speakers are turned on and off by the microcontroller under the control of the Haskell program. The dialogue is stored in WAV files, which are played by a Visual Basic Script called from a Haskell "system" function.) Peter

2 1

Re: DData revision /equivalence vs equality
by Iavor S. Diatchki 17 Mar '04

17 Mar '04

hi , this is an interesting discussion and i agree that in general instances of Eq should be "equality", but what do people mean by "real equality"? probably the most reasonable interpretation is some sort of observational equivalance, i.e. if two things are equal we should always be able to replace the one with the other. for a datatype that is not abstract this basically forces the equality to be structural equality, which has prolems: * if a datatype contains functions, structural equivalance is tricky * every now and than i think the most common test i want to do is an equivalance, and not equality (e.g. consider the implementation of join-lists) so for datatypes that are not abstract it seems more reasonable to expect that Eq will provide an equivalance relation rather than a real equality. for abstract datatypes one can do better as the programmer could control what observations are available to programmers. unfortunately, in Haskell it is a pain to work with those, as we cannot use pattern matching anymore and programs become clunky. so until we can think of better support for working with abstract datatypes, it seems reasonbale to me to adopt daan's original design and have different datatstructures for Bag and MultiSet (if these are commonly assumed to be the same, myabe they should have some other names). -iavor Wolfgang Jeltsch wrote: >Am Mittwoch, 17. März 2004 13:30 schrieb Ketil Malde: > > >>[...] >> >> > > > >>>Furthermore, having only an equivalence implies that there is a >>>stronger equality below that cannot be also an instance of Eq. >>> >>> >>I've already said that I think Eq's (==) should be "structural >>equality", which I thought meant that there shouldn't be any >>"deeper" equality. >> >> > >I think, the name "structural equality" is misleading because it seems to >imply that equivalent values have to have the same (internal) structure. If >values a and b have different internal representations but are >indistinguishable for the library user, than a == b should hold. > >But I totally agree with you that == should mean equality and not anything >different. And this is also what The Haskell Report says in § 6.3.1: "The Eq >class provides equality (==) and inequality (/=) methods." So a lot of the >MultiSet/Bag and the bias discussion can be avoided. DData can and should >assume that the Eq methods mean exactly what they are supposed to mean: >equality and inequality. > > > >>[...] >> >> > > > >>-kzm >> >> > >Wolfgang > >_______________________________________________ >Libraries mailing list >Libraries(a)haskell.org >http://www.haskell.org/mailman/listinfo/libraries > >

1 0

RE: [Haskell] ghc question
by Simon Peyton-Jones 17 Mar '04

17 Mar '04

GHC does context reduction as late as possible, so that when overlapping instances are involved the commitment is made where maximum information is available. Simon | -----Original Message----- | From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Jurriaan Hage | Sent: 17 March 2004 15:35 | To: haskell(a)haskell.org | Subject: [Haskell] ghc question | | Hello, | | Given the fact that Haskell 98 demands that class constraints in an | explicit type are | in a normal form (either a variable, or a type variable applied to a | list of types), it struck me | that in the following (not very useful) program ghci yields a type | which is not of that form. | | class X a where | (><) :: a -> a -> Bool | | class Y a where | (<>) :: a -> a -> Bool | _ <> _ = True | | instance Y a => X [a] where | x >< y = not(head x <> head y) | | --f :: Y a => a -> a -> Bool | f g h = [g] >< [h] | | Now, in ghci | :t f yields f :: forall t. (X [t]) => t -> t -> Bool | | Hugs does reduce the type of f to the explicit type in comments. | | My question is: is there any special reason for this behaviour? | | Jur | -- | http://www.cs.uu.nl/people/jur/progrock.html -- jur(a)cs.uu.nl | If e-mail does not work try jurriaanhage(a)hotmail.com | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

1 0

ghc question
by Jurriaan Hage 17 Mar '04

17 Mar '04

Hello, Given the fact that Haskell 98 demands that class constraints in an explicit type are in a normal form (either a variable, or a type variable applied to a list of types), it struck me that in the following (not very useful) program ghci yields a type which is not of that form. class X a where (><) :: a -> a -> Bool class Y a where (<>) :: a -> a -> Bool _ <> _ = True instance Y a => X [a] where x >< y = not(head x <> head y) --f :: Y a => a -> a -> Bool f g h = [g] >< [h] Now, in ghci :t f yields f :: forall t. (X [t]) => t -> t -> Bool Hugs does reduce the type of f to the explicit type in comments. My question is: is there any special reason for this behaviour? Jur -- http://www.cs.uu.nl/people/jur/progrock.html -- jur(a)cs.uu.nl If e-mail does not work try jurriaanhage(a)hotmail.com

1 0

HaXml and XML Schema
by s_mazanek＠gmx.de 17 Mar '04

17 Mar '04

Hello, I have started thinking about an extension of HaXml to better support XML Schema, i.e., to generate appropriate types (like DtdToHaskell) automatically (cf. Castor for Java). However, it is not obvious to me how to model mixed content (character data appears alongside subelements, i.e., it is not confined to the deepest subelement). Example (readers familiar with the problem may skip this): <salutation>Dear Mr.<name>Robert Smith</name>.</salutation> This structure is represented by the XML Schema <xsd:element name="salutation"> <xsd:complexType mixed="true"> <xsd:sequence> <xsd:element name="name" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> How would you represent this in Haskell? A first idea may be to store the enclosing strings: data Salutation = Salutation String Name String This approach is not scaling well. E.g., there may be multiple names in the text... Do you have other ideas? Thank you and Happy Haskelling, Steffen

4 3

RE: Win32 process spawning, POpen and Hugs, revisited
by Simon Marlow 17 Mar '04

17 Mar '04

On a related note, I recently implemented a System.Process library on Unix. Source code attached. The Windows implementation should be relatively straightforward. Porting it to Hugs will require System.Posix.forkProcess, but I don't see any great difficulties there. One warning: if you want to use it in a concurrent environment with GHC, you need to use GHC's threaded RTS (i.e. use the -threaded option in the forthcoming GHC 6.2.1), otherwise waitForProcess will block all threads. POpen-type abstractions can easily be layered on top of the functionality here - indeed the library should probably contain some higher-level versions which correspond to common usage. I think this is a good platform-independent abstraction for process management. What do others think? Cheers, Simon

1 0

documentation of Language.Haskell.Syntax
by José Vilaça 17 Mar '04

17 Mar '04

I'm searching for more detailed information about Language.Haskell.Syntax than the one provided by the Haddock documentation of the Hierarchical Libraries. I'm doing a tool that pick up code represented in the Haskell Syntax and i need to know the semantics of a lot of Construtors of the Haskell Syntax. If someone know where i can find that documentation please email me. thankfully José Miguel Vilaça mathematics and computer sciences student at University of Minho in Portugal

2 1