Re: Comment Syntax
On 2/2/06, Henrik Nilsson [EMAIL PROTECTED] wrote: Hi all,To corroborate Wadler's law further.:-) Josef wrote: Oh yes, it does happen that a single line comment begins with a special symbol. It has happened to me on several occations when using haddock annotation to my source code. It is all to easy to forget that extra space. With incomprehensible error messages as a result.But might that not just mean that the error messages ought to beimproved?I don't know how hard that would be, but after having played around a bit with GHC, the messages I get are either of the typeparse error on input '--|' or of the type Not in scope: `--'(followed by lots of other stuff not being in scope etc). If this really is a big problem for beginners, it would not seemtotally infeasible to add some special code that helpfully suggeststhat a space perhaps ought to be inserted?Or have you seen significantly worse error messages? My point here was not that the error messages was that terrible. I just wanted to point out to Manuel that it does happen that single line comments start with a symbol. Which makes the current comment syntax somewhat awkward. Cheers,/Josef ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Priorities
For the last few days, my mail-box has been full of mail about the M-R, lazy pattern matching, n+k patterns, comment syntax--it's just like the good old days! And that worries me. Each of these topics is a snake pit--a tricky area of language design, with many alternative possibilities and no clear winner. As such, they make great discussion topics--if you want to start a heated argument, just propose a change to one of these (mea culpa)! We've also been discussing most of them for sixteen years. Of course, it's worth raising them from time to time, in case new insight means we can find a solution that is clearly much better than we found before. But the risk is that we go over the same old arguments, perhaps the consensus is slightly different this time, we make a change to the language, and who knows, next time the language is revised, maybe it'll change back again! That's destructive. We shouldn't change these things unless we can very, very clearly make an improvement. The fact is, we've lived with the present design for over a decade in each case, and we can live with it for another decade if we have to. The problem with Haskell 98 is not its warts--it offers a very pleasant programming experience despite them. The problem with Haskell 98 is that it *lacks* features which have become absolutely essential to Haskell programmers today. Those features are what really *need* discussion and energy spent on them. What are the top priorities for inclusion in a new standard? How can we identify them? I have some personal favourites, of course: ST state threads--absolutely essential. - but how to distinguish strict and lazy state? The present solution--importing a different module--sucks. Monad transformers - dramatically simplify constructing new monads - not a language feature in themselves, but demand extensions to work well. Multi-parameter classes with functional dependencies - used everywhere... for example in monad transformers... so *must* be included this time - omitted from Haskell 98 because the right design wasn't clear - it's still unclear! Functional dependencies *in some form* are essential, but associated types and datatypes look nicer in many ways! - is it too late, in practice, to replace fundeps by something else? How will we know? If we are to standardize on associated types instead, we need a major effort to *make sure* all important applications of fundeps can be represented. How will we organize that? Type system extensions--at least existential and rank-2 types. - should we go further? How will we know? My favourites may not be your favourites. How will we know what the most important features to discuss are? Here's a thought: Wouldn't it be nice if the most important Haskell tools and libraries, were actually written in standard-compliant Haskell'? One such tool is wxHaskell--named by 19% of Haskell users in my survey, it's the de facto standard GUI toolkit. wxHaskell makes essential use of existential types in its interface, a strong reason for including them in Haskell'. It also uses multi-parameter classes and functional dependencies, although much less heavily. What other tools must be supported by Haskell'? What other extensions must be present to support them? What issues remain before those extensions are standardized, and thus frozen in stone for many years to come? I'd like to see clearer priorities and a more focussed discussion--maybe the Wiki can be used to help? John ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Priorities
On Thu, 2006-02-02 at 11:38 +0100, John Hughes wrote: One such tool is wxHaskell--named by 19% of Haskell users in my survey, it's the de facto standard GUI toolkit. wxHaskell makes essential use of existential types in its interface, a strong reason for including them in Haskell'. It also uses multi-parameter classes and functional dependencies, although much less heavily. My priorities for Gtk2Hs (the second most popular GUI toolkit in John Hughes's survey) are very similar. We have adopted wxHaskell's style of attributes which is what uses existential types. I should not that in both cases the use of existential types is not essential. It was done that way only because the symbol that people wnated to use ':=' happens to be a constructor operator. If '=:' were used instead then existential construcotr types would not be necessary. We might make use of MPC +FunDeps if they were standard but it is not at all crucial. Our main concern is namespace issues. As I've said before, Gtk2Hs is a very large library but with the current module system it must export a flat name space. wxHaskell solves this with somewhat of a hack. It defines many multi-parameter type classes to allow the same name to be used by different widgets (with hopefully the same general meaning). I think this would be better solved by using qualified names. We have been trying hard to avoid non-H98isms so that we can hope to work with compilers other than ghc. So having these features standardised would allow us to present a better api and allow us to remain portable. What other tools must be supported by Haskell'? What other extensions must be present to support them? What issues remain before those extensions are standardized, and thus frozen in stone for many years to come? Another gripe is in the FFI, in the handling of include files. The method preferred by GHC and the method preferred by the FFI spec are rather at odds. GHC prefers the file to be specified on the command line while the FFI spec prefers it to be specified in each and every FFI import declaration. If one does the latter then GHC refuses to inline foreign calls across modules. Other mundane but useful things include the ability to specify different FFI import decls for different platforms without using #ifdef's. This would allow a program using a Gtk2Hs GUI to be compiled to bytecode with YHC and run on different platforms, rather than having to be built differently on each platform. (The issue is that even for portable C libs, the calling convention and symbol names can differ across platforms. This is true to a minor degree with the Gtk+ library.) Duncan ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
RE: MPTCs and functional dependencies
I'm confident that it is premature to standardise functional dependencies at this stage, very useful though they are. If you doubt me, read the JFP journal submission that Martin Sulzmann and Peter Stuckey and I have been working on. http://research.microsoft.com/%7Esimonpj/papers/fd-chr Fundeps are very, very tricky. My own view is that associated types are a more promising way forward at the programming language level. They are a little less expressive than fundeps, I think, but a whole lot less tricky. But we don't have an implementation of them yet, so we can hardly standardise them! Multi-parameter type classes, yes. Functional dependencies, no. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of | Ross Paterson | Sent: 02 February 2006 11:25 | To: haskell-prime@haskell.org | Subject: MPTCs and functional dependencies | | On Thu, Feb 02, 2006 at 11:38:07AM +0100, John Hughes wrote: | The problem with Haskell 98 is that it *lacks* features which | have become absolutely essential to Haskell programmers today. Those | features are what really *need* discussion and energy spent on them. | | [...] | | Multi-parameter classes with functional dependencies |- used everywhere... for example in monad transformers... so | *must* be included this time |- omitted from Haskell 98 because the right design wasn't clear |- it's still unclear! Functional dependencies *in some form* | are essential, but associated types and datatypes look nicer | in many ways! |- is it too late, in practice, to replace fundeps by something | else? How will we know? If we are to standardize on associated | types instead, we need a major effort to *make sure* all | important applications of fundeps can be represented. How will | we organize that? | | I agree that MPTCs are much less useful (though not completely useless) | without something like FDs or associated types. But the specification | of FDs is far from clear: the system described in Mark's paper is quite | a bit weaker than what is implemented by GHC and (more shakily) by Hugs. | It seems that associated types aren't ready yet, but I don't think FDs | are either, accustomed as people are to them. | | I have another worry about MPTCs. They require require relaxations on | the form of instances (FlexibleInstances on the wiki), which in turn | require relaxations on contexts and thus deferred context reduction (see | FlexibleContexts). The result is that missing instances get reported | later than they do now. MPTCs are very useful and probably necessary, | but there is a cost. | | ___ | Haskell-prime mailing list | Haskell-prime@haskell.org | http://haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
RE: Test performance impact (was: The dreaded M-R)
On 02 February 2006 09:52, John Hughes wrote:
Summary: 2 programs failed to compile due to type errors (anna,
gg).
One program did 19% more allocation, a few other programs
increased
allocation very slightly (2%).
pic +0.28% +19.27% 0.02
Thanks, that was interesting. A follow-up question: pic has a space
bug. How long will it take you to find and fix it?
I just tried this, and it took me just a few minutes. Compiling both
versions with profiling, for the original:
total time =0.00 secs (0 ticks @ 20 ms)
total alloc = 11,200,656 bytes (excludes profiling overheads)
COST CENTREMODULE %time %alloc
chargeDensity ChargeDensity 0.02.5
accumChargeChargeDensity 0.0 13.5
relax Potential 0.0 31.4
correctPotential 0.05.0
genRandUtils 0.01.0
fineMesh Utils 0.02.4
applyOpToMesh Utils 0.0 12.7
=: Utils 0.02.3
pushParticle PushParticle 0.0 16.1
timeStep Pic0.0 11.0
and with the monomorphism restriction turned off:
total time =0.02 secs (1 ticks @ 20 ms)
total alloc = 12,893,544 bytes (excludes profiling overheads)
COST CENTREMODULE %time %alloc
pushParticle PushParticle 100.0 20.8
chargeDensity ChargeDensity 0.02.2
accumChargeChargeDensity 0.0 18.0
relax Potential 0.0 27.3
correctPotential 0.04.4
fineMesh Utils 0.02.1
applyOpToMesh Utils 0.0 11.1
=: Utils 0.02.0
timeStep Pic0.09.5
So, ignoring the %time column (the program didn't run long enough for
the profiler to get enough time samples), we can see the following
functions increased their allocation as a % of the total:
pushParticle, accumCharge
Looking at the code for accumCharge:
accumCharge :: [Position] - [MeshAssoc]
accumCharge [] = []
accumCharge ((x,y):xys) =
[((i ,j ) , charge * (1-dx) * (1-dy))] ++
[((i',j ) , charge * dx * (1-dy))] ++
[((i ,j') , charge * (1-dx) * dy)] ++
[((i',j') , charge * dx * dy)] ++
accumCharge xys
where
i = truncate x
i' = (i+1) `rem` nCell
j = truncate y
j' = (j+1) `rem` nCell
dx = x - fromIntegral i
dy = y - fromIntegral j
Now, because I know what I'm looking for, I can pretty quickly spot the
problem. I had to look at the definition of MeshAssoc to figure out
that the result type of this function forces i to have type Int, yet it
is used elsewhere as the argument to fromIntegral, where if i is
overloaded will be defaulted to Integer. When I give type signatures to
i and j (:: Int), the allocation reduces.
The pushParticle function has an identical pattern. Fixing these two
functions brought the performance back to the original. But I've also
changed the semantics - the author might have *wanted* i at type Integer
in the definition of dx to avoid overflow, and the monomorphism
restriction had prevented it.
I suppose you could ask how you'd find the problem if you didn't know
what to look for. So I added some more annotations:
i = {-# SCC i #-} truncate x
i' = {-# SCC i' #-} (i+1) `rem` nCell
j = {-# SCC j #-} truncate y
j' = {-# SCC j' #-} (j+1) `rem` nCell
dx = {-# SCC dx #-} x - fromIntegral i
dy = {-# SCC dy #-} y - fromIntegral j
and the profiling output shows:
i ChargeDensity100.06.8
j ChargeDensity 0.06.8
chargeDensity ChargeDensity 0.02.2
accumChargeChargeDensity 0.03.9
relax Potential 0.0 27.2
...
So this pretty clearly identifies the problem area (although the figures
don't quite add up, I suspect the insertion of the annotations has
affected optimisation in some way).
Still, you could argue that it doesn't actually tell you the cause of
the problem: namely that ij are being evaluated twice as often as you
might expect by looking at the code. This is what the compiler warning
would do, and I completely agree that not having this property evident
by looking at the source code is a serious shortcoming.
And how
Re: Priorities
On Thu, Feb 02, 2006 at 11:38:07AM +0100, John Hughes wrote: The problem with Haskell 98 is that it *lacks* features which have become absolutely essential to Haskell programmers today. Those features are what really *need* discussion and energy spent on them. [...] I'd like to see clearer priorities and a more focussed discussion--maybe the Wiki can be used to help? As a small part of that, the tickets page has a tentative list of probably yes changes. Personally, I'm not sure about caseless underscore, concurrency, natural numbers and parallel list comprehensions. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: MPTCs and functional dependencies
Dear all, Simon PJ wrote: Multi-parameter type classes, yes. Functional dependencies, no. My experience is that even with very simple applications of MPTCs, I often end up needing functional dependencies to make things work. Thus, if my hunch is right, and other people have a similar experience, my fear would be that omitting FDs or something similar would result in a Haskell' standard that ends up being out of date even before it is finalised, in that a large number of real world applications and libraries would fail to be standard compliant and could not easily be adapted to be. I think that would be very unfortunate, even though I do agree that the Haskell' effort should strive to be as conservative as possible. Might it be possible to at least allow some simple forms of FDs that would cover the most common cases, e.g. like what's described in Mark's original paper? I personally would not be too worried about adopting a possibly non future-proof solution in this respect, as I would expect that the amount of code that would have to be change would be fairly small if some scheme like associated types later are adopted as a replacement. What would worry me is the lack of ANY functionality like FDs, as having to work without them means that code often would have to be too type specific, which in the end might result in lots of code duplication. Refactoring such code later would seem to be much more work (even if it might not be strictly necessary to do so, as the code would continue to work). But maybe other people have a somewhat difference experience, and feel that this is less of an issue than I believe it is? All the best, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re[2]: Comment Syntax
Hello Manuel, Thursday, February 02, 2006, 3:40:26 AM, you wrote: MMTC I am against such a change. The change would break existing software MMTC (eg, Yampa) and secondly I don't buy the main sources of MMTC confusion for beginners argument. The confusion arises only when a MMTC single line comment is used to uncomment a set of characters that start MMTC with a special symbol. That's a situation that doesn't arise that MMTC often. (I'd actually be very happy if the main sources of confusion fpr MMTC beginners where of such simple syntactic nature.) well, i'm as beginner was runned to this situation enough often 1) | is a special char 2) non-ascii chars are also treated by GHC as special, and i prefer to write comments in Russian ;) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re[2]: strict Haskell dialect
Hello John, Thursday, February 02, 2006, 4:24:06 AM, you wrote: It can, but so far it's really ugly to apply transformations to entire modules. A little syntactic sugar could be good there. JM module $hat.Foo(..) where JM ... JM could mean pass the entire module through the 'hat' function of TH. this JM would be a really cool feature a lot of rather complicated preprocessors JM (hat) could be implemented this way. well, i think even more - that TH by itself can substitute much of the better module system that we need. It can implement parametrization, conditional compilation, hiding. But it will require some more advanced syntax sugar. on the other side, even the existing TH facilities can be used to implement all these features and moreover - remain compatible with other Haskell compilers: module Implement where #ifdef GHC module = [d| #endif foo = ... var = ... #ifdef GHC |] #endif module Use where import Implement $(hat module) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re[2]: Wanted: local data, class, instance declarations
Hello John, Thursday, February 02, 2006, 6:03:06 AM, you wrote: Unfortunately, local instance declarations threaten the coherence property of type classes and principle types. See for example, ``Functional pearl: implicit configurations—or, type classes reflect the values of types'', Sect 6.1, for a bit of discussion. So, this extension would require a very carefully thought out proposal. JM Also, the need for it is questionable if we were to allow polymorphic JM components and newtype deriving. if your data acts differently then it JM should be a different type with a newtype and derive all the properties JM where it acts the same. if you want to do different things to the same JM data then packaging them up as values in a record with polymorphic JM components makes perfect sense and is more functional in nature. That JM class instances are global is a great feature of them, not a weakness. John, local definitions used in Generic Haskell (which you may don't know) and even in the SYB. are you really think that if we need two different algorithms of processing Identifier inside folds, then we should define two different Identifier types? -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re[2]: Test performance impact (was: The dreaded M-R)
Hello John, Thursday, February 02, 2006, 12:51:58 PM, you wrote: JH Let me make clear that what concerns me is not the impact of the M-R on JH space and time JH performance on average. What concerns me is the difficulty of debugging JH performance JH problems. may be it's better in such case to add to the compiler _optional_ warning about possible performance problems specially for programmers that seek such holes. and Haskell by itself will be elegant high-order language which don't bites newcomers with this really rare problem -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: fundeps syntax is ugly
Hello Johannes, Thursday, February 02, 2006, 2:17:42 PM, you wrote: JW When I first learned functional dependencies JW I remember I was really confused by their syntax. JW First, it is hard to find it defined: i should wrote this earlier, but nevertheless: Hugs documentation contains excellent introduction into the fundeps. i learned on it and never read any other papers. moreover, i recommended it to other ghc users, who was unhappy with current ghc docs Simon, may be it's the time to just steal this document section? i will don't say to anyone :) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
CHRs, was Re: MPTCs and functional dependencies
... read the JFP journal submission that Martin Sulzmann and Peter Stuckey and I have been working on. http://research.microsoft.com/%7Esimonpj/papers/fd-chr Has this list discussed using CHRs instead of fundeps? Jim ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: MPTCs and functional dependencies
Henrik Nilsson wrote: Dear all, Simon PJ wrote: Multi-parameter type classes, yes. Functional dependencies, no. My experience is that even with very simple applications of MPTCs, I often end up needing functional dependencies to make things work. As a user, I'll echo this. It seems to me that when you create a multi-parameter typeclass, there are often constraints among the different parameters that need to be expressed. As an example, consider writing a multi-parameter typeclass to capture the idea of being able to select an object out of an indexed collection (e.g. a list or an array). One dependency you'd like to have might be that the collection type determines the type of the item you're selecting (so that the type of the item can be inferred from the type of the collection). As a second data point, I looked at the monad transformer library. The multi-parameter classes MonadState, MonadError, MonadReader and MonadWriter all use functional dependencies among their parameters. I think monad transformers are a significant part of the motivation to include multi-parameter typeclasses. This, to me, implies that we need some answer for their use of functional dependencies. - Ravi ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: MPTCs and functional dependencies
On Thu, Feb 02, 2006 at 11:36:34AM -, Simon Peyton-Jones wrote: I'm confident that it is premature to standardise functional dependencies at this stage, very useful though they are. If you doubt me, read the JFP journal submission that Martin Sulzmann and Peter Stuckey and I have been working on. http://research.microsoft.com/%7Esimonpj/papers/fd-chr Fundeps are very, very tricky. My own view is that associated types are a more promising way forward at the programming language level. They are a little less expressive than fundeps, I think, but a whole lot less tricky. But we don't have an implementation of them yet, so we can hardly standardise them! Multi-parameter type classes, yes. Functional dependencies, no. Yeah, I have been coming to the same conclusion myself. it pains me a lot. (monad transformers! I need thee!) but its not like fundeps will go away, they will just still be experimental so it isn't the end of the world. My main reasons for feeling this way are that assosiated type synonyms seem to solve the problems fundeps were meant to solve, and the other uses seem to be various tricks in order to finagle the class system into giving a sort of type-level programming. which is cool, but it makes me think there is room for an actual type-level programming extension there somewhere. (user defined kinds + GADTs?) John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
[Fwd: Re: Haskell-prime Digest, Vol 2, Issue 6]
Hmm. Seems I missed sending this to haskell-prime. Sorry. /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ---BeginMessage--- Dear all, Simon PJ wrote: Now, someone can try to define a conservative version of FDs, as has been suggested; perhaps it could even be kind-of-isomorphic to associated types. Perhaps something *very* conservative would be enough for most applications. (It would hurt to standardise FDs if we think we're going to discard them subsequently, but if the spec was somewhat crisp maybe it would not hurt too much.) What about the FD Conditions as defined in the paper by Sulzman, Duck, Peyton-Jones and Stuckey you referred to? (Mark Jones original conditions + a so called bound variable condition). If those conditions are imposed, one gets sound, complete, and decidable type inference according to the said paper. I had a quick look at the monadic libraries and a vector space class in Yampa, and my impression is that the FDs used there would be compatible with the FD conditions. But I emphasize that's just an impression. Or are the FD conditions considered too restrictive? Clearly, as exemplified in the above paper, they do rule out a number of reasonable programs. But as long as the adopted version of FDs allow the basic usage of FDs for applications like monad transformers, I don't think I personally would be too unhappy. Best, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] ---End Message--- ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Test performance impact (was: The dreaded M-R)
On Thu, Feb 02, 2006 at 12:34:30PM -, Simon Marlow wrote: Still, you could argue that it doesn't actually tell you the cause of the problem: namely that ij are being evaluated twice as often as you might expect by looking at the code. Would not the entries count in the profile tip you off to this? The entries for i should be twice that for accumCharge, right? Andrew ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re[2]: fundeps syntax is ugly
Hello Bulat, Thursday, February 02, 2006, 3:48:45 PM, you wrote: JW When I first learned functional dependencies JW I remember I was really confused by their syntax. JW First, it is hard to find it defined: BZ Hugs documentation contains excellent introduction into the fundeps. namely chapter 7.1.1 in the http://cvs.haskell.org/Hugs/pages/hugsman/exts.html -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: ~ patterns
Am Mittwoch, 1. Februar 2006 01:32 schrieb Patryk Zadarnowski: [...] The proposal would be to remove the unary - altogether, and, instead, extend the lexical syntax of numeric constant to allow + and - prefix. Would this mean that (-x) is a section while (-1) isn't? That would be confusing. Apart from this, I would like to see the only unary operator of Haskell removed. [...] Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: strict Haskell dialect
Am Mittwoch, 1. Februar 2006 11:49 schrieb Bulat Ziganshin: [...] i had one idea, what is somewhat corresponding to his discussion: make a strict Haskell dialect. implement it by translating all expressions of form f x into f $! x and then going to the standard (lazy) haskell translator. the same for data fields - add to all field definitions ! in translation process. then add to this strict Haskell language ability to _explicitly_ specify lazy fields and lazy evaluation, for example using this ~ sign what it will give? ability to use Haskell as powerful strict language, what is especially interesting for real-world programmers. i have found myself permanently fighting against the lazyness once i starting to optimize my programs. for the newcomers, it just will reduce learning path - they don't need to know anything about lazyness Since laziness often allows you to solve problems so elegantly, I'm really scared of the idea of a Strict Haskell! :-( Is laziness really so unreal that real-world programmers have to see it as an enemy which they have to fight against? In fact, I was kind of shocked as I read in Simon Peyton Jones' presentation Wearing the hair shirt [1] that in his opinion Lazyness doesn't really matter. [...] Best wishes, Wolfgang [1] http://research.microsoft.com/Users/simonpj/papers/haskell-retrospective/ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Comment Syntax
Am Montag, 30. Januar 2006 17:24 schrieb Taral: On 1/30/06, Thomas Davie [EMAIL PROTECTED] wrote: It gives you regexp and nothing more - this makes it a pain in the arse to input every possible character that is/isn't allowed. Steal it from places (vim): syn match hsLineComment ---*\([^-!#$%\*\+./=[EMAIL PROTECTED]|~].*\)\?$ What about Unicode? Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: ~ patterns
On 03/02/2006, at 9:25 AM, Wolfgang Jeltsch wrote: Am Mittwoch, 1. Februar 2006 01:32 schrieb Patryk Zadarnowski: [...] The proposal would be to remove the unary - altogether, and, instead, extend the lexical syntax of numeric constant to allow + and - prefix. Would this mean that (-x) is a section while (-1) isn't? That would be confusing. Apart from this, I would like to see the only unary operator of Haskell removed. Yes, it *would* mean that (-x) and (- 1) are sections while (-1) isn't, and yes, that would be slightly confusing (and a good compiler might want to issue a warning whenever it sees a construct of the form (-identifier). However, it is NOT more confusing than what we already have with the (.) operator. Consider: (Just . not) is a perfectly reasonable function of type (Bool - Maybe Bool) But: (Just.not) has a completely different meaning (and is probably illegal unless you have a module called Just, which exports a function called (not).) In the case of the (.) operator, the confusion is more significant, since the meaning is context-sensitive. With the proposed - operator, it would be purely lexical, and therefore easy to warn about (if the compiler wishes to do so.) In both cases, accidentally omitting a space will result in a compiler or type error anyway, since (-x) has a different type than (- x), so such accidents will be picked by the compiler rather than generating invalid code. In summary: yes, the change would create *some* confusion. But much less confusion than that caused by the current treatment of (-). Pat. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: ~ patterns
On Fri, Feb 03, 2006 at 09:54:59AM +1100, Patryk Zadarnowski wrote: On 03/02/2006, at 9:25 AM, Wolfgang Jeltsch wrote: Am Mittwoch, 1. Februar 2006 01:32 schrieb Patryk Zadarnowski: [...] The proposal would be to remove the unary - altogether, and, instead, extend the lexical syntax of numeric constant to allow + and - prefix. Would this mean that (-x) is a section while (-1) isn't? That would be confusing. Apart from this, I would like to see the only unary operator of Haskell removed. Yes, it *would* mean that (-x) and (- 1) are sections while (-1) isn't, and yes, that would be slightly confusing (and a good compiler might want to issue a warning whenever it sees a construct of the form (-identifier). I'd much prefer it gave a warning for (-1) as, with -1 being a single lexeme, parentheses would never be needed. In both cases, accidentally omitting a space will result in a compiler or type error anyway, since (-x) has a different type than (- x), so such accidents Do you mean (-1) and (- 1) here? Thanks Ian, in support of this proposal ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: MPTCs and functional dependencies
On Thu, Feb 02, 2006 at 03:09:35PM +, Henrik Nilsson wrote: Now, I'm not saying that FDs are that important, only that it seems to me they are. I'd be happy to be convinced of the opposite. But from the above, it at least seems that John M. too actually says that FDs are important? Oh, I don't think anyone is disagreeing that they are important. they are just quite underspecified at the moment, and it looks like they will be replaced at some point anyway. It would be great if we can figure out some well specified subset that works for most uses that is ready to put into haskell prime. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Specifying language extensions
One issue that pains me with Haskell 98 is that it does nothing about one of its original stated goals as a programming language. I've always been very fond of pointing out that Haskell has been designed as a language for EXPERIMENTATION with language features, and therefore the mind-boggling number of extensions in GHC is a good thing, not a bad one. This will NOT change with Haskell' - we already know that at least one language feature which is in high demand (functional dependencies) is far from ready for standardization. However, the language, at the current point, does nothing towards helping with keeping track of the language extensions in use by a particular piece of code. To make things worse, many extension require lexical and/or syntactic changes to the language. Some extensions in the past proved to be incompatible, and not all compilers implement all extensions. So, looking at a particular piece of code, how do we know which compiler it can be compiled with, and which command-line flags do we pass to which compiler? The answer is, simply, we don't. Currently, we do this by introducing ugly GHC-specific pragmas, comments in the documentation, and a plethora of similar half-measures. I would like to propose a language feature to address this concern once and for all. I know that a similar proposal has been circulated on the haskell mailing list in the past, but to the best of my knowledge, none of the current tickets addresses this problem. The proposal: Add explicit syntax for documenting language extensions required by a module. The Problem: * Current language does not provide a uniform extension mechanism. * Pragmas (as currently used in GHC) are NOT suitable for this. Specifically, by their design they are COMMENTS, and therefore should have no impact on the language semantics. Unrecognized pragmas should be ignorable without warnings, while, currently, if you omit the GHC options pragma for a module that requires some syntactic extension, you will receive thousands of lexical and syntactic errors completely unrelated to your extension. * I /strongly/ believe that compiler pragmas should ONLY be used for extensions (such as INLINE, various SPECIALIZE, etc.) that have no impact on the program semantics. The Solution: Add an extension clause to the language. To avoid introduction of a new keyword, I propose to use the following syntax: module - [extensions;] module modid [exports] where body | body extensions - extension_1 ; ... ; extension_n extension - import extension varid [extparam_1 ... extparam_n] extparam - varid | conid | literal A module using some GHC woo-hah extension would look like: import extension GHC woo-hah! module Foo ... Or, if an extension is common enough: import extension fundeps module Foo ... This is a very conservative syntax. It does not support grouping, aliasing and renaming of extensions (as previously circulated on the haskell mailing list) which I personally believe would be very a bad idea. I want to be able to look at a piece of Haskell code and tell immediately which extensions it uses, without being forced to browse through the included modules, etc. Extensions would NOT be exported by a module that uses that extension, but would have to be specified separately by each module that uses the features provided by that extension. For example, one often hides uses of unboxed types, functional dependencies, etc, behind a curtain of abstract data types, and such data type implemented using non-standard features can be happily used within standard-conforming Haskell programs. On the other hand, if an extension is visible in an interface exported by a module, it has to be named explicitly (with import extension clauses) by any module importing that interface. Extensions could be parametized, since I can readily imagine extensions that would require such a thing. I would also recommend in the standard that every compiler groups its own extensions under a common name (for example, GHC, HUGS, JHC, NHC, etc.) until they are in sufficiently common use to be standardized independently (such as fundeps), at which stage there should probably be a corresponding addendum to the standard for that extension. Specifying extensions before the module keyword ensures that the lexer and parser can find them before parsing of the actual module. I recommend that bare modules without the module keyword cannot specify any extensions, and therefore must be written in pure Haskell'. The standard itself should not define any extensions and state that the standard grammar and semantics describes the base language in absence of any import extension clauses. Each extension, including FFI, should be described in a separate addendum.
Re: Comment Syntax
On 2/2/06, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: Am Montag, 30. Januar 2006 17:24 schrieb Taral: On 1/30/06, Thomas Davie [EMAIL PROTECTED] wrote: It gives you regexp and nothing more - this makes it a pain in the arse to input every possible character that is/isn't allowed. Steal it from places (vim): syn match hsLineComment ---*\([^-!#$%\*\+./=[EMAIL PROTECTED]|~].*\)\?$ What about Unicode? Got a unicode-compliant compiler? -- Taral [EMAIL PROTECTED] Computer science is no more about computers than astronomy is about telescopes. -- Edsger Dijkstra ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Unary operators [was: Re: ~ patterns]
On 2/2/06, Benjamin Franksen [EMAIL PROTECTED] wrote: This would open the possibility to allow unary (prefix) operators in general which I find rather more useful than sections. Down that road lies APL. -- Taral [EMAIL PROTECTED] Computer science is no more about computers than astronomy is about telescopes. -- Edsger Dijkstra ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Comment Syntax
On Thu, Feb 02, 2006 at 06:19:43PM -0600, Taral wrote: Got a unicode-compliant compiler? sure do :) but it currently doesn't recognize any unicode characters as possible operators. which it should, but I am just not sure how to specify that yet until some sort of standard develops. Once there are more unicode compliant compilers out there something will evolve probably. Right now I am thinking of being able to add a PRAGMA to force some characters to be interpreted as operators just so that they can start being used now, even though there isn't a standard set you can count on yet. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: H-core (was: Re: ~ patterns)
On Thu, Feb 02, 2006 at 11:19:09AM +, Malcolm Wallace wrote: There is a potential confusion here between the H-core language as used in the Haskell'98 report, and ghc's current external-core language. The former contains classes, and the latter does not. Ghc-core has type-lambdas, but H-core does not. Ghc-core has unboxed values, H-core does not. Yeah, core is a pretty overloaded term in haskell. Here I was definitly thinking of Haskell Core, as in a subset of haskell' that is still pure haskell and will compile via any haskell' compiler. I try to get in the habit of alway saying the full haskell core, ghc core, or jhc core (is there an nhc core?) but sometimes get sloppy. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: H-core (was: Re: ~ patterns)
john: On Thu, Feb 02, 2006 at 11:19:09AM +, Malcolm Wallace wrote: There is a potential confusion here between the H-core language as used in the Haskell'98 report, and ghc's current external-core language. The former contains classes, and the latter does not. Ghc-core has type-lambdas, but H-core does not. Ghc-core has unboxed values, H-core does not. Yeah, core is a pretty overloaded term in haskell. Here I was definitly thinking of Haskell Core, as in a subset of haskell' that is still pure haskell and will compile via any haskell' compiler. I try to get in the habit of alway saying the full haskell core, ghc core, or jhc core (is there an nhc core?) but sometimes get sloppy. Oh, I use Core for GHC's IR, and the Haskell core for the lang in the report. -- Don ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Specifying language extensions
oh, not that I don't see your points about it not being a pragma, I just
wanted to point to some previous work on the matter. All I know for sure
is {-# OPTIONS ... #-} is not a very good solution :)
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
core comparison for fun.
Just for larks, here is a side by side of the various compilers core for
the example on that page:
Haskell:
module FibMain where
main xs = pam daeh xs
daeh (x:xs) = x
pam f [] = []
pam f (x:xs) = f x : pam f xs
Yhc:
FibMain.pam v220 v221 =
case v221 of
Prelude.[] - (Prelude.[])
Prelude.: v222 v223 -
(Prelude.: (YHC.Internal._apply1 v220 v222) (FibMain.pam v220
v223))
FibMain.daeh v224 =
case v224 of
Prelude.: v225 v226 - v225
_ - (Prelude.error (LAMBDA228))
LAMBDA228 =
(prim_STRING FibMain: Pattern match failure in function at 7:1-7:15.)
FibMain.main v227 = (FibMain.pam FibMain.daeh v227)
Jhc: (unicodey!)
FibMain.main = ΛFibMain.v22.λFibMain.1_xs∷[[FibMain.v22]].(let
x9282∷[FibMain.v22] → FibMain.v22 = λx9284∷[FibMain.v22].(case x9284
of
(x9286∷FibMain.v22):(x9288∷[FibMain.v22]) → x9286;
Prelude.[] →
⊥:test/fibmain.hs:5:13: Unmatched pattern∷FibMain.v22;);
x9280∷⋆ = [FibMain.v22];
in FibMain.pam x9280 FibMain.v22 x9282 FibMain.1_xs)
FibMain.pam = ΛFibMain.v5.ΛFibMain.v10.λx9296∷FibMain.v5 →
FibMain.v10.λx9298∷[FibMain.v5].(case x9298 of
(x9300∷FibMain.v5):(x9302∷[FibMain.v5]) → let x9316∷[FibMain.v10] =
FibMain.pam
FibMain.v5 FibMain.v10 x9296 x9302;
x9314∷FibMain.v10 =
x9296 x9300;
in x9314:x9316;
Prelude.[] → ;)
FibMain.daeh = ΛFibMain.v15.λx9284∷[FibMain.v15].(case x9284 of
(x9286∷FibMain.v15):(x9288∷[FibMain.v15]) → x9286;
Prelude.[] →
⊥:test/fibmain.hs:5:13: Unmatched pattern∷FibMain.v15;)
ghc:
daeh :: %forall a . [] a - a =
\ @ a (ds::[] a) -
%case (a) ds %of (wild::[] a)
{[] -
GHC.Err.patError @ a
(test/fibmain.hs:5:0-14|function daeh::Addr#);
: (x::a) (xs::[] a) -
x};
pam :: %forall a a1 . (a - a1) -
[] a - [] a1 =
\ @ a @ a1 -
%let %rec
{pam1 :: (a - a1) - [] a - [] a1 =
\ (f::a - a1) (ds::[] a) -
%case (([] a1)) ds %of (wild::[] a)
{[] -
[] @ a1;
: (x::a) (xs::[] a) -
: @ a1 (f x) (pam1 f xs)}}
%in pam1;
main :: %forall a . [] ([] a) -
[] a =
\ @ a (xs::[] ([] a)) -
FibMain.pam @ ([] a) @ a (FibMain.daeh @ a) xs;
I don't think a common compiler level core is forthcoming :)
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
Re: MPTCs and functional dependencies
Ravi Nanavati wrote: Multi-parameter type classes, yes. Functional dependencies, no. My experience is that even with very simple applications of MPTCs, I often end up needing functional dependencies to make things work. As a user, I'll echo this. Me three, etc. Might it be worth holding off on MPTCs altogether if we don't also have fundeps or associated types? -- Ashley Yakeley ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Unicode, was Comment Syntax
On 2/2/06, John Meacham [EMAIL PROTECTED] wrote: but it currently doesn't recognize any unicode characters as possible operators. which it should, but I am just not sure how to specify that yet until some sort of standard develops. Once there are more unicode compliant compilers out there something will evolve probably. Character attributes are defined in unicode: http://www.unicode.org/Public/UNIDATA/ It's just a matter of mapping. Perhaps this is worth considering amending for Haskell'? The Haskell98 grammar talks about symbol, uppercase, lowercase, while Unicode is a bit more... diverse. -- Taral [EMAIL PROTECTED] Computer science is no more about computers than astronomy is about telescopes. -- Edsger Dijkstra ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Priorities
On Thu, Feb 02, 2006 at 01:05:57PM +, Ross Paterson wrote: Personally, I'm not sure about caseless underscore, concurrency, natural numbers and parallel list comprehensions. There is one more reason to leave concurrency out of the standard. Some experts (like Hans Boehm) argue, that concurrency can't be added to the language as a library. http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf This is true for many imperative programming languages. Haskell seems to be an exception: http://www.haskell.org//pipermail/glasgow-haskell-users/2005-December/009417.html We don't have any problems with ensuring good cooperation between mutable variables and concurrency synchronisation primitives, because the language doesn't have mutable variables, they are delivered in the concurrency library - the variables _are_ the synchronisation primitives. If we add concurrency to the standard, we'll be in a strange situation. In future discussions about language design and concurrency, all we will be able to say to highlight Haskell's strengths will be something like this: The design of Haskell was so great, that we could add concurrency as a library without introducing any problems... but we have concurrency in the standard anyway... ;-) Best regards Tomasz -- I am searching for programmers who are good at least in (Haskell || ML) (Linux || FreeBSD || math) for work in Warsaw, Poland ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
