- Haskell - Haskell.org

Re: [Haskell] GHC binary for Cygwin
by Thomas Hafner 23 Mar '04

23 Mar '04

"Simon Marlow" <simonmar(a)microsoft.com> writes: > We would happily support it, but we don't have the resources. It'll be > supported if someone steps up to take on the responsiblity - the > advantage would be that you would get your name in lights on > > http://www.haskell.org/ghc/contributors.html How about publishing there, that somebody is wanted as a porter/packager for Cygwin? That could be a first, initial step. Regards Thomas

1 0

Re: [Haskell] deriving with newtypes
by Wolfgang Jeltsch 23 Mar '04

23 Mar '04

Am Dienstag, 23. März 2004 12:31 schrieben Sie: > Op zo 21-03-2004, om 18:54 schreef Wolfgang Jeltsch: > > Hello, > > > > I'm trying to use GHC's deriving mechanism for newtypes in the following > > way: class C a b > > instance C [a] Char > > newtype T = T Char deriving C [a] > > Unfortunately, this isn't possible. Is there a reason for this? Can I > > circumvent this restriction? > > You can use the deriving mechanism for user-defined class such as the > class C above. > (see http://www.haskell.org/onlinereport/decls.html#derived-decls) Since you refer to The Haskell Report, I think that you wanted to say: "You can *not* use the deriving mechanism..." But you *can* use it if you use -fglasgow-exts. I was refering to GHC's extension concerning deriving and newtypes. > [...] > Instead of the deriving construct, you could use the tool > DrIFT (http://repetae.net/john/computer/haskell/DrIFT/) I don't want to have a tool involved. > [...] > Greetings Arjan Wolfgang

1 0

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

23 Mar '04

Thanks, Steve and Axel, for your help. I have got serial port IO working, but the solution is a bit ugly. My solution (below) works on Windows 2000, Hugs Nov 2003. It does not work with Windows 2000, GHI 5.04.2. Later tonight I will try it on Windows ME with the latest versions of GHC and Hugs. The aim is to send a '?' character to a device on the serial port "COM2:". The device waits for a button to be pressed, then sends back a character. The test script then has to read this character from the serial port and display it. I first tried opening "COM2:" in ReadWriteMode, but this did not work with either GHCi or Hugs. For my second attempt, I open and close the file "COM2:" in the appropriate mode each time I send or receive a string. Its ugly, but it works. I am still interested in hearing from anyone who can get this working nicely with GHC. My code is below. > module SerialIO where > import IO Attempt 1: > test1 :: IO () > test1 > = do > com2 <- openFile "COM2:" ReadWriteMode > hSetBuffering com2 NoBuffering > isOpen <- hIsOpen com2 > isWritable <- hIsWritable com2 > isReadable <- hIsReadable com2 > putStrLn $ "hIsOpen = " ++ show isOpen > putStrLn $ "hIsWritable = " ++ show isWritable > putStrLn $ "hIsReadable = " ++ show isReadable > putStrLn "About to send..." > hPutStrLn com2 "?" > putStrLn "Reading..." > c <- hGetChar com2 > putStrLn [c] > putStrLn "Hoorah!" > hClose com2 Hugs Nov 2003 sends the character OK, but then... Reading... Program error: <handle>: IO.hGetChar: does not exist (file does not exist) GHCI 5.04.2 gives hIsWritable = False, then "No such file or directory" when it attempts to hPutChar. Attempt 2: open and close COM2 for each transmission > test2 :: IO () > test2 > = do > sendChar '?' > c <- receiveChar > putStrLn [c] > sendChar :: Char -> IO () > sendChar c > = do > com2 <- openFile "COM2:" WriteMode > hSetBuffering com2 NoBuffering > hPutChar com2 '?' > hClose com2 > receiveChar :: IO Char > receiveChar > = do > com2 <- openFile "COM2:" ReadMode > hSetBuffering com2 NoBuffering > c <- hGetChar com2 > return c GHCI fails as before, but Hugs works.

1 0

Proposal for a Standard of Abstract Collections (with Reference Implementation)
by Robert Will 22 Mar '04

22 Mar '04

hi all, Curiously I have finished the promised draft standard for the Abstract Collections just by a time, where many are busily working on DData. It's there: http://www.stud.tu-ilmenau.de/~robertw/dessy/fun/ I'm making this discussion hot now, since my Dessy library implements the proposed collection standard and features all of the concrete structures that are also in DData, and some more, especially Deques and Democratic Sequences (explanation: http://www.stud.tu-ilmenau.de/~robertw/dessy/fun/democratic/ ). But I also want to have your attention for another aspect of the problem: the introduction of abstract data structures makes the programming language much more useful and suggests some generalisations of the manifest syntax. Thus my proposal does not only contain - a formal specification for a collection hierarchy (based on Abstract Algebraic Data Structures (TM)), but also - generalisations of all the standard functions from Prelude and Data.List, and - a formal specification of Haskell extensions, that make abstract structures as easy to use as lists -- but with much more flexibility. Incidentally the current discussion around DData already shows signs of what I predict in the standard's rationale: when concrete data structures are extended to become more general, the number of functions increases so fast, that a general standard isn't more complicated any more, but simpler actually. For example, you discussed whether Sets and Maps should be converted from and to Sequences or the built-in "lists". Well, the best answer is to convert from and two an type classes of which "lists" (if one uses them at all) are an instance. Exactly this is done by the function "convert" proposed in the standard: > convert :: (Collection coll a, Collection coll' a) => > coll a -> coll' a > convert = fold empty single (<+>) (The function can be specialised in the same way as 'fromIntegral' on the numeric types, so we don't loose efficiency.) Abstraction is more: the proposed standard helps to use a lot of different data structure implementations together, using one interface that has been designed with the user first in mind, not the implementation. But this abstraction also allows an entirely new programming style, that is especially useful when TEACHING programming. Data Structures are deeply intertwined with programming as such, that the proposed standard gives Haskell something that NO other language does have today. (Perhaps Eiffel comes closest, but EiffelBase is not standardised.) (Remind me to write "A Gentle Introduction into Haskell with Abstract Collections".) It has been mentioned that an advantage is of functional programming is the ability to easily _compose_ programs. But for this composition data structures are neccessary, without a standard for data structures functional languages loose one of their biggest advantages. In specifications Sets are the most important data structure, but in Haskell today, the so-called "lists" are the linguaga franca and that reminds me too much of the stacks in Forth (remember "lists" are actually functional stacks) or dynamic arrays in imperative languages: it's universal, but unflexible. (I'll have to write a paper on "Liberating programming from the McCarthy-style".) Since "a standard of Abstract Collections" has already been mentioned by some, I expect that there are high expectations regarding my proposal, and perhaps its many disadvantages (all the big ones mentioned in the documentation) will discourage the reader. On the other hand, there are so many advantages that one can hardly neglect that something big is going on. So the least thing that someone interested in the future of (functional) programming should is to download and try out the Collections, or to read a little bit in the design documents. Things to do: - Build examples for the use of the new Collections. (From now on anyone can port his code to get rid of "lists".) - Develop the Haskell Documentation Standard and apply it to Collections. (Specifications are exported and used for Tests.) - Using those specifications make a complete test framework. (Complete meaning every function is tested with the complete specification, so no Bugs can persist.) Given all that, it is trivial to add more implementations of the Abstract Collections. (Just added two concrete structures Yesterday, although Dessy has already much more functionality than DData, but only half its code size. (Or one third if you don't count the type classes and specifications.) I also think that Dessy has more readable code, but I don't know how important that is for anyone.) Have a good time, Bob

2 2

RE: [Haskell] reasons for non-portability
by Simon Marlow 22 Mar '04

22 Mar '04

> Thanks for the info. > > Well, according to that explanation, all modules would be > non-portable since > the Prelude is normally implemented using non-standard > features. I think, > this is solved by declaring all modules described in the > Haskell 98 Report > portable. > > One question: Every module which imports a non-standard > module has to list all > of this other module's non-portability reasons in its own > reasons section again, rigtht? You're right - the definition is incomplete. Additionally, we "declare" some modules to be portable. These modules must be available under all implementations: - The Haskell 98 standard libraries (including Prelude) - Modules listed under "Approved extensions" in that document Cheers, Simon

1 0

RE: [Haskell] GHC binary for Cygwin
by Simon Marlow 22 Mar '04

22 Mar '04

> The other day, I tried to compile the Fudgets library with > GHC-MinGW. It > didn't work, of course, and having GHC for Cygwin would presumably > significantly reduce the amount of pain required to port it. (Support > for certain Posix system calls and symbolic links would be helpful.) > > At first I assumed that it would be fairly easy to create GHC-Cygwin > from GHC-MinGW, but then I read the explicit statement in the > documentation, that Cygwin is not supported, and was rather > discouraged... We would happily support it, but we don't have the resources. It'll be supported if someone steps up to take on the responsiblity - the advantage would be that you would get your name in lights on http://www.haskell.org/ghc/contributors.html Cheers, Simon

1 0

Re: [Haskell] reasons for non-portability
by Wolfgang Jeltsch 22 Mar '04

22 Mar '04

Am Montag, 22. März 2004 13:29 schrieben Sie: > On Sat, Mar 20, 2004 at 08:50:10PM +0100, Wolfgang Jeltsch wrote: > > according to > > http://www.haskell.org/hierarchical-modules/libraries/ > > reference-libraries.html#MODULE-HEADER, > > each module should have a header which contains a line about portability. > > My question is, if a module is considered non-portable only if it > > contains non-portable constructs itself, or if a module is also > > non-portable if it just imports a module which is non-portable. > > follow the link under "reasons" to the definition. Thanks for the info. Well, according to that explanation, all modules would be non-portable since the Prelude is normally implemented using non-standard features. I think, this is solved by declaring all modules described in the Haskell 98 Report portable. One question: Every module which imports a non-standard module has to list all of this other module's non-portability reasons in its own reasons section again, rigtht? Wolfgang

1 0

reasons for non-portability
by Wolfgang Jeltsch 22 Mar '04

22 Mar '04

Hello, according to http://www.haskell.org/hierarchical-modules/libraries/ reference-libraries.html#MODULE-HEADER, each module should have a header which contains a line about portability. My question is, if a module is considered non-portable only if it contains non-portable constructs itself, or if a module is also non-portable if it just imports a module which is non-portable. Wolfgang

3 4

Haddock, QuickCheck, and Functional Design by Contract
by Robert Will 22 Mar '04

22 Mar '04

> import QuickCheck Dear developers of QuickCheck and Haddock, Dear Haskell-Community, ((Summary: I'm trying to find notations for Design by Contract in Haskell which can be standardised to be used by tools like Haddock and QuickCheck. This will give Haskell programmers an order-of-magnitude gain in productivity, since it brings semantic abstraction into the programming language. See [1] and my earlier posts to this list [2].)) I consider it the most important advantage of Haddock, that it encourages the separation of module internal and external documentation (marked with -- | or -- ^). This is added value, even if a module user only reads the source, not the generated documentation. I consider it one of the most important advantanges of QuickCheck, that it allows the automatic verification of (formal) documentation, namely algebraic properties of functions. Yes, I think that that (well-written) QuickCheck properties are excellent documentation, much more worth than just type signatures (which I can look at in the interpreter). I consider it the essence of Design by Contract to have an explicit redundancy in the code, namely Pre- and Post-Conditions, Assertions, whose consistency with the rest of the code is automatically checked during run-time, making it a tight net in which bugs are caught. And what's more, this redundant view is more abstract than the original code, so that it makes for excellent documentation, which can never be out of date (due to the run-time checks). Both the principles "Only one document for code and documentation" and "Contracts have to be run-time checked" were already articulated in 1988 [3]. A standarised notation for contracts should therefore be part of any programming language. The following six points summarise a functional version of Design by Contract. Point 4 is still unclear, others can still change syntax. The rest is relatively straight- forward and we should make it a standard as soon as possible. 1. A notation for postconditions: No problem, use QuickCheck properties. > prop_sort_post xs = let xs' = sort xs > in is_sorted xs' && bag xs == bag xs' - Haddock can automatically include this "postcondition" in the documentation for function @sort@ (removing the prefix "prop_" and the suffix "_post" from the QuickCheck-Property). - For QuickCheck it is already in the right format. 2. A notation for specificative functions. That is, we document / specify a function by giving a more readable (but less efficient) version with the same semantics. For example, the best way to document exponentiation (besides the informal "@x ^ n@ is the @n@th power of @x@.") is the following code: > x ^ 0 = 1 > x ^ n = x * x^(n-1) Or the standard function @scanl@ is specified as > scanl f e = map (foldl f e) . inits > -- @inits@ see appendix. Both of those definitions are not the actual implementation (which is asymptotically faster in both cases), but they are perfectly suited for inclusion in the documentation and as raw material for QuickCheck. We can realise that by a simple notation: > scanl_spec f e = map (foldl f e) . inits Haddock would then publish the definition @scanl f e = ..@ (i.e. with the suffix "_spec" removed) in the documentation. QuickCheck would generate the testing property: prop_scanl_spec f e = scanl f e == scanl_spec f e The same can be done for functions with operator names, e.g. with "//" as suffix for the specification function and "\\" as prefix in "prop_"'s place: x \\^// n = x ^ n == x ^// n (We could also generate names, like "roof_spec" and "prop_roof_spec" for use in the code. The documentation, however, will only show the clear @x ^ n@.) 3. A notation to mark self-specifying functions. These are functions where the implementation is at the same time the simplest (still formal) specification. For example the function @square@ from the Haddock manual: square x = x * x -- || The double bar tells Haddock to export the complete function definition to the user documentation. Another example comes from DData: (<>) = append -- || Only syntactic sugar. Or: lookup k map | member k map = Just (find k map) -- || | otherwise = Nothing -- || -- | Perhaps implement more efficiently later. The documentation that contains those defintions does not reveal whether the functions are really implemented as given, or whether it's only a specificative functions according to point 2. However, since point 2 guarantees semantic equivalence through tests, users don't need to care. For many people self-specifying code seems to be opposed to design by contract, however, this is not at all the case. The modern view of Programming by Refinement (see, e.g. [5]) softens the frontier between specifications and implementations to allow practical compromises between readability and efficiency while at the same time avoiding negative redundancy between code and spec (i.e. simply duplicated information instead of a useful different view). Incidentally most of the Prelude functions are self- specifying in this way. The examples of point 2 are notable exceptions. 4. A notation for preconditions. For simple functions a Precondition can be calculated automatically from the Patterns: > head (x:xs) = x Gives the Precondition @xs /= []@ for @head xs@. This only needs some simple knowledge about @data@ and @newtype@ declarations. (We could also choose to leave it out, if it's too much work, for too few cases where it works. Then programmers would have to state all preconditions explicitly as shown next.) Presently I use the following coding style: > take n xs | not (n >= 9) = error "take.Precondition" The precondition can simply be extracted as <<the bracketed expression behind @not@ in a line containing the words @error@ and "Precondition">>. However it has the disadvantage that I can't simply disable run-time checking of the Precondition (as I could when using @assert@). Furthermore it is also rather ugly. Does anyone have a better idea? The use of Preconditions is expecially important: - Automatically checked on run-time (like @assert@). - Used in documentation. - Used by QuickCheck to create (==>) guards in the automatic @prop_foo_spec@ properties. 5. Default implementations of type class members are often a special case of specification functions: the overwriting provides the same semantics, more efficiently. (Occurs often in Abstract Data Structures, see [2].) A typical example is: > is_empty coll = size coll == 0 -- || We can use the double bar (or whatever we decide to standardise), to mark the function definition for export to the documentation. However, it is more difficult to create test properties which compare the two implementations of a function, since the default implementation is no more accessible after having been overwritten. The property generator will have to copy the default definition to a definition with name @is_empty_spec@ (for example) and can then generate the usual @prop_is_empty_spec@ (as in point 2). The copying of the function definition happens only for testing and is not seen in normal code or documentation. (The overwriting corresponds slightly to the contract refinement in object-oriented inheritance. See [3].) By the way, we can use -- || on a type class header, saying to export all it't default definitions to the documentation. (In my data structure library this is always the case. See, e.g., http://www.stud.tu-ilmenau.de/~robertw/dessy/fun/AlgebraBasic.hs ) 6. Invariants are an important part of Design by Contract according to [3]. In Functional Programming it has been proven practical to check (and at the same time: document) data structure invariants in a smart constructor; the invariant resides only in this place (is not redundantly mentioned in the code) and is run-time checked on each creation of a data cell. This works with @assert@ and doesn't need QuickCheck properties. Also, such internal invariants are not relevant for the external documentation. (Otherwise we could documentation- export the definition of the smart constructor, using -- ||.) External Invariants are nothing else than algebraic properties of data structures. They can be documented using normal QuickCheck- Properties, and these can be documentation- exported via -- ||. As a consequence, invariants need no special notation. I only mention them her for methodological reasons. In order to keep the standard short, I suggest only to include this notations, the discrimination between internal and external comments (as in Haddock) and the discrimination of identifiers in comments (also editors can have hyperlinking and different colors.) Further markup concerns only the documentation generator and not other tools. Users of QuickCheck have reported an order-of-magnitude gain in productivity. That's because redundancy in form of checkable documentation comes very near to semantically automated software engineering. Together with proper documentation mechanisms, we can make such rendundant programming more literate, thus bringing an order-of-magnitude gain in productivity to whole programmer _teams_. Finally, I think, that the topic "Functional Programming and Design by Contract" is also a topic for a keynote lecture. Those who are in the relevant positions might about that. Similar applies to the authors of functional programming text books (and teachers, by the way). Or, and fans of program proving (hello LARCH and OBJ2) might want to statically check those contracts... so far, Robert [1] myself: "Modularity without Abstraction is no more than Syntactic Sugar" http://www.stud.tu-ilmenau.de/~robertw/eiffel/modularity_abstraction.txt [2] myself: "Posts on Functional Data Structures" http://www.mail-archive.com/haskell@haskell.org/msg13980.html http://www.mail-archive.com/haskell@haskell.org/msg13979.html [3] Bertrand Meyer: "Object-Oriented Software Construction", 1st edition, 1988 [4] Richard Bird: "Introduction to Functional Programming using Haskell", 2nd ed. [5] Eric Hehner: "A Practical Theory for Programming", 2nd ed., 2004 http://www.cs.toronto.edu/~hehner/aPToP/ > -- | List of initial segments (including []) of a list > -- in increasing order of size. > inits [] = [[]] > inits (x:xs) = [] : > map (x:) (inits xs) > > prop_inits_initial xs = forAll (elements $ inits xs) (\ ys -> > ys == take (length ys) xs ) > > prop_inits_increasing_length xs > = striclty_increasing $ map length $ inits xs > -- Also checks, that no segment occurs twice.

3 2

deriving with newtypes
by Wolfgang Jeltsch 21 Mar '04

21 Mar '04

Hello, I'm trying to use GHC's deriving mechanism for newtypes in the following way: class C a b instance C [a] Char newtype T = T Char deriving C [a] Unfortunately, this isn't possible. Is there a reason for this? Can I circumvent this restriction? Wolfgang

1 0