Re: Multiple imports on a single line
You can already write this, with only a tiny bit of syntax: module MyApp where import Data.Text; import Data.Foldable; import Control.Concurrent Whether it is good style is another matter, but all compilers will certainly accept it. Regards, Malcolm On 1 Feb 2017, at 14:18, Vassil Ognyanov Keremidchiev wrote: > Hello! > > What do you think about an idea to have multiple imports on a single line, > like: > > module MyApp where > import Data.Text, Data.Foldable, Control.Concurrent > ... > > That way we could write more concise and short code as Haskell promises. This > will be useful for small programs like scripts, small tools, tutorials, > examples, etc. > > Best regards, > Vassil Keremidchiev > ___ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP
On 6 Oct 2015, at 17:47, Herbert Valerio Riedel wrote: > >> The problem by discussions is that they are done between two groups with >> quite a difference in experience. On one hand you have people like Bryan, >> who have considerable contributions to the Haskell ecosystem and much >> experience in large scale software development (e.g. from Facebook). On the >> other hand you have people who don't. That's okay. We've all been at the >> latter group at some point of our career. > [...] > > At the risk of stating the obvious: I don't think it matters from which > group a given argument comes from as its validity doesn't depend on the > messenger. In that case, I think you are misunderstanding the relevance of Johan's argument here. Let me try to phrase it differently. Some people who can reasonably claim to have experience with million-line plus codebases are warning that this change is too disruptive, and makes maintenance harder than it ought to be. On the other hand, of the people who say the change is not really disruptive, none of them have (yet?) made claims to have experience of the maintenance of extremely large-scale codebases. The authority of the speaker does matter in technical arguments of this nature: people without the relevant experience are simply unqualified to make guesses about the impact. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
On other social media forums, I am seeing educators who use Haskell as a vehicle for their main work, but would not consider themselves Haskell researchers, and certainly do not have the time to follow Haskell mailing lists, who are beginning to say that these kinds of annoying breakages to the language, affecting their research and teaching materials, are beginning to disincline them to continue using Haskell. They are feeling like they would be less well disposed to reviewing papers that use Haskell, and less well disposed to collaborating on writing papers that involve Haskell. Please can the Haskell Prime Committee take into account the views of such "peripheral" users of the language, who after all, form some measure of its recent "success". Haskell is a real-world tool for many people, and breakage of their code, and their sources of information about Haskell, is a powerful disincentive to continue with it. Regards, Malcolm > On 5 Oct 2015, at 10:05, Malcolm Wallace wrote: > >> I am also a strong -1 on small changes that break huge numbers of things for >> somewhat trivial benefits. >> >> Regards, >> Malcolm >> >> On 2 Oct 2015, at 11:09, Henrik Nilsson wrote: >> >>> Hi all, >>> >>> I have discussed the monad of no return proposal with >>> my colleague Graham Hutton: a long-standing member of >>> the Haskell community, well-known researcher, some 20 >>> years of experience of teaching Haskell to >>> undergraduate students, and author of one of the most >>> successful introductory Haskell textbooks there are. >>> >>> The upshot of this e-mail is a strong collective -2 >>> from us both on particular proposal, and a general call >>> for much more caution when it comes to breaking changes >>> that are not critically important. >>> >>> First, on a general note, there has recently been a >>> flurry of breaking changes to the (de facto) Haskell >>> standards. In many cases for very good reasons, but >>> sometimes it seems more in a quest for perfection >>> without due consideration for the consequences. It used >>> to be the case that breaking changes were very rare >>> indeed. And for good reason. >>> >>> Right now, the main "measure of breakage" in the >>> on-line discussions seems to be how many packages that >>> break in Hackage. Which of course makes sense: the >>> Hackage repository is very important and such a measure >>> is objective, as far as it goes. >>> >>> But we should not forget that breakage can go far >>> beyond Hackage. For starters, there is *lots* of code >>> that is not in Hackage, yet critically important to its >>> users, however many or few they are. There are more >>> than hundreds of thousands of copies of books out there >>> where that may break in that examples may no longer >>> work. And they cannot be changed. There are countless >>> research papers that may break in the same way. Every >>> single institution that use Haskell in their teaching >>> may have to update their teaching materials (slides, >>> code, lab instructions) for every module that teaches >>> or uses Haskell. And last but not the least, what >>> countless of programmers and students have learned >>> about Haskell over decades, most of whom are *not* >>> power users who can take these changes in their stride, >>> may also break. >>> >>> Now, of course a language has to evolve, and sometimes >>> breaking backwards compatibility is more or less >>> essential for the long-term benefit of the language. >>> But we should not let perfection be the enemy of the >>> good. >>> >>> As to this particular proposal, the monad of no return, >>> it does not seem essential to us, but mostly motivated >>> by a quest for "perfection" as defined by a very >>> knowledgeable but in relative terms small group of >>> people. >>> >>> One argument put forward was that applicative code that >>> uses "return" instead of "pure" should get a less >>> constrained type. But such code is relatively new. The >>> methods of the Monad class have been return and bind >>> for some 25 years. So indeed, as Henning Thielemann >>> wrote: why should not the newer code be adapted and use >>> "pure" instead? In fact, the use of "pure" in such code >>> could serve as a quite useful cue that the co
Call for Nominations: Haskell Prime language committee
Dear Haskell lovers, The Haskell Prime process for standardisation of new versions of the Haskell language is at something of an impasse. Since the Haskell 2010 Report was issued (at the end of 2009), there has been very little momentum to formalise existing extensions and generalisations, nor appetite to decide on whether any such extensions should be adopted as part of the core language standard. We therefore seek nominations for new members of the Haskell Prime language committee; people who have the enthusiasm to take this forward, as well as some relevant experience. If you think you would like to contribute, please nominate yourself by sending a email to haskell-2011-commit...@haskell.org describing who you are, and what you think the committee might hope to achieve. The address above is populated by the existing committee members, but is now (temporarily) open to all during the nomination period. Nominations close in 3 weeks time, i.e. to be received by end of Sunday 24th February 2013. The process for deciding a new language committee is described at http://hackage.haskell.org/trac/haskell-prime/wiki/Committee Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Status of Haskell'?
On 28/12/2012, at 1:01, Ramana Kumar ram...@member.fsf.org wrote: On Wed, Dec 12, 2012 at 6:40 PM, Malcolm Wallace malcolm.wall...@me.com wrote: There is a mailing list for the members of the language committee: haskell-2011-commit...@haskell.org. Hi Malcolm, could you (or someone) help me out with a link to the archives (if any) for this list, and the listinfo page? http://www.haskell.org/mailman/listinfo/haskell-2011-committee But of course, those list archives are private. All substantive discussion is supposed to take place on the Haskell-prime list. The private committee list is only for administration, voting, choice of new committee members, etc. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Status of Haskell'?
I confess that I have not had enough free time in the last two years to have been a good chair for the language committee. (Using Haskell in the real world is just too absorbing!) I think the next chair should probably be an academic, who may have more incentive to spend effort on formalisation of the language design process than us industrial types. (At work, if we want a language extension, we just go ahead and implement it - job done.) There is a mailing list for the members of the language committee: haskell-2011-commit...@haskell.org. It has not seen any activity since 3 messages in October 2011, and prior to that, a thread of 13 messages in Nov/December 2010. Both of those threads were largely about the vanishingly small number of proposals to be decided upon, and whether to issue a new Report (the answer being no on both occasions). So, given that there are a few people who have expressed interest in reviving the language formalisation process, perhaps we should hold nominations for a new committee, in the spirit of the method outlined on the wiki page: http://hackage.haskell.org/trac/haskell-prime/wiki/Committee Please send nominations to haskell-2011-commit...@haskell.org, summarising your interest and experience. The existing committee will (I hope) make some decision on how to proceed, in early January 2013. Regards, Malcolm On 12 Dec 2012, at 02:42, Ramana Kumar wrote: Dear Malcolm, What is the current status of Haskell Prime, as far as you know? (Is there a better way to reach the Haskell Prime committee than just emailing the chair?) We have a few volunteers here looking to keep Haskell Prime moving forward, and Simon suggested following the tracks of earlier pioneers and resuming/joining where they left off. Cheers, Ramana ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: What is a punctuation character?
no purpose to a completely overlapping category unless it is intended to relate to an earlier standard (say Haskell 1.4). I believe all Haskell Reports, even since 1.0, have specified that the language uses Unicode. If it helps to bring perspective to this discussion, it is my impression that the initial designers of Haskell did not know very much about Unicode, but wanted to avoid the trap of being stuck with ASCII-only, and so decided to reference whatever Unicode does, as the most obvious and unambiguous way of not having to think about (or specify) these lexical issues themselves. One of the underlying questions is: what is the concrete syntax of a Unicode character in a Haskell program? Note that Chapter 2 goes to a great pain to specify the ASCII concrete syntax. In my view, the Haskell Report is deliberately agnostic on concrete syntax for Unicode, believing that to be outside the scope of a programming language standard, whilst entirely within the scope of the Unicode standards body. Seeing as there are (in practice) numerous concrete representations of Unicode (UTF-8 and other encodings), it is largely up to individual compiler implementations which encodings they support for (a) source text, and (b) input/output at runtime. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
-1. I agree with John. There is no point in fiddling with the dots, until we have real experience with a new records proposal (which can be implemented entirely without using dot, at least initially). Regards, Malcolm On 10 Feb 2012, at 03:14, John Meacham wrote: I mean, it is not worth worrying about the syntax until the extension has been implemented, used, and proven useful to begin with. Monads were in use well before the 'do' notation. Shaking out what the base primitives that make up a monad took a while to figure out. Even discussing syntax feels a little like a garage band discussing what the lighting of their stage show will look like before they learned to play their instruments. If we can implement it and test it without breaking existing code, why wouldn't we? It would mean more people can experiment with the feature because they wouldn't have to modify existing code much. So we will have more feedback and experience with how it interacts with other aspects of the language. John On Thu, Feb 9, 2012 at 6:41 PM, Greg Weber g...@gregweber.info wrote: There are 2 compelling reasons I know of to prefer dot for record access 1) follows an almost universal convention in modern programming languages 2) is consistent with using the dot to select functions from module name-spaces We can have a lot of fun bike-shedding about what operator we would prefer were these constraints not present. Personally I wouldn't care. However, I find either one of these 2 points reason enough to use the dot for record field access, and even without a better record system the second point is reason enough to not use dot for function composition. It is somewhat convenient to argue that it is too much work and discussion for something one is discussing against. The only point that should matter is how existing Haskell code is effected. On Thu, Feb 9, 2012 at 8:27 PM, Daniel Peebles pumpkin...@gmail.com wrote: I'm very happy to see all the work you're putting into the record discussion, but I'm struggling to see why people are fighting so hard to get the dot character in particular for field access. It seems like a huge amount of work and discussion for a tiny bit of syntactic convenience that we've only come to expect because of exposure to other very different languages. Is there some fundamental reason we couldn't settle for something like # (a valid operator, but we've already shown we're willing to throw that away in the MagicHash extension) or @ (only allowed in patterns for now)? Or we could even keep (#) as a valid operator and just have it mean category/lens composition. Thanks, Dan On Thu, Feb 9, 2012 at 9:11 PM, Greg Weber g...@gregweber.info wrote: Similar to proposal #20, which wants to remove it, but immediately less drastic, even though the long-term goal is the same. This helps clear the way for the usage of the unspaced dot as a record field selector as shown in proposal #129. After this proposal shows clear signs of moving forward I will add a proposal to support a unicode dot for function composition. After that we can all have a lively discussion about how to fully replace the ascii dot with an ascii alternative such as ~ or After that we can make the dot operator illegal by default. This has already been discussed as part of a records solution on the ghc-users mail list and documented here: http://hackage.haskell.org/trac/ghc/wiki/Records/DotOperator ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Please apply the comparison function given to nubBy to elements of the list in the order in which they occur in the list.
If this is a _proposal_ to change ghc's non-Report-compatible Data.List implementation to match the behaviour of the Report implementation, then count me as a +1. I think an important convention when it comes to higher order functions on lists is that to the extent which is possible, the function parameters take elements from the list (or things computed from those) in the order in which they occur in the original list. This seems like an entirely reasonable principle. I'm aware that the Report (strangely!) explicitly leaves the behaviour of nubBy unspecified for functions which are not equivalence relations, but the behaviour given by the Report implementation (the opposite of the current behaviour in GHC) is useful and desirable nonetheless. I notice that the Haskell'98 Report gives a sample implementation, but the Haskell'2010 Report does not. I wonder if this is a regression, since in days of yore, the Report implementation was treated as a gold standard reference for questions about function semantics, strictness and so forth. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: fix simple pattern binding and declaration group
Once you guys have reached consensus on appropriate revised wording for this issue, I'll happily apply the changes to the Haskell 2012 Report as a bugfix. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: TypeFamilies vs. FunctionalDependencies type-level recursion
| Is there a policy that only a proposal's owner can modify the wiki | page? Or that you have to be a member of the Haskell' committee? I'm not sure. Malcolm Wallace is chair at the moment; I'm ccing him. I have no idea: I neither set up the wiki, nor do I have any interesting admin rights for it. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: specify call-by-need
On 16 Feb 2011, at 01:53, Scott Turner wrote: In practice, Haskell a call-by-need language. Still, software developers are not on firm ground when they run into trouble with evaluation order, because the language definition leaves this open. Is this an underspecification that should be fixed? I might actually be inclined to go the other way in the language spec. The Report says the language is non-strict, but there is at least one implementation in the wild which is basically strict (with escape hatches for explicit laziness). Compatibility with Haskell in all other aspects (apart from evaluation order) is a nice property. 2. Virtually all significant-sized Haskell programs rely on lazy evaluation and have never been tested with another evaluation strategy, Having personally converted a reasonable number of modules/programs from Haskell to this strict Haskell implementation, I can verify that the change in evaluation strategy does indeed throw up several surprises. None are insurmountable, but writing for a strict evaluator does require a different way of thinking about some program structuring. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Reform of the Monad, and Disruptive Change
On 4 Feb 2011, at 09:41, John Smith wrote: There has been a fair amount of discussion, both on this list and libraries, regarding the Monad class hierarchy. The many on the libraries list expressed support for the patch at http://hackage.haskell.org/trac/ghc/ticket/4834 , conditional on it being part of the next Haskell report. However, Haskell' prefers patches to have been implemented before proposing here. What is the best way out of this deadlock? I suggested, and several people +1'd, that if we are making disruptive changes to the standard libraries defined in the Language Report (especially the Prelude), then we should aim to make a thorough job of cleaning up all the cruft and redesigning in a single strike. This means not just rearranging the Monad hierarchy, but looking at I/O types, exceptions, the default strictness of foldl, and much much more. I would expect the language committee to get involved in reviewing the decisions of the base library strike force. Then (for instance) ghc could make a major release with the refreshed libraries, and after a little experience in the field (and perhaps a few patches), the libraries would then proceed to be blessed as part of the subsequent language standard. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell] Announce: ~Haskell 2011
(a) we wish to accept the NoDatatypeContexts proposal http://hackage.haskell.org/trac/haskell-prime/wiki/NoDatatypeContexts The Trac-Wiki says: What removing the datatype contexts from a source file will do is make some previously illegal programs legal. What is an example? As on the wiki, data Eq a = Foo a = Constr a getVal :: Foo a - a getVal (Constr x) = x would previously have been rejected. Once the compiler forces the user to remove the Eq a = context on the datatype, the rest of the program will be accepted. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Announce: ~Haskell 2011
On 7 Jan 2011, at 22:25, Ian Lynagh wrote: Have you considered deciding about individual proposals as and when they are completed, rather than making a decision about all proposals each September? This could also avoid merge-conflicts between the report deltas for proposals that touch the same bit of the report. I can see advantages and disadvantages of both approaches - incremental decisions vs a single time-limited big decision. I think it all depends on the engagement of the community. If there is clear consensus from the community on a particular proposal, I can imagine the committee incrementally accepting it. If consensus is not clear, I think a decision is likely to be deferred until voting-time. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Announce: ~Haskell 2011
The Haskell Language committee has had a quiet year. Following the announcement of Haskell 2010 in Nov 2009 [1], and the publication of the 2010 Report in July 2010 [2], we found a distinct lack of complete new proposals to decide upon. As a result, the committee has made the following decisions: (a) we wish to accept the NoDatatypeContexts proposal http://hackage.haskell.org/trac/haskell-prime/wiki/NoDatatypeContexts (b) this delta will be applied to the 2010 Report to form a new baseline; (c) we will _not_ issue a new language standard called 2011; (d) we intend to issue a new language standard in 2012; (e) the committee will continue for another year without new nominations. However, let me make it clear that the apparent lull in committee activity does not mean there are no active proposals being made. On the contrary, proposals for language features (and removals) are made by the community at large (that's you) - the committee's main role is not to make proposals, but to decide which to accept. And there have in fact been a large number of proposals, but very few have made it all the way to the stage of producing a language report delta that could be accepted (or modified) by the committee. So, I wish to declare open season on proposals for the 2012 standard. If there is a language feature you care about, please do take an hour or two to review the details on our wiki [3], search for older discussions on the mailing lists, and draft the Report changes you think would be necessary. I'm looking forward to a more active and exciting collection of potential language changes for 2012, but it will only happen if you get involved. Regards, Malcolm (Haskell 2011 committee chair) [1] http://www.haskell.org/pipermail/haskell/2009-November/021750.html [2] http://www.haskell.org/pipermail/haskell/2010-July/022189.html [3] http://hackage.haskell.org/trac/haskell-prime/ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Functor hierarchy proposal and class system extension proposal
See also http://repetae.net/recent/out/classalias.html http://www.haskell.org//pipermail/libraries/2005-March/003494.html http://www.haskell.org//pipermail/haskell-prime/2006-April/001344.html http://www.haskell.org//pipermail/haskell-prime/2006-August/001582.html On 27 Dec 2010, at 22:35, Howard B. Golden wrote: Hi, In 2006, Ashley Yakeley proposed the functor hierarchy proposal (http://www.haskell.org/haskellwiki/Functor_hierarchy_proposal), and, in 2007, Brianh (his wiki handle since I don't know his name) proposed the class system extension proposal (http://www.haskell.org/haskellwiki/Class_system_extension_proposal). I recently Googled these proposals and didn't see any significant discussion since they were originally proposed. If there has been some, please point me to it so I can read it. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
preparing for Haskell 2011
Dear all, Although the Haskell 2010 Language Report has only been published recently, it will soon be time for the Committee to make decisions on the next version, Haskell 2011. I am aiming for the committee to make decisions around the end of Sept or beginning of October 2010. Can I therefore encourage any people who have made proposals, either informally on mailing lists, or formally in the Haskell-prime ticket system, to consider what they need to do to bring those proposals to a state where the committee can vote on them. Perhaps you have not made such a proposal yourself, but are very keen that someone else's proposal be adopted. Work with the proposer to polish it! Here is what you need to know about the proposal process: http://hackage.haskell.org/trac/haskell-prime/wiki/Process Please note especially that the key requirement that will bring your proposal to the attention of the committee for a decision is the Report delta, which describes the changes with exact precision. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Propsal: NoDatatypeContexts
H98 and H2010 allow a context to be given for datatypes, e.g. the Eq a in data Eq a = Foo a = Constr a I have made a proposal to remove support for that context (ticket #139). Although I would prefer that contexts of datatypes did the right and useful thing, in the absence of a proposal of that nature, I am quite happy to add my +1 to their removal instead. As Igloo notes, GADTs are a more viable way to achieve the storing of the dictionary within the constructor, e.g. data OrdTree a where Leaf :: a - OrdTree a Branch :: Ord a = OrdTree a - OrdTree a - OrdTree a Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Second draft of the Haskell 2010 report available
I have now updated the libraries too. Rather than update all the library documentation manually, I (perhaps rashly) decided to make a LaTeX backend for Haddock instead, and generate the report automatically from the library source code. Perhaps I should have mentioned (before sending a formatting error report): thanks, this looks great! Auto-generation is definitely the way to go, and well worth the effort. I did notice one other small item, which is perhaps an infelicity rather than an error. The documentation for Data.List (20.10.1), the By operations, mentions It is often convenient to use these functions together with Data.Function.on. But sadly, Data.Function is not one of the libraries in the H'2010 set. I would personally be happy to add it, but perhaps it is too late, and we will need to wait for H'2011. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010 libraries
3. allow packages to shadow each other, so haskell2010 shadows base. This is a tantalising possibility, but I don't have any idea what it would look like, e.g. should the client or the package provider specify shadowing? This sounds like a potentially complicated new mechanism, introducing lots of new subtleties. Probably not a good idea for that reason alone. 4. Provide a haskell2010 package and a base2010 package that re-exports all of base except the modules that overlap with haskell2010. You can either use haskell2010, haskell2010+base2010, or base. This is a bit like (1), but avoids the need for shadowing by using package re-exports, on the other hand confusion could well arise due to the strange base2010 package, and some people would surely try to use haskell2010 + base and run into difficulties. In many ways this corresponds to my preferred solution, although I would rephrase it thus: * Deprecate use of the base package, (I do not mean to remove base, just to freeze it, and discourage its general use.) * Create a new haskell2010 package (for ghc this will be built on top of base, but other compilers might make a different choice). * Create a new portablebase package which contains (or re-exports) all of the remaining useful and portable parts of the current base _and_ haskell2010. * Create a new ghcextras package which re-exports (or defines afresh) all of the useful but non-portable parts of the current base. So haskell2010 would be stable and unchanging. portablebase would be a superset of haskell2010, and continue to evolve with community input, and parts of it would eventually migrate into haskell2011, haskell2012, etc. Meanwhile ghcextras would clearly delineate those language/library features that are not portable, and it could continue to grow, or indeed shrink, with some parts migrating into portablebase as the language definition adopts extensions, or as other compilers adopt implementation strategies. To illustrate the forward compatibility story, I envisage that when haskell2011 is created, a new version of portablebase would depend on (and re-export) it instead of haskell2010. This would be OK because the portablebase API would be non-decreasing, and new Reports should not make library changes that have not already been trialled in the community. On the other hand, the ghcextras package would be free to shrink as functionality is gradually transferred to portablebase. Because I suggest that portablebase re-export the haskell2010 API in its entirety, it would be impossible to use both packages explicitly at the same time from a single module - users would need to choose one or the other. Also, packages which currently depend on base should be encouraged to upgrade to a dependency on haskell2010 rather than on portablebase, if possible, because it provides greater stability of interface. The overall dependency graph would look something like this: /--- stablestuff /-- less-stable-stuff / / base --- haskell2010 --- portablebase ---\ \-- ghcextras -\=== experimental-stuff 5. Not have a haskell2010 package, but have the report say that implementations are allowed to add things to the standard libraries. This seems superficially attractive, but I think it would be impossible in practice to guarantee anything. For instance, the semantics of take and drop changed between Haskell 1.4 and Haskell'98 iirc, with no corresponding change in the API. With separate packages it is possible to retain and choose between both sets of semantics. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010 draft report
I'd appreciate a few more eyes over this, in particular look out for messed up typesetting as there could still be a few bugs lurking. Modified versions of this Report may also be copied and distributed for any purpose, provided that the modified version is clearly presented as such, and that it does not claim to be a definition of the language Haskell 98. Well at least you are complying. :-) In the Preface, my affiliation should be University of York, the one in England, not York University, the one in Canada. Also in the Preface, I would expect a citation for the published version of the Haskell'98 book, together with its appearance in the Bibliography. I did not immediately spot any other obvious flaws. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Haskell prime: the sequel (2011)
http://hackage.haskell.org/trac/haskell-prime The new committee for Haskell language standardisation has been appointed, based on public nominations. I am the new chair. http://hackage.haskell.org/trac/haskell-prime/wiki/Committee In case you missed it, the previous committee resulted in the minor revision of the language called Haskell 2010. The next revision (Haskell 2011) is due to be decided later this year, around October- November, and published by the beginning of 2011. I would like to emphasise that the future of Haskell is in the hands of the whole community - and that means you. The committee's role is to make decisions, but the task of making and refining proposals belongs with the language's users. Please cogitate, agitate, and formulate! Here is how to get your language idea accepted: http://hackage.haskell.org/trac/haskell-prime/wiki/Process (Don't forget that you can propose _removal_ of features, as well as additions.) Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Nominations for the Haskell 2011 committee
To nominate someone (which may be yourself), send a message to haskell-prime@haskell.org . Please give reasons for your nomination. I would like to nominate Neil Mitchell for the Haskell Prime committee. He falls into the categories of commercial user, and open-source tool writer. He has been part of the Haskell community for around 5 years, and a very active contributor. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Standarize GHC.Prim.Any
Also, can/do all compilers that implement unsafeCoerce implement a safe Any? Hugs can do it with just data Any = Ignored I believe, not sure about nhc, yhc or jhc... nhc98 and yhc do not implement the Any type. unsafeCoerce is easily implemented without it. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: bug in language definition (strictness)
Yet I think it would be valid to say that seq can turn a non-terminating (exceptioning) program into a terminating one. Do you have an example of that? Sure. foldl (+) 0 [1..1000] :: Integer *** Exception: stack overflow foldl' (+) 0 [1..1000] :: Integer 500500 The only difference between foldl and foldl' is strictness (the use of seq). By non-terminating (exceptioning) I of course really meant terminating with bottom as opposed to terminating with a defined value, but since non-termination and exceptions are semantically both bottom, you won't mind that slip. :-) Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: bug in language definition (strictness)
If, as I understand it, you are relying on the fact that seq's first argument is evaluted before its second, then you really want pseq rather than seq. In GHC we provide a way to do what you want (pseq), I'm just not convinced it should be the required behaviour of seq. Whilst looking for something else, I have discovered that the official list of changes from Haskell 1.2 to Haskell 1.3 has this explicit statement: The seq function evaluates its first argument before returning the second one. http://haskell.org/definition/from12to13.html In addition, the 1.3 and 1.4 Reports, in describing how seq should be understood for any particular type, states: The _case_ is used to force evaluation of the first argument to `seq` before returning the second argument. The Haskell'98 committee decided to remove the Eval class (that had seq as one of its methods), see http://www.cs.chalmers.se/~rjmh/Haskell/Messages/Decision.cgi?id=204 I assume that it was simply inattention whilst editing the Report text, that caused the removal of the official requirement that seq evaluate its first argument before its second, because I can find no discussion by the committee that suggested such an important change. If you can point me to the committee discussion that led to changing this requirement, I would be grateful. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: NoMonomorphismRestriction
On 6 Aug 2009, at 12:18, Simon Peyton-Jones wrote: The paper makes the (somewhat radical) case for not generalising local bindings at all; which would at a stroke remove most of the issues of the MR. (We'd still need to think about the top level.) Only the other day I was writing some code that used a case analysis to build a value I hoped would be polymorphic, and it kept refusing to type-check. Doing the case analysis on a different part of the value, then cutting and pasting the branch code multiple times did however seem to work. Suddenly I remembered about the difference in generalisation between let- and lambda- bindings, and could solve the problem by changing the case to a let! Instantly I could delete the error-prone cut-n-paste copies, and be more assured of the consistency of my code. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: bug in language definition (strictness)
What semantics would you like Haskell to have, in which (x `seq` y `seq` e) and (y `seq` x `seq` e) are not equal? I can easily imagine that (x `seq` y `seq` e) might have *two* semantic denotations: bottom (Exception: stack overflow), and e. And I would like to be able to choose which one I get (please). This is the declared purpose of seq, namely to improve performance by avoiding unneeded laziness. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: change to qualified operator syntax
left section right section prefix unqualified (+ 1) (1 +) (+) Haskell 98 (M.+ 1) (1 M.+) (M.+) proposed (`M.(+)` 1) (1 `M.(+)`) M.(+) or(*) (M.(+) 1) (flip M.(+) 1) The last line is not correct. (M.(+) 1) captures the first argument of the function, not the second like all the other entries in that column. Likewise the flip variant captures the second arg, where all the others capture the first. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010: libraries
A natural language consists of a vocabulary of words, as well as a grammar for stringing them together. If we omit the common basic libraries from the language definition, then are we implicitly reducing the common vocabulary, and encouraging dialects to appear? If I see the function scanr in a module, should I expect that it has the semantics of Data.List.scanr? Or is it OK for someone to define their own Data.List with different semantics? Keep the commonly used and uncontroversial (mostly pure) modules and rename them to use the new hierarchical module names. I would largely concur with this policy, with the caveat that additions to the API might appear in future. Also, the hierarchical versions of the FFI libraries are essential. 3. Numeric keep as Numeric (?) I think we could take the opportunity to rename it to Text.Numeric. Why Text? Because it only defines ReadS and ShowS things (with the exception of fromRat, and floatToDigits, sigh, which should be moved elsewhere). It'd be nice to have a clear dividing line of keeping the pure stuff and dropping the bits for interacting with the system ... The bits for interacting with the system are of course exactly the bits that are most prone to change and are most in need of improvement. In some ways, it is _more_ important to standardise the difficult bits, i.e. interacting with the system, because otherwise it is desparately difficult to write portable programs. But I agree that the choices made in H'98 and earlier to abstract over the underlying OS were probably rather poor and inflexible, and it is probably unrealistic to be able to propose a new stable API for a couple of years yet. I do think we should set it as a goal for the future however. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: what about moving the record system to an addendum?
On 7 Jul 2009, at 02:28, John Meacham wrote: Haskell currently doesn't _have_ a record syntax (I think it was always a misnomer to call it that) it has 'labeled fields'. ... and a reworking of the standard to not refer to the current system as a 'record syntax' but rather a 'labeled fields' syntax. I strongly agree with the latter. In fact, I was under the impression that the Report already avoided the term record syntax completely, but checking just now showed 6 distinct occurrences. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Announcing the new Haskell Prime process, and Haskell 2010
i can't understand. does this list supposed to be full list of changes in haskell'? this is a provisional list of features that the Haskell' committee thinks would be feasible to include in a 2010 revision of the Haskell standard. And just to add, the new standardisation process means that there will also be a Haskell 2011, Haskell 2012, etc. If a feature is not completely specified in time for one standard, then it will not need to wait long until it can be accepted in the next one. Eventually, the process might give us a standard that is stable and unchanging, but right now, we need to take it small pieces. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: Deprecate ExistentialQuantification
I would hereby like to propose that the ExistentialQuantification extension is deprecated. It is worth pointing out that all current Haskell implementations (to my knowledge) have ExistentialQuantification, whilst there is only one Haskell implementation that has the proposed replacement feature, GADTs. Of course, that in itself is not an argument to avoid desirable change to the language, but it is one factor to consider. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: RFC: qualified vs unqualified names in defining instance methods
It is illegal to give a binding for a class method that is not in scope, but thename under which it is in scope is immaterial; in particular, it may be aqualified name. I believe this was a change introduced in H'98 to tidy up the language. Previously, if a class was imported qualified, it was only possible to declare an instance method by using a qualified name on the lhs. It was felt that this was an oddity, because there are no other situations in which it was even possible to define a variable with an explicitly-qualified name, and in any case the qualification was entirely redundant, because there was no ambiguity. Additionally, permitting a qualified name to appear in the definitional position of any declaration led to ambiguity in parsing. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
patch applied (haskell-prime-report): typo in section 3.17.2, rule 8, for pattern-matching n+k
Mon Mar 17 03:45:08 PDT 2008 [EMAIL PROTECTED] * typo in section 3.17.2, rule 8, for pattern-matching n+k M ./report/exps.verb -2 +2 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
patch applied (haskell-prime-report): very minor typos in section 5.6
Mon Mar 17 06:12:29 PDT 2008 [EMAIL PROTECTED] * very minor typos in section 5.6 M ./report/modules.verb -2 +2 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: do-and-if-then-else modification
isaac jones [EMAIL PROTECTED] wrote: Iavor and I just made the trivial modification for DoAndIfThenElse Any comments on this modification? How do people feel about the suggestion that we do it for case statements as well? I'm happy to allow the change for if-then-else. The need for extra indentation there has annoyed me a few times. However, I have never come across the case-of expression variation in practice. Indeed, the wiki page is not very clear on what exactly the problem is. For instance, until a few minutes ago, the given example was merely: case whatever of blah - bluh blah' - bluh' However, that is already perfectly legal Haskell'98. I just changed the example to read do case whatever of blah - bluh blah' - bluh' since that is what I thought was perhaps intended. And indeed that is rejected by a H'98 parser. But it seems a bit of an unlikely coding style. And it now occurs to me that perhaps something different was intended. The following is legal H'98: case whatever of Cons - bluh Nil - foo But stick it in a do block and it ceases to be accepted: do case whatever of Cons - bluh Nil - foo Now for myself, I tend to strictly indent the alternatives in a case expression, but I can see that if you prefer non-indented alternatives, then the latter would indeed be annoying. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: rank-2 vs. arbitrary rank types
Iavor Diatchki [EMAIL PROTECTED] wrote: I don't think that the rank-N system is any more expressive then the rank-2 one. The reason is that by placing a polymorphic value in a datatype we can decrese its rank. In this way we can reduce a program of any rank to just rank-2. The same position could be used to argue against higher-order types. All higher-order programs can be reduced to first-order programs by firstification (encoding functional arguments as data values, which are then interpreted). Yet most functional programmers agree that being able to write higher-order definitions directly is more convenient. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: help from the community?
Douglas Philips [EMAIL PROTECTED] wrote: .to fark around with that stoopid ass ... Pisses off users ... domineering compiler writer can feel smug 'bout 'mself. Feh. Feh^2. Hey, man, take a chill pill. I did say it was a _minor_ horror. this is off topic. Sorry, I don't know if that is troll bait or not... Since yours is the first actual flame I can remember ever being posted to any Haskell list, I think this counts as the beginning of the end of civilisation as we know it. :-) At least, the beginning of the end of civilised discussion. And couldn't you guess - over lexical syntax! :-) Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: List syntax (was: Re: help from the community?)
Douglas Philips [EMAIL PROTECTED] wrote: What would be the proper way to propose that: | ( exp1 , ... , expk ) (tuple, k=2) | [ exp1 , ... , expk ] (list, k=1) be amended to: | ( exp1 , ... , expk [ , ] ) (tuple, k=2) | [ exp1 , ... , expk [ , ] ] (list, k=1) I think you just did. :-) Actually, it would eventually need a supporter on the committee to add a ticket on the trac/wiki for this. I believe that ghc at one time did accept any sequence of white-space separated commas as if they were a single comma, leading to code such as [ 1 , , 2 , 3 , ] Whilst programmers might be able to see the obvious meaning when it occurs in list exprs, do stmts, imports, exports, and the like, they might run into difficulties in the tuple case. For instance, (1,2,) has been proposed as syntactic sugar for a tuple-section, meaning \x- (1,2,x) and this would be a perfectly reasonable and intuitive interpretation IMO. The number of commas is a powerful visual indication of the arity of the tuple. More generally, the notation (,,) is already widely used as the name of both the type- and data- constructor for triples. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: help from the community?
On 1 Feb 2007, at 21:31, Jacques Carette wrote: Stephanie Weirich wrote: I don't think we want to allow types like: forall . Int or forall a b. Int These types are mostly bugs. Furthermore, rejecting them doesn't limit expressiveness: If you restrict yourself to programs entirely written by humans, I agree completely. But if you consider programs written by programs (say Template Haskell to be specific, but it could be via many other means), such degenerate types occur rather often. I find the program-generated code argument rather weak. In that past it was used to justify all kinds of minor horrors like excess commas in lists and so on. But if one can write a program to generate syntactically valid but ugly code, one can easily spend a little extra effort on making the result beautiful too. After all, which is the more difficult task - devising the auto-coding schema, or pretty-printing? There is no reason to accept ugly coding practices just because it makes the auto-coder's job slightly simpler. That only encourages humans to use sloppy practices in hand- written code as well. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: help from the community?
isaac jones [EMAIL PROTECTED] wrote: http://hackage.haskell.org/trac/haskell-prime/ticket/57 Does anyone have any feedback on this work? Yes, here are my thoughts. PROPOSAL: adopt GHC's convention and treat 'forall' specially in types but allow it to be used in value declarations. Agree. [ scheme = 'forall' tvars '.' opt_ctxt type ] The non-terminal 'tvars' is a sequence of type variables that are separated by blank spaces. We have a choice if we should allow empty quantifier sequences. PROPOSAL: be liberal: * allow empty quantifier lists * allow variables that are not mentioned in the body of a type (but warn) * allow predicates that do not mention quantified variables (but warn?) I cannot see how an empty list of tyvars is useful or desirable in practice: data Foo = Foo (forall . Int) is equivalent to just data Foo = Foo Int so why bother to permit the former? It probably indicates some error in the thinking of the programmer, so the compiler should bring it to her attention. On the other hand, I can imagine a use for phantom type variables in the quantifier (especially if they occur in multi-parameter predicates, but not in the type). So I think accepting them with a warning is reasonable. I can also imagine predicates that do not mention locally-quantified variables - the assumption must be that they mention variables bound on the LHS of the datatype decl instead? e.g. the Show predicate here: data Foo a b = Foo a b | Bar (forall c . (Show b, Relation b c) = (b,c)) Hmm, maybe a simpler version of this example would illustrate what you mean by the proposal (first of the three bullets) to allow an empty quantifier list: data Foo a b = Foo a b | Bar (forall . Show b = b) In which case, does this even count as a polymorphic component at all? Is it not rather GADT-like instead? data Foo a b where Foo :: a - b - Foo a b Bar :: Show b = b - Foo a b Strict Fields: Where should we place the '!'? PROPOSAL: before a schema and the schema has to be in parens. Seems the only reasonable choice. Labelled Fields. PROPOSAL: Use syntactic equivalence modulo * alpha renaming * order/repetition of predicates (i.e. compare predicates as sets) Seems OK. Using entailment looks like it would permit a far more obfuscated programming style, without adding any useful functionality. Constructor that have polymorphic components cannot appear in the program without values for their polymorphic fields. I didn't fully understand this requirement. If Haskell-prime gets rank-2 or rank-n types, then do we need to restrict constructors in this way? We do not allow nested patterns on fields that have polymorphic types. Yes, agree. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: defaults
Simon Marlow [EMAIL PROTECTED] wrote: If so, then I offer a counter example: toRational pi If these two points are valid, then I think the slight loss of backward compatibility is acceptable? I spotted the problem because it looks (to me) like the current Haskell 98 rule is designed specifically to handle cases like this. I agree that having to write toRational (pi::Double) is somewhat ugly. Would you mind updating the wiki page? I don't think it's too clear on the need for constraint simplification before applying your defaulting rules either. I have added your counter example to the wiki. But I'm not sure how to make the need for constraint simplification clearer. 3 out of the 7 sentences in the proposal describe it, and 3 out of the 5 examples mention its role. What do you think is missing? Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: defaults
Simon Marlow [EMAIL PROTECTED] wrote: Is your proposal supposed to be backwards compatible with Haskell 98 for programs that don't have default declarations? Yes, it is supposed to be backwards compatible. If so, then I offer a counter example: toRational pi will default pi to Double in Haskell 98, but will be an error under your proposal, because the two constraints (Real and Floating) disagree on the default. Well spotted. So there are some expressions that are defaulted in H'98 but would not pass type-checking with my proposal. (1) Are examples like this common? I am guessing not. You mention Enum/Fractional combinations, but arguably Float and Double do not belong in Enum anyway. (2) The new rule is conservative - it does not silently change the semantics, but it does reject more programs. Such programs are easily fixed by adding a type signature. If these two points are valid, then I think the slight loss of backward compatibility is acceptable? Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
patch applied (haskell-prime-report): Change front matter to say quot; Haskell Primequot; rather than quot; Haskell 98quot; .
Mon Jan 8 07:06:32 PST 2007 [EMAIL PROTECTED] * Change front matter to say Haskell Prime rather than Haskell 98. M ./report/haskell.verb -5 +6 M ./report/intro.verb -1 +1 M ./report/preface-jfp.verb -53 +68 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal for stand-alone deriving declarations?
Brian Smith [EMAIL PROTECTED] writes: http://haskell.org/haskellwiki/GHC/StandAloneDeriving Basically, the syntax for instances and derived instances would be identical, but derived instances would just omit the where clause, while non-derived instances would need the where clause. This is a really _bad_ idea for readability. In a year's time, when this discussion is forgotten, who would be able to tell at a glance the deep and real semantic difference between the following two instance decls? instance Num (Bar z) where and instance Num (Bar z) The former declares that _no_ methods are defined (except for defaults), and the latter, with your proposal, that _all_ methods are defined. The real killer is that both of these decls are already valid in Haskell'98, but they mean the _same_ thing (the former, if you were wondering). This is a sure recipe for introducing new and subtle bugs into existing bug-free programs. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: seq vs. pseq
Simon Marlow [EMAIL PROTECTED] wrote: The difference is subtle. The semantics of seq and pseq are identical; however, GHC can see that seq is strict in both its arguments and hence could choose to evaluate them in either order, whereas pseq is only strict in its first argument as far as the strictness analyser is concerned. The point is that pseq is useful for controlling evaluation order, which is what you want for adding parallelism to a program. seq, on the other hand, is not useful for controlling evaluation order. This is a rather weird thing, and I would consider it a bug in the Haskell Report, rather than a bug in ghc. (It bites hard when you are trying to implement something like HPC.) The very name 'seq' surely suggests that you are controlling the evaluation order. Please evaluate this thing on the left first. But that is _not_ what the Haskell Report says! Ghc takes the Report literally, and so the thing on the right is just as likely to be evaluated before the thing on the left! Surely the language designers did not intend this consequence. For Haskell-prime, can we fix this bug, and ensure that 'seq' really implies ordering of evaluation? [ If you just want strictness annotations, with the compiler free to reorder computations, I would say ($!) is a better bet, and could be redefined to use not the natural `seq`, but the strict-in-both-arguments variation. ] Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: (Pattern) Guards in lambdas
Claus Reinke [EMAIL PROTECTED] wrote: since Pattern Guards appear to be popular with the committee, I suggest to revisit the decision to drop guards from lambdas: suggestion: undo removal of guards from lambdas, especially (but not only) if pattern guards make it into the language. See the existing proposals http://hackage.haskell.org/trac/haskell-prime/wiki/LambdaCase http://hackage.haskell.org/trac/haskell-prime/wiki/MultiWayIf Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Pattern matching order for records
Ian Lynagh [EMAIL PROTECTED] wrote: Has clarifying the pattern matching order for records as described in http://hackage.haskell.org/trac/ghc/ticket/246 been discussed for haskell'? I couldn't see it on the proposals list. Perhaps because this has already been fixed in the errata to the Haskell'98 Report? See http://haskell.org/definition/haskell98-revised-bugs.html Specifically: [July 2004] Page 32, Section 3.17.2, Informal Semantics of Pattern-Matching, case #6. Case 6 says: Matching against a constructor using labeled fields is the same as matching ordinary constructor patterns except that the fields are matched in the order they are named in the field list. All fields listed must be declared by the constructor; fields may not be named more than once. Fields not named by the pattern are ignored (matched against _). You could interpret 'field list' to mean the order the fields appear in the pattern, OR, the order in which the fields were declared. The choice of interpretation affects termination behaviour. The intention of the Report writers was to use the field order of the pattern, not the declaration. Thus, the Report can be clarified by changing the end of the first sentence above to read the order they are named in the pattern field list. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Regarding Class Aliases
Christophe Poucet [EMAIL PROTECTED] wrote: Class Aliases. I have looked at the ticket and right now it's marked as a low priority with low probability of entering the standard. I think class aliases might be a nice idea too. But we don't have any concrete experience with implementations that support them. Haskell' is primarily about standarding the current state-of-the-art, so this is why the idea is unlikely to be adopted. But it would be great if someone were to implement it now anyway, and then it might make it into the next language standard. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org//mailman/listinfo/haskell-prime
Re: preemptive vs cooperative: attempt at formalization
John Meacham [EMAIL PROTECTED] wrote: In a concurrent implementation, a thread performing an infinite loop with no IO or interaction with the outside world can potentially stall switching to another thread forever, in FP, we usually denote an infinite loop by _|_. so I think the first difference would be: By infinite loop, you mean both non-terminating, and non-productive. A non-terminating but productive pure computation (e.g. ones = 1:ones) is not necessarily a problem. Why? Because ultimately the demand that forces production of the infinite data structure must come from somewhere, and that somewhere must essentially be I/O. (The only alternative consumers are terminating pure (no problem), non-terminating productive pure (so look upward to its demand), or an unproductive non-terminating computation, which brings us full circle.) It is a curious artifact that in certain multi-threaded implementations, a non-terminating non-productive thread does not make the entire system unproductive, but I don't think this is a behaviour anyone would want to rely on. I would say such a program has a bug, and the threaded RTS is just masking it. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: preemptive vs cooperative: attempt at formalization
Simon Marlow [EMAIL PROTECTED] wrote: By infinite loop, you mean both non-terminating, and non-productive. A non-terminating but productive pure computation (e.g. ones = 1:ones) is not necessarily a problem. That's slightly odd terminology. ones = 1:ones is definitely terminating. (length ones) is not, though. Well, the expression ones on its own is non-terminating. So if you say putStrLn (show ones), it doesn't just sit there doing nothing. This infinite computation produces an infinite output. So the fact that it is non-terminating is irrelevant. I may very well want a thread to do exactly that, and even with a cooperative scheduler this is perfectly OK. Other threads will still run just fine. The only time when other threads will *not* run under cooperative scheduling is when the non-terminating pure computation is *also* unproductive (like your length ones). Maybe you could expand on in what sense you mean non-terminating, and what productive means? I'm using productive to mean it generates a WHNF in finite time, even if the full normal form takes infinite time. Is there something we need to worry about here? No, I don't think so. John was attempting to formalise an observable difference between scheduling strategies, in much the manner that one sees the strictness of functions being defined. I am pointing out that the situation with threads is not analogous. f _|_ == _|_-- function is strict f _|_ /= _|_-- function is non-strict If you consider f to be the scheduler, and its arguments to be all available threads, then schedule threads | any (==_|_) threads == _|_ means we have a cooperative scheduler. The converse schedule threads | any (==_|_) threads =/= _|_ means we have a preemptive scheduler. The argument John was making is that this is a useful distinguishing point to tell whether your concurrent implementation is cooperative or preemptive. My argument is that, even if you can distinguish them in this way, it is not a useful distinction to make. Your program is simply wrong. If you have a sequential program whose value is _|_, your program is bad. If you execute it in parallel with other programs, that does not make it any less bad. One scheduler reveals the wrongness by hanging, another hides the wrongness by letting other things happen. So what? It would be perverse to say that the preemptive scheduler is semantically better in this situation. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
FD use cases (was Re: postponing discussion on exceptions and deepSeq)
isaac jones [EMAIL PROTECTED] wrote: Ross has asked for use cases for functional dependencies and so far has only two replies. Surely there are those on this list who have use of functional dependencies? Personally, I have never used FDs, but I recall some discussion we had in the Hat tracing project about the possibility of using them to solve a problem we had. (In the end, I think we decided it was either too complex, or the particular FD use case was not supported by any compiler.) The idea was to drop from traced computations down to the original computations (unwrap), and lift them back up again (wrap), in order to run trusted code at the original speed. This class looks something like class Wrap a b | a - b, b - a where wrap :: a - R b unwrap :: R b - a Nothing too unusual I'm sure. But there are some subtleties to do with the way this class interacts with other classes. A sketch of these is given in a short memo, attached to the wiki under Use Cases at http://hackage.haskell.org/trac/haskell-prime/wiki/FunctionalDependencies The relevant section is 3.2. One interesting thing to note for the FD discussion is the need/possibility of defining the same multi-parameter class at several different kinds. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: FFI, safe vs unsafe
Simon Marlow [EMAIL PROTECTED] wrote: I thought yhc supported unboxed values, so a loop like count 0 = 0 count n = count (n - 1) count 10 could block the runtime (assuming it was properly unboxed by the compiler) since it never calls back into it and is just a straight up countdown loop? are we talking about the same compiler? YHC is fully interpreted, has no unboxed types, and AFAIK it is impossible to write any code that doesn't get preempted after a while. Indeed. But unboxing is not the issue - the main reason is that yhc cannot currently compile that code into a loop - jumps only go forwards in the bytecode, never backwards. The only possible bytecode representation of a loop is as a recursive call, which immediately presents an opportunity to insert a yield. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
concurrency (was Re: important news: refocusing discussion)
Tomasz Zielonka [EMAIL PROTECTED] wrote: It may be relevant for this discussion: I believe I reimplemented STM, including retry and orElse, on top of old GHC's concurrency primitives. http://www.uncurry.com/repos/FakeSTM/ Perhaps it could serve as a drop-in replacement for STM in haskell compilers which don't implement STM directly. Nice idea. But your code already uses a whole heap of Haskell extensions which may or may not make it into Haskell'. monad transformer lib (requires MPTC) exceptions dynamically extensible exceptions deriving non-standard classes extended newtype deriving pattern guards Certainly, no compiler other than GHC currently implements all of these extensions. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
concurrency (was Re: important news: refocusing discussion)
Simon Marlow [EMAIL PROTECTED] wrote: The portable interface could be Control.Concurrent.MVar, perhaps. I don't really understand the problem, maybe I'm missing something. I thought the idea would be that a thread-safe library would simply use MVar instead of IORef. I was misled by several people's hand-waving assertion that, provided you used MVars correctly, there would be no synchronisation problems. But no-one had yet defined what correct meant. I kind of assumed they meant you could write concurrent threaded code (with only some minor restrictions) and have it work in a single-threaded implementation without change. This seemed like a pretty strong (and dubious) claim to me. But now I see you are actually saying something quite different. (And I recall some discussion on these points from a few months ago.) * IORef is inherently thread-unsafe, and so we should eliminate IORefs from the language. * One can write single-threaded code using MVars instead of IORefs, and it will be safe on a multi-threaded implementation. The latter point is quite the opposite of what I thought was being proposed. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Concurrency (was: RE: Re[2]: important news: refocusing discussion)
Simon Marlow [EMAIL PROTECTED] wrote: (a) we're going to standardise concurrency anyway Well, but that only begs the question, what *kind* of concurrency are we going to standardise on? e.g. Will we admit all variations of scheduling (co-operative, time-slice, and pre-emptive)? (b) it is unlikely that Hugs or JHC will implement concurrency even if it goes into the standard Now this is something that puzzles me. I was under the impression that Hugs already implements concurrency, using pretty much the same APIs as ghc. I'd also like to know a bit more about jhc's position here. Is it just that JohnM wants to keep his compiler pure and free from having a runtime-system? Or are there other issues? Yes there are several ramifications of this decision, but none of them are technical. As I see it, we either specify Concurrency as an addendum, or NoConcurrency as an addendum, and both options are about the same amount of work. There are certainly technical questions. If Hugs's implementation of concurrency is not concurrency after all, on what basis do we make that determination? Why is a definition of concurrency that encompasses both ghc and Hugs models unacceptable? Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: important news: refocusing discussion
John Goerzen [EMAIL PROTECTED] wrote: On Fri, Mar 24, 2006 at 11:07:53AM +, Malcolm Wallace wrote: I assume that since a non-concurrent implementation has only one thread, that thread will be trying to MVar-synchronise with something that does not exist, and hence be blocked for ever. Not necessarily. An MVar is a useful tool in place of an IORef. It works well when a given hunk of code is used in a threaded program, but it also works well in a non-threaded program. If they are used correctly, there is no problem. Your final sentence is the one that I want to emphasise. What does it mean to use an MVar correctly, such that one can avoid blocking in a non-threaded implementation? Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
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: Infix expressions
[EMAIL PROTECTED] (Donald Bruce Stewart) writes: Yes, this is _exactly_ the kind of thing to add to the Idioms page of the wiki, here: http://www.haskell.org/haskellwiki/Category:Idioms So if anyone knows of an interesting Haskell trick, and wants to write about it, add a page! It is not entirely clear _how_ to add a page hanging off Idioms. When you click on Edit this page, the text edit box contains only a single word: [[Category:Haskell]], and no visible record of the existing text. Rather confusing, and there is no link to add a new page or similar. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: the dreaded offside rule
Simon Marlow [EMAIL PROTECTED] wrote: Here's another couple that just occurred to me: f x | let y = x = y f x = case x of _ | let y = x - y granted these are unlikely to occur in practice. Are these Haskell'98? I'm afraid I don't understand how a let binding (without in) can occur in a guard for a function decl or case branch. In Ben's examples, the vertical bar was not a guard, but the separator in a comprehension (although he omitted to show the surrounding brackets...) [ ... | let x, y :: T x = 3 y = 4, ... ] [ ... | let x = 3, ... ] Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Keep the present Haskell record system!
Ross Paterson [EMAIL PROTECTED] wrote: On Wed, Mar 01, 2006 at 08:26:14AM +, Henrik Nilsson wrote: I'm increasingly convinced that the records should be left alone for Haskell', possibly modulo some minor tweaks to polish the system. Yes, no alternative candidate is available (specified, implemented, used). Well, there _are_ some alternatives that have been specified and implemented e.g. TREX in Hugs, and experimental languages like Daan Leijen's Morrow. But the main reason I can see for there being little use of these candidates, is that they are not compatible with current Haskell. Thus, although I agree that none is ready for inclusion in Haskell-prime, I think we do need some mechanism for experimental records to be tried out in real Haskell implementations before the Haskell-double-prime committee starts its work. Perhaps, taking the extensions-layering idea, we could say that the current named-fields are encapsulated as an extension that is part of the standard. Implementations could then introduce a flag to switch off this particular extension (current records) in conjunction with flags to switch on experimental replacements. This would give a certain flexibility for users to play with different systems, and the breaking of compatibility would be explicitly notated, either by the build options, or using a proposal like ticket #94. My suggestion is that we separate out everything from the Report to do with named-field records into something like a self-contained addendum. Whilst still an official part of the language standard, it might also be marked as a possibility for future removal. This would make it clear what parts of the language could be changed (or re-used without conflict) in an alternative records system. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Export lists in modules
Johannes Waldmann [EMAIL PROTECTED] wrote:
For reference, in Java, ... there's nice syntactic sugar for looping
over collections: CollectionE c; for (E item : c) { ... }
I'd say this is an example of moving away from a left-biased
representation, or at least freeing the programmer from having
to think about it).
In Haskell, this is called 'fmap'. :-)
Regards,
Malcolm
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
Re: Export lists in modules
Johannes Waldmann [EMAIL PROTECTED] wrote: In Haskell, this is called 'fmap'. :-) OK, then show me an instance Functor Set so that I can use it :-) instance Function Set where fmap = Data.Set.mapMonotonic Ok, so this introduces a precondition on the function being mapped, so there is a proof obligation on the programmer. But if contexts-on-datatypes worked correctly, data Set a = Ord a = then even the real map from Data.Set: map :: (Ord a, Ord b) = (a - b) - Set a - Set b could be an instance method of Functor. (Because the Ord constraints would be packaged inside the Set type, rather than needing to be explicit.) Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: instance Functor Set, was: Re: Export lists in modules
But if contexts-on-datatypes worked correctly, data Set a = Ord a = then even the real map from Data.Set: map :: (Ord a, Ord b) = (a - b) - Set a - Set b could be an instance method of Functor. I'd love that. But I don't quite understand: do you think this is/should be possible with: current Haskell? Haskell-Prime? Current ghc (what extensions)? It is not possible currently, because of the H'98 language definition. I do think it would be nice to fix this in Haskell-prime. However, although the idea is somewhat related to Polymorphic Components http://hackage.haskell.org/trac/haskell-prime/wiki/PolymorphicComponents there is no specific proposal about this issue on the wiki. (It was mentioned on some mailing list in the last couple of months, but I can't find the thread now.) By working correctly I mean that: it is a wart in Haskell'98 that you can declare a datatype to require some class constraints on contained elements, but that these extra constraints do not really buy you any expressive power. They just force you to repeat the same context decl on every function that uses such a type. Ideally, the data decl should be more like an alias, capturing the constraints as part of the semantics associated with the type, so that you don't need to mention the constraints at every usage location of the type. Of course, there are some details to work out, about where you can validly omit the constraints, and where they are still required. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell'-private] pragmas and annotations (RE: the record system)
Simon Marlow [EMAIL PROTECTED] wrote:
How does ENCODING work for a UTF-16 file, for example?
We don't know the file is UTF-16 until we read the ENCODING pragma,
and we can't read the ENCODING pragma because it's in UTF-16.
Use the same type of heuristic as XML uses (for instance).
* If the first three bytes of the file are {-#, then keep reading in
ASCII/Latin-1/whatever until you discover an ENCODING decl (or not).
* If the first six bytes of the file are one of the two possible
UTF-16 representations of {-#, then assume UTF-16 with that
byte-encoding until we find the ENCODING decl. (A missing decl in
this case would be an error.)
* If the first twelve bytes of the file are a UCS-4 representation of
{-# then ... you get the picture.
* For UTF-16 and UCS-4 variations, you must also permit the file to
begin with an optional byte-order mark (two or four bytes).
* Otherwise, there is no ENCODING pragma, so assume the implementation
default of {ASCII, Latin-1, UTF-8, ...}.
I know it's pretty horrible, but it seems to work in practice for the
XML people. In practice, the ENCODING decl is most needed for those
that have ASCII as a subset - one could argue that the heuristic tells
you the UTF-16 and UCS-4 variations without needing a pragma. (But
then, how would you guarantee that the first three characters in the
file must be {-# ?)
Regards,
Malcolm
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
Re: Export lists in modules
Ketil Malde [EMAIL PROTECTED] wrote: I would solve this problem by reducing the Prelude to just a core. List function could go, for example, (mostly) into Data.List. If this means that you must import Data.List almost everywhere, this won't change anything - only add yet another import to every file. People often overlook the useful facility of the module system to group multiple common imports into a single re-exporting super-module. With my proposal, you would simply replace the implicit import Prelude with an explicit import Prelude.Standard (or use a build flag like -fimplicit-prelude, or +98). The idea is that backward compatibility with the old Prelude is preserved as much as possible, but the experimental ability to replace or remove parts of the Prelude is gained. Over time and through experience, a new consensus about what should be included might emerge. I know most - if not all - of my modules use lists, but just in case, I checked with the darcs sources - 95 of 107 source files appear to use lists. Ignoring the : and ++ operators (looking for null, map, and filter) the count is 76 files. Some data-structures people (e.g. Chris Okasaki) are of the opinion that lists tend to be over-used (because they are built-in), when other datatypes might be much more appropriate. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Export lists in modules
Simon Marlow [EMAIL PROTECTED] wrote: However, I would be equally happy to combine type/newtype/data into a single keyword for exports. for the record, I am in favour of tagging export specifiers with 'class' or 'type' (using 'type' for all type constructors, in light of yours and John's points). For the sake of avoiding confusion, perhaps we should choose a keyword (or better, a reserved identifier with no meaning outside of the export/import list) that is none of type, data, or newtype? How about datatype, tycon, or the like? Then it would be clearer that there is no relationship between the way the type is defined, and how its namespace is notated in the export list. If modules are to contain interfaces, I don't think extending the export list is the way to do it. I'd rather do something like: -- modules M exports class Eq a where (==) :: a - a - Bool data T :: * - * f :: T - Int mkT :: Int - T where -- implementation below here -- But, apart from adding fuller signatures than I proposed, that is exactly the same as an export list, modulo some very minor syntactic differences! Not a proposal by any means, and I don't think that Haskell' should tackle this, but this seems the right direction to me. I agree that full interface specs are beyond Haskell'. JPBernardy's argument that tools (Haddock, compilers) can already extract the interface automatically is quite persuasive too. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Re[2]: Export lists in modules
Bulat Ziganshin [EMAIL PROTECTED] wrote: MW With my proposal, you would simply replace the MW implicit import Prelude with an explicit import MW Prelude.Standard import Prelude ($) can't solve this problem? One of the problems with the current mechanism for overriding Prelude definitions, is that every module that /uses/ such an entity must also explicitly hide the original Prelude: module NewMap (map) where import Prelude () map = ... module User where import Prelude hiding (map) import NewMap By forcing the H' Prelude to be explicit by default, it removes this nuisance. Instead, you just change which Prelude you import. module Prelude.NewMap (module Prelude.Haskell98, map) where import Prelude.Haskell98 hiding (map) map = ... module User where import Prelude.NewMap Note that, my suggestion is that compilers which continue to support the Haskell'98 language will continue to give you the original implicit Prelude in that mode. It is only Haskell-prime programs that would be affected. Yes, many trivial programs would acquire one extra import decl - is that such a big deal? Especially for beginners, I'm thinking that some teachers might /prefer/ to remove lots of the current Prelude, and build up students' knowledge gradually, by allowing them to write map, fold, curry, etc for themselves, without name clashes. Later, they could switch on more of the language, like numeric classes, by need. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Export lists in modules
John Meacham [EMAIL PROTECTED] wrote: Malcolm Wallace wrote: There is also the issue that we might adopt the proposal to allow (and perhaps eventually, to require) type signatures on export lists. All I have to say is please, no to the requiring part that is. I don't seriously propose for haskell-prime that signatures should be required on exports. Just permitting them would be a large and useful step up already. But the argument about whether to specify a module interface completely and explicitly in the source file might arise again in the next standardisation process, where I can see the balance might tip more in favour of compulsion. I totally think type signatures in export lists should be allowed optionally with the exact same meaning as if they were specified at the top level within the module. At the moment, only one type signature is permitted per entity (except for FFI foreign exports, where the exported signature may be more specific than the definitional signature). My proposal is that the normal export list can have signatures /in addition to/ the definitional signature, but that if there are thus two signatures for an entity, they must be identical. This is to prevent the case where one modifies the definition of the function, making it more general, but forgets to modify the corresponding export. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Export lists in modules
Johannes Waldmann [EMAIL PROTECTED] wrote: Sounds like the perfect example to illustrate the point that information shouldn't be doubled in the first place. Yes, I suppose one could argue that. Can you say why you want the type in the export list? As a compact description of the module interface. Many people already do it, except that the signature is in a comment, and therefore not checked. Or really, why you want an export list at all? An explicit interface would be useful for many purposes besides machine-checked documentation. For instance, it could be used to eliminate the hs-boot or hi-boot files used by some compilers when dealing with recursive modules. Presumably because it constitutes the module's interface, but it is an ad-hoc thing (one interface per module). We already have the concept of type class which gives us re-usable interfaces. Isn't that much better? The near correspondence between type classes, modules, and records, is well-known, yet still they are separate concepts in Haskell. Perhaps one day they will be merged. However, in the meantime, for both records and classes one is forced to give a signature to the contained elements/methods. For consistency, modules should do the same... Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Export lists in modules
Simon Peyton-Jones [EMAIL PROTECTED] wrote: | I don't seriously propose for haskell-prime that signatures should | be required on exports. Just permitting them would be a large and | useful step up already. If this is to be a serious proposal, someone had better think what to do about classes, data types, instances and so on. As far as I can see, there is very little to change. Here is a concrete proposal. A qvar in an export list may optionally have a type signature. A qtycon or qtycls in an export list may optionally have an annotation saying whether it is a type, newtype, data, or class. Instances cannot be mentioned in export lists, and this does not change. export - qvar | qtycon [ (..) | ( cname_1, ... , cname_n ) ] (n=0) | qtycls [ (..) | ( var_1, ... , var_n ) ] (n=0) | module modid becomes export - qvar [ :: type ] | [type]qtycon | [newtype] qtycon [ (..) | ( cname_1, ... , cname_n ) (n=0) | [data]qtycon [ (..) | ( cname_1, ... , cname_n ) (n=0) | [class] qtycls [ (..) | ( var_1, ... , var_n ) (n=0) | module modid As far as import entity lists are concerned, we permit an optional annotation for type synonyms, newtypes, datatypes, and classes: import - var | tycon [ (..) | ( cname_1, ... , cname_n ) ] (n=0) | tycls [ (..) | ( var_1, ... , var_n ) ] (n=0) becomes import - var | [type]tycon | [newtype] tycon [ (..) | ( cname_1, ... , cname_n ) ] (n=0) | [data]tycon [ (..) | ( cname_1, ... , cname_n ) ] (n=0) | [class] tycls [ (..) | ( var_1, ... , var_n ) ] (n=0) Anyone see any difficulties? Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Pragmas for FFI imports
On Fri, Feb 17, 2006 at 01:45:27AM +0200, Einar Karttunen wrote: 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. Just to note that nhc98 has had the pragma FFI_LIB for a long time (under the name OPTIONS_LINK). Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Export lists in modules
Jared Updike [EMAIL PROTECTED] wrote: I am not sure if this has been mentioned before, but something I would really find useful is the ability to tell Haskell to export everything in a function except for some named functions. No one has responded so ... I believe some people (perhaps on another list) have been advocating the addition of Java-style public/private modifiers on function definitions, to indicate whether they are exported or not. (A truly horrible idea in my opinion!) module Module hiding ( list, of, things, not, to, export ) where I quite like this for its minimal syntactic overhead, and backward compatibility. There is a slight worry that it would be too easy to overlook the hiding keyword when reading a module, leading to confusion. There is also the issue that we might adopt the proposal to allow (and perhaps eventually, to require) type signatures on export lists. If so, then it would be kind of ridiculous to have interface signatures only for the things you are /not/ exporting! Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Re[2]: Tuple-like constructors
Robert Dockins [EMAIL PROTECTED] writes: instance (Bin a,Bin b,Bin c,Bin d) = Bin (a,b,c,d) See the problem? Sooner or later (probably sooner) I'll get tired of typing. I have to write down an 'instance' declaration for each value of n. Clearly this can't generalize to all n. There has been a suggestion that the 'deriving' mechanism be de-coupled from the datatype declaration. Together with a generic default definition, that means you could write something like deriving Bin for () and hence not need to write the tedious instance header yourself, since the compiler can easily infer it. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: The dreaded M-R
Simon Marlow [EMAIL PROTECTED] writes: Given the new evidence that it's actually rather hard to demonstrate any performance loss in the absence of the M-R with GHC, I'm attracted to the option of removing it in favour of a warning. As another data point, today for the first time I received an error (not a warning) from ghc about the M-R: Ambiguous type variable `a' in the constraint: `Ord a' arising from use of `Data.Set.insert' at Pretty.hs:28:11-20 Possible cause: the monomorphism restriction applied to the following: addToSet :: a - Data.Set.Set a - Data.Set.Set a (bound at Pretty.hs:28:0) Probable fix: give these definition(s) an explicit type signature or use -fno-monomorphism-restriction So, without the M-R or a type signature, my code is OK. The proposal to accept this code but produce an optional warning is (I think) better than the current error. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: separate class and type namespace
Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] writes: I've always liked the idea of saying 'class C' or 'type T' in import/export lists. Type signatures too should be allowed in export lists. Both ideas already noted at http://haskell.galois.com/trac/haskell-prime/wiki/ModuleSystem Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: The dreaded M-R
[EMAIL PROTECTED] writes: Nhc didn't use to implement the M-R (maybe it does now). When porting code to nhc this caused a few code changes. Perhaps 10 lines out of 1 when I tried the Bluespec compiler. So my gut feeling is that the M-R is a rare beast in practise. I can confirm that nhc98 (and hence yhc) still does not implement the M-R. I haven't noticed any particular performance problems in code compiled by nhc98 that were down to a consequent loss of sharing. (But I can't claim to have explicitly looked.) But as Lennart says, you do get occasional type errors which mean you need to restructure your code. Almost always, these are local bindings, e.g.: Context required in LHS pattern is an error emitted for code like: do (x,y) - something complicated and numeric ... and the fix is do xy - something complicated and numeric let x = fst xy y = snd xy ... As I recall, there were about 4-5 of these I needed to fix in the entire nofib suite. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: The dreaded M-R
Simon Marlow [EMAIL PROTECTED] writes: On 26 January 2006 09:59, John Hughes wrote: The solution I favour is simply to use *different syntax* for the two forms of binding, I wonder if there's an alternative solution along these lines: - We use ParialTypeSignatures to make bindings monomorphic: eg. x :: _ x = (+1) I agree with Simon that two forms of binding feels like a heavyweight solution. Variable-binding is just such a fundamental thing, that introducing a second form would need exceptional justification IMO. However partial type signatures seem like a very nice alternative. Just as currently, the decision on monomorphising a binding is based on the type signature (its presence, absence, or form). Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
