[GHC] #699: GHCi doesn't implement foreign import on amd64 when interpreting.
#699: GHCi doesn't implement foreign import on amd64 when interpreting. ---+ Reporter: guest |Owner: Type: bug | Status: new Priority: normal |Milestone: Component: GHCi| Version: 6.4.1 Severity: normal | Keywords: Os: Linux | Difficulty: Unknown Architecture: x86_64 (amd64) | ---+ When GHCi is used to load source which has a foreign import I get a message: ghc-6.4.1: foreign import is not implemented for GHCi on this platform. If the source is compiled with ghc it compiles and runs fine. If the compiled source is loaded into GHCi it works fine. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/699 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
[Haskell] CFP: Workshop on Generic Programming 2006
CALL FOR PAPERS
Workshop on Generic Programming 2006
Portland, Oregon, 16th September 2006
The Workshop on Generic Programming is sponsored by ACM SIGPLAN
and forms part of ICFP 2006. Previous Workshops on Generic
Programming have been held in Marstrand (affiliated with MPC),
Ponte de Lima (affiliated with MPC), Nottingham (informal
workshop), Dagstuhl (IFIP WG2.1 Working Conference), Oxford
(informal workshop), and Utrecht (informal workshop).
http://www.informatik.uni-bonn.de/~ralf/wgp2006.{html,pdf,ps,txt}
Scope
-
Generic programming is about making programs more adaptable by making
them more general. Generic programs often embody non-traditional kinds
of polymorphism; ordinary programs are obtained from them by suitably
instantiating their parameters. In contrast with normal programs, the
parameters of a generic program are often quite rich in structure; for
example they may be other programs, types or type constructors, class
hierarchies, or even programming paradigms.
Generic programming techniques have always been of interest, both to
practitioners and to theoreticians, but only recently have generic
programming techniques become a specific focus of research in the
functional and object-oriented programming language communities. This
workshop will bring together leading researchers in generic
programming from around the world, and feature papers capturing the
state of the art in this important emerging area.
We welcome contributions on all aspects, theoretical as well as
practical, of
o adaptive object-oriented programming,
o aspect-oriented programming,
o component-based programming,
o generic programming,
o meta-programming,
o polytypic programming,
o and so on.
Submission details
--
Deadline for submission:3rd June 2006
Notification of acceptance:24th June 2006
Final submission due: 8th July 2006
Workshop: 16th September 2006
Authors should submit papers, in postscript or PDF format, formatted
for A4 paper, to Ralf Hinze ([EMAIL PROTECTED]) by 3rd June
2006. The length should be restricted to 12 pages in standard
(two-column, 9pt) ACM. Accepted papers are published by the ACM and
will additionally appear in the ACM digital library.
Programme committee
---
Roland Backhouse University of Nottingham
Pascal Costanza Vrije Universiteit Brussel
Peter Dybjer Chalmers University of Technology
Jeremy Gibbons University of Oxford
Johan JeuringUniversiteit Utrecht
Ralf Hinze (chair) Universität Bonn
Karl Lieberherr Northeastern University
David Musser Rensselaer Polytechnic Institute
Rinus Plasmeijer Universiteit Nijmegen
Sibylle Schupp Chalmers University of Technology
Jeremy Siek Rice University
Don Syme Microsoft Research
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] lazy file reader
Hi, Im starting in haskell, and wish to develop a program to process hd images, searching for file specific patterns. I will have to deal with situations where I only want to read the end of the image. My problem is: if I use hGetContents to that, the beginning of the file will allways be readen, even if only the end is important. Is there any way to tell the compiller to be 'more lazy' so if appears content!!10 it skips a lot of data? Im not concearned with concurrency here. Átila ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Question for the haskell implementors: Arrays, unsafePerformIO, runST
On Feb 15, 2006, at 10:53 PM, John Meacham wrote: So, I finally decided that jhc needs real arrays, but am running into an issue and was wondering how other compilers solve it, or if there is a general accepted way to do so. ... now, the problem occurs in newAT__ newAT__ :: Int - AT a - Array__ a newAT__ n (AT a1) = a1 (prim_newAT__ n) ^ this gets floated out as a CAF. Yes, you need to have some construct in the language which can't be floated out. When you implement runST / unsafePerformIO you quickly learn that you can't rely on data dependency alone (though you'll get lucky a surprising proportion of the time if you try). In phc, due to our pH heritage we had a set of compiler primitives which were known to be unfloatable. We were otherwise shockingly generous about floating things around (most of the other limitations got switched off in Haskell mode and only kicked in when you were compiling pH, which let you stick imperative stuff in without monads). -Jan-Willem Maessen ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] lazy file reader
Hi, I will have to deal with situations where I only want to read the end of the image. Try: hOpen, hSeek, then probably hGetBuf http://haskell.org/ghc/docs/latest/html/libraries/base/System-IO.html#t%3ASeekMode Thanks Neil ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Question for the haskell implementors: Arrays, unsafePerformIO, runST
Data.Array.ST has runSTArray :: Ix i = (forall s . ST s (STArray s i e)) - Array i e I think if you can implement that, then all your problems will be solved. -- Ben ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Parallel list comprehensions
(warning. rambling) On Thu, Feb 16, 2006 at 09:06:24AM +, Ross Paterson wrote: On Sat, Feb 04, 2006 at 03:11:10PM +0100, John Hughes wrote: I noticed ticket #55--add parallel list comprehensions--which according to the ticket, will probably be adopted. I would argue against. As there are many voices against and only John M speaking for these, it seems reasonable at least to move them from probably yes to maybe. I don't think that field on the wiki is meant to be taken with more than a grain of salt. The real meat should be in the pros and cons section on the attached page. Part of the reason I really like parallel list comprehensions is that they give substantially more power to list comprehensions over do notation. I would be worried about dropping things because people exist who have not used the feature. For all they know, they might love it once they start using it. Very little of haskell is manditory so there really is no need for everyone to explore every corner of the language, but a lot of the syntax makes our lives easier, sometimes substantially so. My opinion may be coloured by the fact that I never use the things. However, I think it's a mistake to add rarely used features with a small payoff to the language. It just makes the language larger, harder to learn, and harder to read for all but the expert, without much corresponding benefit. I agree, but then I feel the same way about pattern guards. I've used them only recently, and that was modifying code (GHC) that already had lots of Maybe-returning functions designed for use with pattern guards. Oh golly. I can't live without pattern guards. they are the best darn thing since sliced bread. I highly recommend them. I would be anoyed at not having parallel list comprehensions, but would have to seriously refactor a ton of code if pattern guards disapeared. So much so that it would be less work to implement pattern guards for other compilers and submit the patches. I also always sort of liked the symmetry between pattern guards, list comprehensions, and do notation. list comprehensions are do-notation restricted to the list monad and pattern guards are do notation restricted to the identity monad... John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Parallel list comprehensions
oops, sorry for the double post. I accidentally sent a draft along with the final result. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: pattern synonyms
Dear all,
Conor wrote:
You forgot to define the term behaviour also. Pattern synonyms may be
used to construct as well as to match values.
Conor and I discussed this over lunch.
Specifically, we talked about whether the right hand side of a pattern
synonym would be any Haskell pattern (including _, ~, possibly !),
or restricted to the intersection between the patterns and terms, as
Conor propose that pattern synonyms also be used for construction.
By adopting some simple conventions, like replacing _ by undefined
when a synonym is used as a term for construction, it is clear that one
can be a bit more liberal than a strict intersection between the pattern
and current expression syntax.
Incidentally, this would be consistent with the way record patterns
and record construction currently works. E.g.
data Foo = MkFoo {l1 :: T1, l2 :: T2}
A pattern MkFoo {} expands to MkFoo _ _, a term MkFoo {} expands
to MkFoo undefined undefined.
Moreover, didn't someone (John Mecham?) propose that _ be a valid
term anyway, standing for undefined (with an explicit requirement
of keeping track of the source code position)?
Maybe ~ (and !) wouldn't cause much trouble either.
I like the idea, but it would be nice if the RHS of a pattern
synonym definition really coudl be any Haskell pattern, without any
additional restriction (except that it has to be acyclic).
All the best,
/Henrik
--
Henrik Nilsson
School of Computer Science and Information Technology
The University of Nottingham
[EMAIL PROTECTED]
This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
Re: ExistentialQuantifier
Ross Paterson wrote: I don't think the original name is inappropriate: the feature described is certainly existential quantification, albeit restricted to alternatives of data definitions. I think that existential quantification should mean, well, existential quantification, in the sense that term is used in logic. I don't like the idea of using it for the feature currently implemented with forall in front of the data constructor, given that these type variables are universally quantified in the data constructor's type. How about changing the name to existential product types or existential tuples? I would even suggest boxed types, but that's already taken. -- Ben ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: proposal for moving forward
Isaac Jones wrote: My intuition (and a proposal) is that our job will be to: 1. conservatively standardize some of the most robust extensions, 2. clean up the class hierarchies and some libraries, 3. solve the MPTC dilemma (see above), and 4. pick one other big idea such as records or bang patterns. Thoughts? Given the amount of excitement and interest in new extensions (and in doing more than a conservative standard), I see a fifth goal: come up with some way of helping users and implementers cope with the complexity of lots of different (and sometimes conflicting) extensions. Some possibilities I see here are: (a) some standard, documented way for groups to come together to bless a widely-used extension (and, consequently, a way for people to find out what the blessed extensions are) (b) a way for programs to test what extensions are provided by their implementation (so users know what specific things a program depends on - rather than just saying you need some specific implementation) (c) a way for programs to conditionally configure themselves based on what extensions are available - so it is easier to write portable programs and libraries that use extensions beyond Haskell' The long-run hope I would have is that this sort of infrastructure might make the next standardization round easier - it will be more immediately obvious which extensions exist and where they belong in the process. - Ravi ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Pragmas for FFI imports
Hello I would like to propose two pragmas to be included in Haskell' for use with FFI. One for specifying the include file defining the foreign import (INCLUDE in ghc) and an another for defining a library that the foreign import depends on, called FFI_LIB (not implemented at the moment). These changes would not break any existing code. - Einar Karttunen ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
[Haskell-cafe] Re: Associated Type Synonyms question
Stefan Wehr writes: Niklas Broberg [EMAIL PROTECTED] wrote:: On 2/10/06, Ross Paterson [EMAIL PROTECTED] wrote: On Fri, Feb 10, 2006 at 05:20:47PM +0100, Niklas Broberg wrote: - when looking at the definition of MonadWriter the Monoid constraint is not strictly necessary, and none of the other mtl monads have anything similar. Is it the assumption that this kind of constraint is never really necessary, and thus no support for it is needed for ATS? I think that's right -- it's only needed for the Monad instance for WriterT. But it is a convenience. In any instance of MonadWriter, the w will be a monoid, as there'll be a WriterT in the stack somewhere, so the Monoid constraint just saves people writing general functions with MonadWriter from having to add it. Sure it's a convenience, and thinking about it some more it would seem like that is always the case - it is never crucial to constrain a parameter. But then again, the same applies to the Monad m constraint, we could give the same argument there (all actual instances will be monads, hence...). So my other question still stands, why not allow constraints on associated types as well, as a convenience? Manuel (Chakravarty) and I agree that it should be possible to constrain associated type synonyms in the context of class definitions. Your example shows that this feature is actually needed. I will integrate it into phrac within the next few days. By possible you mean this extension won't break any of the existing ATS inference results? You have to be very careful otherwise you'll loose decidability. Something more controversial. Why ATS at all? Why not encode them via FDs? Example -- ATS class C a where type T a m :: a-T a instance C Int where type T Int = Int m _ = 1 -- FD encoding class T a b | a-b instance T Int Int class C a where m :: T a b = a-b instance C Int where m _ = 1 -- general recipe: -- encode type functions T a via type relations T a b -- replace T a via fresh b under the constraint C a b The FD program won't type check under ghc but this doesn't mean that it's not a legal FD program. It's wrong to derive certain conclusions about a language feature by observing the behavior of a particular implementation! Martin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] enforcing strictness on arbitrary subexpressions
hei, I want to force evaluation on an arbitrary expression. What I have found is only strict datatypes (the '!' thing), but not a strictness idiom for arbitrary subexpressions. (I want this for debugging mostly, so if there is a better way to unsafePerformIO something in one piece I would be happy with that, too.) ++ veryLongString = ... data StrictThingy = StrictThingy ! String main :: IO () main = do hPutStr stdout veryLongString -- lazy veryLongString `seq` hPutStr stdout veryLongString -- still lazy? (StrictThingy veryLongString) `seq` hPutStr stdout veryLongString -- strict (or at least i hope it is) ++ Problem with the last line is that it doesn't work for arbitrary types, and it's kind of ugly. What I would like to have is something like: ++ hPutStr stdout ! veryLongString ++ but I guess it's not that easy? Sorry for asking without consulting the list archives, but I promise I'll add it to the faq in the wiki once i understood. (-: I am using ghci and ghc, latest ubuntu package, but I am happy to switch to new versions. thanks, matthias signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] module for probability distributions
hei again, (-: I wrote a module for sampling arbitrary probability distribution, so far including normal (gaussian) and uniform. http://www.wiwi.hu-berlin.de/~fis/code/ For those who need something like this: feel free to take it, it's BSD. For those who feel like growing their karma: - There are a few questions in the code (marked with 'XXX'). - There are probably far better way to do this. I am eager to learn. - There is probably a better implementation out there already. Please point me to it. cheers, Matthias signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Decidable type systems? (WAS: Associated Type Synonyms question)
Martin Sulzmann wrote, By possible you mean this extension won't break any of the existing ATS inference results? You have to be very careful otherwise you'll loose decidability. Can someone explain to me why decidability is of any practical interest at all? What's the (practical) difference between a decision procedure which might never terminate and one which might take 1,000,000 years to terminate? Actually, why push it out to 1,000,000 years: in the context of a compiler for a practical programming language, a decision procedure which might take an hour to terminate might as well be undecidable ... surely all we really need is that the decision procedure _typically_ terminates quickly, and that where it doesn't we have the means of giving it hints which ensure that it will. There's a very nice paper by George Boolos on this[1]: he gives an example of an inference which is (and is intuitively) valid in second- order logic, and which can be first-orderized ... but the proof of the first-order equivalent is completely unfeasible. [1] Boolos, G., A Curious Inference, Journal of Philosophical Logic, 16, 1987. Also in Boolos, Logic, Logic and Logic, 1998. Useful citation here, http://www.nottingham.ac.uk/journals/analysis/preprints/KETLAND.pdf Cheers, Miles ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] enforcing strictness on arbitrary subexpressions
Matthias Fischmann wrote: I want to force evaluation on an arbitrary expression. [...] main :: IO () main = do hPutStr stdout veryLongString -- lazy veryLongString `seq` hPutStr stdout veryLongString -- still lazy? (StrictThingy veryLongString) `seq` hPutStr stdout veryLongString -- strict (or at least i hope it is) The last line is actually equivalent to the second. Strict data constructors are defined in term of seq, and seq only forces the evaluation of the outermost constructor. So after seq'ing a string, it is either empty or has at least one element, but that element and the whole tail are still unevaluated. You have to recurse into the string to evaluate everything: hPutStr stdout $ foldr seq veryLongString veryLongString There is no primitive to do this for arbitrary data types, but the DeepSeq type class comes close. You can find DeepSeq and some more hints on strict evaluation at http://users.aber.ac.uk/afc/stricthaskell.html. Udo. -- Today is the tomorrow you worried about yesterday. signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Decidable type systems? (WAS: Associated Type Synonyms question)
Can someone explain to me why decidability is of any practical interest at all? What's the (practical) difference between a decision procedure which might never terminate and one which might take 1,000,000 years to terminate? Actually, why push it out to 1,000,000 years: in the context of a compiler for a practical programming language, a decision procedure which might take an hour to terminate might as well be undecidable ... surely all we really need is that the decision procedure _typically_ terminates quickly, and that where it doesn't we have the means of giving it hints which ensure that it will. I'm tempted to agree with you. I don't care if the compiler terminates on all my programs, or if it sometimes quits and says: I don't know if this is correct. However, I do think that it is of very much importance that programmers and compiler implementors know which programs are legal and which are not. If a problem is decidable, it has the nice property that the problem (*not* the algorithm) can be used as a specification. Implementors are free to implement different algorithms, as long as they all solve the problem. If the problem is undecidable, how do you make sure that different compilers accept the same programs? If you don't want to find a subproblem that is decidable, you'll have to specify an algorithm, which is usually far more complicated, error-prone, and difficult to grasp for programmers. Cheers, Andres ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Badly designed Parsec combinators?
Tomasz Zielonka wrote: On Sun, Feb 12, 2006 at 06:22:46AM -0800, Juan Carlos Arevalo Baeza wrote: This brings me to wonder also if it'd be possible for the compilers to add a little bit more smarts to the do notation syntax, so that it'll add the return () at the end if it's missing. Maybe too much to ask of the Haskell crowd :). I wouldn't like that, as do-expressions without return at the end can be convenient. They can also make your intent clearer for other programmers and perhaps also the compiler, especially when you want to write tail-recursive monadic code (assuming a suitable monad and/or a sufficiently smart compiler). Right, I understand and share that thought. But that's not what I meant. I really didn't explain the way I should, and I didn't think it through. What I was proposing needs to be implemented not as an addition to the do-syntax sugar, but as something the compiler does to monads when matching their type. Take for instance this function: myParser :: Parser () myParser = do string Hello optional (string , world!) It makes no sense for myParser to generate any values, especially not the result from the optional statement, so it is set to return (). But that function as written will not compile (with my proposed modification to optional), and so we have to manually add the return () at the end. But... the thing is, if we have any do statement, or any monad whatsoever, which does not return (), and the program needs it to return () in order to be able to match its type, that transformation is always trivial. It just has to add return () to it. () is special that way, because there's only one possible value, and monads are also special already (do-notation, for instance). Another case where I encounter this is with the when function: myParser2 :: Bool - Parser () myParser2 all = do string Hello when all $ do string , world string ! Again that doesn't compile, because when requires a ()-returning monad as its second parameter, but the string parser returns String. Same thing with if-then-else, when used to switch IO actions and such: the IO actions must fully match in type, even if the returned value will be discarded, and again that can be trivially resolved by adding the return (). All I'm saying is that I wish the language and the compiler would take care of that for me. Hence what I said: maybe too much for the Haskell crowd to start playing games with the type system like this. It resembles a lot the automatic conversions that C++ does. I agree Haskell can't have those in any form, but still... return ()... Thanx! JCAB ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Decidable type systems? (WAS: Associated TypeSynonyms question)
Miles Sabin [EMAIL PROTECTED] wrote: Can someone explain to me why decidability is of any practical interest at all? procedure which might never terminate and one which might take 1,000,000 years to terminate? Actually, why push it out to 1,000,000 years: in the context of a compiler for a practical programming language, a decision procedure which might take an hour to terminate might as well be undecidable But are there any decidable type checking algorithms that have been seriously proposed or used which would take far too long to terminate for real code? If not, then decidability is the only thing that matters. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Decidable type systems? (WAS: Associated Type Synonyms question)
Andres Loeh wrote, If a problem is decidable, it has the nice property that the problem (*not* the algorithm) can be used as a specification. Implementors are free to implement different algorithms, as long as they all solve the problem. If the problem is undecidable, how do you make sure that different compilers accept the same programs? If you don't want to find a subproblem that is decidable, you'll have to specify an algorithm, which is usually far more complicated, error-prone, and difficult to grasp for programmers. Again, I'm not sure that decidability helps practically here: we're not interested in compiler A and compiler B accept the same programs, we're interested in compiler A and compiler B accept some well defined subset of possible programs in a reasonable amount of time and space. Cheers, Miles ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Code completion? (IDE)?
Marc, On 2/16/06, Marc Weber [EMAIL PROTECTED] wrote: vim7 has introduced omni-completion... So I'm interested wether there are any projects which support any kind of completion.? I have been working on some code completion support for EclipseFP. It is right now in a really infant stage, but it at least is something. Just take a look at the latest integration build that you are able to find at http://eclipsefp.sourceforge.net/download Cheers, Thiago Arrais ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Decidable type systems? (WAS: Associated TypeSynonyms question)
Robin Green wrote, But are there any decidable type checking algorithms that have been seriously proposed or used which would take far too long to terminate for real code? If not, then decidability is the only thing that matters. Surely what matters is that they don't take far too long to terminate! Cheers, Miles ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Code completion? (IDE)?
On 2/16/06, Thiago Arrais [EMAIL PROTECTED] wrote: Just take a look at the latest integration build that you are able to find at http://eclipsefp.sourceforge.net/download There is also a screenshot at http://eclipsefp.sourceforge.net/images/first-content-assist.png Cheers, Thiago Arrais ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Badly designed Parsec combinators?
Juan Carlos Arevalo Baeza wrote: Another case where I encounter this is with the when function: myParser2 :: Bool - Parser () myParser2 all = do string Hello when all $ do string , world string ! I made a function (did I miss one in the base package?) ignore :: Monad m = m a - m () ignore m = m return() and write ignore $ string ... if necessary. when b m is if b then m else return(). I don't think that the then- or else- branch of any if- expression schould be automatically casted to some matching type m () (and I don't know what implications this would have to typing in general). However when b m could be generalized by if b then ignore m else return (). (The same applies to unless) Cheers Christian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Cyclical Type Synonyms
I want to define a type for a function that returns its own type... type F a = a - (F a,a) But the compiler gives me an error: Cycle in type synonym declaration: Why is this a restriction? Of course I can create a user defined type, but then I need an extra mechanism to call the embedded function: data F a = F (a - (F a ,a)) call :: F a - a - (F a, a) call (F f) a = f a -Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Lazy read
Hi, I have a nice big data structure that I serialise to a file using show, and read back in using read. This data structure has deriving (Read, Show), which makes it all nice and easy to save and load this data structure, without worrying about parsing code etc. The problem is that this data structure can become quite big, and while show operates lazily, read does not. I understand the reason for this - that it internally calls reads and that on a parse error reads will not return a result - i.e. it has to get to the end to determine whether the parse was valid or not. However, in my particular case, I know the data structure is valid, and if it isn't then I'm quite happy with the parser throwing an error half way through - after having lazily returned half of the data. A short example, which shows up the exact same issue is: head ((read $ show [1..n]) :: [Int]) The time of this operation is dependant on n, because of the strictness of read. What is the best way to modify the code to have read operate lazily? Is there any method that doesn't require writing a custom parser? Is there any standard way for solving a problem like this? Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Badly designed Parsec combinators?
Juan Carlos Arevalo Baeza wrote: myParser :: Parser () myParser = do string Hello optional (string , world!) It makes no sense for myParser to generate any values, especially not the result from the optional statement, so it is set to return (). Don't you think this will interfere somehow with type inference? I wouldn't like a function that might decide to throw away its result if (erroneously) used in a context that wouldn't need it. I also think almost every function has a sensible result, and written with the right combinator, can return it without too much hassle. So I'd probably write: yourParser :: Parser String yourParser = liftM2 (++) (string Hello) (option (string , world!) I also find it very convenient to have a combinator that does a bind and return the unmodified result of the first computation. With that you get: (*) :: Monad m = m a - m b - m a m * n = do a - m ; n ; return a ourParser :: Parser String ourParser = string Hello * optional (string , world!) Therefore, implicit (return ()) is selsdom useful, has the potential to cause annoying silent failures and is generally not worth the hassle. Another case where I encounter this is with the when function: myParser2 :: Bool - Parser () myParser2 all = do string Hello when all $ do string , world string ! A better fix would be more flexible when: when :: Monad m = Bool - m a - m (Maybe a) when True m = Just `liftM` m when False _ = return Nothing ...which is quite similar to the proposed change to Parsec's 'optional'. I'd support both. It resembles a lot the automatic conversions that C++ does. I'm more reminded of Perl... Udo. -- Avoid strange women and temporary variables. signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cyclical Type Synonyms
This is because 'type' only allows you to define synonyms for existing
types, not create new types altogether (for that, use newtype). The
synonyms are expanded to their definitions early on in compilation. In
this case, that expansion process would not terminate (but the
compiler is clever enough to realise that).
While you can't have the type synonym you wanted, you can construct a
type which should have no extra runtime baggage by using newtype, and
use record syntax to define call automatically.
newtype F a = F { call :: a - (F a, a) }
As far as I know, all types in Haskell can be written as a finite tree
of type constructors. There are some tricks one can play with
typeclasses though. See Text.Printf in the Hierarchical libraries for
a good example of that.
- Cale
On 16/02/06, Tom Hawkins [EMAIL PROTECTED] wrote:
I want to define a type for a function that returns its own type...
type F a = a - (F a,a)
But the compiler gives me an error: Cycle in type synonym declaration:
Why is this a restriction?
Of course I can create a user defined type, but then I need an extra
mechanism to call the embedded function:
data F a = F (a - (F a ,a))
call :: F a - a - (F a, a)
call (F f) a = f a
-Tom
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] monad combinator
Udo Stenzel wrote: (*) :: Monad m = m a - m b - m a m * n = do a - m ; n ; return a Right, that one is really useful. I named it (), though, conforming to (=) versus (=). Christian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] library sort
Is there a sort function in the libraries that come with GHC (6.4)? My search at http://www.haskell.org/ghc/docs/latest/html/libraries/index.html has failed, but I can't believe there is none. -- regards, radu http://rgrig.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] library sort
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Radu Grigore Is there a sort function in the libraries that come with GHC (6.4)? My search at http://www.haskell.org/ghc/docs/latest/html/libraries/index.html has failed, but I can't believe there is none. Data.List.sort (and sortBy): http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-List.htm l#v%3Asort * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] library sort
Data.List contains sort :: Ord a = [a] - [a] and sortBy :: (a - a - Ordering) - [a] - [a] I believe they're currently implemented using merge sort, at least in GHC. /g On 2/16/06, Radu Grigore [EMAIL PROTECTED] wrote: Is there a sort function in the libraries that come with GHC (6.4)? My search at http://www.haskell.org/ghc/docs/latest/html/libraries/index.html has failed, but I can't believe there is none. -- regards, radu http://rgrig.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- We have lingered in the chambers of the sea By sea-girls wreathed with seaweed red and brown Till human voices wake us, and we drown. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] library sort
Hi Radu, Is there a sort function in the libraries that come with GHC (6.4)? import Data.List Or just hit Hoogle with sort http://haskell.org/hoogle/?q=sort Thanks Neil On 16/02/06, Radu Grigore [EMAIL PROTECTED] wrote: My search at http://www.haskell.org/ghc/docs/latest/html/libraries/index.html has failed, but I can't believe there is none. -- regards, radu http://rgrig.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] library sort
Yes, it's in Data.List, and called 'sort'. You can use the index (see top right) to look for it under 'S'. - Cale On 16/02/06, Radu Grigore [EMAIL PROTECTED] wrote: Is there a sort function in the libraries that come with GHC (6.4)? My search at http://www.haskell.org/ghc/docs/latest/html/libraries/index.html has failed, but I can't believe there is none. -- regards, radu http://rgrig.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] monad combinator
On Thu, Feb 16, 2006 at 04:36:06PM +0100, Christian Maeder wrote: Udo Stenzel wrote: (*) :: Monad m = m a - m b - m a m * n = do a - m ; n ; return a Right, that one is really useful. I named it (), though, conforming to (=) versus (=). But = first executes the second argument... Best regards Tomasz -- I am searching for programmers who are good at least in (Haskell || ML) (Linux || FreeBSD || math) for work in Warsaw, Poland ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lazy read
On 2/16/06, Neil Mitchell [EMAIL PROTECTED] wrote: What is the best way to modify the code to have read operate lazily? Is there any method that doesn't require writing a custom parser? Is there any standard way for solving a problem like this? Honestly, don't use read. It's icky. Check out ReadP or parsec, they are far superior in general. I think there was a suggestion of replacing Read with ReadP? -- Taral [EMAIL PROTECTED] Computer science is no more about computers than astronomy is about telescopes. -- Edsger Dijkstra ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lazy read
Honestly, don't use read. It's icky. Check out ReadP or parsec, they are far superior in general. I think there was a suggestion of replacing Read with ReadP? The whole point is not about writing a parser, its about having a parser written for me with deriving Read - unfortunately their is no deriving LazyRead or deriving Parsec etc. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Badly designed Parsec combinators?
Udo Stenzel wrote: Juan Carlos Arevalo Baeza wrote: myParser :: Parser () myParser = do string Hello optional (string , world!) It makes no sense for myParser to generate any values, especially not the result from the optional statement, so it is set to return (). Don't you think this will interfere somehow with type inference? With type inference? No, why? I mean... specifying the type of a function (as is recommended practice in multiple places) places a hard-point in the type system. It is even sometimes critical to make the types of a program totally predictable (or decidable), as when it's needed to resolve the the monomorphism restriction. Therefore, the language/compiler can do things to types at those hard points. If, say, the compiler needs to match some expression with IO () (or else it'll throw an error), and it infers IO String, it can unambiguously resolve it by adding the return (). In my opinion, this would make the program better by removing chaff. In the function above, the string statement returns a value which is ignored because it is in the middle of a do-notation sequence. The second statement, after my proposed change, also returns a value. But this value currently cannot be ignored like the others in the do-sequence, even though it could without ambiguity of any kind. If I hadn't specified the type of myParser, it would have gotten the inferred type Parser (Maybe String). But I should be able to specify the more general one Parser () because that change is decidable. In some conceptual way, this is no different than this: max :: Int - Int - Int max a b = if a b then a else b In this case, I've forced the type of the function to be more restrictive (and definitely different) than what it would have had if the type signature weren't there. I wouldn't like a function that might decide to throw away its result if (erroneously) used in a context that wouldn't need it. I also think almost every function has a sensible result, and written with the right combinator, can return it without too much hassle. So I'd probably write: yourParser :: Parser String yourParser = liftM2 (++) (string Hello) (option (string , world!) Personally, that style is way too functional (and a bit lisp-ish) for me. I prefer just using: yourParser :: Parser String yourParser = do helloResult - string Hello worldResult - option $ string , world! return $ helloResult ++ worldResult But that's just a matter of style. In this case, that might even be a reasonable thing to do, returning this value from this function. But sometimes isn't. Sometimes, dropping results is the right thing to do. I also find it very convenient to have a combinator that does a bind and return the unmodified result of the first computation. With that you get: (*) :: Monad m = m a - m b - m a m * n = do a - m ; n ; return a ourParser :: Parser String ourParser = string Hello * optional (string , world!) So you do drop returned values now and then? But with that function you lose out on the do-notation convenience. Therefore, implicit (return ()) is selsdom useful, has the potential to cause annoying silent failures and is generally not worth the hassle. Useful? No more than the do-notation. They are both conveniences. No more than the liftM2 function you used above: that's another convenience. All languages are full of conveniences that are not strictly necessary. Annoying silent failures? No more than the monad combinator. Another case where I encounter this is with the when function: myParser2 :: Bool - Parser () myParser2 all = do string Hello when all $ do string , world string ! A better fix would be more flexible when: when :: Monad m = Bool - m a - m (Maybe a) when True m = Just `liftM` m when False _ = return Nothing ...which is quite similar to the proposed change to Parsec's 'optional'. I'd support both. I like that. It resembles a lot the automatic conversions that C++ does. I'm more reminded of Perl... I don't know perl :) Thanx! JCAB ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Badly designed Parsec combinators?
Juan Carlos Arevalo Baeza wrote: Udo Stenzel wrote: Don't you think this will interfere somehow with type inference? With type inference? No, why? I mean... specifying the type of a function [...] Okay, so want an implicit (return ()) only if the type of the do-block has been explicitly specified as (m ()) for a monad m. I've become used to type inference and assumed you wanted to tack on the (return ()) if the corresponding type was only inferred. The former is less destructive, of course. I still dislike it, being a special rule with very limited use. yourParser :: Parser String yourParser = liftM2 (++) (string Hello) (option (string , world!) Personally, that style is way too functional (and a bit lisp-ish) for me. Uhm, well, of course you're entitled to an opinion, but I know where to find the children of Algol when I need them... ourParser :: Parser String ourParser = string Hello * optional (string , world!) So you do drop returned values now and then? But with that function you lose out on the do-notation convenience. Why, yes, I do, but I like being explicit about it. (And I'm not sure that (*) is explicit enough.) And I must confess, I don't find do-notation all that convenient. If it weren't for fail being called if a pattern match fails, I'd probably never use it at all. I'm more reminded of Perl... I don't know perl :) You're a very lucky man. (No, seriously, Perl is quite the opposite of Haskell in nearly every aspect.) Udo. -- fork(2) New processes are created by other processes, just like new humans. New humans are created by other humans, of course, not by processes. -- Unix System Administration Handbook signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lazy read
Neil Mitchell [EMAIL PROTECTED] writes: Check out ReadP or parsec, they are far superior in general. I think there was a suggestion of replacing Read with ReadP? The whole point is not about writing a parser, its about having a parser written for me with deriving Read - unfortunately their is no deriving LazyRead or deriving Parsec etc. Well, DrIFT can derive my TextParser class (another proposal for a replacement of Read in haskell-prime). However, TextParser isn't lazy in the way you would like. It can detect failure early and commit to it, but detecting success early, in order to commit to returning the initial portion of the datastructure, is not so nice to express. Essentially, rather than having an indication of success/failure in the type system, using the Maybe or Either types, you are asking to return the typed value itself, with no wrapper, but perhaps some hidden bottoms buried inside. One could certainly define such a parsing set-up, but there are no standard ones I know of. The attraction of lazy parsing is obvious, but there is a cost in terms of safety. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Decidable type systems? (WAS: Associated Type Synonyms question)
On Thu, Feb 16, 2006 at 12:45:03PM +, Miles Sabin wrote: Andres Loeh wrote, If a problem is decidable, it has the nice property that the problem (*not* the algorithm) can be used as a specification. Implementors are free to implement different algorithms, as long as they all solve the problem. If the problem is undecidable, how do you make sure that different compilers accept the same programs? If you don't want to find a subproblem that is decidable, you'll have to specify an algorithm, which is usually far more complicated, error-prone, and difficult to grasp for programmers. Again, I'm not sure that decidability helps practically here: we're not interested in compiler A and compiler B accept the same programs, we're interested in compiler A and compiler B accept some well defined subset of possible programs in a reasonable amount of time and space. But it seems that well defining that subset is equivalent to the problem of finding a suitable decidable algorithm. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Badly designed Parsec combinators?
On Thu, Feb 16, 2006 at 04:22:40AM -0800, Juan Carlos Arevalo Baeza wrote: But... the thing is, if we have any do statement, or any monad whatsoever, which does not return (), and the program needs it to return () in order to be able to match its type, that transformation is always trivial. It just has to add return () to it. () is special that way, because there's only one possible value, and monads are also special already (do-notation, for instance). How do you know what type the do statement returns in general? in haskell, type inference goes both directions, deciding the type at any point depends not just on what routine you are calling but the context it is called in. Again that doesn't compile, because when requires a ()-returning monad as its second parameter, but the string parser returns String. Same thing with if-then-else, when used to switch IO actions and such: the IO actions must fully match in type, even if the returned value will be discarded, and again that can be trivially resolved by adding the return (). This is a straight up bug in the definition of when I hope we fix. it should have type when :: Bool - IO a - IO () when = ... John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Decidable type systems? (WAS: Associated Type Synonyms question)
John Meacham wrote, Again, I'm not sure that decidability helps practically here: we're not interested in compiler A and compiler B accept the same programs, we're interested in compiler A and compiler B accept some well defined subset of possible programs in a reasonable amount of time and space. But it seems that well defining that subset is equivalent to the problem of finding a suitable decidable algorithm. Fair comment. I was (unintentionally) playing fast and loose with terminolgy there. What I really meant by well defined in the above was much weaker than the context implied. I meant something more like operationally useful and agreed on in the way that most informal or semi-formal specs are. That's probably going to seem unsatisfactory to a lot of the readers of this list, and I guess I could reasonably be accused of begging Andres' question. But I stand by my original point. What I should have said in reponse to Andres' is that it's all very well, but most (or at least a very large proportion of) interesting problems are undecidable so, for those at least, the benefits of a decidable specification are moot. Expressive type systems, and programming languages in general, are a Good Thing, and I'm prepared to trade expressive power for decidability. Having a well understood and decidable fragment of such seems like a Good Thing too, it's just that I don't see many circumstances under which I'd need or want to restrict myself to working in that fragment. Cheers, Miles ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell as scripting language?
Wow, that easy? Just eval ...? Can't believe it.. Will have look at those examples.. Marc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Constructor classes implementation
Hey all, If you're interested in an implementation of constructor classes (type classes which can take constructors as arguments; already implemented in Haskell) please see: http://www.cse.unsw.edu.au/~sseefried/code.html This should help understanding the paper by Mark P. Jones called A system of constructor classes: overloading and implicit higher-order polymorphism much easier. The implementation not only infers the type but also prints out a trace of the derivation tree for the syntax directed rules. Cheers, Sean p.s. If you find any bugs, please let me know. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GADTs and bar :: Foo t1 - Foo t2
Hello, I have a recursive type data Foo = A | B [Foo] | C [Foo] that I would like to restrict so that a C can only contain Bs, and a B can only contain As. If I use a GADT as follows the bar function, understandably, will not type check. data AType data BType data CType data Foo a where A :: Foo AType B :: [Foo AType] - Foo BType C :: [Foo BType] - Foo CType --get the successor of the Foo bar c@(C [] ) = c bar (C (b:_)) = b bar b@(B [] ) = b bar (B (a:_)) = a bar [EMAIL PROTECTED] = a How do I achieve this restriction? Do I need to have some sort of successor class with dependent types? Ta Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
