Re: Haskell 2010 libraries
Hello Simon, Friday, April 30, 2010, 1:42:33 PM, you wrote: During the Haskell 2010 process the committee agreed that the libraries in the report should be updated, i think: if committee assignment turned out to be ambiguous, it should be returned to committee. we can discuss it here but then committee should make a clear decision -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: Haskell 2010: libraries
Hello Ganesh, Tuesday, July 14, 2009, 10:48:36 AM, you wrote: I don't have any strong opinion about whether there should be a library standard or not, but if there is a standard, how about putting the entire thing (perhaps including the Prelude) under the prefix Haskell2010. or similar? Most of it could be implemented by just re-exporting things from the real libraries. we already have PvP mechanism for these things -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: Haskell 2010: libraries
Hello Ian, Tuesday, July 14, 2009, 3:20:42 AM, you wrote: We've been fortunate recently that, because the hierarchical modules haven't been in the standard, we've been able to extend and improve them without breaking compatibility with the language definition. but breaking compatibility with existing programs. i hate situation when we need to reupload entire hackage every year -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[4]: Haskell 2010: libraries
Hello Ganesh, Tuesday, July 14, 2009, 11:59:00 AM, you wrote: I don't have any strong opinion about whether there should be a library standard or not, but if there is a standard, how about putting the entire thing (perhaps including the Prelude) under the prefix Haskell2010. or similar? Most of it could be implemented by just re-exporting things from the real libraries. we already have PvP mechanism for these things The PvP isn't (proposed as) part of the standard, and without package qualified imports as implemented by GHC, it wouldn't help anyway. but package versioning implemented by ghc, hugs and probably other compilers. with your idea we will have two things that address the same problem, and these will be miltiplied - i.e. we will carry several versions of base package, each having Haskell2010.*, Haskell2011.* and so on modules -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: Haskell 2010: libraries
Hello Isaac, Wednesday, July 8, 2009, 11:05:44 PM, you wrote: It could be a mere informative reference: the most-community-accepted libraries at the time of publication are:. no, i mean that if we include some library in Haskell-2010, then it means that any compiler declared as H2010-compliant, is obliged to support this library of this exact version final goal is to allow someone to get code and compiler both meeting the same Haskell-20XX standard and be able to use the later on the former for sure. it's because we want to provide some base for learning Haskell, and, it will be great - for its industrial usage too this not necessarily should be bare compiler, but may be some compiler-based distribution like that existing Haskell Platform does for GHC -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: Announcing the new Haskell Prime process, and Haskell 2010
Hello Don, Thursday, July 9, 2009, 1:44:28 AM, you wrote: Tom Lokhorst suggests[1] Haskell'10 now i understand - Haskell committee was just skipping those unbeautiful one-digit years :) -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: Announcing the new Haskell Prime process, and Haskell 2010
Hello kahl, Thursday, July 9, 2009, 2:43:01 AM, you wrote: Haskell'10 Some people expect Haskell and/or Haskell' not to be around anymore in 2110? it would be Haskell10 :) ability to accurately count apostrophes is one of the prerequisites to learn Haskell :D -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: what about moving the record system to an addendum?
Hello Duncan, Tuesday, July 7, 2009, 2:15:42 AM, you wrote: For one thing the spec currently says that pragmas cannot change the semantics of the program. That would have to read apart from the LANGUAGE pragma. sometime ago i've proposed to make a language statement a part of haskell. i don't insist on this but at least keep this possibility in mind - making it a pragma is a poor man solution -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ 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
Hello Simon, Tuesday, July 7, 2009, 6:04:46 PM, you wrote: i can't understand. does this list supposed to be full list of changes in haskell'? it seems to include mainly supplementary syntax changes while even Rank2Types are not here, the same for assoc. types, GADTs and other fundamental type system improvements and btw - from my user's POV, we can just start with common GHC Hugs subset, remove a few features, add a few GHC-specific features and will become close to what should be named next Haskell standard, standard de-facto of Haskell used in last years. why so much time spent on this process.. ForeignFunctionInterface LineCommentSyntax PatternGuards DoAndIfThenElse Remove n+k patterns RelaxedDependencyAnalysis EmptyDataDeclarations HierarchicalModules NonDecreasingIndentation remove FixityResolution from the context-free grammar change the syntax of QualifiedOperators In the coming weeks we'll be refining proposals in preparation for Haskell 2010. By all means suggest more possibilities; however note that as per the new process, a proposal must be complete (i.e. in the form of an addendum) in order to be a candidate for acceptance. I have updated the status page http://hackage.haskell.org/trac/haskell-prime/wiki/Status marking everything except the proposals that have been already implemented in the draft Report as old. The new process requires a proposal to have an owner or owners in order to make progress; once a proposal has an owner it will move into the under discussion state. To take up ownership of an existing proposal, or to start a new proposal, ask on the mailing list. There are other ways you can get involved; some suggestions are on the Haskell' main page: http://hackage.haskell.org/trac/haskell-prime/wiki (hmm, I suppose we should fix that logo too...) Cheers, Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: One more 'do' pattern
Hello Thomas, Saturday, March 28, 2009, 12:05:02 PM, you wrote: In all honesty, I find the idea of adding yet more imperative looking stuff to do notation an appalling idea. We already get problems because people read do notation and think it means execute this in sequence (see threads about lazy IO not doing what's expected for example). well, people already have problems understanding haskell, not only 'do' statements As an aside, while these are merely syntactic sugars, I find the idea of attacking the problem with syntax to be somewhat silly as well. This simply adds a special syntax for another couple of cases that crop up occasionally. What do we do when we have another, and another, and another, do we keep just adding more and more syntax? i'm just making industrial programming, with lots of imperative code and 'do' syntax (compared to imperative languages) is somewhat limited. so, what i want to have is better syntax. i don't have any idea whether semantics can be somewhat improved to fix those shortages -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[6]: One more 'do' pattern
Hello Thomas, Saturday, March 28, 2009, 12:34:05 PM, you wrote: I'm not sure why industrial programming means programming not in a functional style. It certainly doesn't mean that where I work. what kind of problems you are solving? Large GUI applications doing lots of 3D rendering. and you have written GUI in FP style? with trees, dd support and so on? -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[10]: One more 'do' pattern
Hello Thomas, Saturday, March 28, 2009, 12:55:39 PM, you wrote: And we can't possibly have written our own GUI library as part of the project? *you* can. i cannot. instead, i write a lot of code that implements features lacking in gtk2hs generally, i have very opposite positions in Haskell community and outside it some peoples say that i shouldn't use haskell because FP doesn't provide serious advantages over Java. they tend to consider anyone using Haskell as scientist other people say that i shouldn't use haskell if my usage doesn't fall into their idea of how it should be used but i just work. i deliver program to my users and using haskell for some its parts decrease time-to-market. if haskell will improve its 'do' syntax, it will reduce my development costs even more. just for comparison - something like GADT or AT or generics, while cute by itself, cannot help me at all -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[10]: One more 'do' pattern
Hello Thomas, Saturday, March 28, 2009, 1:04:01 PM, you wrote: To get back on topic though... Here's *why* I don't want these specific things I wouldn't use added to haskell: • The syntax gains very little over the nice consistent syntax we already have – all you do is move a symbol a little to the left. main problem with lack-of-syntax is that we write variables at right: action x y = \v - do action x y $ \v - do another problem is all those funny $\-do one need to write • We encourage people to write code unnecessarily in an imperative style i wonder at this argument. we make using 'do' simpler and this is bad thing? :) probably you should argue against invention monads at all - it's Wadler who added imperative features to this pure shine Haskell :D about syntax - i don't mean that i proposed something ideal i just want to figure out here one pattern of 'do' usage which i use quite often. imho, moving variables to the left would be good thing, exact syntax is a matter of debates -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: One more 'do' pattern
Hello Conal, Saturday, March 28, 2009, 11:54:55 PM, you wrote: no, i don't use other monads at all Do you have examples of usefulness your sugar for monads besides the one? Since do sugar is notation for general monadic programming, I wouldn't want to see it made more complex for the sake of just one monad. - Conal On Sat, Mar 28, 2009 at 1:54 AM, Bulat Ziganshin bulat.zigans...@gmail.com wrote: Hello haskell-prime, as we know, the following code action x y = \v - do can be shortened to following v - action x y but there is one more very popular 'do' pattern, with a 'do' block passed as a parameter: for list $ \element - do ... or bracket createDialog destroyDialog $ \dialog - do ... what about adding one more 'do' sugar that will allow to move variable name to the left, such as for element in list do or with dialog in bracket createDialog destroyDialog do or just element -- for list do dialog -- bracket createDialog destroyDialog do ? -- Best regards, Bulat mailto:bulat.zigans...@gmail.com ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
FFI and fixed-size integer types
Hello , citating letter from cafe After reading an ISO draft for standard C, I found a few types that could be usefull when binding to libraries (these are from stdint.h): int8_t, uint8_t, int16_t, uint16_t, int32_t, uint32_t, int64_t, uint64_t i propose to change FFI addendum so that haskell compilers guarantee correspondence between Int16 and int16_t types and so on -- Best regards, Bulat mailto:bulat.zigans...@gmail.com ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: Meta-point: backward compatibility
Hello Neil, Thursday, April 24, 2008, 12:21:41 PM, you wrote: Some questions: don't forget about most complex part: does this tool will convert human minds? :D -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: patch applied (haskell-prime-status): add Make $ left associative, like application
Hello Cale, Wednesday, April 23, 2008, 10:54:06 AM, you wrote: By the way, as Don suggests, I do strongly advocate this change, and i agree that the change by itself is reasonable, but fixing all the old issues and providing new beautiful language version should be project of its own. for example, i will propose raising precedences when there are no spaces around operator. this will significantly reduce amount of parentheses/$s: f a+b c*d f g(x) h(y) for now, wee need to standardize current haskell practice just for compilers interoperability and teaching purposes (noone wants to write book about ghc 6.8 or teach students to it) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[4]: patch applied (haskell-prime-status): add Make $ left associative, like application
Hello Cale, Wednesday, April 23, 2008, 11:26:49 AM, you wrote: f x+y = (x+y)^2 f x + y = x^2 + y imho, it's easy to see what there are no spaces around + on first line, but there are spaces at the second. imho, it's just our habits - ignore spaces and split expression by operators actually, shift from usual style of f(x+y,z*t) to f (x+y) (z*t) was no less dramatic. i propose to go one step further and use spaces instead of brackets as one more way to control precedence. this idea born from my haskell programming practice - these additional parentheses are rather common and avoiding them will make program reading easier. but it needs to shift habits That's a pretty hard to see bug, and it sneaks right past the typechecker. I'm all for a certain amount of whitespace sensitivity, but that might be going too far. my main point is that considering space-less operators as having larger priority is our natural habit. consider this: f a*b x+c imho, my interpretation of this expression sounds more natural than haskell's current one for now, wee need to standardize current haskell practice just for compilers interoperability and teaching purposes (noone wants to write book about ghc 6.8 or teach students to it) Well, my point is that if we can see these changes that we want to make to the libraries, it makes little sense to let people write those books and then change all the libraries out from under them a few months down the road. Maybe it's what we'll end up doing anyway, but it's worth considering. unfortunately, it will be not a few months. there are many important things we may change in haskell. sometime ago it was said that haskell' will just standartize existing haskell (ghc/hugs) state and haskell 2 will be new, probably incompatible language. fixing just one oddity in haskell' will give us worst of both worlds - broken compatibility and lots of oddities still remaining -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: Meta-point: backward compatibility
Hello Philippa, Wednesday, April 23, 2008, 10:53:54 PM, you wrote: Current practice often involves removing certain warts anyway - the MR being a great example. it's already in ghc for a years and doesn't affect too much code. we need a solid base of a language to write to, to learn, to popularize. and to develop next, more advanced language versions -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: patch applied (haskell-prime-status): add Make $ left associative, like application
Hello Lennart, Wednesday, April 23, 2008, 11:38:50 PM, you wrote: Just pick some other (Unicode?) operator, but leave $ alone. good said. i have my own version of /|| which i love more but they are called /||| -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: patch applied (haskell-prime-status): add Make $ left associative, like application
Hello Niklas, Thursday, April 24, 2008, 12:42:02 AM, you wrote: But then I started questioning my own motives. What changes would that be? Changing a . to a $ if I decided to remove the previous last piece of the pipeline? Doesn't seem too hairy, and I have to do far worse than that already when refactoring. it's not refactoring! it's just adding more features - exception handler, progress indicator, memory pool and so on. actually, code blocks used as a sort of RAII for Haskell. are you wanna change all those ';' when you add new variable to your C++ code? bracketCtrlBreak (archiveReadFooter command arcname) (archiveClose.fst) $ \(archive,footer) - do bad_crcs - withList $ \bad_crcs - do doChunks arcsize sector_size $ \bytes - do uiWithProgressIndicator command arcsize $ do or handleCtrlBreak (ignoreErrors$ fileRemove arcname_fixed) $ do bracketCtrlBreak (archiveCreateRW arcname_fixed) (archiveClose) $ \new_archive - do withJIT (fileOpen = originalURL originalName arcname) fileClose $ \original' - do is just two examples from my code -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: patch applied (haskell-prime-status): add Make $ left associative, like application
Hello John, Wednesday, April 23, 2008, 9:41:22 AM, you wrote: Haskell' will not be fully Haskell 98 compatible. But it won't break things too much hopefully. And no doubt compilers will have strategies for mixing h98 and h' code. aside compilers, there are people, too. are we really want to put comments on each haskell snippet published - in which version of language it's written, for a such small benefit? -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: patch applied (haskell-prime-status): add overloaded string literals
Hello Wolfgang, Friday, April 11, 2008, 6:19:26 PM, you wrote: Would it be possible to change the class name “IsString” to something different? Would it be possible to remove the type alias “String” and let “String” be the class name? Can I add this remark somewhere on the wiki? this reminds me one idea i've once proposed to discuss: allow to use class names in type signatures with obvious translation to classic code: putStr :: String - IO () means putStr :: (String a) = a - IO () writing a lot of polymorphic code for Streams lib, i've found this feature very useful - with current standard, type signatures using type classes are very hard to read: -- | Copy `size` bytes from one BlockStream to another copyStream :: (BlockStream h1, BlockStream h2, Integral size) = h1 - h2 - size - IO () -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Proposal: hands off the base! :)
Hello Twan, Thursday, January 17, 2008, 2:00:37 AM, you wrote: An often requested function is 'split', to split a list into parts delimited by some separator. ByteString has the functions split and splitWith for this purpose. I propose we add equivalents to Data.List: one more proposal to ruin all the programs that define this function themselves. i wonder whether all who propose to add function or two ever seen MissingH package? it includes a lot of such popular functions and anyone who needs them can install this package (or just borrow code) i make a contra-proposal - fix base library in 6.8 state and add to ghc distribution new libs with all the popular Monad, List and any other functions. this will allow: 1) precisely control which functions are available by importing exact versions of all libs (except of base which anyway will be frozen) 2) use all the new functions regardless of ghc version you are using. otherwise, adding `split` function to the base actually means that noone except for core hackers can use it for a year - because all these changes in base will go in production GHC version at the end of 2008 and because using user-defined split function will automatically make program incompatible with next GHC version overall, i want to use GHC for production, open-source programming and can formalize requirements which will allow to do this: 1) frozen base library interface, except for GHC.* modules 2) if we want to improve some base code, we *duplicate* it into new lib (with modified module names), publish first version of this libarry with exactly original code (and therefore equivalent interfaces) and then start to improve it, publishing newer and newer versions. imagine, for example, that we want to improve Data.Array.*: step 1: create library NewArray with modules Data.NewArray.* copied one-to-one from Data.Array.* and publish it as version 1 step 2: raise NewArray version to 2.0 and start making changes. once we've finished, raise version to 3.0 and keep interfaces for 3.* intact so anyone can import NewArray 3.* and got latest version with exactly the same interface as he used yes, this means that every functionality improved against the base package, should be installed in two versions - one inside base one in new package. but this is very natural taking into account that we can't change base without breaking all the code that relies on it. so, if we want new arrays, Handles or Exceptions - we will need to keep old version in base and add new one in other lib. overall, it should be recommended to not import directly anything from base but use separate libraries instead 3) GHC distribution should include all the popular libs (which, at the last end, should terminate rushes to include popular functions into the base!) with *MULTIPLE* versions - i.e. last 1.* version of NewArray, last 2.* version and so on. this will ensure that program developed in year 2007, will continue to compile with newest ghc versions in 2008, 2009 and so on. we can drop library from ghc distribution after, say, 3 years. i also propose that Haskell' ccommittee will decide every year which libs to include into Haskell standard libs set with exact major version. for example: year 2007: BS 1.*, Collections 2.*, HDBC 1.* year 2008: BS 2.*, Collections 2.*, HSQL 1.* year 2009: BS 2.*, Collections 2.*, HSQL 2.* ghc-2009 should include std libs from last 3 years, i.e. BS 1.*/2.*, Collections 2.*, HDBC 1.*, HSQL 1.*/2.* ghc-2010 may drop BS 1.* and HDBC 1.* support and of course should add newer libs from HL-2010 standard. the same should do other haskell compilers. this will significantly improve situation with Haskell standard libraries: 1) Haskell' committee will not need to develop artificial standard libraries set - actually, i think it can't and anyway any fixed set will become obsolete next year. libraries are most important part of any language and nowadays we can't develop proper stdlibs set by committee. it should be made by community and committee should only sign up final results 2) every haskell distribution will include some guaranteed minimum of common, up-to-date libraries. any program written using H2009 specifications, will continue to run with any major Haskell compilers for a next 3 years. this should overcome libraries hell for mid-sized apps 3) any book or courses teaching Haskell can declare, for example, that it investigates Haskell-2009 and any Haskell2009-compatible compiler will provide both the syntax and libs discussed in the book. it will also mean that when you hire Haskell2009-certified specialist, you will be sure that he knows not only the language itself but also basic set of libs, equivalent of STL for C++ defining large standard set of libs was the major source of success for Java/C#/C++ last decade. we can go one step further and join development by community with standardization by committee. it should make Haskell better solution for developing large,
Standard libraries
Hello haskell-prime, one more proposal is about standard libs. it is well known that today libs outweighs all other parts of modern language and work on their standardization will probably stall the whole Haskell-prime process. OTOH, languages like Java was grown due to their rich set of libraries, which is far more than any committee may even discuss, all the more invent. afaiu, Java versions just standardize libraries that are in wide use on the moment of standard acceptance i propose to do the same. first, library developers should follow http://haskell.org/haskellwiki/Package_versioning_policy second, every year Haskell committee should decide which libraries of currently Hackage-available are most widely used, portable and free, and call this set a Haskell- standard libraries, together with versions inspected. Next year some libs may disappear from the list, some new appear and some upgrade to newer versions. so, we may had: H2008 libs: base 3.0, FPS 1.0, Binary 1.0 H2009 libs: base 3.0, FPS 2.0, SuperBinary 0.1 With above-mentioned versioning policy, this means that any FPS 1.0.* will comply to the H08 standard and this means that this line of version may continue to fix bugs, improve performance, add support for new systems, while keeping its interface Third, each compiler shipped should declare which HSL (Haskell Standard Libraries) versions it supports. F.e.: ghc 7.10: HSL 2010-2014 ghc 7.12: HSL 2011-2014 ... So, every new compiler version will try to support newest HSL versions and try to keep compatibility with old ones while they last in wide use, and newer compilers/platforms may be supported by old libs by publishing their minor modifications (base 3.0.1, base 3.0.2 and so on) Fourth, this may make Haskell education more organized - i.e. book or course may declare that it teaches Haskell-2008 standard with HSL-2010 libraries and this will mean that at the end programmer will be able to use some set of functionality (i.e. all the libs included in the HSL-2010) and that his knowledge will allow him to immediately start working with ghc 7.0-8.10, hugs 2010-2015 and jhc 1.0-1.5, for example One important drawback that i see here is that full compiler downloads should be shipped with older library versions too - i.e. providing newest FPS library will be not enough, you need to ship older HSL libraries too -- Best regards, Bulat mailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Haskell'2008
Hello haskell-prime, i propose to omit type functions/families from standard you are currently developing and leave only MPTC (without FDs) here reason: it not yet included in GHC. probably, it will be in 6.10 next fall. then we will need one more year to prove its usefulness and one more year to finish developing new Haskell standard. at this time we will also have many new ghc/hugs extensions which will be again very appetite instead, i propose to make H2008 standard and be ready to update it each 3-4 years -- Best regards, Bulat mailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: Make it possible to evaluate monadic actions when assigning record fields
Hello Neil, Thursday, July 12, 2007, 3:10:10 PM, you wrote: This extension seems like a great idea - my only concern would be about the order of computations. Clearly left-to-right makes sense, but this may break some natural intuition in Haskell: i think that undefined order will be a best one -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: Make it possible to evaluate monadic actions when assigning record fields
Hello Simon,
Wednesday, July 11, 2007, 11:38:31 AM, you wrote:
So Greg's idea (or at least my understanding thereof) is to write it like
this:
do { f $(stuff1) $(stuff2) }
Simon, it is thing i dreamed for a years! Haskell has serious drawback
for imperative programming compared to C - each action should be
written as separate statement and this makes program too wordy - just
try to rewrite something like x[i] += y[i]*z[i] in Haskell
i need a way to perform actions and read data values inside
calculations. there are two possible ways:
* write pure expressions like we do in C and let's ghc guess yourself
where evaluation should be added:
x - newIORef 1
y - newIORef 1
z - newIORef 1
f x (y*z)
this means that any expression of type IORef a or IO a automatically
translated into evaluation. the same should work for arrays, hashes
and so on, so it probably should be a class. the problem, of course, is
that IO/IORef/.. is a first class values so it's hard to distinguish
where it should be evaluated and where used as is. another problem is
its interaction with type inference - we may not know which concrete
type this expression has
* add an explicit operation which evaluates data, as you suggests.
again, it should be a class which allows to add evaluation support for
hashes/...
actually, ML has something similar - it uses . operation to evaluate
variable values
=
and, while we on this topic, another problem for imperative
programming style usability is control structures. how we can rewrite
the following:
delta=1000
while (delta0.01)
x = ...
if (x0) break
delta = abs(n-x*x)
=
btw, proposal of prefix expressions also simplifies imperative
programs a bit: now we should write something like this:
when (a0) $ do
.
while this proposal allows to omit $ and make program look a bit more
natural
=
one more complaint: the syntax
for list $ \item - do
doesn't look too natural compared to other languages. it will be great to
write it as
for item in list do
- of course, with 'for' still a plain function defined by user
=
may be, i should collect all these ideas on imperative programming
page?
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: default fixity for `quotRem`, `divMod` ??
Hello Isaac, Monday, June 18, 2007, 9:20:29 PM, you wrote: I was just bitten in ghci by `divMod` being the default infixl 9 instead of the same as `div` and `mod`. one of my hard-to-find bugs was exactly in this area: i wrote something like x `div` y+1 instead of x `div` (y+1) so, based on practical experience, i have opposite proposal: give to all `op` lowest precedence (a bit higher than of '$') because it complies to its visual effect otoh this relates to my other (too revolutionary) proposal: bind x+y more closely than x * y for any (+) and (*), i.e. operation written without spaces around it should increase its priority by whole 10 points. it will allow significantly decrease amount of parentheses: f a+b*c x:xs ++ g uv record.$field -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: [Haskell-cafe] global variables
Hello Isaac, Sunday, May 20, 2007, 6:41:54 PM, you wrote: Maybe some sort of ISOLATE, DON'T_OPTIMIZE (but CAF), or USED_AS_GLOBAL_VARIABLE pragma instead of just the insufficient NOINLINE would be a good first step... or LOOK_BUT_DON'T_TOUCH :) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: General pattern bindings
Hello Twan, Saturday, April 14, 2007, 5:43:03 AM, you wrote: I did not even know these things existed, is there anyone who actually uses general pattern bindings? b:kb:mb:gb:_ = iterate (1024*) 1 unfortunately, they got monotypes, so at last end i finished with simpler definitions nevertheless, i think that this feature should remain. in particular, it may be required for initialization via unsafePerformIO: (hin,hout) = unsafePerformIO $ do runProcess sh -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: List syntax (was: Re: help from the community?)
Hello Brian, Saturday, February 3, 2007, 10:55:52 AM, you wrote: bracket_ (enter a) (exit a) (do b c)-- looks like LISP... this pattern is very typical in my programs and i use '$' before last parameter: postProcess_wrapper command $ \postProcess_processDir deleteFiles - do tempfile_wrapper arcname command deleteFiles pretestArchive $ \temp_arcname - do bracket (archiveCreateRW temp_arcname) (archiveClose) $ \archive - do ... ... for compressionOptions $ \option - case option of 'd':rest | Just md - parseDict rest - dict =: md -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[4]: ADT views Re: [Haskell] Views in Haskell
Hello J., Thursday, February 1, 2007, 1:36:33 AM, you wrote: Yes - you've reiterated Wadler's original design, with an automatic problems with equational reasoning raised by this approach. ok, i can live without it. i mean reasoning :) i guess that anything more complex than Turing machine makes reasoning harder. 18 years ago Haskell fathers chosen to simpilfy language in order to make reasoning easier. may be now we can change this decision? that i've proposed is made on basis of my 15 years of software development experience and i'm sure that abstraction of data representation is very important issue (and much more important than reasoning for practical programming) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: [Haskell] Views in Haskell
Hello Rene, Wednesday, January 24, 2007, 10:49:06 PM, you wrote: Going by the traffic over the previous months, I think that class aliases or extensible records would be higher on most peoples lists than views. i think that proper views is a must for Haskell - We are keen on abstraction, but pattern matching is so convenient that we break abstractions all the time. It's our dirty little secret. we need views in order to stop dealing with concrete datatypes and start writing polymorphic functions. just imagine that the following definition sum [x]= x sum (x:xs) = x + sum xs may deal with *anything*, from strict list to patricia tree. isn't that great? -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
ADT views Re: [Haskell] Views in Haskell
Hello Simon, Monday, January 22, 2007, 5:57:27 PM, you wrote: adding view patterns to Haskell. many of us was attracted to Haskell because it has clear and simple syntax. but many Hugs/GHC extensions done by independent developers differ in the syntax they used, because these developers either has their own taste or just don't bother with syntax issues. you may remember my examples of how the guards syntax may be reused for GADTs and class declarations: data T a = C1 a | Show a || C2 a | Read a instance Binary a | Storable a where ... but unfortunately we've finished with 3 different syntax for the same things i'm sorry for so big introduction but this shows why i don't like the *syntax* you've proposed. you wrote The key feature of this proposal is its modesty, rather than its ambition... that means that this proposal is great for you as implementor - you should write a minimal amount of code to add this to GHC. but let's look at this from viewpoint of one who learn and then use Haskell: first, he should learn two syntax to do matching instead of one. second, he should learn how to implement them both. third, he need to make decision of whether to provide abstract interface to his datatypes or not. if he make a bad decision, he will end either in rewriting lot of code (and change is not s///-style !) or having a lots of trivial definitions like data List a = Nil | Cons a (List a) nil Nil = Just Nil nil _ = Nothing cons (Cons a b) = Just (a,b) cons _ = Nothing then IDEs will automate this code generation and refactoring of code, etc, etc :) On the other hand, view patterns can do arbitrary computation, perhaps expensive. So it's good to have a syntactically-distinct notation that reminds the programmer that some computation beyond ordinary pattern matching may be going on. *you* said :) are you don't know that explicit control of generated code is advantage of low-level languages? we use higher-level languages exactly to avoid dealing with implementation details. as far as we can describe algorithm in some form understandable by computer, we are done. lazy evaluation, classes and even plain functions are the tools to describe algorithm without having any guarantees about its efficiency so, i propose to define views in a way that 1) preserves syntax compatibility with existing patterns 2) allow to define class of views to provide common interface to all sequences, for example 3) old-good guards may be used instead of Nothing to provide backtacking (are you don't think that we already have full Prolog power between | and =? :) something like this: data Coord = Coord Float Float view of Coord = Polar Float Float where Polar r d= Coord (r*d) (r+d)-- construction Coord x y | x/=0 || y/=0 = Polar (x*y) (x+y)-- matching f :: Coord - Float f (Polar r _) = r f (Coord 0 0) = error ... class ListLike c e where head :: c - e tail :: c - c class view of ListLike where Cons :: e - e - c Nil :: c instance ListLike [a] a where head (x:xs) = x tail (x:xs) = xs instance view ListLike [a] a where Cons x xs = x:xs -- for constructing new values using Cons (x:xs)= Cons x xs-- used to match Cons in patterns Nil = xs xs | null xs = Nil i know that this is longer way (and probably will be never implemented) but the language should remain orthogonal. otherwise it will dead in terrible tortures :) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: ADT views Re: [Haskell] Views in Haskell
Hello David, Wednesday, January 31, 2007, 7:12:05 PM, you wrote: data Coord = Coord Float Float view of Coord = Polar Float Float where Polar r d= Coord (r*d) (r+d)-- construction Coord x y | x/=0 || y/=0 = Polar (x*y) (x+y)-- matching This is somewhat pretty, but in spite of your desire to avoid creating new syntax, you have just done so, and in the process made views more limited. Pattern matching sytax remains the same, but a new declaration syntax has been added. And now in order to pattern match on a function it needs to explicitely be declared as a view. yes. among the possible uses for views i clearly prefers the following: definition of abstract data views that may differ from actual type representation. moreover, i think that this facility should be syntactically indistinguishable from ordinary data constructor patterns in order to simplify learning and using of language. *defining* view is a rare operation, using it - very common so my first point is that views should be used in just the same way as ordinary constructors, both on left and right side: f (Polar r a) = Polar (r*2) a Next, i don't think that ability to use any functions in view buy something important. pattern guards can be used for arbitrary functions, or such function can be used in view definition. view, imho, is not a function - it's a two-way conversion between abstract and real data representation which has one or more alternative variants - just like Algebraic Data Types. so, when defining a view, i want to have ability to define exactly all variants alternative to each other. for another representation, another view should be created. so view Polar Float Float of Coord where constructor (Polar r a) means (Coord (r*sin a) (r*cos a)) match pattern (Polar (sqrt(x*x+y*y)) (atan(y/x))) for (Coord x y) where x/=0 (Polar y (pi/2))for (Coord x y) where y0 (Polar (-y) (-pi/2))for (Coord x y) where y0 of course, my syntax is cumbersome. that is important is that view definition should be explicit (no arbitrary functions), it should mention all possible alternatives and provide a way to use the same constructor name both for construction of new values and matching existing ones. this all together should allow to transparently use ADT views instead of plain ADTs And unless you are planning to allow one-way views (you don't give any examples of that), view functions must be invertible, which greatly weakens their power. If you choose to allow one-way views (non-invertible functions), then I'd vote for not allowing two-way views, as it adds complexity without adding any appreciable gain. I don't like your use of capital letters for ordinary functions, I enjoy having the syntax tell me whether (Foo 1) might or might not be an expensive operation. the whole idea of abstraction is to not give users any knowledge aside from algorithmic specifications. when you write (x+y) you don't know whether this (+) will end in ADD instruction or sending expedition to Mars :) why you need low-level control over data matchers exported by library but not over its functions? Finally, you've replaced Simon's explicit incomplete function using Maybe with an implicit incomplete function that returns _|_ when the view doesn't match. it's an independent idea that can be used for Simon's syntax or don't used at all. really, we need Prolog-like backtracking mechanism, i.e. way to say this pattern don't match input value, please try the next alternative. Simon emulated backtracking with Maybe, one can does the same with return/fail, i figured out one more way - just allow recursive use of function guards. Here, if all alternatives for Polar pattern fails, then the whole Polar pattern don't match and we should try the next alternative. so, the following: f (Polar r a) = Polar (r*2) a f (Coord 0 0) = Coord 0 0 should be translated into: f (Coord x y) | x/=0 = Coord (r*2*sin a) (r*2*cos a) where r = sqrt(x*x+y*y) a = atan(y/x) f (Coord x y) | y0 = Coord (r*2*sin a) (r*2*cos a) where r = y a = pi/2 f (Coord x y) | y0 = Coord (r*2*sin a) (r*2*cos a) where r = -y a = -pi/2 f (Coord 0 0) = Coord 0 0 I find this rather unappealing. I certainly prefer *intentionally* incomplete functions to return Maybe somthing, rather than just bombing out when given invalid input. I suppose you'll point out that the view Coord is a function that you can never explicitely call, but to me that just makes things even more confusing. Now we're defining functions that we can only use in pattern matching, but can never call. i hope that now my idea is clear -- Best regards, Bulatmailto:[EMAIL PROTECTED]
Re[2]: Teaching
Hello Iavor, Thursday, November 30, 2006, 8:41:43 PM, you wrote: However, I am not sure that this particular use justifies the addition of defaulting to the _language_. For example, it is possible that defaulting is implemented as a switch to the command-line interpreter. how about using Haskell for scripting? i find it as great alternative to perl/ruby, particularly because i don't want to remember two languages, particularly because of great data processing instruments -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Standard (core) libraries initiative: rationale
Hello libraries, like computer is a net, nowadays language is a library. there is nothing exceptional in C++ and Java languages except for their huge library codebase that makes them so widely appreciated while it's impossible for Haskell to have the same level of libraries maturity, we can try to do our best. Libraries was considered so important, that in H98 report libs required more pages than language itself. But, really, all libraries described there together is appropriate only for learning and small programs - to do real work, we need even much, much more fortunately, now we have large enough set of libs. moreover, this set grows each year. but these libs don't have official/recommended status. now we have two languages - H98 as reported with its bare libs, which is appropriate only for teaching, and real Haskell language with many extensions and rich set of libs, used to develop real programs with a language itself, now we go to standardize current practice and include into language definition all popular extensions. this will close the gap between standard and practice. Haskell' committee also plan to define new version of standard Haskell library. but what a library can be defined in this way? slightly extended version of standard Haskell98 lib? or, if it will be significantly extended - how much time this work will require and isn't that a duplication of work done at libraries list? i propose not to try to define reality, but accept existing one and join committee's work on new library definition with a current discussion of core libraries, which should define a set of libs available on any Haskell compiler on any platform - aren't goals the same? instead of providing rather small and meaningless standard Haskell library, now we can just include in Report docs existing and widely used libs, such as Network, mtl and so on. This will mean that language, defined in Haskell standard, can be used to write real programs, which will be guaranteed to run in any Haskell environment. of course, this mind game can't change anything in one moment. but it will change *accents* first, Haskell with its libraries will become language for a real work. such extended language isn't small nor easy to master in full, but it is normal for any mature programming environment. people learning Haskell should select in which area they need to specialize - be it gaming or web service development, and study appropriate subset of libs. people teaching Haskell now can show how *standard* Haskell may be used to solve real world problems, and this should change treatment of Haskell as academic language. also, we may expect that books teaching Haskell will start to teach on using standard libs, while their authors now don't consider teaching for non-standard libs second, by declaring these libs as standard ones we create sort of lingua franca, common language spoken by all Haskell users. for example, now there are about 10 serialization libs. by declaring one of them as standard, we will make choice simpler for most of users (who don't need very specific features) and allow them to speak in common language. in other words, number of Haskell libs is so large now that we should define some core subset in order to escape syndrome of Babel tower. defining core libraries set is just sharing knowledge that some libraries are more portable, easier to use, faster and so on, so they become more popular than alternatives in this area third. now we have Cabal that automates installation of any lib. next year we will got Hackage that automates downloading and checking dependencies. but these tools still can't replace a rich set of standard libs shipped with compiler. there are still many places and social situations where Internet downloading isn't available. Compiler can be sold on CD, transferred on USB stick. and separate Haskell libs probably will be not included here. Standard libraries bundled with compiler will ensure that at least this set of libs will be available for any haskell installation. Internet access shouldn't be a precondition for Haskell usage! :) fourth. now there is tendency to write ghc-specific libs. by defining requirements to the standard libs we may facilitate development of more portable, well documented and quick-checked ones. or may be some good enough libraries will be passed to society which will polish them in order to include in the set. anyway, i hope that *extensible* set of standard libraries with a published requirements to such libs would facilitate polishing of all Haskell libs just because ;) and this leads us to other question - whether this set and API of each library should be fixed in language standard or it can evolve during the time?... -- Best regards, Bulat mailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: base libraries
Hello Malcolm, Friday, November 24, 2006, 8:26:11 PM, you wrote: i think that we should require H' compatibility instead of H98 one, so require to not use fundeps, but allow MPTC. this means that NHC should be ruled out as non-H' compliant compiler instead of these libs Why pick on nhc98? Today, there are absolutely _no_ haskell-prime compliant implementations, because there is no haskell-prime standard yet. As and when the standard is fixed, implementations will catch up. that was started as internal GHC initiative, now seems to also have support from you and Ross Paterson and that's great. i hope we can consider this as initiative to define modern set of standard libraries which should be available with any modern Haskell compiler. because nowadays Haskell-prime standard also developed i hope that these two initiatives will come together, probably we can develop libraries part of this standard (or, to be exact, describe current state of widely used libs as Library Report part of this standard) the next question to consider is that a modern compiler? may be it's only ghc? or ghc/hugs which has a lot of common extensions? or ghc/hugs/nhc which is declared as supporting Base lib? or maybe all 5 compilers whose authors present here? in the light of forthcoming Haskell' standard, i propose to consider compatibility with H' as a mark that library may be standardized. it is especially important if we want to continue live of this proposal in the H' world instead of reinventing the wheel again yes, this means that some standard libraries will be available only for hugs/ghc now, but we have the same situation even for parts of Base library (Data.Array.*, at least) but when other problems arrives, this may be a stop-mark, because these problems will not be fixed in future NHC versions Who says? nhc98 is not dead. Yhc is a very active project, and it is basically just a re-branding of nhc98. i tried to say that problems which probably will be not fixed in future nhc versions, should be a stop-mark for inclusion library in standard set so, my proposal now is to require that libraries going to Core should obey H' standard in its current proposed form and for non-language features (if such exists) it should be compatible with ghc/hugs/nhc (i hope that yhc is compatible with nhc in this aspect) this will allow, when H' arrives and nhc will be updated to support this standard, to have standard libraries readily available on these 3 or 4 platforms of course, it's rather speculative to test on compatibility with non yet fixed standard. on the other hand, such tests may influence the standard itself, requiring inclusion of some language features that is required for some great lib (like mine ;) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: String literals
Hello Simon, Monday, November 13, 2006, 8:27:08 PM, you wrote: In my experience I've seen more requests for overloaded *Boolean* literals than strings. In a Fran context, for example. what you mean by this? а few days ago i've published in cafe small lib that allows to write things like (str 0 || 1) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Annotation system for Haskell
Both Java and C# provides annotations that can be used to pass some
additional information about code to around-language tools and queried
at program runtime via Reflection API:
[AuthorAttribute (Ben Albahari)]
class A
{
[Localizable(true)]
public String Text {
get {return text;
}
...
}
}
in the last poll for Haskell', it was widely noted that some form of
attribute (annotation) system for Haskell will be great, although
there is no any design yet. i think that i've found rather good one:
1. Attributes must be available at run-time via some library that
uses RTS-provided information, at compile-time for
TemplateHaskell-like language extensions using appropriate APIs, and
for 3rd-party tools like DrIFT using database generated by compiler
during compilation process
2. Attributes are linked to _entities_, which includes packages,
modules, values, types, classes and instances. Entity can be found by
specifying its _path_, say package Foo - module M - class Eq -
value (==). Of course this path on practice may be written just as
Foo:M:Eq:(==). Because almost any module imports class Eq from
Prelude, we can find the very same entity by a number of various paths,
including Base:Data.List:Eq:(==) and stm:Control.Concurrent.STM:Eq:(==).
If module A imports module B qualified, then path may look as Foo:A:B.f.
Of course, we will also need some way to get current package/module
name
3. It should be also possible to _enumerate_ all sub-entities of given entity
or all attributes of entity. I think that we should provide both ability to
enumerate all entities _available_ inside module and to
enumerate all entities _defined_ in the module
4. Each entity has a list of named attributes. We should provide a way
to define new attribute name together with its sort. Using Haskell
type to define this sort looks like a natural solution:
[Declare Author :: String]
[Declare Deriving :: [String]]
[Author Bulat]
data T = X | Y
[^Deriving [Eq,Ord]]
5. Then, using a path to entity and attribute's name, one can easily get
attribute value: getAttr Foo:M:T Author. Simplest solution is
just to return String representation of attribute value, leaving to
programmer the job of using read to convert this String value into
right type
I don't consider this in deeper details, but some form of dynamic
typing (Typeable/Data class) can also be used. Ideal solution will be
to allow programmer to define his own datatypes of attributes which
then may be used _both_ instead of [Declare] statements above and as
result type for getAttr function, say:
data MyAttrs = Author String
| Deriving [String]
deriving (Attribute)
[Author Bulat]
data T = X | Y
[^Deriving [Eq,Ord]]
use_reflection_api = case getAttr (CurrentPackage ++ : ++
CurrentModule ++ :T)
Author
of Author str - str
In this scenario, standard (predefined) attributes may be just
imported as part of Prelude, and user-defined attributes may be
defined in current or imported module
But while this way greatly simplifies and makes almost type-safe the
most common case - using of well-known attributes, it should also be
possible to keep 2 features:
1) ability to declare new attribute types inside a module and use
these new attributes immediately inside the same module
2) ability to enumerate and get values of attributes of unknown types.
imagine, for example, attribute browsing tool
6. Returning to compiler/3rd-party tools interaction, we can now say
that attributes database for each module should be build during
compilation of this module. It is something very like .hi file, one per each
module compiled, but for external consumption. It looks natural to use
XML format here, so the entity path will be translated into the path of
appropriate xml file and xml path inside the file. Information in this file
don't limited to the attributes provided by module writers, it can
also contains any information compiler may provide (types of values,
code metrics, options used when compiling module) and 3rd-party tools
can also add their own information here
it seems that also some indexing/xml merging tools should arise at
some moment to speed up access to this database, especially to databases
of installed packages
--
Best regards,
Bulat mailto:[EMAIL PROTECTED]
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String literals
Hello Lennart, Saturday, November 11, 2006, 6:49:15 AM, you wrote: class IsString s where fromString :: String - s My guess is that the defaulting mechanism needs to be extended to default to the String type as well, imho, it is MUST BE. this will allow to became ByteString and any other alternative string implementation a first-class Haskell citizen btw, String class is regularly debated and even implemented in fps-soc project where it includes a lot of common string functionality. just a head of this class: class (Eq s) = Stringable s where -- Introducing and eliminating -- | The empty string. empty :: s -- | Create a string containing a single 'Char'. singleton :: Char - s -- | Convert a string into a standard Haskell 'String'. toList :: s - [Char] toList = foldr (:) [] this may be disputed as part of library reorganization -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: String literals
Hello Donald,
Saturday, November 11, 2006, 7:33:48 AM, you wrote:
Yes, pattern matching is the issue that occurs to me too.
While string literals :: ByteString would be nice (and other magic
encoded in string literals, I guess), what is the story for pattern
matching on strings based on non-inductive types like arrays?
it's my day :) i'm regularly propose to pass list syntax to the
special class which should define methods for building and analyzing
data in head/tail way:
class ListLike ce e | ce-e where
-- Construction
empty :: ce
cons :: c - ce - ce
-- Analyzing
null :: ce - Bool
head :: ce - e
tail :: ce - ce
and then the following definition:
trim (' ':xs) = trim xs
trim xs = xs
would imply the following type constraints:
trim :: (ListLike ce Char, Eq Char) = ce - ce
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re[4]: [Haskell-cafe] Fractional/negative fixity?
Hello Nicolas, Wednesday, November 8, 2006, 1:25:23 AM, you wrote: prec ?? $ over-specification). You want ?? to bind more tightly than does $; that's exactly what this approach would let you specify. and how then compiler will guess that is relational priority of this operator comparing to '$!' ? :) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: [Haskell-cafe] Fractional/negative fixity?
Hello Henning, Monday, November 6, 2006, 1:27:54 PM, you wrote: print msg `on` mode==debug but failed because my code frequently contains '$' and there is no way to define operation with a lower precedence This could be solved by the solutions proposed in this thread: http://www.haskell.org/pipermail/haskell-cafe/2006-October/018923.html it's too complex for my purposes. -1 priority is enough -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell-cafe] Fractional/negative fixity?
Hello Dan, Saturday, November 4, 2006, 5:07:15 AM, you wrote: Here's an idea that (I think) is useful and backwards compatible: fractional and negative fixity. yes, i think the same. for example, once i've tried to define postfix 'when' operator like those in perl/ruby print msg `on` mode==debug but failed because my code frequently contains '$' and there is no way to define operation with a lower precedence really, there is another alternative to solve my particular problem: make `op` applications having fixed -1 precedence. such applications look heavyweight and once i have a wonderful debugging story just because for my eyes it was obvious that (a `div` b+1) means do add before div -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: Proposal for stand-alone deriving declarations?
Hello Brian, Thursday, November 2, 2006, 12:15:38 AM, you wrote: In particular, I think having features like : import M1 hiding (instance C T) and module M hiding (instance C T) would eliminate the need for special-case handling of derived instances (if two imported modules happen to derive the same instances, you can just hide the instances from one of them). Instance hiding is an important feature in its own right. i vote for this feature too. in my AltBinary library, there are many different ways to serialize strings, for example. i want to provide default instance Binary String for quickdirty use and ability to hide just this instance in the case when user need to overwrite it. now i forced to put all instance declarations in separate file and suggest user to copy this file into his project and make appropriate edits! also, expicit instance imports was in prewvious Haskell versions. so i think it will be great to use implicit importing of all instances by default but allow to hide all instances or specific instance and import just the instance required: import M (instance Binary String) -- hides all other Binary instances module M hiding (instance Binary) -- hides all Binary instances -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: Proposal for stand-alone deriving declarations?
Hello Malcolm, Thursday, November 2, 2006, 12:46:43 AM, you wrote: 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 i join to this note. moreover, currently GHC supports generics for the masses that may mean very subtle semantic changes between code generated by these two forms :)) i think it will be better to use derive/deriving/derived prepended to the former: derive instance Num (Bar z) derive instance Num z = Num (Bar z) and allow generics/TH/other forms of user-specified deriving to catch such declarations and provide alternative to compiler-wired deriving mechanism. so we can imagine that we discuss some general deriving syntax that in future will be reused by new Haskell extensions -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: digit groups
Hello Iavor, Thursday, October 26, 2006, 4:51:00 AM, you wrote: kb,mg,gb :: Num a = a kb = 1024 mb = 1024 * kb gb = 1024 * mb b :kb :mb :gb :_ = iterate (1024*) 1 :: [Int] b_:kb_:mb_:gb_:tb_:_ = iterate (1024*) 1 :: [Integer] and now we can write (4 * kb) instead for 4096. btw, your variant requires re-calculating values on each their use -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[4]: digit groups
Hello Taral, Thursday, October 26, 2006, 6:33:44 PM, you wrote: btw, your variant requires re-calculating values on each their use That's what constant folding is for. are c.f. should work for polymorhic values? afaiu, it's just the problem that leads to the famous monomorhism restriction. w/o type specifier your expressions will got monomorhic types -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: digit groups
Hello Jon, Wednesday, October 25, 2006, 6:37:33 PM, you wrote: 0x_3729 makes perfect sense as hex and the _ does a nice job of separating the digits into readable groups. 0x~~3729 looks similar, but doesn't mean the same thing at all. 0x~~0x3729 is ugly and probably less readable than the unbroken form. and it's again not the same - ~~ operator multiplies by 1000, not 65536 :))) No. A small alteration to the lexical syntax for the sake of improved readability seems perfectly justifiable as long as it doesn't make the lexical syntax /significantly/ more complicated or harder to learn. believe it or not, but i once implemented this as ghc patch and send to SPJ, who suggested me to postpone such micro-changes until new Haskell standard will be discussed :) afair, it was about 3 lines patch :) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Module imports anywhere
Hello Henning, Sunday, October 22, 2006, 5:48:11 PM, you wrote: I don't see the benefit of allowing imports anywhere at top-level. it is useful to move together imports and related code. say: #if HUGS import Hugs.Base addInt = hugsAddInt #elseif GHC import GHC.Base addInt = ghcAddInt #endif currently we are forced to make separate sections for import and use: #if HUGS import Hugs.Base #elseif GHC import GHC.Base #endif #if HUGS addInt = hugsAddInt #elseif GHC addInt = ghcAddInt #endif just another example: -- higher-level stuff: openFile = ... -- medium-level-stuff createFD = .. -- low-level stuff import System,FD _create = ... System.FD.create (i don't propose subj. i just know pros and contras for it) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Standard syntax for preconditions, postconditions, and invariants
Hello Alan, Thursday, October 19, 2006, 5:54:06 PM, you wrote: I propose that haskell' include a standard syntax for invariants that the programmer wants to express. The intent is not to have standardized checks on the invariants, its just to supply a common way to specify invariants to that the various strategies for checking them can all work from the same data. For example, one tool might use the invariants to generate QuickCheck properties seems that it should be a sort of annotation, yes? so we again need to define common annotation syntax and you can add this as one more possible usage to annotations-proposal page -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: (Pattern) Guards in lambdas
Hello Claus, Wednesday, October 18, 2006, 2:44:29 PM, you wrote: (\ arms ) x this looks great. smth like: proc $ \[x] - x*2 \[x,y] - x*y \[]- 0 -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Concurrency
Hello William, Sunday, October 15, 2006, 5:07:26 PM, you wrote: http://www.seas.upenn.edu/~lipeng/homepage/unify.html can this be ported to windows? (i don't yet read the paper) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Two things that i still can't understand in Haskell standard
Hello haskell-prime, first is the monomorphism restriction. why isn't it possible to check _kind_ of parameter-less equation and apply monomorphism restrictions only to values of kind '*'? so, this: sum = foldr1 (*) will become polymorphic because its kind is '*-*' while this exps = 1 : map (2*) exps will become monomorphic because its kind is * second is lack of support for prefix/postfix operations. why it is impossible to do in first pass only lexical analysis of Haskell program, then split it into sentences, extract all import/infix operations and only after processing of these operations, having all the information about operator types and precedence, do the syntax analysis? -- Best regards, Bulat mailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
three syntax-sugar proposals
Hello haskell-prime, 1. allow to use '_' in number literals. its used in Ruby and i found that this makes long number literals much more readable. for example maxint = 2_147_483_648 2. allow to use string literals in patterns as head of matched list: optionValue (kb++n) = read n * 2^10 optionValue (mb++n) = read n * 2^20 this syntax already used in Erlang 3. writing kinds is very rare task, but i still don't like to count number of stars in something like '* - * - * - *'. i think that representing this as '' will be more readable -- Best regards, Bulat mailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: Pattern guards
Hello Conor, Thursday, September 28, 2006, 10:30:46 PM, you wrote: gcd x y | compare x y - LT = gcd x (y - x) GT = gcd (x - y) y gcd x _ = x or some such. I wish I could think of a better example without too much context, but such a thing escapes me for the moment. In general, I think it's good to collocate on the left as much as possible of a function's scrutineering. Stringing out ifs and cases makes it harder to see what's going on. i like this. for me, left part of function definition is a half of logical programming language, it only omits two-direction pattern-matching mechanism -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[4]: Exceptions
Hello Manuel, Wednesday, September 6, 2006, 9:17:46 PM, you wrote: So, both features are truly orthogonal and, in fact, they are synergetic! More precisely, an alternative syntax for Löh/Hinze open types are overlapping type families. So, we might define S alternatively as data family S :: * data instance S = S1 data instance S = S2 to be exact, it's alternative syntax for GADT data S = S1 | S2 while open types just allows to split GADT definition into several chunks. It seems that you skipped this point - they also propose to use open technique for GADT-style definitions. as a result, while open data types are truly orthogonal to GADT, together they implement something very close to type families. the only difference between GADT+OT vs TF remains: GADTS+open types: * Local type-refinement in case alternatives Data families: * Type constraints due to indexes is propagated globally can you please explain that this means? In fact, there is nothing essential preventing us from having indexed families of GADTs for why? the only difference is that TF define a one-to-one relationship (each type index defines just one data constructor) while GADT define one-to-many relationship (one type index may be mapped to several data constructors). are we really need this difference and especially different syntax for such close things? just for curiosity, i was also interested in ideas of type-level programming and invented my own syntax that is more like yours. but really my syntax just based on the syntax of ordinary functions: type BaseType [a] = BaseType a BaseType (Set a) = BaseType a BaseType (Map a b) = BaseType a BaseType a = a is a recursive definition which may be evaluated with first-fit or best-fit strategy data Expr a= If (Expr Bool) (Expr a) (Expr a) Expr Int = Zero Expr Int = Succ (Expr Int) Expr Bool = TRUE Expr Bool = Not (Expr Bool) is alternative syntax for GADT. we may consider it as multi-value function, and 'data' defines functions that maps types into data constructors while 'type' defines functions that maps types into types. going further, why not allow 'type' to define multi-value functions? and vice versa, why not use 'data' to define one-to-one relation by best-fit or first-fit strategy? going further, why not define type of relation in function head? so that we can both use 'data' and 'type' to define one-to-one (non-overlapped) type families or one-to-many (overlapped, GADT-style) ones and even select matching strategy here? for example: data nonOverlapped T TTrue = CTrue T TFalse = CFalse data bestFit Eq a b = CFalse Eq a a = CTrue type firstFit Eq a a = TTrue Eq a b = TFalse -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: Exceptions
Hello Simon, Thursday, August 31, 2006, 12:33:26 PM, you wrote: I don't think we need more extensions to do a reasonable job of extensible exceptions: http://www.haskell.org/~simonmar/papers/ext-exceptions.pdf i'm not yet read but guess that this is paper you will present at ICFP? can you please say in 2 words - what is the current state of this? is it can be used with ghc 6.4, or 6.6, or ...? some solution in this area, imho, is a must for serious application development -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: Exceptions
Hello Andres, Friday, September 1, 2006, 2:27:34 PM, you wrote: Thanks for your interest in open data types. As one of the authors of the open data types paper, I'd like to comment on the current discussion. i'm not yet read about this, but may be open types have something in common with type families already implemented by Manuel Chakravarty? http://hackage.haskell.org/trac/ghc/wiki/TypeFunctions one more question what i still plan to ask him is what is the difference between GADTs and type families -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: map and fmap
Hello Duncan, Tuesday, August 15, 2006, 2:37:50 AM, you wrote: If it goes in that direction it'd be nice to consider the issue of structures which cannot support a polymorphic map. Of course such specialised containers (eg unboxed arrays or strings) are not functors but they are still useful containers with a sensible notion of map. unboxed arrays - not if you using implementation from ArrayRef lib ByteStrings - can be also parameterized by its type elements, as i always suggested. of course, these elements should be unboxable and belong to the Storable class in order to allow peek/poke them there is also faking solution: type ByteStr a = ByteString instance Functor ByteStr (although i never tested it) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
allow to give default implementatoions for methods of base class
Hello Jon, Monday, August 14, 2006, 1:49:58 PM, you wrote: instance Monad [] where fmap = map return x = [x] join = concat i support this idea. [...] I'm not sure it's quite right. Surely it only makes sense if it defines all the (necessary) superclass methods -- in other words, what you are doing is defining an instance, just omitting the instance Functor [] line, which doesn't seem like a great advantage. This shrinks size of code that is especially important when writing a lot of small instances. second, it allows me to think that all the methods belongs to the same class instead of specifying each and every class: class Show s = Stream s where sTell :: .. class Stream s = OutputStream s where sPutChar :: .. instance Show s where show = .. instance Stream s where sTell = .. instance OutputStream s where sPutChar = .. i might prefer to write just instance OutputStream s where sPutChar = .. sTell = .. show = .. - and as you can see i also changed the ordering/grouping of operations. of course it's just syntax sugar, but i like it - it will shrink class declarations and bring them closer to OOP style when derived class also owns all the methods of base classes If we are going to play around with this stuff, here's another suggestion that solves my original problem more neatly: In a class declaration, a superclass context is a requirement that instances of the class have instances of the superclass; this is similar to the type declarations of the methods. We could have had class Monad m where instance Functor m (=):: ... instead of class Functor m = Monad m where (=):: ... of course, there's no reason to do that, but what I'm proposing is that we allow default instance declarations in class declarations in much the same way as default methods: class Functor m = Monad m where i think, you mean: class Monad m where instance Functor m where fmap f = (= return . f) (=):: ... return:: ... join:: ... i support this too. but bringing these two ideas together the class declaration should look as class Functor m = Monad m where fmap f = (= return . f) (=):: ... return:: ... join:: ... and instance declaration should be: instance Monad [] where fmap = map return x = [x] join = concat instead of: instance Monad [] where return x = [x] join = concat instance Functor [] where fmap = map this proposal should be named as subj, independent of syntax form used -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[4]: All Monads are Functors
Hello Taral, Monday, August 14, 2006, 3:34:29 PM, you wrote: On 8/14/06, Jon Fairbairn [EMAIL PROTECTED] wrote: of course, there's no reason to do that, but what I'm proposing is that we allow default instance declarations in class declarations in much the same way as default methods: I just realized that default superclass methods have a small problem: module A contains instance Monad [] module B contains instance Functor [] module C imports A and B. Do we complain about a duplicate instance declarations? yes. after all, this is just syntax sugar of giving both declarations: instance Monad [] where fmap = map return = (:[]) is equivalent to instance Functor [] where fmap = map instance Monad [] where return = (:[]) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: Class System current status
Hello Stephanie, Thursday, May 11, 2006, 5:45:15 PM, you wrote: - We're already in that state. There *is* a lot of Haskell code that uses FDs, it's just not Haskell 98 code. Whenever ATs take over, we'll still have to deal with this code. are you sure about *lots* ? i seen only 3-4 ones (monad transformers, collections, may be arrays, my streams) and think that all these libraries can be redesigned without any problems once in several years. that is really important is that CLIENTS of these libraries don't need to be changed - It may be that all uses of MPTCs/FDs may be subsumed by ATs, and in fact there is (or will be) some automatic way of translating FD code to AT code. i think that is not necessary considering that i said above - It may not be all bad for a future Haskell standard to include both ATs and FDs. Certainly more complicated, but I haven't seen any evidence that these features interfere with eachother. language should be orthogonal, i.e. include only one way to implement each feature. otherwise, it becomes too large Are there any merits to these counterarguments? More generally, our discussion about the class system seems to be stalled. How should we to come to a decision? i think the same - goal of discussion should be developing of proposal/proposals in this area for Haskell' committee. any other directions of discussion, while very important for future of Haskell language, should be somewhat limited or moved to cafe list. i propose the following structure of discussions: 1. initial proposal 2. critique 3. correction of proposal and going to 2nd step 4. final proposal or abandoning this proposal making several concurrent proposals on the same topic would be great because concurrency motivates to make better things and because ideas can be easily borrowed by proposals from each other -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org//mailman/listinfo/haskell-prime
Re[2]: Class System current status
Hello Johannes, Friday, May 12, 2006, 4:18:29 PM, you wrote: = Partial p i b | p i - b where ... -- (*) (*) A funny visual aspect of FDs is the absurd syntax. On the left of |, the whitespace is (type arg) application, but on the right, it suddenly denotes sequencing (tupling) i also don't like this - it's really confusing. p,i-b will be better approach -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org//mailman/listinfo/haskell-prime
Re[2]: Class System current status
Hello Simon, Friday, May 12, 2006, 8:05:25 PM, you wrote: My suggestion is this: * Specify MPTCs in the main language * Specify FDs in an Appendix (with some reasonably conservative interpretation of FDs). * A Haskell' implementation should implement the Appendix, and programmers can write programs against it. But we are advertising specifically that we aren't sure, one way or the other, whether FDs will stay in the language for ever i agree with that and even feel that this proposal reflect viewpoint of most of us (of course, i may be wrong). moreover, my own proposal is essentially the same, only from practical viewpoint - use FDs today but be ready to reimplement these libs several years later using some new extension. so the developer will decide whether he prefer to have maximum features or maximum compatibility moreover, i think that idea of Appendixes can be used to allow many other extensions be somewhat standard but not required in each and every compiler. this includes GADT, concurrency, TH, TRex and many other things -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org//mailman/listinfo/haskell-prime
Re: Class ATs Question
Hello Ashley, Friday, April 28, 2006, 5:09:07 AM, you wrote: You can do two-way fundeps. Can these be done with associated types? For instance: It might not be a great loss if not. may be you want to say it might be a great loss ? i'm using two-way fundeps to implement monad-independent algorithms that uses references. these definitions: class (Monad m) = Ref m r | m-r, r-m where newRef :: a - m (r a) readRef :: r a - m a writeRef :: r a - a - m () instance Ref IO IORef where newRef = newIORef readRef = readIORef writeRef = writeIORef instance Ref (ST s) (STRef s) where newRef = newSTRef readRef = readSTRef writeRef = writeSTRef allows me to write algorithms that works in both monads -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re[2]: deeqSeq proposal
Hello John, Tuesday, April 11, 2006, 2:43:49 AM, you wrote: true. in any case, deepseq is not always a win. don't forget that Andy don't plan to apply deepSeq to any expression. in his program, there is a LARGE datastructure with a couple of unevaluated thunks what may be simplified by call to deepSeq. your example is based exclusively on the syntax transformations of source code, i think that in his program the logic is so complex that such syntax transformations is entirely impossible anyway i think that the easisest way for Andy to get what he need is to write ghc-specific `deepSeq` implementation that should just walk unevaluated parts of datastructure and evaluate them all. as i understand, he don't need to evaluate arguments of partially applied functions - there is just no such beasts in his data -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re[2]: FFI, safe vs unsafe
Hello John, Tuesday, April 4, 2006, 5:55:19 AM, you wrote: In my survey of when 'reentrant concurrent' was needed, I looked at all the standard libraries and didn't find anywhere it was actually needed. Are there some compelling examples of when it is really needed in a setting that doesn't have OS threads to begin with? may be i can help? :) i'm not sure that i understood you properly, but my own compression program uses several compression algorithms, written in C, in parallel - i.e. output from first algorithm is piped to the second and so on. if this is not enough - all these algorithms are executed via one function, which receives algorithm name and input/output routines, so i run in parallel, for example: compress words read_func1 write_func1 and compress ppm read_func2 write_func2 -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Deriving for newtypes
Hello , as i see, it was some form of formal specification for subj: http://www.cse.unsw.edu.au/~dons/haskell-1990-2000/msg05468.html -- Best regards, Bulat mailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re[2]: 'deriving Tree (Eq,Ord)'
Hello Ross, Tuesday, April 4, 2006, 4:55:09 PM, you wrote: http://www.cse.unsw.edu.au/~dons/haskell-1990-2000/msg00727.html (Making 'deriving' a separate declaration instead of a clause) Orphan instances are discouraged in the GHC libraries, so there might not be much support for adding a feature designed to permit orphan derived instances. sorry, i don't understand how them are discouraged? GHC can't support this because of it's internal limits? i think you mean some other thing but i can't understand you -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re[2]: FFI, safe vs unsafe
Hello John, Monday, April 3, 2006, 12:53:05 PM, you wrote: new stacks can be allocated by alloca() calls. all these alloca-allocated stack segments can be used as pool of stacks assigned to the forked threads. although i don't tried this, my own library also used processor-specific method. so you alloca new big areas and then use 'longjmp' to jump back and forth within the same stack simulating many stacks? yes that is a neat trick. will confuse the hell out of the bohem garbage collector but I don't want to rely on that much longer anyway :) setjmp/longjmp is not compatible with C++ exception handling (because stack unwinding will be confused :) ). may be this GC also don't compatible with setjmp/longjmp in any case? it will be cool to extend jhc with multi-threading -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re[2]: FFI, safe vs unsafe
Hello John, Saturday, April 1, 2006, 4:53:00 AM, you wrote: In an implementation which runs more than one Haskell thread inside one OS thread, like ghc without -threaded or hugs, the threads are NOT completely independent, because they share one C stack. So while no, state-threads, a la NSPR, state-threads.sf.net, or any other of a bunch of implementations. each thread has its own stack, you 'longjmp' between them. it can almost practically be done in portable C except the mallocing of the new stack, new stacks can be allocated by alloca() calls. all these alloca-allocated stack segments can be used as pool of stacks assigned to the forked threads. although i don't tried this, my own library also used processor-specific method. i planned to suggest this to the ghc-via-C compilation we are discussed on February. it's great that the libs already exists. why you don't implement this himself, at least in cooperative (yield-driven) manner? -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re[4]: thread priorities?
Hello Simon, Friday, March 31, 2006, 4:57:19 PM, you wrote: threadSetPriority :: ThreadID - Int - IO () it was requested by Joel Reymont, and he even give us information how that is implemented in Erlang, together with hint to assign higher priorities to consuming threads. Yes, but the Erlang implementation doesn't do anything about priority inversion. Also, I don't think Joel really wanted priorities, his problem could have been solved by using bounded channels. to be exact, his problem (1000 producers and one consumer) can be solved ONLY by using some bounded queue. but for typical usage when there are one or several producers and one consumer, priorities allow to solve problem: 1) in easier and more intuitive way, that is well known from other environments (Unix, for example) 2) without introducing new data structures - bounded channels, bounded priority queues and so on, so on (although it should be easy to construct them) priorities are also useful for solving other problems, where bounded queues can't help us. as i said, my own program contains one thread that reads thousands of files from disk and pushes their data into the queue. then other threads process these data. as you can see, first thread is I/O-bound while other is CPU-bound. of course, i want to give higher priority to the first thread so that it reads next portion of data as soon as previous read operation is complete (and there is free buffer). how can i accomplish it with current ghc implementation? -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re[2]: Concurrency
Hello David, Saturday, April 1, 2006, 4:31:05 PM, you wrote: I'd like to be sure that asynchronous exceptions can get into the standard. They require concurrency, but I'm not sure that they're included in John's page. this an another ticket It would also be nice to address signal behavior, and by default state that signals should be converted to asynchronous exceptions. it was surprise for me that i don't receive ^Break as an exception and should do something special to handle this. on the other side, in more complex setting involving lengthy FFI calls, ghc's solution is the only way to let know to this FFI function that it should abort his execution -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
the following program can't be compiled with ghc 6.4.1
to be fair, it also don't work with Hugs 03 and Hugs 05 data UnboxedMutableArray i e = UMA !i !i type IOUArray i e = UnboxedMutableArray i e data Dynamic a i e = Dynamic (a i e) type DynamicIOUArray s = Dynamic IOUArray if second line substituted with the following type IOUArray = UnboxedMutableArray then all compilers are happy. i don't know, may be i should appeal to Haskell' committee instead of compiler developers (but you are the same persons, anyway :) btw, the kinds are trickiest language part, especially in Hugs what don't supports kind annotations. in one case compiler don't accept partial type (as here), in other case compiler don't accept extraneous parameters. as net result, making type definition that will work everywhere is a kind of shamanism -- Best regards, Bulat mailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
unicode/internalization issues
Hello haskell-prime, i've planned some time ago to open unicode/internalization wiki page, what reflects current state of the art in this area. here is the information i have, please add/correct me if i don't know something or wrong. 1. Char supports full Unicode range (about million of chars) instead of just 8-bit ASCII: implemented in GHC 6.0 and Hugs 2005 (i'm not sure about exact versions) 2. Character classification/convertion routines in Data.Char: all Unicode chars managed properly starting from GHC 6.4 and Hugs 2005. Author of this update, Dmitry Golubovsky, also provides it as additional lib for ghc 6.2.2, and i think it is possible to extend his work to work with any compiler supporting wide Chars. 3. Unicode support in I/O routines, i.e. ability to read/write UTF-8 encoded files and files what use other Unicode byte encodings: not implemented in any compiler, afaik, but there are 3rd-party libs: Streams library, New I/O library, and even CharIO module from jhc sources 4. Support for UTF-8 encoded source files: implemented in ghc 6.5 and jhc. afaik, ghc's support is more advanced because it uses abovementioned routines to classify Chars, so you can use any national characters in identifiers according to their case, and all other symbols in operators. because ghc 6.5 supports ONLY utf-8 encoded source files, these creates some problems when compiling files created for previous versions of ghc (or for other compilers) and using ASCII encoding with national (chr 127) chars in comments and especially string literals. GHC team asked their users for best solution of this problem if i don't mentioned here any issues regarding unicode/internalization, please add this -- Best regards, Bulat mailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re[2]: important news: refocusing discussion
Hello Ross, Saturday, March 25, 2006, 4:16:01 AM, you wrote: On Fri, Mar 24, 2006 at 02:47:09PM -, Simon Marlow wrote: I think it would be a mistake to relegate concurrency to an addendum; it is a central feature of the language, and in fact is one area where Haskell (strictly speaking GHC) is really beginning to demonstrate significant advantages over other languages. We should make the most of it. Essential for many applications, certainly, but central? How can you say that? it becomes central language feature just because it's much easier to write concurrent programs in Haskell than in other languages and because ghc's implementation of user-level threads is blazing fast, outperforming closest competitor in hundreds (!) times in the Language Shootout concurrency testing so, the concurrent programming, may be, the only area at now, where real-world, commercial programmers should prefer Haskell over all other languages. in this light, leaving the concurrency outside of language standard will decrease our chances of pushing the language to the commercial arena and gathering critical mass of Haskellers -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Ticket #15: add a binary IO interface
Hello Bulat, Wednesday, March 22, 2006, 4:38:13 PM, you wrote: BZ about this - i'm almost sure that current widely used libraries BZ (NewBinary) is not as good as my own one BZ (http://freearc.narod.ru/Streams.tar.gz) is not ever used and even BZ still not documented, so it is not easy to make right choice :) sorry. this can be misunderstood, i want to say that _my_ library is not ever used and its AltBinary part is not documented -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re[2]: Strict tuples
Hello Wolfgang, Wednesday, March 22, 2006, 1:29:24 AM, you wrote: you said WHAT you think but not said WHY? my motivation is to be able to use myriads of already implemented algorithms on new datatypes as i said, shebang patterns allow only to specify that IMPLEMENTATION of some function is strict. this helps only when this function are called directly. they can't help when function is passed as parameter or enclosed in data structure or a part of class. the same about datatypes - i can't declare what some algorithm works only with strict lists. i try to find extensions what will allow to specify strictness in every case where now we forced to use lazy computations the concrete syntax what i propose may be wrong WJ Well, it's probably nice sometimes to have types which guarantee the WJ strictness of certain components. For example, it might be good to have a WJ list type where the strictness of the elements is guaranteed. But I'm sure WJ that it's wrong to try to achieve this by annotating type arguments like in WJ [!a]. I think, this approach is wrong, not just the syntax. WJ Best wishes, WJ Wolfgang WJ ___ WJ Haskell-prime mailing list WJ Haskell-prime@haskell.org WJ http://haskell.org/mailman/listinfo/haskell-prime -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Ticket #15: add a binary IO interface
Hello , about this - i'm almost sure that current widely used libraries (NewBinary) is not as good as my own one (http://freearc.narod.ru/Streams.tar.gz) is not ever used and even still not documented, so it is not easy to make right choice :) -- Best regards, Bulat mailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re[2]: Strict tuples
Hello Simon, Monday, March 20, 2006, 1:47:52 PM, you wrote: i've proposed to allow adding strict mark to any type constructors and type constructor parameters so that finally we can define any data structure that can be defined in strict languages. in particular: type StrictPair a b = !(,) a b type StrictElements a b = (,) !a !b type StrictBoth a b = !(,) !a !b type StrictFunction a b = !(-) !a !b strictMap :: StrictFunction a b - ![!a] - ![!b] where ![!a] is a strict list with strict elements SM Bulat, this doesn't constitute a proposal. It leaves too many questions SM unanswered. If it is supposed to be just syntactic sugar, and I believe SM that is your intention, then can you show me how the above definitions SM translate into Haskell 98? i'm not sure that i can make complete proposal, but i can say what i mean in more details: one of the differences between Haskell and most other languages is what even when we don't need laziness we are forced to buy it. so i want to see the language where laziness is optional at any place. shebang patterns allow to specify that concrete IMPLEMENTATION of some function is strict in its using of parameters. but this can't help us if we want to carry strict function in data structure, pass it as function argument, has is as a class member. i was bitten by this when i wrote Streams library - although Char encoding transformers are simple strict computations that just read several bytes and then return one Char, and byte reading operation by itself is very fast - they cannot be combined to fast Char-reading function. another problem is what while we can specify strictness of fields in ADTs, we cannot redefine strictness of fields in existing ADT, such as list. my solutions to these problems: 1) make a strictness annotation part of function type declaration, i.e. when function type can include strictness annotation on each of its arguments and on result: fac :: !Int - !Int - !Int strictness annotation on argument means that function is strict in this argument - if its value diverges then entire function diverges. informally, strict argument can be evaluated before evaluation of function body, as in the strict languages - what opens up possibility to unbox such values and to omit checking of argument evaluation in function body, moving this evaluation to the caller side strictness annotation on result means that function DON'T DIVERGE if all arguments are don't diverge. this allows to unbox result and to skip checking that result was evaluated on callee side by moving real computation inside the function. informally, this means that a function is inexpensive enough and therefore can be computed non-lazily 2) to allow changing of strictness inside existing ADTs, i propose to copy strictness annotations on type arguments to the type declaration bodies: data List a = Nil | Cons (List a) a type StrictElements a = List !a is equal to the: data StrictElements a = Nil | Cons (List a) !a i.e. it's the same list but each element is strict. using strictness annotation on type constructor itself should mean strictifying of all other (non-type-variable) fields: type StrictList a = !List a = data StrictList a = !Nil | !Cons !(List a) a of course, i don't mean introducing new incompatible types - that is a compiler responsibility (sorry, Simon :) ) to convert between variants of types with different strictness. That we should fix at the language definition level is what on strict types te user don't expects lazy evaluation of list/it's elements and compiler is free to use program transformations what non-lazily computes these data. for example, if putStr function accepts strict list, then it can be implemented without evaluated? checks on each step and the callers would ensure that all strings passed to this function are fully evaluated these two changes together should make it possible to implement strictly strict algorithms in Haskell -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re[2]: the MPTC Dilemma (please solve)
Hello Lennart, Sunday, March 19, 2006, 4:05:03 AM, you wrote: LA I have to agree with Manuel. I write a lot of Haskell code. LA People even pay me to do it. I usually stay with Haskell-98, when i wrote application code, i also don't used extensions very much, i even don't used Haskell-98 very much and afair don't defined any type classes at all but when i gone to writing libraries, that can be used by everyone, type classes and requirement in even more extensions is what i need permanently. in particular, i try to write library so what any conception (stream, Binary, reference, array) can be used in any monad and that immediately leads me to using MPTC+FD. moreover, problems with resolving class overloading and other deficiencies of current unofficial Hugs/GHC standard are permanently strikes me so, from my point of view, we should leave MPTC+FD+any well-specified extensions in resolution of overlapping classes. but these should be seen only as shortcuts for the new type-calculation functions, like the old-style data definitions now seen as shortcuts for GADT ones just some examples how this can look: i had a class which defines default reference type for monads: class Ref m r | m-r where newRef :: a - m (r a) readRef :: r a - m a writeRef :: r a - a - m () instance Ref IO IORef where ... instance Ref (ST s) (STRef s) where ... this class allows to write monad-independent code, for example: doit = do x - newRef 0 a - readRef x writeRef x (a+1) readRef x can be runned in IO or ST monads, or in any monad derived from IO/ST (with appropriate instance Ref definitions). As you can see, even such small example require using FDs. That's all great but not flexible. That we required is a real functions on type values. In ideal, types should become first-time values, compile-type computations should be allowed (what resembles me Template Haskell), and computed types should be allowed to used in any place where current Haskell allows type literals. moreover, runtime-computed types can be used for dynamic/generic programming, but that is beyond of our current theme. really, Haskell already has functions on types: type Id a = a type Two a = (a,a) and so on. but these definitions don't have full computational (Turing) power, can't contain several sentences, can't be split among different modules/places and so on, so on. on the other side, class definitions are our most powerful type functions, but has very different syntax and semantic model compared to plain functions, plus had some additional duties (declaring a family of functions) how about adding to type functions the full power of ordinal functions? first, data/newtype declares new type constructor on its left part in the same way as it defines new data constructors on its right part: data List a = Nil | Cons a (List a) defines Nil and Cons data constructors and List type constructor. Together all data constructors defined in program plus primitive types (Int, Char...) defines a full set of types that can be constructed/analyzed by type construction functions. so, we should not only allow to construct new more complex types on the right side of type function, but also allow to analyze complex types on the left side of function definition! : type Element (List a) = a Element (Array i e) = e Element (UArray i e) | Unboxed e = e cute? i love it :) i also used pattern guard here, it's a partial replacement of Prolog's backtracking mechanism. of course, to match power of type classes, we should allow to split these definitions among the whole module and even among the many modules. library type function should be allowed to be extended in application modules and application definitions should have a priority over library ones this will allow to rewrite my Ref class as: type Ref IO = IORef Ref (ST s) = STRef s Next problem is declaring types (to be exact, kinds) of type functions. currently, kinds are defined only in terms of arity: type ReturnInt (m :: * - *) = m Int but what we really want is to declare that `m` is Monad here: type ReturnInt (m :: Monad) = m Int or type ReturnInt :: Monad - * type ReturnInt m = m Int i also propose to show kind arity by using just **, *** instead of current *-*, *-*-*. the above definition can be extended in user module by: type ReturnInt (ST s) = Int but not with type ReturnInt Int = IO because last definition break types for both left and right sides having all this in mind, we can break class definitions into the lower-level pieces. say, class Monad m where return :: a - m a fail:: String - m a instance Monad IO where return = returnIO fail = failIO translates into: type Monad :: ** - (a - m a, String - m a) type Monad IO = (returnIO, failIO) i.e. Monad is function that translates '**' types into the tuple containing several functions. well, translation is not ideal, but at least it seems promising
Re[4]: Keep the present Haskell record system!
Hello Claus, Monday, March 6, 2006, 2:35:04 PM, you wrote: also, while i like dynamic records for some types of tasks, i think that the spirit of Haskell in whole is to give explicit definitions of all types used and in this respect this type extension in not on main way. CR record extension is the basis for record concatenation, which is CR the basis for composing programs that use records. for instance, CR if you have two attribute grammars that compute two sets of CR attributes and you want to compose them into a single grammar, CR you run into troubles. (dual arguments for extensible variants, CR be it for exception types, or for extensible grammars that cover CR haskell+extensions without having to specify and maintain two CR separate grammars). and the concept of partial type specifications CR is not uncommon in Haskell (polymorphism, type classes). (sorry for late answer) this again should be maintained in Haskell way, i.e. with static type declarations: data Pizza = ... data Cola = ... type PizzaWithCola = Pizza+Cola weight :: PizzaWithCola - Double weight pc = pizzaWeight pc + colaWeight pc pizzaWeight :: Pizza - Double colaWeight :: Cola - Double it is one more remainder of what we need OOP-like features such as data fields inheritance. O'Haskell has something in this area, although afair it doesn't support the multiple inheritance -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re[4]: the MPTC Dilemma (please solve)
Hello Manuel, Sunday, March 19, 2006, 7:25:44 PM, you wrote: i had a class which defines default reference type for monads: class Ref m r | m-r where to be exact, class Ref m r | m-r, r-m where newRef :: a - m (r a) readRef :: r a - m a writeRef :: r a - a - m () or even worser: class Ref2 m r a | m a-r, r-m instance (Unboxed a) = Ref2 IO IOURef a instance (!Unboxed a) = Ref2 IO IORef a instance (Unboxed a) = Ref2 (ST s) (STURef s) a instance (!Unboxed a) = Ref2 (ST s) (STRef s) a MMTC My statement remains: Why use a relational notation if you can have a MMTC functional one? how about these examples? MMTC class Monad m = RefMonad m where MMTC type Ref m :: * - * can i use `Ref` as type function? for example: data StrBuffer m = StrBuffer (Ref m Int) (Ref m String) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re[2]: [Haskell-cafe] STUArray
Hello Chris, Sunday, March 12, 2006, 2:05:09 PM, you wrote: CK Is GHC.PArr documented? it's perfectly documented in module sources itself :) you can also look at the ndpFlatten directory in ghc compiler's sources. i've successfully used them in my program, of course this makes program faster but only-GHC compatible. so i plan to document it on http://haskell.org/haskellwiki/Arrays and incorporate it in Data.Array.* infrastructure so that strict arrays will be emulated under Hugs. CK The -fparr option is not in the 6.4.1 User's Guide. they just forgot to do this :) btw, strict arrays will be a good candidate for Haskell-prime library standard -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re[2]: darcs patch: add Data.Set.notMember and Data.Map.notMember
Hello Christian, Friday, March 10, 2006, 2:32:02 PM, you wrote: f x | not (x `Set.member` map) foo = ... is hard to read. btw, (x `not.Set.member` map), as proposed by Doaitse Swierstra, will look better in this case -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: small extension to `...` notation
Hello Doaitse, Thursday, March 9, 2006, 12:01:37 AM, you wrote: DS xs `zipWith (+)` ys i had the same desire several times Possibly `(expr)` ? it will be non-readable. it is better to just prohibit using of backquotes inside backquotes. and fixity can be fixed at 0, imho. at least, my cases was just when i want to use two words inside backquotes instead of just one. and fixity should be 0 because such expression with space inside it should have a small priority because parts of expression too distant from each other (btw, i had (not serious) proposal to raise priority of operations if there is no spaces around it, so that the following: x:xs ++ y:ys translates to (x:xs)++(y:ys) in full accordance with natural reading) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re[2]: Keep the present Haskell record system!
Hello Claus, Monday, March 6, 2006, 4:30:04 PM, you wrote: my own opinion is that this scheme is like classes - they can be resolved at compile time in most real cases but noone do it because code will be too large. if some function can accept any records which has field 'a' then to use this function on records of different types we need either to do specialization or use scheme with non-constant access time CR for those who haven't seen it, the following paper explored the former CR possibility with good success (at a time when type classes where CR still somewhat simpler:): CR Dictionary-free Overloading by Partial Evaluation CR Mark P. Jones, ACM SIGPLAN Workshop on Partial CR Evaluation and Semantics-Based Program Manipulation, CR Orlando, Florida, June 1994. CR http://www.cse.ogi.edu/~mpj/pubs/pepm94.html 2-3 weeks ago i rolled in ghc-users list list of suggestions to improve ghc efficiency and make it close to C++. in particular, i proposed to make more aggressive compile-time specialization (at cost of less aggressive inlining of non-polymorphic functions) like the C++ templates common-used implementation. may be, i don't know something, but i think that in most cases we can end up with fully specialized code -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re[2]: overlapping instances and constraints
Hello John, Tuesday, February 28, 2006, 4:23:24 AM, you wrote: i had plans to propose the same and even more: instance C2 a b | a/=b JM I was thinking it would be all kinds of useful if we had two predefined JM classes JM class Eq a b JM class NEq a b JM where Eq has instances exactly when its two types are equal and NEq has JM instances exactly when its two types are not equal. JM Eq should be straightforward to implement, declaring any type JM automatically creates its instances. (sort of an auto-deriving). NEq JM might be more problematic as that would involve a quadratic number of JM instances so its implementation might need to be more special. but JM perhaps we can do with just 'Eq'. with 'Eq' class we can't do anything that is impossible without it :))) the whole devil is to make general instance NON-OVERLAPPING with specific one by EXPLICITLY specifying EXCLUSIONS with these /= rules: class Convert a b where cvt :: a-b instance Convert a a where -- are we need Eq here? :) cvt = id instance (NEq a b) = Convert a b where cvt = read.show ... yes, i recalled! my proposal was to allow ! in instance headers: instance C Int where ... instance (!Int a, Integral a) = C a where ... instance (!Integral a, Enum a) = C a where ... adding your Eq class, it will be all we can do on this way interesting, that the language theoretics can say about decidability, soundness, and so on of this trick? :) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re[2]: overlapping instances and constraints
Hello Claus, Tuesday, February 28, 2006, 1:54:25 PM, you wrote: CR class NEq a b CR instance Fail a = NEq a a CR instance NEq a b i think that this definition just use ad-hoc overlapping instances resolution mechanism that we want to avoid :))) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: public/private module sections (was: Haskell-prime Digest, Vol 2, Issue 58)
Hello Claus, Friday, February 24, 2006, 2:46:40 PM, you wrote: CR yes, this would add one constraint on where to place definitions. but CR grouping logically related definitions together is not quite what one CR might think anyway: aren't the definitions making up the interface CR most strongly related, with the others just changeable auxiliaries? so: -- |iterate function over list map :: (a-b) - [a] - [b] -- |find length of list length :: [a] - Int private: map f (x:xs) = f x : map f xs map f [] = [] length xs = length# xs 0# length# (x:xs) n# = length# xs (n# +# 1) length# [] n# = n# and in order to see map's type or comment when i implement it, i should see to other part of file. i personally prefer to have public/private modifiers on each function and gather interface documentation by tools like haddock -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re[2]: public/private module sections (was: Haskell-prime Digest, Vol 2, Issue 58)
Hello Claus, Friday, February 24, 2006, 6:55:51 PM, you wrote: CR not quite (though I believe that would be close to Simon M's idea). CR in my modification, both map and length would move completely CR into the export section WHY? it's not the interface. implementation of exported functions is of no interest for module users like the implementations of any other functions. i tried to emphasize this moment - in any case we should either duplicate part of code or have the definitions splitted in the very unpleasant manner. i prefer instead to not have interface section at all and generate it automatically by haddock -- |iterate function over list map :: (a-b) - [a] - [b] -- |find length of list length :: [a] - Int private: map f (x:xs) = f x : map f xs map f [] = [] length xs = length# xs 0# length# (x:xs) n# = length# xs (n# +# 1) length# [] n# = n# and in order to see map's type or comment when i implement it, i should see to other part of file. i personally prefer to have public/private modifiers on each function and gather interface documentation by tools like haddock -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re[2]: public/private module sections (was: Haskell-prime Digest, Vol 2, Issue 58)
Hello Claus, Friday, February 24, 2006, 7:53:09 PM, you wrote: CR public class C a CR where CR public m1 :: a CR private m2 :: a - String please don't stop on this! public map (private f) (public (private x:public xs)) = private (public f (private x)) `public :` private map (public f) (private xs) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re[2]: Module System
Hello Simon, Thursday, February 23, 2006, 2:21:22 PM, you wrote: SMghc --make My.Dotted.Module.hs Main.hs SM works fine. Similarly with GHCi. i don't known that. we should add this to faq SM It's only when GHC has to actually *find* a source file for a module SM that the hierarchical naming convention comes into play. There are two SM reasons we don't allow the dotted convention: one is simplicity (the SM description of where GHC looks for files is already a bit complex), and SM the other is performance - GHC does a lot of looking for interface SM files, and looking in more places might slow things down (I haven't SM measureed it, though). 1) ghc's startup speed (before it compiles any module) is good enough at this moment 2) that will slower search only for modules that use this advantage. modules that don't use new naming scheme (including all std library modules) will be found in just the same time -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re[2]: Pragmas for FFI imports
Hello Simon, Wednesday, February 22, 2006, 12:53:09 PM, you wrote: SM simplicity, packages are the unit in several concepts: distribution, SM dependency, versioning, licensing, dynamic linking, include file SM dependencies, external library dependencies, and more. If we start SM confusing the issue by having smaller units for some of these concepts, SM things get even more complicated. i definitely don't want to create packages just to add to my application several C-defined functions. and moreover i think that it will make using FFI in Haskell harder for novices. now it's rather simple with ghc and i will be happy to preserve this simplicity. this means please preserve ability to specify include files and make this uniform for all haskell'-compilers. -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re[2]: Array interface refactoring
Hello Ben, Wednesday, February 22, 2006, 9:47:19 PM, you wrote: BRG While we're on the topic, I have a couple of problems with the current array BRG system that cut deeper than the naming: BRG * The function for getting the bounds of an MArray is pure, so the BRGinterface can't accommodate resizable arrays. i think that it is because such arrays can be implemented more efficiently. then you can implement dynamic arrays on top of MArray interface (although i'm not sure that this will be efficient. GHC's classes efficiency is black magic :) BRG * unsafeAt, unsafeRead and unsafeWrite take 0-based indices, and the BRGbounds checking and conversion is handled externally, based on the BRGbounds you return. This means the interfaces can't support array BRGwindowing, at least in the multidimensional case. I'd be happy with BRGwindowing for one-dimensional arrays only, but there's no way to BRGrestrict your array type to one-dimensional index types. for one-dimensional arrays it's easy to implement. i agree with you, though, that we can move more operations to the class interface -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: runtime reflection for classes
Hello Johannes, Thursday, February 09, 2006, 1:43:38 PM, you wrote: JW With Data.Generics, we can get an object's type, constructor and fields. really, SYB way to metaprogramming is just to encode information about type in the datastructure. you can do somethiong in this fashion just by coupling together value and functions that is able to show, map and otherwise process this value. due to simple changes in the compiler, functions that translate value into such self-describing structure, are generated automatically. but they can be written manually or by TH 9it was used before compiler was modified). so it is not exact compile-time vs dynamic inspection of metainformation, it's just a general datatype which hoilds all the metainformation about value and therefore can be inspected at run-time to dynamically decide what to do with that value in its current state, information coupled together with value, don't include that you want, but this can be changed. again, this change need to either change a compiler so that it can pack his information when converting a-Dynamic, or you can write these data manually, or again TH can be used and you will be limited only by the volume of information, available for TH code. except for this, extensing SYB don't require any extensions to the language -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re[2]: runtime reflection for classes
Hello Johannes, Thursday, February 09, 2006, 2:43:49 PM, you wrote: again TH can be used and you will be limited only by the volume of information, available for TH code. JW Is information such as instance C t1 t2 .. available for such code? JW I guess not since this would require information from the compiler JW (type checker), but TH splicing runs earlier? afair, this info is not available, but not because TH runs too early (info about types structure is available, for example), but just because it is not still implemented (although there was the requests about adding this feature). in meantime, you can use the usual trick: enclose the whole module text (or at least these instance declarations) in the [d|...|] parentheses and generate all additrional definitions using analysis of program text instead of analysis of reified typing information. at least, this way you can implement all what you want without waiting while GHC team will change something in TH/SYB. and, imho, main feature of SYB is not generation of RTTI (run-time type information) but inventing of cool combinators to process data structures dynamically, without prior knowledge of the exact type structure. that is a really far beyound of my own abilities -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
