- Haskell - Haskell.org

Problem: "invalid argument" emitted by sendTo
by mgross＠dorsai.org 21 Sep '01

21 Sep '01

I am using SocketPrim to send a udp packet to each of 254 addresses on a network. The message packets have been preconstructed and placed in a list, whose content has already been checked for correctness and appear to meet the specifications in the appropriate RFC. When I go through the list (using mapM_), sending a packet to each address with sendTo, I get a valid return code from sendTo (used trace to check that) for the addresses from 10.129.129.1 through 10.129.129.239. Address 10.129.129.240, however, fails with the messages Fail: invalid argument Action: sendTo Reason: invalid argument The message "invalid argument" does not appear within the source of SocketPrim, but it does appear in several of the binary files in the library. I've begun to dig around in the source code, but I've taken to hoping that someone out there in Haskell land may be able to point me directly to where (and for what) I should be looking to determine just what triggered those messages. Oh, yes, verson info: ghc-5.00.2, linux (debian testing). Thanks in advance for attention. Murray Gross mgross(a)dorsai.org

1 0

Haskell Communities Survey - Call for Contacts
by C.Reinke 20 Sep '01

20 Sep '01

Dear fellow Haskellers, the recent (and eternal) questions about GUIs and future Haskell developments are closely related to a general problem: trying to keep up to date with what is going on within the Haskell community as a whole while the breadth of interests in that community keeps expanding. For the sin of pointing out this problem at this year's Haskell workshop, I was volunteered to try and organise some way of getting summaries of what the various (sub-)communities are working on and posting the results to the main Haskell list as well as on haskell.org. Below, you'll find (I) a summary of the problem, (II) my slightly revised suggestion on what to do about it, and (III) a preliminary grouping of Haskell communities by topic (some of which do not have their own mailing lists right now, or are really dispersed over several more specific lists). What I need from you now is (a) a look at the list of topics/communities at the end of this email -- it is meant as a starting point, likely to be incomplete, so if anyone feels left out, if you can confirm some of the topics as dead, or anything else is wrong, let me know. (b) a contact person in each of the communities, willing to put together a brief, representative summary of that community's work and interests (see part II below for what would be useful). Being brief, the individual reports won't require a lot of work for someone actively interested in one of the topics. In fact, they might have to be shorter than you would like them to be - feel free to include pointers to more extensive documentation. The plan is to get this set up over the next weeks, and to give the contact persons a little bit of time to get feedback on their status reports from their communities. As soon as the individual reports start flowing into my mailbox, I'll try to edit them together. Optimistically, we could have the whole report ready for the main Haskell list before October is gone (famous last words..), realistically, we'll wait and see what happens. Ultimately, the aim is to have two yearly updates of the status report, covering all active Haskell communities (sorted by topic); one update in time for the yearly Haskell workshops and one in between. The first go doesn't have to cover everything, we can add or remove topics and fine-tune the level of detail once we get going. The report will - help to keep experienced Haskellers updated - give newcomers some orientation about current activities - help communities to attract collaborators I'll step back now to make room for the volunteers;-) Claus --------------------------------------------------- THE PROBLEM: 1. The Haskell community continues to grow in size and in the variety of interests. [this is good:-] 2. Sub-communities have formed, often with their own mailing lists, to work on specific issues or just to provide foci for specialist discussion. [this is necessary to get some work done] 3. Both specialists and the "just a Haskell user" find it difficult to keep track of what is going on behind the scenes of the main list. In fact, some folks have opted out of much of the main list (the discussions were factored into the "haskell-cafe" list) and only follow the announcements part (the "haskell" list). Few people can afford spending their days reading through all of the dozens of Haskell-related mailing lists (this is not a joke: you'll find about a dozen "real" lists plus a similar number of cvs-watchlists hosted at haskell.org alone, and that isn't counting the lists hosted elsewhere or the communities that use small meetings to coordinate their work). [this is bad, and we can try to do something about it] --------------------------------------------------- THE SUGGESTION: My initial proposal at the workshop was to collect summaries from contacts on the various mailing lists every six months or so and to edit them for the main Haskell list and for a page on haskell.org. However, having combed through the list of mailing lists I am aware of so far, I am more and more convinced that the current proliferation of very narrowly focussed and often shortlived (in terms of activity) mailing lists is part of the problem, not part of the solution. Not to mention that certain important topics, such as GUIs do not even have their own mailing list yet.. My current suggestion is to come up with a broader topical grouping of Haskell communities (see below), and then to solicit brief summaries from contacts in those communities every six months, taking the yearly Haskell workshop as one of the reference points: - twice a year, everyone gets a snapshot of what's happening with Haskell. In the meantime, the communities can get on with their interests without having to bother with summaries too often (it is always difficult to find volunteers..). - six months is enough time to make some real progress and have something worth summarizing. After half a year, the summaries definitely need to be brought up to date, if only to state which groups have dissolved and which are still active. - the summaries should be brief (rough idea: a paragraph each for looking back and for looking ahead, plus pointers to current documents or other deliverables), as they will be collated into overviews of the Haskell community as a whole, but could contain references to more extensive documents or other deliveries. As a side-effect, this cuts down the work for the contact persons. - having status reports grouped by topic should give a more useful and homogeneous picture; it might also encourage people on related mailing lists to cooperate more closely, or people with related interests to set up a mailing list. Where this is perceived necessary, a status report on any given area can be amended by additional paragraphs covering individual mailing lists or projects in that area. - keeping the collected summaries on a page at haskell.org should give both newcomers and experienced Haskellers a rough idea of what is going on, and which sub-communities they might want to join. ----------------------------------------------- What's in a summary? That is really up to you: what do you think Haskellers in general should know about what is going on in your part of the field? Whom would you like to join your efforts? Think of it as an executive summary with pointers to more details. Here is a rough outline: + major topics and results since the last report (~1 paragraph) + current hot topics (some keywords) + major goals for the next six months (~1 paragraph) + pointers to material for further reading (group charter, group home page, how to join, mailing list archives, specifications and drafts, implementations, meetings, minutes,..) So a minimal report is 2-3 paragraphs, plus pointers. If you like, add extra paragraphs for subtopics in your area. That's it! ---------------------------------------------- TOPICS/COMMUNITIES: Below, the major "communities" (as defined by common areas of interest) are grouped into a small number of top-level categories. Most of the communities are themselves spread over several mailing lists or projects, and some topics appear in several categories, with different emphasis (e.g., FFI development depends on a small set of language extensions, on top of which foreign function interfaces can be built as a combination of tools and libraries; also, applications may center around a set of libraries; language extensions are more interesting if implemented, etc.). It would be easiest for me to get status reports for the major groupings, but that might not be feasible (apart from Haskell implementers, I hope; applications, someone?). So: ** I need contact persons for each of the topics ** who are willing to produce a summary report for their own community, with additional paragraphs per sub-group as appropriate (of course, if any of those sub-groups would like to present their own, separate summary instead, feel free to suggest a separate contact person;-). It is quite likely that some of your own topics/communities are not yet on the list -- let me know about such omissions. |what follows is an outline; a slightly more detailed list, with |links, can currently be found at: | | http://www.ukc.ac.uk/people/staff/cr3/tmp/Communities/ | |Note the "tmp" - this list should move to haskell.org later. Haskell Communities, by topics ============================== Haskell implementers -------------------- : irregular meetings, visits, email, separate mailing-lists - what's up with each implementation (ghc,nhc,hugs,hbc???)? - what's in store across implementations (implementer's meetings)? Language and implementation extensions -------------------------------------- : separate sub-communities + FFI foreign function interface for Haskell + Libraries hierarchical module namespaces for Haskell + Non-sequential Haskell concurrent, parallel, and distributed Haskell + Type systems extensions and variants of all kinds and types + Generic Haskell generic programming for Haskell (Generic Haskell, Polyp, Strafunski, generalised deriving, Drift, ..) + O'Haskell objects and concurrency for Haskell + Meta Haskell Metaprogramming support ala Meta ML + Haskell modules (re-)emerging interest in a lightweight redesign + Arrows towards built-in support for Libraries --------- : current core priorities are high-level FFI, GUIs, and overall library reorganisation (using hierachical namespaces), + Libraries organisation and collection of libraries (hslibs, nofib, ..) + FFI (Foreign, CForeign, ..) + GUIs (Gtkhs, iHaskell, FranTk, Fudgets, Haggis, Fruit,..) [no separate forum for GUIs yet??] + computer algebra Tools ----- : widely dispersed, small and sometimes short-lived communities, as many tools are still implementation-specific, most of the discussion is currently mixed into the main implementation lists [a combined Haskell-Tools forum might be more appropriate; many tools share similar problems, such as program analysis, etc.; tools should be visible independent of the implementations they depend on, and indeed portable tools would seem to be an important topic..] + FFI (greencard, hdirect, c2hs) + Debuggers [dormant? probably too limited in scope?] + Development tools (tracing, profiling, pre-processors, editor modes, IDEs, testing, ..) + Documentation/Publishing (automated documentation generation tools, source code browsers, literate programming; HaskellDoc, HDoc, Habitat, ..) Applications ------------ : no separate forum yet, but might deserve one separate from the general discussions list? + Haskell for teaching other topics, teaching haskell + stock markets, computer algebra, numerical algorithms, hardware,.. + FRP functional reactive programming [list at yale, dormant?] (robotics, vision, animation, stage lightning, ..)

3 2

RE: Prelude and (:) and []((:), []) bugs?
by Simon Marlow 20 Sep '01

20 Sep '01

Ian Lynagh writes: > On Thu, Sep 20, 2001 at 01:32:54PM +0100, Simon Marlow wrote: > > (:) is allowed in an export list; it is just a normal operator. > > An export is > > export -> qvar > | qtycon [(..) | ( qcname1 , ... , qcnamen )] (n>=0) > | qtycls [(..) | ( qvar1 , ... , qvarn )] (n>=0) > | module modid > > and we need to match (:). We can clearly reduce this to [ proof that this isn't possible deleted ] Ah, I forgot that you can't export a constructor on its own. In which case, I would like to submit a bug report for Hugs: Hugs allows constructors to be named in an export list, and it shouldn't (see Section 5.2 in The Report, point 2 in the enumerated list). Cheers, Simon

2 1

RE: Prelude and (:) and []((:), []) bugs?
by Simon Marlow 20 Sep '01

20 Sep '01

> As far as I can tell, the report doesn't allow (:) or []((:), > []) in the > export list, yet the hugs prelude has the first and the GHC > prelude has > the second. Have I missed something that allows them or is > this a bug in > the preludes or the report? (:) is allowed in an export list; it is just a normal operator. GHC has a couple of extensions to export lists: we allow gcon instead of just qcon, and gtycon instead of qtycon. These are quite natural extensions, and just reduce the amount of built-in compiler magic needed to express the Prelude. Cheers, Simon

2 1

mouse & HOpenGL
by Andre W B Furtado 19 Sep '01

19 Sep '01

Does anybody know if (H)OpenGL can recognize a mouse movement even if the mouse cursor doesn't move? For example, suppose the mouse cursor is placed at the top left corner of the screen, and I move my mouse to the top left corner direction. The mouse cursor won't move, although the mouse WAS moved. Unfortunately, the "motionFunc" and "passiveMotionFunc" are related to the new position of the mouse cursor, rather than the mouse movement... (in the Allegro library, this is solved by a thing called "mouse mickeys"). Thanks a lot, Andre W B Furtado

1 0

Prelude and (:) and []((:), []) bugs?
by Ian Lynagh 19 Sep '01

19 Sep '01

As far as I can tell, the report doesn't allow (:) or []((:), []) in the export list, yet the hugs prelude has the first and the GHC prelude has the second. Have I missed something that allows them or is this a bug in the preludes or the report? Thanks Ian

1 0

Re: Tab "\t" character behaviour in (Win)hugs/ghc
by Sigbjorn Finne 19 Sep '01

19 Sep '01

Rijk-Jan van Haaftenrjchaaft(a)cs.uu.nl writes: > > Recently, Craig Delehanty discovered that there is > a difference in behaviour of putStr "a\tb" between > Hugs and WinHugs (see comp.lang.functional). > > Hugs interprets it as a alignment character: > >putStr "a\tb" > "a b" > > > (7 spaces) > but in WinHugs, it is always the same as 8 spaces: > >putStr "a\tb" > "a b" > > > (8 spaces) > > What does the language definition say about this? Nothing at all, I believe, but the convention is for tab characters to be interpreted by an output device as moving the cursor to the next tab stop/alignment column. In the absence of any custom set of tab stops, the convention is to space them evenly every 8 characters. So, WinHugs is being unnecessarily non-standard to interpret "\t" as being a shorthand for 8 spaces. I've changed this to have it fall into line with the conventional interpretation & checked in the tweak. Thanks for reporting this. --sigbjorn

5 5

Tabs and Haskell
by George Russell 19 Sep '01

19 Sep '01

Alistair David Reid wrote: > "Rijk-Jan van Haaften" <rjchaaft(a)cs.uu.nl>: > >> What does the language definition say about [tabs]? > > Sigbjorn: > > Nothing at all, I believe, but the convention is [...] > > The Haskell 1.4 report says what is meant to happen (section 1.5) > (which was to follow the convention). > > The Haskell 98 report omits this section. > > I would like to report this omission as a bug in the report. Absolutely not. Tab interpretation is OS dependent, it isn't for the language to specify. In any case, you would also need to specify the effect of backspaces, vertical tabs . . . Basically, I think that if your program relies on Unix-like tab handling, you have only yourself to blame . . .

1 0

A monad for type casting
by Koen Claessen 19 Sep '01

19 Sep '01

Hi all, Here is a little experiment I did a while ago. I was trying to isolate the capability of the ST monad to deal with different types at the same time. (Following up on a discussion at the Haskell Workshop in 2000, where we discussed that the ST monad is really a combination of different features that should be separated.) The idea is that one has a monad, "O s", in which one can create objects with identity, of type "Object s a": type O s a -- abstract, Monad type Object s a -- abstract newObject :: O s (Object s a) The idea is now that, we want to be able to compare these objects for equality. But not only that! Given two objects of possibly different types, say "Object s a" and "Object s b", if they are equal, then so must their types be! So, instead of making "Object s a" an instance of "Eq", we provide the following function: compareObject :: Object s a -> Object s b -> Maybe (a -> b) If the objects are not equal, we get "Nothing". But, if the objects are equal, we also get a "proof" of that you can cast between their types. This monad is safe, and can be used as a basis for monads in which one wants to implement something like "STRef"s. I provide an implementation of an (inefficient, but complete) ST monad, only using the O monad. I conjecture this functionality cannot be implemented in Haskell 98, nor in any of the known safe extensions of Haskell. Here, I provide an implementation that works with Hugs. Any comments? One thing I would like to propose for GHC and Hugs is to provide a function like "compareObject" for "STRef"s and "IORef"s. Regards, /Koen. ===== module Object ( O -- :: * -> * -> *; Monad , Object -- :: * -> * -> * , newObject -- :: O s (Object s a) , compareObject -- :: Object s a -> Object s b -> Maybe (a -> b) , runO -- :: (forall s . O s a) -> a ) where ------------------------------------------------------------------- -- This module is an attempt to isolate the capability of the ST -- monad of dealing with several types at the same time. -- -- The idea is that objects of type "Object s a" represent `objects -- with identity', that are associated with a type a. There exists -- a comparison function that checks if two objects have the same -- identity. If this is the case, the associated types should be -- the same too, and a witness function is provided. -- -- To ensure that objects with the same identity really are the -- same object, and also to avoid polymorphically typed objects, -- we have to create the objects in a monad. We also have to use the -- "trick with the s", also used in the realization of the ST -- monad in Haskell. This trick also ensures we can never compare -- two "Object"s from two different "O"-threads. -- -- I conjecture that it is impossible to implement this module in -- pure Haskell with any of the known safe extensions. (So it is -- even impossible if you are allowed to use the ST monad.) -- -- Koen Claessen, 19 November 2000 ------------------------------------------------------------------- ------------------------------------------------------------------- -- type O, type Object: -- "O" is a state monad keeping track of unique tags. "Object" -- only contains a tag for checking equality. newtype O s a = MkO (Int -> (a, Int)) newtype Object s a = MkObject Int instance Monad (O s) where return x = MkO (\n -> (x, n)) MkO m >>= f = MkO (\n -> let (a, n') = m n ; MkO m' = f a in m' n') ------------------------------------------------------------------- -- newObject: -- creating a new object is creating a new tag. newObject :: O s (Object s a) newObject = MkO (\n -> (MkObject n, n+1)) ------------------------------------------------------------------- -- compareObject: -- We check if the objects are equal. If so, we know we can safely -- cast. compareObject :: Object s a -> Object s b -> Maybe (a -> b) compareObject (MkObject tag1) (MkObject tag2) | tag1 == tag2 = Just unsafeCoerce | otherwise = Nothing -- boo! primitive unsafeCoerce "primUnsafeCoerce" :: a -> b ------------------------------------------------------------------- -- runO: -- Executing the state monad. runO :: (forall s . O s a) -> a runO m = let MkO f = m ; (a, _) = f 0 in a ------------------------------------------------------------------- -- the end. ===== module MyST ( ST -- :: * -> * -> *; Monad , STRef -- :: * -> * -> *; Eq , newSTRef -- :: a -> ST s (STRef s a) , writeSTRef -- :: STRef s a -> a -> ST s () , readSTRef -- :: STRef s a -> ST s a , runST -- :: (forall s . ST s a) -> a ) where ------------------------------------------------------------------- -- This module implements an inefficient version of the ST -- monad in "normal" Haskell; the only extensions we use are -- existential and universal quantification, and the "Object" module. -- -- The implementation is inefficient because it uses lists as -- lookup tables. -- -- Koen Claessen, 19 November 2000 ------------------------------------------------------------------- import Object ( O , Object , newObject , compareObject , runO ) ------------------------------------------------------------------- -- type ST, type State, type Entry, type STRef: -- the implementation is straightforward: "ST" is a state monad -- in a type "State", which is a lookup table of existentially -- quantified "Entry"s. We also implement a weaker form of -- equality on "STRef"s. newtype ST s a = MkST (State s -> O s (a, State s)) type State s = [Entry s] data Entry s = forall a . Object s a := a newtype STRef s a = MkSTRef (Object s a) instance Monad (ST s) where return x = MkST (\n -> do return (x, n)) MkST m >>= f = MkST (\n -> do (a, n') <- m n ; let MkST m' = f a in m' n') instance Eq (STRef s a) where MkSTRef tp1 == MkSTRef tp2 = case tp1 `compareObject` tp2 of Just _ -> True Nothing -> False ------------------------------------------------------------------- -- newSTRef, readSTRef, writeSTRef, runST: -- the only interesting things happening here are the safe casts -- by "readSTRef" and "writeSTRef" (note that they are done in -- different directions). newSTRef :: a -> ST s (STRef s a) newSTRef a = MkST $ \st -> do tp <- newObject return (MkSTRef tp, (tp := a) : st) readSTRef :: STRef s a -> ST s a readSTRef (MkSTRef tp) = MkST $ \st -> do return (find st tp, st) where find ((tp1 := a) : st) tp2 = case tp1 `compareObject` tp2 of Just cast -> cast a Nothing -> find st tp2 writeSTRef :: STRef s a -> a -> ST s () writeSTRef (MkSTRef tp) a = MkST $ \st -> do return ((), update st tp a) where update (ent@(tp1 := a) : st) tp2 a' = case tp2 `compareObject` tp1 of Just cast -> (tp1 := cast a') : st Nothing -> ent : update st tp2 a' runST :: (forall s . ST s a) -> a runST m = let MkST f = m in runO (do (a,_) <- f []; return a) ------------------------------------------------------------------- -- the end.

1 0

TIE: A CHR-based Type Inference Engine
by Martin Sulzmann 18 Sep '01

18 Sep '01

Dear all, the following might be of interest to Haskellians and Types people. I'd like to announce the availability of TIE: A CHR-based Type Inference Engine We present a generic type inference algorithm for Hindley/Milner style systems based on Constraint Handling Rules (CHRs). The system has been implemented in Haskell. We also provide a number of examples which show the expressiveness of the system. You can download it from http://www.cs.mu.oz.au/~sulzmann/chr/ Martin Sulzmann

1 0