Re: [GHC] #716: Unloading a dll generated by GHC doesn't free all resources
#716: Unloading a dll generated by GHC doesn't free all resources -+-- Reporter: [EMAIL PROTECTED] | Owner: simonmar Type: bug | Status: reopened Priority: normal | Milestone: 6.6 Component: Runtime System |Version: 6.4.1 Severity: normal | Resolution: Keywords: | Os: Unknown Difficulty: Unknown | Architecture: Unknown -+-- Changes (by simonmar): * resolution: fixed = * milestone: 6.4.2 = 6.6 * status: closed = reopened Comment: On second thoughts I'll leave the ticket open until it's fully fixed. I don't expect to fix it properly in 6.4.2, though - the best chance for a complete fix is in the HEAD with the threaded RTS. As far as I'm aware, in the HEAD's threaded RTS, all threads should shut down properly at exit except those currently blocked in foreign calls. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/716 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #492: Retainer and biographical profiling with STM
#492: Retainer and biographical profiling with STM -+-- Reporter: simonmar| Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.4.2 Component: Runtime System |Version: 6.4.1 Severity: normal | Resolution: fixed Keywords: | Os: Unknown Difficulty: Unknown | Architecture: Unknown -+-- Changes (by simonmar): * architecture: = Unknown * resolution: None = fixed * difficulty: = Unknown * status: assigned = closed * os: = Unknown Comment: fixed in 6.4.2 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/492 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #731: GHCi doesn't work on powerpc64
#731: GHCi doesn't work on powerpc64 --+- Reporter: simonmar |Owner: Type: bug| Status: new Priority: normal |Milestone: Component: GHCi | Version: 6.4.1 Severity: normal | Keywords: Os: Unknown| Difficulty: Unknown Architecture: powerpc64 | --+- See diagnosis from Duncan Coutts: [http://www.haskell.org//pipermail/cvs-ghc/2006-March/028889.html] -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/731 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #732: Error in shutdownHaskell() in Win32 DLL
#732: Error in shutdownHaskell() in Win32 DLL -+-- Reporter: [EMAIL PROTECTED] |Owner: Type: bug | Status: new Priority: normal|Milestone: 6.4.2 Component: Runtime System| Version: 6.4.1 Severity: normal| Keywords: Os: Windows | Difficulty: Easy (1 hr) Architecture: Unknown | -+-- If an exception occurs in a Windows DLL produced by GHC, the following error message appears: {{{ ghcDll: internal error: too many hs_exit()s Please report this as a bug to glasgow-haskell-bugs@haskell.org, or http://www.sourceforge.net/projects/ghc/ }}} == How to reproduce == 1. Make a Haskell DLL using the enclosed Dll.hs and dllMain.c, e.g. {{{ ghc -c Dll.hs -fglasgow-exts ghc -c dllMain.c ghc --mk-dll -o test.dll Dll.o Dll_stub.o dllMain.o }}} 2. Generate an export library for the DLL, e.g. {{{ lib /DEF:test.def /MACHINE:x86 /OUT:test.lib }}} 3. Compile the executable with Visual C++ and run it. {{{ cl -c testdll.cpp link testdll.obj test.lib /OUT:testdll.exe testdll.exe }}} Note: if I comment out the shutdownHaskell() call from dllMain.c (the line marked with /***/), it works fine. Kind regards, Cyril --- Dll.hs --- {{{ module Dll (test) where foreign export ccall test :: IO () test = error Exception occurred }}} --- dllMain.c --- {{{ #include windows.h #include Rts.h extern void __stginit_Dll(void); static char* args[] = { ghcDll, NULL }; BOOL STDCALL DllMain ( HANDLE hModule , DWORD reason , void* reserved ) { if (reason == DLL_PROCESS_ATTACH) { startupHaskell(1, args, __stginit_Dll); return TRUE; } else if (reason == DLL_PROCESS_DETACH) { /***/ shutdownHaskell(); } return TRUE; } }}} --- test.def --- {{{ EXPORTS test }}} --- testdll.cpp --- {{{ extern C void test(); int main() { test(); return 0; } }}} -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/732 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Show-ing GHC internal data structures
David William Simmons-Duffin wrote: I'm working with a friend on a project that involves hacking at the GHC internals. We'd like to be able to print some of the large data structures involved -- specifically a TcGblEnv. TcGblEnv is a record with a number of fields of different types, and it would be silly to go through the source adding deriving Show to the end of each type definition. It seems like Show instances for internal data structures would be useful for the GHC developers (for debugging purposes -- perhaps they were left out of the GHC distribution to keep the compiled code small?), and we were wondering if anyone had the relevant instance declarations lying around. The TcGblEnv is Very Large Indeed. It probably includes almost everything in the heap :-) I suggest you selectively print out the bits you're interested in, there is plenty of pretty-printing machinery in GHC for displaying the contents of internal stuff. Also, in GHC we generally don't use Show. There is a class Outputable (utils/Outputable.lhs) which many datatypes are instances of, and it provides for pretty-printing data in several different styles: debug, user, code, etc. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] CFP2: Mathematically Structured Functional Programming
SECOND CALL FOR PAPERS Workshop on Mathematically Structured Functional Programming MSFP 2006 Kuressaare, Estonia, 2 July 2006 http://cs.ioc.ee/mpc-amast06/msfp/ a satellite workshop of MPC 2006 a small workshop of the TYPES project Background Something wonderful happened when monads arrived in Haskell: some human mathematics explaining the structure of certain computational phenomena became a mechanical means to implement those phenomena. It's a good way to go about functional programming - to dig out the mathematical structure underlying a problem and set it to work! There's more where monads came from, and we want it. This new workshop is about getting it. In recent years, a diverse array of mathematical structures has appeared in our programs: monads dualise to comonads and generalise to Freyd categories aka 'arrows'; 'container' types have a generalised polynomial structure supporting generic programming, not to mention a differential calculus; isomorphisms from 'high school algebra' are used to search libraries and repair type errors; coalgebras give structure to recursion; the list goes on... MSFP is broad in scope, covering the extraction of functionality from structure wherever it can be found. It complements the remit of its host conference, Mathematics of Program Construction, by seeking to enrich the language and toolset available for specifications and programs alike. It is also a small workshop of the FP6 IST coordination action TYPES. Invited speakers Andrzej Filinski, Kbenhavns Universitet John Power, University of Edinburgh Important dates * Submission of papers: 10 April 2006 * Notification of authors: 8 May 2006 * Camera-ready version: 5 June 2006 Topics Submissions are welcome on, but by no means restricted to, topics from the following partially computed coinductive list: * structured effectful computation * structured recursion * structured tree and graph operations * structured syntax with variable binding * structures for datatype-genericity * structures for search * structured representations of functions * structured manipulation of mathematical structure * structured thunk in functional programming Authors concerned about the suitability of a topic are very welcome to contact Conor McBride, ctm(at)cs.nott.ac.uk. Submission and publication Papers in pdf not exceeding 15 pages and adhering to the eWiC style must be submitted by 10 April 2006 via an online submission webpage. Papers must report previously unpublished work and not be submitted concurrently to another conference with refereed proceedings. Accepted papers must be presented at the workshop by one of the authors. The proceedings of MSFP 2006 will be published in the Electronic Workshops in Computing (eWiC) series of the British Computer Society, http://ewic.bcs.org/. After the workshop, the authors of the best papers will be invited to submit revised and expanded versions to a special issue of the Journal of Functional Programming from Cambridge University Press. Programme committee Yves Bertot, INRIA Sophia Antipolis Marcelo Fiore, University of Cambridge Masahito Hasegawa, Kyoto University Graham Hutton, University of Nottingham Paul Levy, University of Birmingham Andres Lh, Universitt Bonn Christoph Lth, Universitt Bremen Conor McBride, University of Nottingham (co-chair) Marino Miculan, Universit degli Studi di Udine Randy Pollack, University of Edinburgh Amr Sabry, Indiana University Tarmo Uustalu, Institute of Cybernetics (co-chair) Main conferences MSFP 2006 is a satellite workshop of the 8th International Conference on Mathematics on Program Construction, MPC 2006, to take place 3-5 July. Co-located with MPC 2006, the 11th International Conference on Algebraic Methodology and Software Technology, AMAST 2006, will follow 5-8 July. Venue Kuressaare (pop. 16000) is the main town on Saaremaa, the second-largest island of the Baltic Sea. Kuressaare is a charming seaside resort on the shores of the Gulf of Riga highly popular with Estonians as well as visitors to Estonia. The scientific sessions of MPC/AMAST 2006 will take place at Saaremaa Spa Hotel Meri, one among the several new spa hotels in the town. The social events will involve a number of sites, including the 14th-century episcopal castle. Accommodation will be at Saaremaa Spa Hotels Meri and Rtli. To get to Kuressaare and away, one must pass through Tallinn (pop. 402000), Estonia's capital city. Tallinn is famous for its picturesque medieval Old Town, inscribed on UNESCO's World Heritage List. TYPES support MSFP 2006 is an official workshop of the EU FP6 IST coordination action TYPES. Participants from TYPES sites/subsites may use project funds to cover their travel and participation. Local organizers MPC/AMAST 2006 is organized by Institute of Cybernetics, a
Re: [Haskell] Haskell as a markup language
On Wed, 01 Mar 2006 17:46:47 +0900, [EMAIL PROTECTED] wrote: We demonstrate that Haskell as it is, with no TH or other pre-processors, can rather concisely represent semi-structured documents and the rules of their processing. In short, Haskell can implement SXML (ssax.sourceforge.net), right in its syntax and with the *open* and extensible set of `tags'. The benefit of Haskell is of course in static type guarantees, such as prohibiting an H1 element to appear in the character content of other elements. It also seems that the specification of various pre-post-order and context-sensitive traversals is more concise in Haskell compared to Scheme. Again, we are talking about the existing Haskell, i.e., Haskell98 plus common extensions. No Template Haskell or even overlapping instances are required. It's Great! But ... replacing my HTML Generator from SXML, I face s problems. We should note that |title| -- which can be either an element or an attribute -- is indeed rendered differently depending on the context. Just to emphasize the extensibility of the framework, we show how easy it is to add new elements. For example, the `tags' |longdash|, |a|, |div| and |title| are not defined in the base file HSXML.hs. We add these tags in sample1c.hs, as follows: Let us start with an abbreviation for the long dash. It may appear in the character content of an element or an attribute data LongDash = LongDash deriving Show longdash :: Check_ia LongDash ct = HW ct LongDash longdash = HW LongDash -- and how to render it in HTML instance RenderInline (HW ct LongDash) where render_inline f _ = emit_lit mdash; return f Actually, the latter instance describes rendering of longdash in any |MonadRender m| -- any monad that defines morphisms |emit|, |emit_elem| and |emit_attr|. Anchor is an inline element with an inline content data Anchor a b = Anchor a b deriving Show a attrs body = build (as_inline . HW . Anchor (as_block attrs) . rev'apppend HNil) nil_inline body instance (Render a, RenderInline b) =RenderInline (HW ct (Anchor a b)) where render_inline f (HW (Anchor attrs body)) = emit_elem a [] (Just (render attrs)) (render_ib body) return False Title can be either - a block-level element whose content is CT_inline - an attribute (whose content is, therefore, CT_attr) newtype Title a = Title a deriving Show title x = build ((`as_ctx` co) . HW . Title . rev'apppend HNil) nil_ab x where nil_ab = HW HNil `as_ctx` ci (ci,co) = title_ctx class Check_ia (Title ()) i = TitleCtx i o | i - o, o - i where title_ctx :: (HW i a, HW o a) ; title_ctx = undefined instance TitleCtx CT_attr CT_battr instance TitleCtx CT_inline CT_block It can be rendered context-sensitively: instance RenderInline a = Render (HW CT_battr (Title a)) where render (HW (Title x)) = emit_attr title ((render_inline False x) return ()) instance RenderInline a = Render (HW CT_block (Title a)) where render (HW (Title x)) = emit_elem title [Hint_nl] Nothing (render_ib x) Okay, I know how to add element, attribute and Character Entity References ... but how to write placeholder - pseudo element and pseudo attribute in HSXML? SXML can add useful function for macro, like this; (define (M:link keyword url) `(a (@ (href ,url)) ,keyword)) (define (M:link_amazon keyword asin) (M:link keyword `(http://www.amazon.co.jp/exec/obidos/ASIN/; ,asin /someone_id/))) (define (M:book keyword urn) `((cite ,(M:link keyword `(urn:isbn: ,urn))) ( ,(M:link_amazon Amazon urn) ) )) and M:link can use SXML code in its parameter any place; ,(M:link `(SXML (em can write) this.) http://foo.bar/;) But if use HSXML, I must write rest of List in last parameter, link url keyword = a (attr [href url]) keyword linkToAmazon asin keyword = link (URL $ concat [http://www.amazon.co.jp/exec/obidos/ASIN/;, asin, /someone_id/]) keyword and can't write part of code. So I must wirte code like this form, book urn first rest keyword = p first [[link (URL $ concat [urn:isbn:, urn]) keyword]] ( [[linkToAmazon urn Amazon]] ) rest I think this is less convenient than SXML. -- shelarcy shelarcy capella.freemail.ne.jp http://page.freett.com/shelarcy/ ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Ranges and the Enum class
Wolfgang Jeltsch [EMAIL PROTECTED] writes: Also, toEnum and fromEnum would make more sense mapping from and to Integer. Why do we need toEnum and fromEnum at all? As far as I know, they are merely there to help people implement things like enumFrom. They are often useful for writing serialisation routines, and they see occasional use for other kinds of safe type coercion as well (toEnum . fromEnum) Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
RE: Strict tuples
On 21 March 2006 03:10, John Meacham wrote: On Mon, Mar 20, 2006 at 09:39:41AM -0500, Manuel M T Chakravarty wrote: Apart from the syntactic issues, does anybody else support the idea of strict tuples as proposed? I just want to know whether I am alone on this before putting it on the wiki. I have a few issues though, not entirely easy to articulate. I worry about all the (! .. !) types that will appear in interfaces, making things like (map fst) not work. After some thought, I find myself with a similar view to John. Strict tuples are starting to feel like real language bloat, one tiny addition too much. Remember, every addition we make to the core syntax is multiplied by all the parsers for Haskell and tools that have to grok Haskell, and make the bar ever-so-slightly higher to producing such tools. There's a reason that syntax ends in tax :-) By all means have strict tuples in a library somewhere. They don't need to have special syntax. Cheers, Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Strict tuples
On 3/21/06, Simon Marlow [EMAIL PROTECTED] wrote: By all means have strict tuples in a library somewhere.They don't needto have special syntax.I have a module Data.Pair which provides pairs with different strictness properties. Perhaps it can be used as a startingpoint. Cheers,/Josef - -- | -- Module : Data.Pair -- Copyright : (c) Josef Svenningsson 2005 -- License : BSD-style -- -- Maintainer : [EMAIL PROTECTED] -- Stability : experimental -- Portability : portable -- -- Several pair data types with different strictness properties -- -- module Data.Pair ( Pair(..), StrictLeft(..), StrictRight(..), StrictPair(..) ) where -- |A class for pairs. We need this to have a consistent interface for -- several different pair types with different strictness properties. -- Minimal complete instances are either @first@, @second@ and @pair@ -- or @casePair@ and @[EMAIL PROTECTED] class Pair p where first:: p a b - a first p = casePair (\a _ - a) second :: p a b - b second p = casePair (\_ b - b) casePair :: (a - b - c) - p a b - c casePair c p = c (first p) (second p) pair :: a - b - p a b propPair p = p == pair (first p) (second p) data StrictLeft a b = StrictLeft !a b data StrictRight a b = StrictRight a !b data StrictPair a b = StrictPair !a !b instance Pair (,) where first (f,_) = f second (_,s) = s pair f s = (f,s) instance Pair StrictLeft where first (StrictLeft f _) = f second (StrictLeft _ s) = s pair f s = StrictLeft f s instance Pair StrictRight where first (StrictRight f _) = f second (StrictRight _ s) = s pair f s = StrictRight f s instance Pair StrictPair where first (StrictPair f _) = f second (StrictPair _ s) = s pair f s = StrictPair f s ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Strict tuples
John Meacham: On Mon, Mar 20, 2006 at 09:39:41AM -0500, Manuel M T Chakravarty wrote: Apart from the syntactic issues, does anybody else support the idea of strict tuples as proposed? I just want to know whether I am alone on this before putting it on the wiki. I have a few issues though, not entirely easy to articulate. I worry about all the (! .. !) types that will appear in interfaces, making things like (map fst) not work. It has been my experience that a lot of things that should be strict that are obvious to the user, are often obvious to the compiler as well. having the user place redundant strictness annotations in can ofsucate where the actual performance fixes are. As in, are lazy tuples actually a source of problems or are we just guessing? ghc's strictness analyzer is pretty darn good, If something is subtle enough for the compiler not to catch it, then the programmer probably won't right off the bat either. it usually takes profiling to determine where the human-fixable problems are. I agree that strict tuples can be abused, but that's true for most language features. strictness does not belong in the type system in general. strictness annotations are attached to the data components and not type components in data declarations because they only affect the desugaring of the constructor, but not the run-time representation or the types in general. attaching strictness info to types is just the wrong thing to do in general I think. I am *not* proposing any addition or change to the type system. In H98, I can define data Pair a b = Pair a b data StrictPair a b = StrictPair !a !b For some reason, we have Pair with special syntax pre-defined, but we haven't got StrictPair pre-defined. All I am proposing is to also pre-define StrictPair. however, strict tuples I think would have use in function returns, no need to declare them as a separate type, just have (! a,b !) desugar exactly to a `seq` b `seq` (a,b) this avoids any type issues and the only time the strictness of a constructor comes into play is in the constructor desugaring anyway, it makes sense that strict tuples would be a simple desugaring to normal tuples as well. The disadvantage of this scheme is that the consumer of a strict tuple, then, has no knowledge of the fact that the components are already evaluated - ie, this wastes a good opportunity for optimisations. Manuel ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Strict tuples
On Tue, Mar 21, 2006 at 02:27:37PM -0500, Manuel M T Chakravarty wrote: strictness does not belong in the type system in general. strictness annotations are attached to the data components and not type components in data declarations because they only affect the desugaring of the constructor, but not the run-time representation or the types in general. attaching strictness info to types is just the wrong thing to do in general I think. I am *not* proposing any addition or change to the type system. In H98, I can define data Pair a b = Pair a b data StrictPair a b = StrictPair !a !b For some reason, we have Pair with special syntax pre-defined, but we haven't got StrictPair pre-defined. All I am proposing is to also pre-define StrictPair. yes, but 'StrictPair a b' being a separate type from '(,) a b' is the problem I am refering to. personally, I just really don't see much use for them and feel they will give a false sense of efficiency while only creating headaches. Imagine two uses. f :: (! a,b!) - Int f (!a, b!) = 3 well, this can better be expressed as f :: (a,b) - Int f (!a, !b) = 3 and now you can still do things like 'curry f' now, imagine it in return position f :: a - (! x,y!) f a = (! x, y !) this can better be expressed as f :: a - (x,y) f a = x `seq` y `seq` (x,y)-- ^ some syntatic sugar for this could be nice If you care enough about some data you are passing around to intimatly know whether it might or might not have bottoms in it, then chances are it is something you want a custom data type for anyway. strict tuples would not really express intent any more and without some sort of subtyping mechanism the hassle of dealing with them would greatly outweigh the questionable benefit. not that people shouldn't create their own 'data StrictPair' if they want. but I would never want to see such a type in any public APIs. It would just not be very friendly. however, strict tuples I think would have use in function returns, no need to declare them as a separate type, just have (! a,b !) desugar exactly to a `seq` b `seq` (a,b) this avoids any type issues and the only time the strictness of a constructor comes into play is in the constructor desugaring anyway, it makes sense that strict tuples would be a simple desugaring to normal tuples as well. The disadvantage of this scheme is that the consumer of a strict tuple, then, has no knowledge of the fact that the components are already evaluated - ie, this wastes a good opportunity for optimisations. optimizations for who? knowing something is already evaluated without any other knowledge about it affords no optimizations in the ghc model (but actually does in the jhc one), knowing things will definitily be evaluated certainly does. which strict tuples don't really help with any more than the 'seq' translation would. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: the MPTC Dilemma (please solve)
you're right about interactions in general. but do you think constructor classes specifically would pose any interaction problems with FDs? You have to be more careful with unification in a higher-kinded setting. I am not sure how to do that with CHRs. to quote from the ATS paper: just like Jones, we only need first-order unification despite the presence of higher-kinded variables, as we require all applications of associated type synonyms to be saturated. variant A: I never understood why parameters of a class declaration are limited to variables. the instance parameters just have to match the class parameters, so let's assume we didn't have that variables-only restriction. class Graph (g e v) where src :: e - g e v - v tgt :: e - g e v - v we associate edge and node types with a graph type by making them parameters, and extract them by matching. The dependency seems to be lost here. what dependency? the associated types have become parameters to the graph type, so the dependency of association is represented by structural inclusion (type constructors are really constructors, so even phantom types would still be visible in the type construct). any instances of this class would have to be for types matching the form (g e v), fixing the type parameters. variant B: I've often wanted type destructors as well as constructors. would there be any problem with that? type Edge (g e v) = e type Vertex (g e v) = v class Graph g where src :: Edge g - g - Vertex g tgt :: Edge g - g - Vertex g Also no dependency and you need higher-order matching, which in general is undecidable. the dependency is still represented by the type parameters, as in the previous case. and is this any more higher-order than what we have with constructor classes anyway? here's an example implementation of the two destructors, using type classes with constructor instances: {-# OPTIONS_GHC -fglasgow-exts #-} import Data.Typeable data Graph e v = Graph e v class Edge g e | g - e where edge :: g - String instance Typeable e = Edge (g e v) e where edge g = show (typeOf (undefined::e)) class Vertex g v | g - v where vertex :: g - String instance Typeable v = Vertex (g e v) v where vertex g = show (typeOf (undefined::v)) [the Typeable is only there so that we can see at the value level that the type-level selection works] *Main edge (Graph (1,1) 1) (Integer,Integer) *Main vertex (Graph (1,1) 1) Integer variant C: the point the paper makes is not so much about the number of class parameters, but that the associations for concepts should not need to be repeated for every combined concept. and, indeed, they need not be class Edge g e | g - e instance Edge (g e v) e class Vertex g v | g - v instance Vertex (g e v) v class (Edge g e,Vertex g v) = Graph g where src :: e - g - v tgt :: e - g - v (this assumes scoped type variables; also, current GHC, contrary to its documentation, does not permit entirely FD-determined variables in superclass contexts) You still need to get at the parameter somehow from a graph (for which you need an associated type). oh, please! are you even reading what I write? as should be clear from running the parts of the code that GHC does accept (see above), FDs are quite capable of associating an edge type parameter with its graph. all three seem to offer possible solutions to the problem posed in that paper, don't they? Not really. ... II. The other one is that if you use FDs to define type-indexed types, you cannot make these abstract (ie, the representations leak into user code). For details, please see the Lack of abstraction. subsubsection in Section 5 of http://www.cse.unsw.edu.au/~chak/papers/#assoc do they have to? if variant C above would not run into limitations of current implementations, it would seem to extend to cover ATS: class C a where type CT a instance C t0 where type CT t0 = t1 would translate to something like: class CT a t | a - t instance CT t0 t1 class CT a t = CT a instance CT t0 t1 = C t0 as Martin pointed out when I first suggested this on haskell-cafe, this might lead to parallel recursions for classes C and their type associations CT, so perhaps one might only want to use this to hide the extra parameter from user code (similar to calling auxiliary functions with an initial value for an accumulator). That doesn't address that problem at all. come again? CT expresses the type
important news: refocusing discussion
Greetings, While discussion on this mailing list has been coming fast furious, actual tangible progress, even as measured on the wiki, has not been as fast. To remedy this, we propose to focus immediately and intently on a few of the most critical topics, and to focus all of our energies on them until they are done. We'd like to go so far as to ask folks to drop discussion on other items until these are solved. The goal of this approach is that we will spend the most time on the critical (and hard) stuff, instead of leaving it for last. We know that we can spend a _lot_ of time and energy discussing relatively small things, and so we want to make sure that these relatively small things don't take up all of our time. We will tackle them later. The topics that John and I feel are critical, and rather unsolved, are: * The class system (MPTC Dilemma, etc) * Concurrency * (One more, perhaps standard libraries) The logic here is that Haskell' will be accepted by the community if we solved these problems, and if we go with some of the most robust and uncontroversial extensions already out there. We will probably partition the committee into subcommittees to focus on each topic. Our goal will be to bring these topics to beta quality by mid April. That is, something that we could be happy with, but that perhaps needs some polishing. After that, we may try to pick the next most critical topics with the goal of having everything at beta quality by the face-to-face we're hoping to have at PLDI in June. With an eye toward considering related proposals together, we've added a topic field to the wiki, and a new query to the front page which groups the proposals by topic: http://hackage.haskell.org/trac/haskell-prime/query?status=newstatus=assignedstatus=reopenedgroup=topiccomponent=Proposalorder=priority I'd like to ask folks to please bring currently open threads to a close and to document the consensus in tickets. Anyone can edit tickets, so please don't be shy. your chairs, Isaac Jones John Launchbury -- isaac jones [EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Ranges and the Enum class
Am Dienstag, 21. März 2006 02:47 schrieb Aaron Denney: [...] No, I use them. In my opinion, it makes much more sense to write succ n than n + 1. Agreed, for non-arithmetical types. I think, it's perfectly sensible for arithmetical types like Integer. If you mean “the next integer” then succ n is the most logical thing to write. If you write n + 1 instead, you invoke a more complex operation (addition) with a special constant as one of its parameters, and this obfuscates what you actually mean, in my opinion. Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Ranges and the Enum class
Am Dienstag, 21. März 2006 10:08 schrieb Malcolm Wallace: Wolfgang Jeltsch [EMAIL PROTECTED] writes: [...] Why do we need toEnum and fromEnum at all? As far as I know, they are merely there to help people implement things like enumFrom. They are often useful for writing serialisation routines, and they see occasional use for other kinds of safe type coercion as well (toEnum . fromEnum) Regards, Malcolm Maybe they should be in a separate class. Enum should be about enumerating, not “indexing”. Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Strict tuples
Am Dienstag, 21. März 2006 11:28 schrieb Bulat Ziganshin: [...] as i said, shebang patterns allow only to specify that IMPLEMENTATION of some function is strict. this helps only when this function are called directly. they can't help when function is passed as parameter or enclosed in data structure or a part of class. the same about datatypes - i can't declare what some algorithm works only with strict lists. i try to find extensions what will allow to specify strictness in every case where now we forced to use lazy computations the concrete syntax what i propose may be wrong Well, it's probably nice sometimes to have types which guarantee the strictness of certain components. For example, it might be good to have a list type where the strictness of the elements is guaranteed. But I'm sure that it's wrong to try to achieve this by annotating type arguments like in [!a]. I think, this approach is wrong, not just the syntax. Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Time Library
On 3/20/06, Ashley Yakeley [EMAIL PROTECTED] wrote: Never as far as I can imagine. The 'a' parameter will be taken by a phantom type. http://haskell.org/haskellwiki/Phantom_type Now I don't recall, but is it allowed to do: data HasResolution a = Fixed a = ...? -- Taral [EMAIL PROTECTED] You can't prove anything. -- Gödel's Incompetence Theorem ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: important news: refocusing discussion
On 3/21/06, isaac jones [EMAIL PROTECTED] wrote: I'd like to ask folks to please bring currently open threads to a close and to document the consensus in tickets. Anyone can edit tickets, so please don't be shy. Claus, can you document some of your FD work in the FunctionalDependencies ticket? I think that the new confluence results lends a lot towards the adoption of FDs in Haskell'. -- Taral [EMAIL PROTECTED] You can't prove anything. -- Gödel's Incompetence Theorem ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Strict tuples
On 3/18/06, Manuel M T Chakravarty [EMAIL PROTECTED] wrote: Of course, the caller could invoke addmul using a bang patterns, as in let ( !s, !p ) = addmul x y in ... but that's quite different to statically knowing (from the type) that the two results of addmul will already be evaluated. The latter leaves room for more optimisations. I looked back at this, and I'm not sure that this statement (which appears to be the core reason for considering this) is true at all. I don't see that more optimization follows from the availability of information regarding the strictness of a function result's subcomponents. -- Taral [EMAIL PROTECTED] You can't prove anything. -- Gödel's Incompetence Theorem ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Time Library
Taral wrote: Now I don't recall, but is it allowed to do: data HasResolution a = Fixed a = ...? Not usefully. data T a = MkT a data C a = T a = MkT a It's allowed, but it doesn't do what you probably want. All it does is change the type of the constructor MkT. If the parameter a to Fixed is free, we don't particularly want to hide away the HasResolution constraint on it somehow. Of course, once it's specialised as a particular type (e.g. Fixed E12), then it's not needed anymore. -- Ashley Yakeley, Seattle WA WWED? http://www.cs.utexas.edu/users/EWD/ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: important news: refocusing discussion
On Tue, 2006-03-21 at 15:27 -0800, Ashley Yakeley wrote: isaac jones wrote: The topics that John and I feel are critical, and rather unsolved, are: * The class system (MPTC Dilemma, etc) * Concurrency * (One more, perhaps standard libraries) Could you summarise the current state of these? AFAIK, the class system is summarized on this page: http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/MultiParamTypeClassesDilemma Although there are some proposals here that are not really covered by that topic, they should probably be considered together: http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/query?status=newstatus=assignedstatus=reopenedgroup=topiccomponent=Proposalorder=priority Concurrency is summarized here: http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/Concurrency and libraries have not really been discussed much at all. peace, isaac -- isaac jones [EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Collections interface
I have created a ticket to make a standard collection interface. It is here: http://hackage.haskell.org/trac/haskell-prime/ticket/97 Obviously, it will be tough to figure out what the library can look like without knowing what MPTC's will look like. Jim ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Restricted Data Types Now
On 2/8/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: It seems we can emulate the restricted data types in existing Haskell. I have proposed this for Haskell' libraries. See http://hackage.haskell.org/trac/haskell-prime/ticket/98 Jim ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
MonadPlus Reform
Does this come under the standard libraries topic? I would like to see the MonadPlus class disambiguated: class Monad m = MonadZero m where mzero :: m a class MonadZero m = MonadPlus m where mplus :: m a - m a - m a class MonadZero m = MonadOr m where morelse :: m a - m a - m a http://haskell.org/haskellwiki/MonadPlus_reform_proposal -- Ashley Yakeley, Seattle WA WWED? http://www.cs.utexas.edu/users/EWD/ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Time Library
On 3/21/06, Ashley Yakeley [EMAIL PROTECTED] wrote: Not usefully. data T a = MkT a data C a = T a = MkT a It's allowed, but it doesn't do what you probably want. All it does is change the type of the constructor MkT. I think it also allows the inference of HasResolution a from Fixed a, thus removing the HasResolution condition on your instances. -- Taral [EMAIL PROTECTED] You can't prove anything. -- Gödel's Incompetence Theorem ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
[Haskell-cafe] Re: strange ghc program behaviour
I remember that we had problems with HaXml producing empty or truncated files, too. I think with ghc-6.4.1 and HaXml-1.13 this problem was solved. (The deprecated stuff is definitely not the cause). The problem must have been related to the output handle being either stdout or a file (and maybe a missing flush). HTH Christian [EMAIL PROTECTED] wrote: Hi, I'm a Haskell newbie using HaXml for the conversion of xml files into html files. I'm using GHC 6.4 to compile the program. When I run the program, it will not convert the whole file: the document tree is incomplete and will stop when the limit of e.g. 8k has been reached. E.g. An xml file of 12.3k will result in a file of 8k and will stop at 8k An xml file of 15.7k will result in a file of 16k An xml file of 36k will result in a file of 24k In an output to the screen (and not to a file), the whole document tree is being generated. Am I missing something obvious here (memory issues)? On compilation, ghc issues warnings about the class FiniteMap and Module IOExts being deprecated. Is this the cause? Any ideas? Cheers, K. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] strange ghc program behaviour
Hi, I'm a Haskell newbie using HaXml for the conversion of xml files into html files. I'm using GHC 6.4 to compile the program. When I run the program, it will not convert the whole file: the document tree is incomplete and will stop when the limit of e.g. 8k has been reached. E.g. An xml file of 12.3k will result in a file of 8k and will stop at 8k An xml file of 15.7k will result in a file of 16k An xml file of 36k will result in a file of 24k In an output to the screen (and not to a file), the whole document tree is being generated. Am I missing something obvious here (memory issues)? On compilation, ghc issues warnings about the class FiniteMap and Module IOExts being deprecated. Is this the cause? Any ideas? Cheers, K. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] strange ghc program behaviour
[EMAIL PROTECTED] wrote: E.g. An xml file of 12.3k will result in a file of 8k and will stop at 8k An xml file of 15.7k will result in a file of 16k An xml file of 36k will result in a file of 24k From ghc-6.4, the runtime system no longer flushes open files; it truncates them instead. You should close (or flush) the file explicitly with 'hClose' or 'hFlush' before the program terminates. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Porting GHC to OSX86?
Hi there, Has anyone made any attempt to port GHC to Mac OS X on x86? Wolfgang Thaller’s binary package runs over Rosetta but slow (not surprising). It can not be used to compile a native version either (I got some errors related to machine registers). I tried to do a bootstrap but can't find the .HC files mentioned in the manual. They don't seem to be on the download page of GHC. Any ideas? Thanks. Deling___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Associated types and data constructors (was: the MPTC Dilemma (please solve))
David Menendez: This is something I've been wondering about for a while. Can you do that sort of thing with associated types? As another example, consider this type class for composible continuation monads: class Monad m = MonadCC p sk m | m - p sk where newPrompt :: m (p a) pushPrompt :: p a - m a - m a withSubCont :: p b - (sk a b - m b) - m a pushSubCont :: sk a b - m a - m b You can use instances of this class to create backtracking monads, along these lines: data Tree m a = HZero | HOne a | HChoice a (m (Tree m a)) newtype SR p m a = SR (forall ans. ReaderT (p (Tree m ans)) m a) instance MonadCC p sk m = MonadPlus (SR p m) With associated types, the MonadCC class becomes: class Monad m = MonadCC m where type Prompt m a type SubCont m a b newPrompt :: m (Prompt m a) pushPrompt :: Prompt m a - m a - m a withSubCont :: Prompt m b - (SubCont m a b - m b) - m a pushSubCont :: SubCont m a b - m a - m b Since |Prompt m| is determined by |m|, can we eliminate the prompt parameter from SR? newtype SR' m a = SR' (forall ans. ReaderT (Prompt m (Tree m ans)) m a) instance MonadCC m = MonadPlus (SR' m) Yes, that's right. That would presumably lead to SR' having the type SR' :: (MonadCC m) = ReaderT (Prompt m (Tree m ans)) m a - SR' m a That doesn't seem like it should be a problem, since it's impossible to create a value of type |ReaderT (Prompt m (Tree m ans)) m a| unless m is an instance of MonadCC, but it also puts a context on a newtype data constructor, which isn't currently allowed. If you go by the rules in the associated types paper, you need to put that context there. However, whether that context is really needed is the topic of an ongoing discussion. Without that sort of context, you can write programs where type errors are raised a bit later than if you have the context, but type safety doesn't seem to be affected by those contexts. The fact that newtype cannot have a context is an argument in favour of not requiring the context. As your example shows, associated types (in comparison to FDs) not only eliminate type arguments from classes, but also from data type declarations. IMHO this improves the readability of programs. Manuel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Returning a list element?
Robert Dockins robdockins at fastmail.fm writes: FYI, putStrLn will automatically insert a newline for you, and the final 'return ()' is unnecessary. My favorite idiom for this kind of thing is: mainMenu = putStr $ unlines [ line 1 , line 2 , line 3 ] Or how about mainMenu = sequence_ $ map putStrLn [line1, line2, line3] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Returning a list element?
dominic.steinitz: Robert Dockins robdockins at fastmail.fm writes: FYI, putStrLn will automatically insert a newline for you, and the final 'return ()' is unnecessary. My favorite idiom for this kind of thing is: mainMenu = putStr $ unlines [ line 1 , line 2 , line 3 ] Or how about mainMenu = sequence_ $ map putStrLn [line1, line2, line3] I argue if you want to sequence_ a map you should write mapM_: mapM_ putStrLn [line1, line2, line3] mapM is under-appreciated? More under-appreciated are line gaps: main = putStr line1\n\ \line2\n\ \line3\n -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe