November 2004 - Haskell

Re: [Haskell-cafe] Re: [Haskell] Re: Global Variables and IO initializers
by Adrian Hey 08 Nov '04

08 Nov '04

On Monday 08 Nov 2004 6:00 am, Peter Simons wrote: > Frankly, the idea that anyone would want to jump through > hoops to add them to a purely functional language sounds > bizarre to me. The first step to solving a problem is to at least recognise that it exists. What is "bizarre" is that so many folk seem to be in denial over this. Perhaps you would like to show me your solution to the "oneShot" problem. If this is such a wacky idea then why is the use of the unsafePerformIO hack to do precisely this so common place? I gather it's even used within ghc. If the two Simons don't know how to write "proper" Haskell, what hope is there for the rest of us. Also a few more points that seem to need repeating.. 1- We're talking about the general problem of creating top level "things with identity" (does anyone have a less cumbersome term?) 2- Creating top-level mutable variables (IORefs) is just one utterly trivial use of this capability. 3- Top-level does not imply global. 4- They already exist (stdin,stout,stderr) and I don't recall anybody ever complaining about this. 5- The above are already *implicitly* referenced by many other commonly used top level IO related functions. > But by all means, as long as the compiler > extension is disabled per default I won't mind. :-) No doubt it would be, like all non-standard extensions. But why would it be a problem if it was not? If you don't want to use <- bindings then don't. Nothing else has changed. Regards -- Adrian Hey

4 6

RE: [Haskell] threading mutable state through callbacks
by Simon Marlow 08 Nov '04

08 Nov '04

On 08 October 2004 19:18, Sven Panne wrote: > Jules Bean wrote: >> [...] Unfortunately, it's not going to work. It's not going to work >> because some of the procedures take callbacks, and the callbacks are >> values of type IO (). I can see two solutions to this: >> >> a) revert to using an IORef [...] >> b) write the callbacks as values of type StateT Env IO () [...] > > or > > c) Give up any hope of clean semantics and simply use a common hack > like: > > {-# NOINLINE myGlobalVar #-} > myGlobalVar :: IORef Int > myGlobalVar = unsafePerformIO (newIORef 0) > > My GLUT binding does it happily, as does GHC itself, [snip] I'd like to add that while the implementation might be a little unsafe, there's no problem in principle with the semantics of top-level IORefs. We could add such a thing as a GHC extension, but it would be nice if it were an instance of a more general-purpose extension. Cheers, Simon

18 48

RE: [Haskell-cafe] Re: [Haskell] Re: Global Variables and IOinitializers
by Simon Peyton-Jones 08 Nov '04

08 Nov '04

| Please, can we confine this discussion to just one mailing list:-) | | It started out on haskell(a)haskell.org so that's where I'd like | to keep it (at least that's where I will be posting my responses | from now on). Actually, I'd like to suggest that it move to Haskell-café. It's certainly an interesting discussion, but it's quite a high bandwidth one, and that seems more appropriate to the Haskell-café list. Simon

1 0

Re: [Haskell] Re: Global Variables and IO initializers
by Adrian Hey 08 Nov '04

08 Nov '04

Please, can we confine this discussion to just one mailing list:-) It started out on haskell(a)haskell.org so that's where I'd like to keep it (at least that's where I will be posting my responses from now on). On Sunday 07 Nov 2004 10:38 pm, Keean Schupke wrote: > >I don't understand the relevance of this. In the example I gave > >we're not talking about an abstract data structure and the init > >function is not stateless. > > Well, it works like this, to call any function in your library > you must present a state-type. The only way to get a > state-type would be to call the init function. Therefore the > type system enforces that initialisation has occured > before a function is called. The user would not need to > call the initialiser again as you would pass the state-type > between functions. The neatest way to do this would be > to make functions in your interface instances of a > state-monad-transformer that could be layered over the > IO monad. So how does this _prevent_ the user calling realInit twice? Also, you seem to be assuming that the parameter returned by realInit is a some kind of state reference that must be passed as an argument to every function that is dependent on that state. There may be something to be said for that approach (for the reasons you give), but it's also rather tiresome to do this. (Almost as awkward as Cleans unique environment passing.) But maybe realInit simply returns a Bool to indicate whether or not initialisation is successful (as is typical with C). Or maybe it just returns () if there's no possibility of failure. I certainly could design the realInit binding so that it returns an abstract state reference, and I could insist that every function in the library takes that state reference as an argument. But why should I make life so awkward for both myself and library users, especially as AFAICS it does not stop realInit being used twice or more. > >I can assure you that for the intended applications of oneShot it > >is vital that realInit is executed once at most, but the user must > >have the freedom to execute userInit as many times as they need > >(I.E. without the burden of having to keep track of whether or not > >they've used it before). > > I don't understand this - If you pass the state type you > do not need to call init again. Please just take my word for it that that realInit can never be used more than once. That is the basic premise of this problem. The user may not need to use it more than once, but that doesn't mean they won't, and in fact it may be rather awkward for them to ensure they don't (other than by using oneShot or similar mechanism themselves at the top level). > It would work like openFile, > which seems easy enough for users to understand is > called only once on a file to get the filehandle that is used > with the IO functions. You can call the state-type returned > from your library an opaque-handle, and treat it like a file > handle. No it wouldn't. realInit is not an "act of creation" which may be used again and again to create more and more things. It is an act of initialisation of a unique external resource. > I am only trying to understand the need for this. As it > appears the cost of using the unsafePerformIO style is that > certain optimisations need to be switched off. They only need to be switched off for an entire module because of the use of unsafePerformIO. This is the problem, not the use of top level <- bindings (if they existed). So why not fix the language to make the use of unsafePerformIO unnecessary? > it seems it would be better to find an alternative. Sure there are alternatives, darned awkward ones AFAICS. Why should this awkwardness be forced upon us because of (what appears to me) a dogmatic belief that top level "things with identity" are a bad thing? Why are they a bad thing? Why are top level IORefs any worse than other IORefs (for example)? [I hope nobody is going to bring up the old type security chestnut in response to this question. We've already been over that ground.] > If you could give > more details of the application someone may be able to > suggest a resonable way of refactoring. The problem is to ensure that a top level IO action cannot be executed more than once. Regards -- Adrian Hey

2 1

Re: [Haskell] Re: Global Variables and IO initializers
by Adrian Hey 08 Nov '04

08 Nov '04

On Monday 08 Nov 2004 1:55 am, Benjamin Franksen wrote: > [moving to haskell-cafe] > > Sorry for the long post. [moving back to haskell] Hope you'll exuse me if I don't respond to everything here, just don't have the stamina. But maybe this.. > Timber doesn't even have top-level IO actions, instead > everything you need from the environment is given as an argument to main. > Mark that Timber is used for real-time control, an inherently stateful and > IO intensive field. > Your opinion that it automatically leads to a horrible API if you have > to pass the initialized state around amounts to saying that in an OO > language like Eiffel only libraries with horribly inconvenient APIs can > be written. This is ridiculous. It would be ridiculous if this was my opinion, but it ain't. Or to be more precise I think the O'Haskell (and I presume Timber and maybe Eiffel) approach to state is absolutely right. Unfortunately it just ain't that easy to apply these ideas in Haskell as it is (which is why O'Haskell was produced in the first place I guess). However, turning Haskell into O'Haskell seems like a far more radical suggestion than the (IMO) conservative language extension under discussion. So I don't expect it to happen anytime soon. Maybe if Haskell ever gets a better records/modules system things might look a bit different. But there doesn't seem to much prospect of that happening either at the moment. BTW, I also think there are some important differences between the O'Haskell way (which I don't object to) and what you and Keaan are advocating AFAICT (which I do object to). Regards -- Adrian Hey

2 1

Re: [Haskell] Re: Global Variables and IO initializers
by Benjamin Franksen 07 Nov '04

07 Nov '04

On Sunday 07 November 2004 13:36, you wrote: > AFAICS the only alternative to.. > > userInit <- oneShot realInit > > is to export realInit, have users create their own userInit, and then pass > that around as an argument to everything that might make use of userInit. Yes. For instance, user code executes handle <- YourModule.init and in the rest of the program the handle is used as an argument to those and only those routines that actually depend on the initialized state represented by 'handle'. In the Haskell Web Server it turned out that after all it wasn't that many routines that depended on initialized state. It's a similar advantage as using the IO monad has over allowing arbitrary side-effects in functions: The IO monad gives you a clear separation between stuff that has (side-) effects (i.e. depends on the real word) and pure functions (which don't). Abandoning global variables gives you a clear separation of stuff that depends on initialized state and other stuff that does not depend on it. > Maybe I'm missing something, but this doesn't seem very attractive to me > as a library writer (it means I must expose realInit and just trust > users to only use it once). Your realInit is an IO action, right? Imagine you are a library user, and the library exports some IO action for you to use. Would you assume that it makes no difference whether you call it once or twice in the program? Surely you won't: You know that IO actions have (side-) effects, so you would take care that the actions get executed as many times as is apropriate. If the library docs indicate that it makes no sense to call it twice, why would you do so? Maybe *I* am missing something, but I can't see any principle difference between exporting 'realInit' and exporting 'putString'. In both cases the program behaves differently depending on whether I call it once or twice. > It doesn't seem very attractive to users either > (considerably complicates their code and places the burden on them to > "get it right"). It may seem so at first, but I think it's a delusion. I found out with the HWS, that it does *not* necessarily "considerably complicate" the (user) code. And the compiler helps you a lot to "get it right", much more in fact than if you hide state dependency inside global variables. In the above example, the compiler *forces* you to call 'YourModule.init' because it is the only way to produce a 'handle' and you need some 'handle' to call the routines that depend on it. It also forces you to call it *before* you use any of the routines that depend on it. All in all this lifts a lot of the burdon off the user, rather than placing it on her. At the moment I cannot imagine a well designed library interface where user code would be considerably complicated if no global variables were used. But maybe you have a good example at hand to prove that this is merely due to lack of imagination on my side, and that I was extremely lucky with the HWS? ;-) Cheers, Ben

2 1

Re: [Haskell] Re: Global Variables and IO initializers
by Benjamin Franksen 07 Nov '04

07 Nov '04

On Sunday 07 November 2004 16:18, you wrote: > Adrian Hey wrote: > >I'm not at all convinced, having not seen or groked either the "before" or > >"after" code. Perhaps you could show how this would work with an even > > simpler example, the one that I posted concerning the use of oneShot to > > create a top level (I.E. exportable) userInit. > > > >AFAICS the only alternative to.. > > > > userInit <- oneShot realInit > > > >is to export realInit, have users create their own userInit, and then pass > >that around as an argument to everything that might make use of userInit. > > The way I would do it would be to have an init function that > initialises an abstract data structure. Because the results of > the init function are stateless and not in a global variable it > does not matter if the user calls it twice. Yes, whenever possible I would use this approach. Unfortunately, there are libraries (or just modules) that need to do some IO action in order to produce the (A)DT. In this case it _will_ make a difference how often you call it. But then this is just how IO actions are by nature, isn't it? Ben

1 0

Coordination 2005: First call for papers
by Jean-Marie JACQUET 06 Nov '04

06 Nov '04

[ Our apologies for multiple copies. ] ====================================================================== Second Call for Papers COORDINATION 2005 7th International Conference on Coordination Models and Languages Namur, Belgium, 20-23 April 2005 http://www.coordination2005.org ====================================================================== IMPORTANT NEWS * Publication of the proceedings in the Lecture Notes of Computer Science of Springer-Verlag * Publication of selected work in Science in Computer Programming ====================================================================== IMPORTANT DATES * Submission of abstract: December 15, 2004 * Submission of papers: December 21, 2004 * Notification of acceptance: February 1, 2005 * Final version: February 15, 2005 * Conference: April 20-23, 2005 CONFERENCE GOALS Modern information systems rely increasingly on combining concurrent, distributed, mobile, reconfigurable and heterogenous components. New models, architectures, languages, verification techniques are necessary to cope with the complexity induced by the demands of today's software development. Coordination languages have emerged as a successful approach, in that they provide abstractions that cleanly separate behavior from communication, therefore increasing modularity, simplifying reasoning, and ultimately enhancing software development. Building on the success of the previous editions, this conference provides a well-established forum for the growing community of researchers interested in models, languages, architectures, and implementation techniques for coordination. PREVIOUS EDITIONS The previous editions of COORDINATION took place in Cesena (Italy), Berlin (Germany), Amsterdam (Netherlands), Limassol (Cyprus), York (UK), and Pisa (Italy). More details are available at http://music.dsi.unifi.it/coordination. TOPICS OF INTEREST They include but are not limited to: * Theoretical models and foundations for coordination: component composition, concurrency, mobility, dynamic aspects of coordination, emergent behavior. * Specification, refinement, and analysis of software architectures: patterns and styles, verification of functional and non-functional properties. * Coordination, architectural, and interface definition languages: implementation, interoperability, heterogeneity. * Multiagent systems and coordination: models, languages, infrastructures. * Dynamic software architectures: mobile code and agents, configuration, reconfiguration, self-organization. * Coordination and modern distributed computing: Web services, peer-to-peer networks, grid computing, context-awareness, ubiquitous computing. * Programming languages, middleware, tools, and environments for the development of coordinated applications * Industrial relevance of coordination and software architectures: programming in the large, domain-specific software architectures and coordination models, case studies. * Interdisciplinary aspects of coordination PROCEEDINGS The conference proceedings will be published by Springer, in the Lecture Notes in Computer Science (LNCS) series. Proceedings of the previous editions of this conference are also available in the LNCS series: volumes 1061, 1282, 1594, 1906, 2315, and 2949. A selection of the best papers will published in a special issue of the journal Science of Computer Programming. SUBMISSION INSTRUCTIONS Authors are invited to submit full papers electronically in PostScript or PDF using a two-phase online submission process. Registration of the paper information and abstract (max. 250 words) must be completed before December 15, 2004. Submission of the full paper is due no later than December 21, 2004. Submission will be handled through a conference management system: instructions will be published at http://www.coordination2005.org. Submissions must be formatted according to the LNCS guidelines (see http://www.springer.de/comp/lncs/authors.html) and must not exceed 15 pages in length. Papers that are not in the requested format or significantly exceed the mandated length may be rejected without going through the review phase. Submissions should explicitly state their contribution and their relevance to the theme of the conference. Other criteria for selection will be originality, significance, correctness, and clarity. Simultaneous or similar submissions to other conferences or journals are not allowed. CONFERENCE LOCATION The conference will be hosted by the Institute of Informatics at the University of Namur, Belgium. Capital of the Walloon Region, Namur is a beautiful city of 80.000 inhabitants. Its position at the confluent of two rivers gave it military and economic appeal, exploited by the Roman Empire and by many others since then. Much evidence of Namur's past can be visited nowadays, including the citadel, one of the greatest in Europe. Close to Brussels (60 km) and at the intersection of European railways and highways, Namur can be easily reached by road, train, and plane. PROGRAM COMMITTEE Co-Chairs Jean-Marie Jacquet University of Namur, Belgium jmj(a)info.fundp.ac.be www.info.fundp.ac.be/~jmj/ Gian Pietro Picco Politecnico di Milano, Italy picco(a)elet.polimi.it www.elet.polimi.it/upload/picco Members Farhad Arbab CWI, The Netherlands Luca Cardelli Microsoft Research, United Kingdom Gianluigi Ferrari University of Pisa, Italy Paola Inverardi University of l'Aquila, Italy Toby Lehman IBM Almaden Research Center, USA Ronaldo Menezes Florida Institute of Technology, USA Amy Murphy University of Lugano, Switzerland Andrea Omicini University of Bologna, Italy George Papadopoulos University of Cyprus, Cyprus Ernesto Pimentel University of Malaga, Spain Rosario Pugliese University of Firenze, Italy Antonio Porto New University of Lisbon, Portugal Carolyn Talcott SRI International, USA Sebastian Uchitel Imperial College, United Kingdom Jan Vitek Purdue University, USA Michel Wermelinger New University of Lisbon, Portugal The Open University, UK Herbert Wiklicky Imperial College, United Kingdom Alexander Wolf University of Colorado, USA Alan Wood University of York, United Kingdom Gianluigi Zavattaro University of Bologna, Italy

1 0

PPDP 2005 First Call for Papers
by Amy Felty 05 Nov '04

05 Nov '04

First Call for Papers: PPDP 2005 Seventh ACM-SIGPLAN International Symposium on Principles and Practice of Declarative Programming Lisboa, Portugal, 11-13 July 2005 IMPORTANT DATES Submission 13 February 2005 Notification 1 April 2005 Final Version 1 May 2005 WEB SITES: PPDP 2005 CFP: http://www.site.uottawa.ca/~afelty/ppdp05/ PPDP: http://pauillac.inria.fr/~fages/PPDP/ SCOPE OF THE CONFERENCE: PPDP 2005 aims to provide a forum that brings together those in the declarative programming communities, including those working in the logic, constraint and functional programming paradigms. The goal is to stimulate research in the use of logical formalisms and methods for specifying, performing, and analyzing computations, and to stimulate cross-fertilization by including work from one community that could be of particular interest and relevance to the others. Topics of more specific interest are enhancements to such formalisms with mechanisms for mobility, modularity, concurrency, object-orientation, and static analysis, as well as the fuller exploitation of the programming-as-proof-search framework through new designs and improved implementation methods. At the level of methodology, the use of logic-based principles in the design of tools for program development, analysis, and verification relative to all declarative paradigms is of interest. Papers related to the use of declarative paradigms and tools in industry and education are especially solicited. This list is not exhaustive: submissions related to new and interesting ideas relating broadly to declarative programming are encouraged. Prospective authors are encouraged to communicate with the Program Chair about the suitability of a specific topic. TOPICS (Not exhaustive): Logic, Constraint, and Functional Programming; Applications of Declarative Programming; Methodologies for Program Design and Development; Declarative Aspects of Object-Oriented Programming; Concurrent Extensions to Declarative Languages; Declarative Mobile Computing; Integration of Paradigms; Proof Theoretic and Semantic Foundations; Type and Module Systems; Program Analysis and Verification; Program Transformation; Abstract Machines and Compilation; Programming Environments PAPER SUBMISSIONS: Papers should be submitted electronically by 13 FEBRUARY 2005 via the symposium's web page. Acceptable formats are PostScript or PDF, viewable by gv. Submissions should not exceed 12 pages (including bibliography and appendices) in standard ACM conference format (see URL below). They must be written in English, must have a cover page with an abstract of up to 200 words, keywords, postal and electronic mailing addresses, and phone and fax numbers of the corresponding author. EVALUATION OF SUBMISSIONS: Submitted papers will be judged on the basis of significance, relevance, correctness, originality, and clarity. They should include a clear identification of what has been accomplished and why it is significant. They must describe original, previously unpublished work that has not been simultaneously submitted for publication elsewhere. Authors who wish to provide additional material to the reviewers beyond the 12-page limit can do so in clearly marked appendices: reviewers are not required to read such appendices. Submissions that do not meet these guidelines may not be considered. PROCEEDINGS: Proceedings will be published by ACM Press. ACM formatting guidelines are available online, along with formatting templates or style files for LaTeX, Word Perfect, and Word: http://www.acm.org/sigs/pubs/proceed/template.html. Authors of accepted papers will be required to sign the ACM copyright form. RELATED EVENTS: PPDP 2005 will be co-located with the 32nd International Colloquium on Automata, Languages and Programming (ICALP 2005), which will take place 11-15 July 2005. See http://icalp05.di.fct.unl.pt for more information. CONFERENCE CHAIR: Pedro Barahona, Universidade Nova de Lisboa, web: http://centria.di.fct.unl.pt/~pb, email: pb(a)di.fct.unl.pt PROGRAM CHAIR: Amy Felty, University of Ottawa, web: http://www.site.uottawa.ca/~afelty, email: afelty(a)site.uottawa.ca PROGRAM COMMITTEE: Pedro Barahona (Univ. Nova de Lisboa, Portugal) Gopal Gupta (Univ. Texas at Dallas, USA) Michael Hanus (Univ. Kiel, Germany) Kohei Honda (Queen Mary & Westfield Coll., UK) Michael Maher (National ICT, Australia) Maria Chiara Meo (Univ. G. D'annunzio, Italy) Gopalan Nadathur (Univ. Minnesota, USA) Atsushi Ohori (JAIST, Japan) Carsten Schuermann (Yale Univ., USA) German Vidal (Technical Univ. Valencia, Spain) Joe Wells (Heriot-Watt Univ., UK) Elena Zucca (Univ. Genova, Italy) PREVIOUS PPDP CONFERENCES: Paris (1999), Montreal (2000), Firenze (2001), Pittsburgh (2002), Uppsala (2003), Verona (2004).

1 0

Re: [Haskell] Re: Global Variables and IO initializers
by MR K P SCHUPKE 05 Nov '04

05 Nov '04

>You don't want stdin/stdout/stderr? Also these are only available in the IO monad... >without breaking referential transparency >by use of unsafePerformIO hack. I don't understand this still... how can it not break referntial transparancy. For example consider if stdin were available outside the IO monad. Could someone give an example of what these things are that need to be initialised and that are safe. The reason these things are unsafe is if I have two references to the same thing, and one reference is used to mutate the thing, the other will see the mutated value and not the original value as it should. The only solution has to be these things must be constants or in the ST or IO monad. Keean.

8 21