[Haskell] Non-drifting clock, anyone?
Here it is, in all its greatly untested glory: http://pastebin.ca/109242 I don't know how much error it has, but the error won't stack up: if it's one second off, it will remain one second off until the end of time, or until your system clock drifts. But system clock drifts will be fixed by synchronizing your system clock with the outside world, except that if your clock jumps forward, this one will suddenly tick like mad, and if it jumps backward, this one will stop for a while... oh well. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] thread-local variables
Frederik Eaton wrote: On Mon, Jul 31, 2006 at 03:09:59PM +0300, Einar Karttunen wrote: On 31.07 03:18, Frederik Eaton wrote: 4) the library runs the callback code in Tw where the TLS state is invalid. This is even worse than a global variable in this case. If you have threads, and you have something which needs to be different among different threads, then it is hard for me to see how thread-local variables could be worse than global variables in any case at all. I haven't been following the technicalities of the particular scenario that's under discussion so I don't know exactly what either of you mean by "(even) worse than global variables". I just want to point out that, as I (and a few others) see it at least, top level mutable state (aka "global variables") is absolutely necessary sometimes for _SAFETY_ reasons. If anybody still doesn't "get it" re. why we need top level mutable state, the point is not to avoid explicit state handle threading. The point is to avoid exposing "newState" constructors as part of the IO library API (thereby making it invulnerable to accidental state "spoofing"). If you're going to deny library users the ability to create new state handles then you have to make at least one "ready made" state handle available at the top level. It just so happens that in the common case where there can be only one such state handle (for safety reasons) then you can completely eliminate this from the exposed API. As for the subject under discussion (thread local state), I am personally sceptical about it. Why do we need it? Are we talking about safety or just convenience/API elegance? I've never encountered a situation where I've needed thread local state, (but this does not necessarily make it evil:-) But I would say that I think I would find having to know what thread a particular bit of code was running in in order to "grok it" very strange, unless there was some obvious technical reason why the thread local state needed to be thread local (can't think of any such reason right now). My 2p.. Regards -- Adrian Hey ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Call for Participation: Scheme & Functional Programming Workshop 2006
Dear all, The Scheme and Functional Programming Workshop pre-registration deadline is in about 2 and a half weeks -- do be sure to register for ICFP and the workshop before then. Come to hear Manuel Serrano talk about HOP, his new language for programming the web, a status report from the R6RS editors, and presentations of the work below. I look forward to seeing you in Portland! http://scheme2006.cs.uchicago.edu/ Best, Robby A Self-Hosting Evaluator using HOAS Eli Barzilay (Northeastern University) We demonstrate a tiny, yet non-trivial evaluator that is powerful enough to run practical code, including itself. This is made possible using a Higher-Order Abstract Syntax (HOAS) representation -- a technique that has become popular in syntax-related research during the past decade. With a HOAS encoding, we use functions to encode binders in syntax values, leading to an advantages of reflecting binders rather than re-implementing them. In Scheme, hygienic macros cover problems that are associated with binders in an elegant way, but only when extending the language, i.e., when we work at the meta-level. In contrast, HOAS is a useful object-level technique, used when we need to represent syntax values that contain bindings -- and this is achieved in a way that is simple, robust, and efficient. We gradually develop the code, explaining the technique and its benefits, while playing with the evaluator. >From Variadic Functions to Variadic Relations William E. Byrd and Daniel P. Friedman (Indiana University) Scheme makes it easy to define variadic functions, which take an arbitrary number of arguments; miniKanren, a logic programming language embedded in R5RS Scheme, makes it easy to define variadic relations. A variadic miniKanren relation takes two arguments: a list containing input arguments and an output argument. A fresh or partially-instantiated logic variable passed to a variadic relation can represent the list of input arguments. A relation may also be super-variadic---such a relation takes a list of lists of input arguments. We show the variadic and super-variadic relational equivalent of several variadic functions, examples of their use, and several abstractions over these relations. We also present a brief miniKanren overview, along with an R5RS-compliant implementation of the subset of miniKanren that we use. Experiences with Scheme in an Electro-Optics Laboratory Richard Cleis and Keith Wilson (Air Force Research Laboratory) The Starfire Optical Range is an Air Force Research Laboratory engaged in Atmospheric Research near Albuquerque, New Mexico. Since the late 1980's it has developed numerous telescope systems and auxiliary devices. Nearly all are controlled by C programs that became difficult to manage due to the large number of configurations required to support the experiments. To alleviate the problem, Scheme has been introduced in at least six distinct ways. This paper describes the uses of Scheme, emerging programming techniques, and general experiences of the past several years. Rapid Case Dispatch in Scheme William D. Clinger (Northeastern University) The case expressions of Scheme can and should be implemented efficiently. A three-level dispatch performs well, even when dispatching on symbols, and scales to large case expressions. A Stepper for Scheme Macros Ryan Culpepper, Matthias Felleisen (Northeastern University) Even in the days of Lisp's simple defmacro systems, macro developers did not have adequate debugging support from their programming environment. Modern Scheme macro expanders are more complex than Lisp's, implementing lexical hygiene, referential transparency for macro definitions, and frequently other source properties. Scheme implementations, however, have only adapted Lisp's inadequate macro inspection tools. Unfortunately, these tools rely on a rather naive model of the expansion process, thus leaving a large gap between Scheme's complex mode of expansion and what the programmer sees. In this paper, we present a macro debugger with full support for modern Scheme macros. To construct the debugger, we have extended the macro expander so that it issues a series of expansion events. A parser turns these event streams into derivations in a natural semantics for macro expansion. From these derivations, the debugger extracts a reduction-sequence (stepping) view of the expansion. A programmer can specify with simple policies which parts of a derivation to omit and which parts to show. Last but not least, the debugger includes a syntax browser that graphically displays the various pieces of information attached to syntactic tokens. Automatic construction of parse trees for lexemes Danny Dub\'e (Universit\'e Laval) and Anass Kadiri (EPITA, Paris France) Recently, Dub\'e and Feeley presented a technique that makes lexical analyzers able to build parse trees for the lexemes that match regular expressions. While parse tr
Re: [Haskell] thread-local variables (was: Re: Implicit Parameters)
On Mon, Jul 31, 2006 at 03:09:59PM +0300, Einar Karttunen wrote: > On 31.07 03:18, Frederik Eaton wrote: > > I don't think it's necessarily such a big deal. Presumably the library > > with the worker threads will have to be invoked somewhere. One should > > just make sure that it is invoked in the appropriate environment, for > > instance with the database connection already properly initialized. > > > > (*) One might even want to change the environment a little within each > > thread, for instance so that errors get logged to a thread-specific > > log file. > > So we have the following: > 1) the library is initialized and spawns worker thread Tw > 2) application initializes the database connection and it >is associated with the current thread Tc and all the children >it will have (unless changed) > 3) the application calls the library in Tc passing an IO action >to it. The IO action refers to the TLS thinking it is in >Tc where it is valid. > 4) the library runs the callback code in Tw where the TLS state is >invalid. This is even worse than a global variable in this case. If you have threads, and you have something which needs to be different among different threads, then it is hard for me to see how thread-local variables could be worse than global variables in any case at all. > Of course one can argue that the application should first initialize > the database handle. But if the app uses worker threads (spawned > before library initialization) then things will break if a library > uses TLS and callbacks and they end up running in threads created > before the library initialization. OK, sure. In certain situations you have to keep track of whether a function to which you pass an action might be sending it off to be run in a different thread. We've been over this. Perhaps users should be warned in the documentation - and in the documentation for exceptions as well. I really don't see that as a problem that would sneak up on people, since if you're passing an action to a function, rather than executing it yourself, then in most cases it should be clear to programmers that the action will run in a different context if not a different thread altogether. And if you want to force the context to be the same, you wrap the action in something restoring that context, just like you would have to do with your state transformer monad stack. Another way to write buggy code is to have it so bloated with extra syntax - e.g. with monad conversions, or extra function parameters, as you propose - that it becomes impossible to read and understand. Frederik -- http://ofb.net/~frederik/ ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] thread-local variables (was: Re: Implicit Parameters)
On 31.07 14:03, Thomas Conway wrote: > This is why I believe transaction-local variables are a more useful concept. > You are garanteed that there is only one thread accessing them, and > they behave just like ordinary TVars except that each transaction has > its own copy. This seems like it could be useful. E.g. marking graph nodes while traversing them. > The argument to newLVar is an initial value that is used at the start > of each transaction. Note that this means that the value in an LVar > does not persist between transaction. I agree that this limits their > use, but simplifies them immensely, and doesn't stand in the way their > being useful for solving a bunch of problems. I think that them "reverting" to the initial value is more useful than persisting behavior. - Einar Karttunen ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] thread-local variables (was: Re: Implicit Parameters)
On 31.07 03:18, Frederik Eaton wrote: > I don't think it's necessarily such a big deal. Presumably the library > with the worker threads will have to be invoked somewhere. One should > just make sure that it is invoked in the appropriate environment, for > instance with the database connection already properly initialized. > > (*) One might even want to change the environment a little within each > thread, for instance so that errors get logged to a thread-specific > log file. So we have the following: 1) the library is initialized and spawns worker thread Tw 2) application initializes the database connection and it is associated with the current thread Tc and all the children it will have (unless changed) 3) the application calls the library in Tc passing an IO action to it. The IO action refers to the TLS thinking it is in Tc where it is valid. 4) the library runs the callback code in Tw where the TLS state is invalid. This is even worse than a global variable in this case. Of course one can argue that the application should first initialize the database handle. But if the app uses worker threads (spawned before library initialization) then things will break if a library uses TLS and callbacks and they end up running in threads created before the library initialization. - Einar Karttunen ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Paper announcement: Software Extension and Integration with Type Classes
Dear Haskellers, The following paper may still benefit from your comment. The final version is only due per 10 August 2006. Thanks, Ralf Laemmel -- http://homepages.cwi.nl/~ralf/gpce06/ Title: Software Extension and Integration with Type Classes Authors: Ralf Lämmel and Klaus Ostermann Abstract The abilities to extend a software module and to integrate a software module into an existing software system without changing existing source code are fundamental challenges in software engineering and programming-language design. We show that these challenges can be tackled, at the level of language expressiveness, by using the language concept of type classes, as it is available in the functional programming language Haskell. A detailed comparison with related work shows that type classes provide a powerful framework in which solutions to known software extension and integration problems can be provided. We also pinpoint several limitations of type classes in this context. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
