- Haskell - Haskell.org

Dynamic Loading?
by Ashley Yakeley 21 Mar '05

21 Mar '05

Is it possible to do dynamic loading in Haskell? Let us say you want to have plug-in loadable widgets. You create a widget API, which is in fact a data-type W (which you make an instance of Typeable). You then write an application that loads widgets, using something like this: loadDynamic :: FilePath -> IO Dynamic Someone else could then use your widget API to write code that provides a value of type W (or a Dynamic), and compile and link it as a widget that can then be loaded. Is this possible? -- Ashley Yakeley, Seattle WA

4 4

Arrows GUI Library Based on GTK+
by Kevin Atkinson 19 Mar '05

19 Mar '05

What follows is my first attempt of using Arrows to create a GUI Library based on GTK+. It uses many ideas from Fruit (http://haskell.org/fruit/) However it is based on discrete events rather than a continuous signal. The interface is only updated during an Event. It also ideas from Fudgets (http://www.md.chalmers.se/Cs/Research/Functional/Fudgets/) some of which were also used by Fruit. To the best of my knowledge this has note been attempted before as Fruit is not based on an existing GUI. As such I ran into a number of unique problems. Some of which are discussed in the implementation notes below. I plan on elaborating on the many issues I had to deal with latter. You can find the code and documentation at: http://kevin.atkinson.dhs.org/fg/. I am also intersting parts below (The whole file is two large). Feedback appreciated. -- FG.hs -- Copyright (C) 2005 by Kevin Atkinson under the GNU LGPL license -- version 2.0 or 2.1. You should have received a copy of the LGPL -- license along with this library if you did not you can find -- it at http://www.gnu.org/ {-| This module is a first attempt of using Arrows to create a GUI Library based on GTK+. A good understanding of how Arrows work is required in order to understand the interface. For more information on Arrows see <http://www.haskell.org/arrows/>. It uses many ideas from Fruit (<http://haskell.org/fruit/>). However it is based on discrete events rather than a continuous signal. The interface is only updated during an Event. It also ideas from Fudgets (<http://www.md.chalmers.se/Cs/Research/Functional/Fudgets/>), some of which were also used by Fruit. Here is a complete working example to give you an idea of how to use FG: > import FG > > -- A Widget with three buttons "Inc", "Dec" and "Reset". "Dec" is > -- disabled when the count is 0. Does not actually display the count. > -- The output value is the current value of the counter. > counter :: Widget WidgetP Int > counter = proc p -> hbox [] (proc _ -> do > rec inc <- tag (+1) <<< button [text "Inc"] -< def > dec <- tag (+(-1)) <<< button [text "Dec"] -< [enabled (c > 0)] > reset <- tag (const 0) <<< button [text "Reset"] -< def > cs@(_,c) <- hold 0 -< onEvent (\f -> Just $ f c) Nothing > (inc >< dec >< reset) > returnA -< cs) -< (p, ()) > > -- The main FG. Connects the value of the counter to a Label. > mainFG :: Container () () > mainFG = vbox [spacing 2] $ proc _ -> do > (_,c) <- counter -< def > label [] -< [text $ show c] > returnA -< () > > main :: IO () > main = runFG mainFG -} --------------------------------------------------------------------------- -- -- Basic Types -- data FG a b = FG !(FGState -> IO (FG' a b, FGState)) data Event = NoEvent | Event --------------------------------------------------------------------------- -- -- Internal data types -- data FG' a b = FG' !(Control -> a -> IO (Control, b)) data Control = Init | Pending !EventId | Handled !EventId | Done deriving Eq type EventId = Int data AbstrWidget = forall w. WidgetClass w => AbstrWidget w data PendingCallback = PendingCallback !EventId !(Callback -> IO ()) type Callback = IO () data FGState = FGState ![AbstrWidget] !EventId -- Last used callback id ![PendingCallback] --------------------------------------------------------------------------- -- -- Arrow Implementation -- instance Arrow FG where arr = arrFG (>>>) = combFG first = firstFG instance ArrowLoop FG where loop = loopFG arrFG :: (a -> b) -> FG a b arrFG f = FG $ \s -> do let f' c x = return (c, f x) return (FG' f', s) combFG :: FG a b -> FG b c -> FG a c combFG (FG f1) (FG f2) = FG $ \s -> do (FG' f1, s) <- f1 s (FG' f2, s) <- f2 s let f c v = do (c, v) <- f1 c v (c, v) <- f2 c v return (c, v) return (FG' f, s) firstFG :: FG a b -> FG (a,c) (b,c) firstFG (FG f) = FG $ \s -> do (FG' f, s) <- f s let f' c (x, y) = do (c, x) <- f c x return (c, (x, y)) return (FG' f', s) loopFG :: FG (a, c) (b, c) -> FG a b loopFG (FG f) = FG $ \z -> do (FG' f, z) <- f z st <- newIORef undefined let f' Init v = do (Init, (v', s)) <- f Init (v, undefined) writeIORef st s return (Init, v') f' c v = do s <- readIORef st (c, (_, s)) <- f c (v, s) (c, (v', s)) <- f c (v, s) writeIORef st s return (c, v') return (FG' f', z) --------------------------------------------------------------------------- -- -- ArrowDef -- class ArrowDef a where def :: a -- ^Evaluates to a sensible default value. When used as an Arrow, -- ie on the RHS of a @-<@, evaluates to 'init' which takes a -- paramater for the default value, if this parameter is ommited -- the default value is 'def'. instance ArrowDef () where def = () instance ArrowDef [a] where def = [] instance ArrowDef (Maybe a) where def = Nothing instance ArrowDef Event where def = NoEvent instance (ArrowDef a, ArrowDef b) => ArrowDef (a, b) where def = (def, def) --------------------------------------------------------------------------- -- -- AbstractFunction -- -- | An AbstractFunction is either a true function or an Arrow class AbstractFunction f where mkAFun :: (a -> b) -> f a b mkAFunDef :: (a -> b) -> b -> f a b ... --------------------------------------------------------------------------- -- -- Arrow Utilities -- -- -- |In a loop context (ie when rec is used) some arrows are not well -- defined as they may receive 'undefined' as a value during the first -- iteration. Guard those arrows by giving them a default value -- during the initial value, by using one of 'init', 'guard', or 'def', -- during the first iteration. -- -- Note: 'init' is also defined by the Prelude and List, and 'guard' -- is defined in Monad. -- init, guard :: a -> FG a a init d = FG $ \s -> do let f' Init _ = return (Init, d) f' c v = return (c, v) return (FG' f', s) guard = init -- def :: a -> FG a a instance ArrowDef (a -> FG a a) where def = init -- ArrowDef a => def :: FG a a instance ArrowDef a => ArrowDef (FG a a) where def = init def -- this is not a recursion the 'def' called is a -- different function -- -- |'><' merges two events, taking the value from the signal with an Event, -- if none of the signals have an event than the value is taken from -- the first signal. The case where more than one signal have an event -- should't happen but if it does the value of the first signal is taken -- (><) :: (Event, a) -> (Event, a) -> (Event, a) v >< (NoEvent, _) = v (NoEvent, _) >< v = v v >< _ = v -- -- |'tag' tages an event with a value, throwing away the old value. -- -- can either be used as a function or an arrow -- tag :: (AbstractFunction f) => b -> f (Event, a) (Event, b) tag v = mkAFun (\(e, _) -> (e, v)) -- -- |'hold' creates a value that will hold onto a value until instructed -- to change it. 'hold' is safe to use in a loop context -- hold :: Show s => s -> FG (Maybe s) (Event, s) hold s0 = FG $ \z -> do st <- newIORef s0 let f' c x = do s <- readIORef st case (c, x) of (Init, _) -> return (c, (NoEvent, s)) (_, Nothing) -> return (c, (NoEvent, s)) (_, (Just s')) -> do writeIORef st s' return (c, (Event, s')) return (FG' f', z) -- -- |'arrIO' is like 'arr' except that the function may perform IO -- -- This may be called multiple times during a single event, so be -- careful. It is best only to perform actions with side effects -- during the actual occurrence of the event of interest. -- arrIO :: (a -> IO b) -> FG a b arrIO f = FG $ \z -> do let f' c x = do r <- f x return (c, r) return (FG' f', z) -- -- |'onEvent' will call a function on the value of the event when there -- is any sort of event otherwise it will return a default value. It is -- also safe to in a loop context when used as an arrow. -- onEvent :: (AbstractFunction f) => (a -> b) -> b -> f (Event, a) b onEvent f def = mkAFunDef f' def where f' (NoEvent, _) = def f' (_, v) = f v --------------------------------------------------------------------------- -- -- runFG -- -- | Runs a FG Arrow runFG :: Container () () -> IO () runFG fg = runFG' fg () -- | Runs an FG Arrow with the given input and throws away the return value runFG' :: Container a b -> a -> IO () runFG' (FG f) v = do initGUI window <- windowNew onDestroy window mainQuit containerSetBorderWidth window 10 (FG' f, FGState [AbstrWidget w] _ cbs) <- f $ FGState [] 1 [] let h id = do f (Pending id) ([], v) return () mapM_ (\(PendingCallback id instCb) -> instCb $ h id) cbs widgetShow w f Init ([], v) -- initialize loops h 0 -- set initial state containerAdd window w widgetShow window mainGUI --------------------------------------------------------------------------- -- -- Widget data type -- -- $widget -- A 'Widget' is an Arrow corresponding to GUI element. A widget -- constructor is generally of the form @[p] -> Widget p v@ where @p@ -- is a property type. A property is created using a, possible -- overloaded, property function, common propery function include -- 'text', 'markup', 'enabled' and, 'visible'. -- -- A widget is of the type @'FG' [p] ('Event', v)@. The arrow input is -- a list of properties to change. The arrow output is an 'Event' and -- the current value associated with the Widget, if any. -- -- The event value is either 'NoEvent' if no event is emitted or 'Event'. -- Future versions will have a more specific mechanism to distinguish -- between different types of events. -- type Widget p v = FG [p] (Event, v) --------------------------------------------------------------------------- -- -- Properties -- class Text a where -- | The widget label text :: String -> a class Enabled a where -- | If the Widget is enabled, ie can receive user events enabled :: Bool -> a ... --------------------------------------------------------------------------- -- -- Label Widget -- type Label = Widget LabelP () -- ^ -- * doesn't emit any events -- -- * doesn't have any readable properties -- newtype LabelP = LabelP (forall w. LabelClass w => w -> IO ()) labelP (LabelP a) = a instance Enabled LabelP where enabled p = LabelP (enableW p) instance Visible LabelP where visible p = LabelP (visibleW p) instance Text LabelP where text p = LabelP (\w -> labelSetText w p) instance Markup LabelP where markup p = LabelP (\w -> labelSetMarkup w p) label :: [LabelP] -> Label label = widget' (labelNew Nothing) labelP NoEventP noProp --------------------------------------------------------------------------- -- -- Button Widget -- type Button = Widget ButtonP () -- ^ -- * emits an Event when pressed -- -- * doesn't have any readable properties -- newtype ButtonP = ButtonP (forall w. ButtonClass w => w -> IO ()) buttonP (ButtonP a) = a instance Enabled ButtonP where enabled p = ButtonP (enableW p) instance Visible ButtonP where visible p = ButtonP (enableW p) instance Text ButtonP where text p = ButtonP (textWL p) instance Markup ButtonP where markup p = ButtonP (markupWL p) button :: [ButtonP] -> Button button = widget' (widgetWithLabelNew buttonNew) buttonP (EP Event onClicked) noProp --------------------------------------------------------------------------- -- -- Container Widgets -- type Container a b = FG ([WidgetP], a) b -- ^ -- A container simply arranges the widgets of the underlying arrow in -- a fixed fashion. The first input of an arrow is for dynamically -- changing the properties of a container. The second input is passed -- to underlying arrow. The output is the same as the underlying -- arrow. -- hbox, vbox :: [BoxP] -> FG a b -> Container a b hbox = box' hBoxNew vbox = box' vBoxNew ... --------------------------------------------------------------------------- -- -- Generic Widget Implementation -- data EventParm w z = NoEventP | EP Event (w -> Callback -> IO z) noProp _ = return () widget' :: (WidgetClass w) => IO w -> (a -> w -> IO b) -> EventParm w z -> (w -> IO p) -> ([a] -> Widget a p) widget' create apply eventP prop ps = FG $ \(FGState ws cid cbs) -> do w <- create widgetShow w mapM_ (\a -> apply a w) ps case (eventP) of NoEventP -> do let f c ps = do unless (c == Init) $ mapM_ (\a -> apply a w) ps p <- prop w return (c, (NoEvent, p)) return (FG' f, FGState (AbstrWidget w : ws) cid cbs) (EP e cbF) -> do let f c ps = do unless (c == Init) $ mapM_ (\a -> apply a w) ps p <- prop w case c of Pending id | id == cid -> return (Handled cid, (e, p)) Handled id | id == cid -> return (Done, (NoEvent, p)) _ -> return (c, (NoEvent, p)) let cb f = do cbF w f; return () return (FG' f, FGState (AbstrWidget w : ws) (cid + 1) (PendingCallback cid cb : cbs)) ... --------------------------------------------------------------------------- -- -- Extra Documentation -- {- $ImplementationNotes Arrows essentially build up a huge tree like data structure represting the control flow between arrows. In the current implementation the /entire/ top-level structure has to be traversed when ever an event is fired -- even if absolutely no actions need to be taken. Worse when ever a loop is used the entire loop has to we traversed twice. Consequently, this means that any inner loops will end up being tranversed four times. More generally the deepest most loop will be traversed 2^d times, where d in the depth of loop. Thus FG will obviously not scale well for large applications. By mainating some state information on the value of final value of a loop during a previous event it should be possible to avoid having to traverse a loop twice. However, avoiding the problem of having to traverse the entire tree for every event is much more difficult and require dataflow analysis. Precise analysis will probably require the use of Generalised Algebraic Data Types (GADT) and possible changes to how code is generated when using the arrow notation. -} {- $Requirements FG is based on gtk2hs and uses several GHC extensions. It was tested with GHC 6.2.2 and gtk2hs 0.9.7. -} -- http://kevin.atkinson.dhs.org

4 7

Cfp: ICTCS'05 conference and Special issue announcement
by g. michele pinna 19 Mar '05

19 Mar '05

Apologies if you receive multiple copies ________________________________________________________________ Ninth Italian Conference on Theoretical Computer Science (ICTCS'05) Certosa di Pontignano (Siena), Italy October 12 - 14, 2005 http://ictcs05.dsmi.unisi.it Call for Papers The Ninth Italian Conference on Theoretical Computer Science will take place at the Certosa di Pontignano (Siena), Italy. Papers presenting original contributions in any area of theoretical computer science are being sought. A special issue of the journal Theory of Computing Systems (formerly Mathematical System Theory) containing full versions of papers selected from the conference is planned. Details of this special issue will be provided to the authors of those papers that are accepted for presentation at the conference. Topics include (but are not limited to): analysis and design of algorithms, computability, computational complexity, cryptography, formal languages and automata, foundations of programming languages and program analysis, foundations of artificial intelligence and knowledge representation, foundations of web programming natural computing paradigms (quantum computing, bioinformatics), parallel and distributed computation, program specification and verification, term rewriting, theory of concurrency, theory of data bases, theory of logical design and layout, type theory, security, symbolic and algebraic computation, Program Committee: Michele Bugliesi (Venezia), Mario Coppo (Torino, Co-Chair), Pierluigi Crescenzi (Firenze), Giulia Galbiati (Pavia) Luisa Gargano (Salerno), Giorgio Ghelli (Pisa), Roberto Grossi (Pisa), Benedetto Intrigila (L'Aquila), Nicola Leone (Cosenza), Elena Lodi (Siena, Co-Chair), Flaminia Luccio (Trieste), Andrea Masini (Verona), Giancarlo Mauri (Milano), Corrado Priami (Trento), Geppino Pucci (Padova), Davide Sangiorgi (Bologna). Organizing Committee: Sara Brunetti (Siena), G. Michele Pinna (Cagliari - Siena, Chair), Elisa B.P. Tiezzi (Siena). Invited Speakers: Luca Cardelli (Microsoft Research, Cambridge, United Kingdom) Giuseppe Castagna (LIENS - École Normale Supérieure, Paris, France) Nicola Santoro (School of Computer Science, Carleton University, Ottawa, Canada) Dates and Deadlines: Submission Deadline: 15 April 2005 Acceptance Notification: 7 June 2005 Camera-ready deadline: 2 July 2005 Early registration deadline: 16 September 2005 Conference: 12-14 October 2005 Submissions: Authors are invited to submit electronically one copy of their draft paper, not exceeding fifteen pages. The paper should clearly indicate the results achieved, their significance, and their relation to other work in the area. Extended proofs can be placed in a clearly marked appendix. It is planned to publish the proceedings in the Springer Lecture Notes in Computer Science series. To uniform the submissions the authors are encouraged to use Latex and the Springer LNCS style (www.springer.de/comp/lncs) The web-based submission form is available at the page ictcs05.dsmi.unisi.it/submission.html. In case electronic submission is not possible, the authors should contact: Mario Coppo Dipartimento di Informatica, Universita' di Torino Corso Svizzera 185 I-10149 Torino, Italy email: coppo(a)di.unito.it Conference Page: This Call For Papers is available online at the conference web page ictcs05.dsmi.unisi.it Registration Details: The registration form will be reachable from the conference web page. A limited number of grants for students and young researchers covering the registration fees are available. Details for the applications are in the conference web page.

1 0

State, StateT and lifting
by Juan Carlos Arevalo Baeza 19 Mar '05

19 Mar '05

I've recently been experimenting with a little "make" engine I've implemented in Haskell. I'm using state monads to do the work. I was attempting to use two functions: matchRuleST :: String -> State RuleSet (Maybe Rule) makeST :: String -> StateT RuleSet IO () matchRuleST doesn't really need IO for anything (it just works on the current state "RuleSet"). makeST needs IO (it does file date comparisons, actions on the files, etc... the usual "make" stuff). The problem is how to properly use matchRuleST from makeST. I searched for a proper lifting function (similar to liftIO, but which would lift from the state monad), and couldn't find one. So I changed the function signature to: matchRuleST :: String -> StateT RuleSet IO (Maybe Rule) and everything worked just fine. Then, I decided to try again, and came up with this function: liftState :: State s a -> StateT s m a liftState s = do state1 <- get ( let (result, state) = evalState (do {result <- s; state <- get; return (result, state)}) state1 in do put state return result ) which works like a charm and is not even IO-dependent. I'm learning here, so the questions are: Is there a better way to do this? Did I miss a similar function anywhere? Did I miss some useful abstraction that makes this a moot point? I'm using GHC 6.4. JCAB

2 1

Happy Error Token
by Clemens Ley 18 Mar '05

18 Mar '05

Hi I've had some trouble with the happy error token: What is it actually there for (apart form implementing the Haskell layout rule). I've not been able to find an example where it matters weather I include the error token or not. Can someone help me? Thanks in advance Clemens Ley

1 0

GHC: Setting default +RTS options at compile time?
by Graham Klyne 18 Mar '05

18 Mar '05

Is there any way to specify at compile/link time default options for GHC program +RTS options? I'm using the latest release (6.4). #g -- <aside> Why do I want this? I'm using GHC to write a program that will be used by non-comp uting people to preprocess some data in conjunction with an 18Mb database file. To load the database into a Data.Map value requires more than GHC's default 256Mb of heap, and I'd like to increase the program's default heap size, rather than telling users to use the +RTS -M100M option, as its one less thing to get wrong. There are of course other possible solutions, but in this case specifying a default heap size at compile time seems to be the most natural. </aside> ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

2 1

CfP: Curry and Functional Logic Programming 2005
by mh＠informatik.uni-kiel.de 18 Mar '05

18 Mar '05

We apologize if you receive multiple copies of this announcement. ====================================================================== CALL FOR PAPERS WCFLP 2005 International Workshop on Curry and Functional Logic Programming An ACM SIGPLAN sponsored workshop at ICFP 2005 Tallinn, Estonia September 29, 2005 WWW: http://www.informatik.uni-kiel.de/~mh/wcflp2005 ====================================================================== The integration of functional and logic programming has been extensively studied during the last years. The declarative multi-paradigm language Curry is one of the important results of this work since it combines in a seamless way the most relevant features of functional, logic, and concurrent programming. The development of Curry is an international initiative intended to provide a common platform for the research, teaching, and application of integrated functional logic languages. Various implementations of Curry are available and they have been used in a number of different applications. The aim of this workshop is to bring together researchers interested in Curry, related functional logic languages, and general aspects of integrating declarative programming paradigms. It promotes the cross-fertilizing exchange of ideas and experiences among researches and students from the different communities interested in the foundations, applications, and combinations of high-level, declarative programming languages and related areas. WCFLP 2005 includes the annual Workshop on Functional and Logic Programming (WFLP). Previous WFLP editions were: WFLP 2004 (Aachen, Germany), WFLP 2003 (Valencia, Spain), WFLP 2002 (Grado, Italy), WFLP 2001 (Kiel, Germany), WFLP 2000 (Benicassim, Spain), WFLP'99 (Grenoble, France), WFLP'98 (Bad Honnef, Germany), WFLP'97 (Schwarzenberg, Germany), WFLP'96 (Marburg, Germany), WFLP'95 (Schwarzenberg, Germany), WFLP'94 (Schwarzenberg, Germany), WFLP'93 (Rattenberg, Germany), and WFLP'92 (Karlsruhe, Germany). ---------------------------------------------------------------------- TOPICS WCFLP 2005 solicits papers in all areas of functional and (constraint) logic programming, including (but not limited to): * Language Design: modules and type systems, multi-paradigm languages, concurrency and distribution, objects * Foundations: formal semantics, rewriting and narrowing, type theory * Implementation: abstract machines, parallelism, compile-time and run-time optimizations, interfacing with external languages * Transformation and Analysis: abstract interpretation, specialization, partial evaluation, program transformation, meta-programming * Software Engineering: design patterns, specification, verification and validation, debugging, test generation, programming pearls * Integration of Paradigms: integration of declarative programming with other paradigms such as imperative, object-oriented, concurrent, and real-time programming * Applications: declarative programming in education and industry, domain-specific languages, visual/graphical user interfaces, embedded systems, WWW applications, knowledge representation and machine learning, deductive databases, advanced programming environments and tools The primary focus is on new and original research results but submissions describing innovative products, prototypes under development or interesting experiments (e.g., benchmarks) are also encouraged. ---------------------------------------------------------------------- PUBLICATION Abstracts of workshop papers will be published in ACM SIGPLAN Notices. Full workshop proceedings will be published by ACM's printing vendor and in ACM's Digital Library under the usual copyright policy. It is intended to publish a special issue of the best papers after the workshop. ---------------------------------------------------------------------- IMPORTANT DATES Deadline for submissions: June 5, 2005 Notification of acceptance: June 30, 2005 Camera-ready papers: July 12, 2005 Workshop: September 29, 2005 ---------------------------------------------------------------------- PROGRAM COMMITTEE Sergio Antoy (Portland State University, co-chair) Olaf Chitil (University of Kent) Rachid Echahed (IMAG, Grenoble) Moreno Falaschi (University of Siena) Michael Hanus (CAU Kiel, co-chair) Frank Huch (CAU Kiel) Tetsuo Ida (University of Tsukuba) Herbert Kuchen (Univ. Muenster) John W. Lloyd (Australian National University ) Francisco J. Lopez-Fraguas (UC Madrid) Wolfgang Lux (Univ. Muenster) Julio Marino (UP Madrid) Peter Thiemann (Univ. Freiburg) German Vidal (UP Valencia) ---------------------------------------------------------------------- PROGRAM CO-CHAIRS Sergio Antoy Michael Hanus Portland State University Institut fuer Informatik Dept. of Computer Science CAU Kiel P.O. Box 751 Olshausenstr. 40 Portland, OR 97207-0751 D-24098 Kiel USA Germany Phone: +1 (503) 725-4036 Phone: +49-431-880-7271 Fax: +1 (503) 725-3211 Fax: +49-431/880-7613 email: antoy(a)cs.pdx.edu email: mh(a)informatik.uni-kiel.de ---------------------------------------------------------------------- SUBMISSION Authors are invited to submit an extended abstract (no longer than 8 pages including figures and references) or a system description (no longer than 3 pages) in PDF or Postscript format. Submissions should include the title, authors' names, affiliations, addresses, and e-mail. All submissions must be written in English. Authors are strongly encouraged to use LaTeX2e and the ACM Proceedings Format (http://www.acm.org/sigs/pubs/proceed/template.html) All submissions must be original work. Submissions must be unpublished and not submitted for publication elsewhere. Work that already appeared in unpublished or informally published workshops proceedings may be submitted. Further details about the procedure to submit papers electronically will be announced at the workshop's web page at http://www.informatik.uni-kiel.de/~mh/wcflp2005 ----------------------------------------------------------------------

1 0

Using -main-is with GHC 6.4/Windows
by Graham Klyne 17 Mar '05

17 Mar '05

I've been trying to use the -main-is option with GHC 6.4 on Windows. In isolation it works fine, but it still doesn't achieve what I hoped it would. Consider this compilation output frgament: [[ Compiling AffyDataCalcTest ( AffyDataCalcTest.hs, AffyDataCalcTest.o ) Linking ... ./AffyDataCalc.o(.data+0xa70):fake: multiple definition of `ZCMain_main_srt' AffyDataCalcTest.o(.data+0x1fc):fake: first defined here ./AffyDataCalc.o(.data+0xa78):fake: multiple definition of `ZCMain_main_closure' AffyDataCalcTest.o(.data+0x204):fake: first defined here ./AffyDataCalc.o(.text+0x9158):fake: multiple definition of `ZCMain_main_info' AffyDataCalcTest.o(.text+0x1ff0):fake: first defined here ./AffyDataCalc.o(.text+0x9408):fake: multiple definition of `__stginit_ZCMain' AffyDataCalcTest.o(.text+0x20c0):fake: first defined here ]] The module 'AffyDataCalc' contains a function called 'main', which is the topo-level function of the target program I have under development. The module AffyDataCalcTest also has top-level function called runtest, which, you guessed it, runs a test of the program functions. It seems that the top-level functions still interfere with each other. [later] OK, it's not so bad. If I delete the AffyDataCalc.o file before compiling AffyDataCalcTest, it all works fine. [[ E:\OxfordCVS\DTGED\AffyData>ghc --make -fglasgow-exts -iD:\Cvs\DEV\HaskellUti C:\Dev\Haskell\Lib\HUnit;C:\Dev\Haskell\Lib\Parsec;C:\Dev\Haskell\MyLibs\ -o yDataCalcTest.exe -main-is AffyDataCalcTest.runtest AffyDataCalcTest Chasing modules from: AffyDataCalcTest Compiling ParseCSV ( ./ParseCSV.hs, ./ParseCSV.o ) Compiling FormatCSV ( ./FormatCSV.hs, ./FormatCSV.o ) Skipping ListHelpers ( D:\Cvs\DEV\HaskellUtils/ListHelpers.hs, D:\Cvs\D HaskellUtils/ListHelpers.o ) Compiling AffyDataCalc ( ./AffyDataCalc.hs, ./AffyDataCalc.o ) Skipping HUnitLang ( C:\Dev\Haskell\Lib\HUnit/HUnitLang.lhs, C:\Dev\H ell\Lib\HUnit/HUnitLang.o ) Skipping HUnitBase ( C:\Dev\Haskell\Lib\HUnit/HUnitBase.lhs, C:\Dev\H ell\Lib\HUnit/HUnitBase.o ) Skipping HUnitText ( C:\Dev\Haskell\Lib\HUnit/HUnitText.lhs, C:\Dev\H ell\Lib\HUnit/HUnitText.o ) Skipping HUnit ( C:\Dev\Haskell\Lib\HUnit/HUnit.lhs, C:\Dev\Haske Lib\HUnit/HUnit.o ) Skipping TestHelpers ( D:\Cvs\DEV\HaskellUtils/TestHelpers.hs, D:\Cvs\D HaskellUtils/TestHelpers.o ) Compiling AffyDataCalcTest ( AffyDataCalcTest.hs, AffyDataCalcTest.o ) Linking ... E:\OxfordCVS\DTGED\AffyData>affydatacalctest Cases: 2 Tried: 0 Errors: 0 Failures: 0AffyDataCalc done. Cases: 2 Tried: 1 Errors: 0 Failures: 0AffyDataCalc done. Cases: 2 Tried: 2 Errors: 0 Failures: 0 E:\OxfordCVS\DTGED\AffyData>ghcc AffyDataCalc ]] Hmmm... is there something the GHC --make feature can do to force recompilation of the other modules previously compiled as main modules? Just a thought. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

Call for IPSI Transactions Special Issues in 2005/6; c/ba
by IPSI Transactions Special Issues 17 Mar '05

17 Mar '05

Dear potential Speaker: We are pleased to inform you that both IPSI Transactions journals are planing some special issues in late 2005 and early 2006, and you are welcome to submit your paper(s), until the deadlines listed below! IPSI Transactions on Internet Research: March 31, 2005 - Special Issue on E-Education: Concepts and Infrastructure June 30, 2005 - Special Issue on E-Business: Concepts and Infrastructure IPSI Transactions on Advanced Research: March 31, 2005 - Special Issue on the Research with Multidisciplinary Elements June 30, 2005 - Special Issue on the Research with Interdisciplinary Elements Each submitted paper first undergoes the editor review, and those who pass this first stage are sent to 12 external experts for a rigorous review; decisions are made after at least 6 external reviewers respond! The review is free of charge, but the authors of the accepted papers ar expected to pay the publication fee of E400 per paper (if 4 or 5 or 6 pages of the TIR/TAR format), and the additional fee of E100 per page, for each extra page, till the maximum of 10 pages. Rigorous reviewing is the major strength of IPSI journals, which is the major contributor to their high quality! Soft copies of the existing issues of TIR and TAR can be seen at the web, and hard copies can be obtained on a special request by email, as indicated on the web, where can find all information! Sincerely yours, Prof. Dr. Veljko Milutinovic, Editor-in-Chief P.S. If you need aditional information, please reply to this e-mail.

1 0

Call for Participation: AAMAS 2005 Conference on Autonomous Agents & Multiagent Systems
by Matthias Klusch 17 Mar '05

17 Mar '05

+++ Apologies for multiple copies due to cross postings +++ Call for PARTICIPATION ****************************************************** 4th International Joint Conference AAMAS on Autonomous Agents and Multiagent Systems July 25 - 29, 2005 Utrecht University, The Netherlands http://www.aamas2005.nl ****************************************************** Technical program: http://www.aamas2005.nl/technical_program.php On-line registration: http://www.aamas2005.nl/registration.php On-line hotel reservation: http://www.aamas2005.nl/accommodation.php About the conference ==================== Agents are one of the most prominent and attractive technologies in computer science at the beginning of the new milennium. The technologies, methods, and theories of agents and multiagent systems are currently contributing to many diverse domains such as information retrieval, user interfaces, electronic commerce, robotics, computer mediated collaboration, computer games, education and training, ubiquitous computing, and social simulation. They not only are a very promising technology, but are also emerging as a new way of thinking, a conceptual paradigm for analyzing problems and for designing systems, for dealing with complexity, distribution, and interactivity, while providing a new perspective on computing and intelligence. The aim of this conference series established in 1995 is to provide a single, high-profile, internationally renowned forum for research in theory and practice of autonomous agents and multiagent systems. In particular, it brings together the world's researchers active in this important, vibrant, and rapidly growing field. AAMAS 2005 events include 29 workshops and 13 tutorials given by distinguished experts in the field, as well as an agent school, and doctoral mentoring program. AAMAS 2005 Workshops: http://www.aamas2005.nl/workshops.php AAMAS 2005 Tutorials: http://www.aamas2005.nl/tutorials.php EASSS 2005 European Agent Systems Summer School: http://www.aamas2005.nl/agent_school.php AAMAS 2005 Doctoral Mentoring: http://www.aamas2005.nl/doctoral_mentoring_program.php For more information please visit http://www.aamas2005.nl or please contact one of the co-chairs: General co-chairs Sarit Kraus, Bar-Ilan University / University of Maryland Munindar Singh, North Carolina State University Program co-chairs Sven Koenig, University of Southern California Michael Wooldridge, University of Liverpool Local organization chair Frank Dignum, Utrecht University --------------------------------------------------------------- Your are very cordially invited to participate in one of the major events of the year in the area of agent-based computing! --------------------------------------------------------------- We are looking forward to welcome you in Utrecht! The AAMAS 2005 Organizational Board

1 0