Re: ANSIfication of hp2ps
Nicholas Nethercote wrote: Ralf Wildenhues wrote a patch ANSIfying hp2ps, which included a fix that could avoid a bug. See: bugs.kde.org/show_bug.cgi?id=82098 I've applied the patch to GHC's HEAD and STABLE branches, thanks. Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
typo in decl. of timezone in Time.hsc?
I think there may be a typo in libraries/base/System/Time.hsc. Right now lines 362-364 of Time.hsc are: #if !defined(mingw32_TARGET_OS) foreign import ccall unsafe timezone timezone :: Ptr CLong #endif I think the foreign import of timezone on line 363 is missing an ampersand. That is, I believe this should be: #if !defined(mingw32_TARGET_OS) foreign import ccall unsafe timezone timezone :: Ptr CLong #endif This would make it consistent with the declaration on line 355, and would allow it to compile in my environment (building ghc as a cross-compiler for a target OS in which line 363 of Time.hsc gets compiled). -Antony ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[Haskell] Re: Initialisation without unsafePerformIO
In article [EMAIL PROTECTED],
John Meacham [EMAIL PROTECTED] wrote:
I am a fan of allowing top level declarations of the form:
foo - newIORef foo
which would behave as an initializer, with the semantics being that it
be evaluated at most once before foos first use. (so it could be
implemented via unsafePerformIO or as an init section run before main).
The
{-# NOINLINE foo #-}
foo = unsafePeformIO $ newIORef foo
idiom is so common and useful, it should have some compiler support. It
is 'clean' too, since all we are doing is extending the world with new
state, but in a much cleaner/safer way then writing to a file or environment
variable or other methods of storing state in the world.
Clean it is not:
foo :: a
foo - newIORef undefined
writeChar :: Int - IO ()
writeChar x = writeIORef foo x
readString :: IO String
readString = readIORef foo
cast :: Char - IO String
cast c = (writeChar c) readString
--
Ashley Yakeley, Seattle WA
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Initialisation without unsafePerformIO
On Fri, 04 Jun 2004 00:35:14 -0700, Ashley Yakeley [EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED],
John Meacham [EMAIL PROTECTED] wrote:
I am a fan of allowing top level declarations of the form:
foo - newIORef foo
which would behave as an initializer, with the semantics being that it
be evaluated at most once before foos first use. (so it could be
implemented via unsafePerformIO or as an init section run before main).
The
{-# NOINLINE foo #-}
foo = unsafePeformIO $ newIORef foo
idiom is so common and useful, it should have some compiler support. It
is 'clean' too, since all we are doing is extending the world with new
state, but in a much cleaner/safer way then writing to a file or environment
variable or other methods of storing state in the world.
Clean it is not:
foo :: a
foo - newIORef undefined
writeChar :: Int - IO ()
writeChar x = writeIORef foo x
readString :: IO String
readString = readIORef foo
cast :: Char - IO String
cast c = (writeChar c) readString
If we check that the type of foo is monomorphic,
this is no longer unsafe.
-- Daan.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Initialisation without unsafePerformIO
On Fri, Jun 04, 2004 at 12:35:14AM -0700, Ashley Yakeley wrote:
In article [EMAIL PROTECTED],
John Meacham [EMAIL PROTECTED] wrote:
I am a fan of allowing top level declarations of the form:
foo - newIORef foo
which would behave as an initializer, with the semantics being that it
be evaluated at most once before foos first use. (so it could be
implemented via unsafePerformIO or as an init section run before main).
The
{-# NOINLINE foo #-}
foo = unsafePeformIO $ newIORef foo
idiom is so common and useful, it should have some compiler support. It
is 'clean' too, since all we are doing is extending the world with new
state, but in a much cleaner/safer way then writing to a file or environment
variable or other methods of storing state in the world.
Clean it is not:
foo :: a
foo - newIORef undefined
writeChar :: Int - IO ()
writeChar x = writeIORef foo x
readString :: IO String
readString = readIORef foo
cast :: Char - IO String
cast c = (writeChar c) readString
Yeah, such an extension would need to ensure initializers are monomorphic. another
advantage of a special syntax rather than unsafePerformIO.
John
--
John Meacham - repetae.netjohn
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] TLCA 05 Call for Papers
TLCA'05 CALL FOR PAPERS Seventh International Conference on Typed Lambda Calculi and Applications (TLCA '05) Nara, Japan 21-23 April 2005 (Colocated with RTA as RDP '05) http://www.kurims.kyoto-u.ac.jp/rdp05/tlca/ The TLCA series of conferences serves as a forum for presenting original research results that are broadly relevant to the theory and applications of typed lambda calculi and related systems. The following list of topics is non-exhaustive: * Typed and untyped lambda-calculi as models of computation. * Proof-theory: Natural deduction, sequent calculi, cut elimination and normalization. Propositions as types, linear logic and proof nets. * Types: Subtypes, dependent types, type inference, polymorphism, types for security. * Semantics: Denotational semantics, game semantics, realizability, categorical models. * Programming languages: Foundations of functional and object-oriented programming, proof search, logic programming, type checking. * Implementation: Abstract machines, parallel execution, optimal reduction, program optimization. * Computer-aided reasoning. The programme of TLCA'05 will consist of three invited talks and about 25 papers selected from original contributions. Accepted papers will be published as a volume of Springer Lecture Notes in Computer Science series. [http://www.springer.de/comp/lncs/index.html] Submissions: The submitted papers should describe original work and should allow the Programme Committee to assess the merits of the contribution: in particular references and comparisons with related work should be included. Submission of material already published or submitted to other conferences with published proceedings is not allowed. Papers should not exceed 15 pages in Springer LNCS format. An abstract (ASCII text) of no more than 150 words should be sent separately at least a week before the paper submission deadline. All submissions should be sent by e-mail to [EMAIL PROTECTED] Important dates: Authors are required to submit a paper title and a short abstract at least a weak before the paper submission deadline. All deadlines below are at 24:00 Central European time (GMT+1). Titles and abstracts due: October 25, 2004 Paper submission deadline: November 2, 2004 Notification: December 22, 2004 Final versions due: January 31, 2005 Accepted papers should be prepared according to Springer LNCS guidelines as described in http://www.springer.de/comp/lncs/authors.html. Final versions must include all source files. Further information is available from the conference web page http://www.kurims.kyoto-u.ac.jp/rdp05/tlca/ Inquiries concerning submissions and programme should be addressed to [EMAIL PROTECTED] Inquiries concerning the conference organization and participation should be sent to [EMAIL PROTECTED] TLCA Steering Committee: Samson. Abramsky, Oxford, chair Henk Barendregt, Nijmegen Mariangiola Dezani-Ciancaglini, Turin Roger Hindley, Swansea Martin Hofmann, Munich TLCA 05 Programme Committee: Thorsten Altenkirch, University of Nottingham Stefano Berardi, University of Turin Adriana Compagnoni, Stevens Institute of Technology, Hoboken Herman Geuvers, Nijmegen University Andy Gordon, Microsoft Research, Cambridge Fritz Henglein, Copenhagen University Martin Hofmann, LMU Munich Assaf J. Kfoury, Boston University Atsushi Ohori, JAIST, Tatsunokuchi Laurent Regnier, IML Marseille Pawel Urzyczyn, Warsaw University, chair Marek Zaionc, Jagiellonian University, Cracow TLCA 05 Organizing Committee: - Masahito Hasegawa, Kyoto, chair Ryu Hasegawa, Tokyo Mitsu Okada, Keio Masahiko Sato, Kyoto Masako Takahashi, ICU -- ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Initialisation without unsafePerformIO
What ideas do people have for getting rid of unsafePerformIO? Hope my suggestion is not too naive. I get along quite fine using implicit parameters in many cases, it's just tedious explicitly typing them in every function context. I'd be pretty happy if it was possible to define the 'scope' of some implicit parameters in a module and/or define their scope as being a whole module. The 2nd option would be something like: module (?par :: Parameter) = A where ... Functions in A could have ?par in their context without having it explicitly typed. Now the import of A could be done with: module B where import A -- simple, ?par unbound import A as Ak where ?par = k -- ?par bound to k import A as Am where ?par = m -- ?par bound to m ... k :: Parameter k = ... m :: Parameter m = ... ... Also, module (?par :: Parameter) = C where import A -- both A and C paremeterised by ?par Since both modules share the same parameter, instantiation on ?par in the import of C would propagate to the import of A. At first glance it seems simple syntactic sugar and therefore doable. Along with some options in the interpreter to hide/show (this kind of) implicit parameters when displaying signatures, check module context, etc. probably also quite usable. J.A. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
