Re: Proposal: Scoping rule change
sounds good. will there be a shadowing warning? On Mon, Jul 23, 2012 at 5:28 PM, Lennart Augustsson lenn...@augustsson.net wrote: It's not often that one gets the chance to change something as fundamental as the scoping rules of a language. Nevertheless, I would like to propose a change to Haskell's scoping rules. The change is quite simple. As it is, top level entities in a module are in the same scope as all imported entities. I suggest that this is changed to that the entities from the module are in an inner scope and do not clash with imported identifiers. Why? Consider the following snippet module M where import I foo = True Assume this compiles. Now change the module I so it exports something called foo. After this change the module M no longer compiles since (under the current scoping rules) the imported foo clashes with the foo in M. Pros: Module compilation becomes more robust under library changes. Fewer imports with hiding are necessary. Cons: There's the chance that you happen to define a module identifier with the same name as something imported. This will typically lead to a type error, but there is a remote chance it could have the same type. Implementation status: The Mu compiler has used the scoping rule for several years now and it works very well in practice. -- Lennart ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
I am starting up the proposal. http://hackage.haskell.org/trac/haskell-prime/ticket/143 http://hackage.haskell.org/trac/haskell-prime/wiki/OpaqueText Unfortunately I haven't had any time to work on this for the last week and won't for 2 more weeks. Your help is appreciated. I think the first step is to move list functions into a separate module for the Text package to see if we can get rid of name conflicts with the Prelude. On Sat, Mar 31, 2012 at 11:49 PM, Colin Paul Adams co...@colina.demon.co.uk wrote: Gabriel == Gabriel Dos Reis g...@integrable-solutions.net writes: Gabriel On Mon, Mar 26, 2012 at 5:08 AM, Christian Siefkes Gabriel It is not the precision of Char or char that is the issue Gabriel here. It has been clarified at several points that Char is Gabriel not a Unicode character, but a Unicode code point. That's not what the standard says: 6.1.2 Characters and Strings The character type Char is an enumeration whose values represent Unicode characters [2]. [2] Unicode Consortium. Unicode standard. http://unicode.org/standard/standard.html. -- Colin Adams Preston Lancashire () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
Can anyone explain how the tangent discussion of the finer points of Unicode and the value of teaching [Char] is relevant to the proposal under discussion? We aren't going to completely eliminate String and break most existing Haskell code as Simon said. String is just a list anyways, and lists are here to stay in Haskell. I would like to get back to working on the proposal and determining how Text can be added to the language. Thank you, Greg weber ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
I would like to get back to working on the proposal and determining how Text can be added to the language. The discussion started because of the question of whether Text should support list processing functions at all, and if so how. That is a very legitimate question related to the Text proposal, at least if you are concerned about correct semantics. Once you are there, the discussion about Unicode characters is unavoidable, and is very much within the scope of discussing Text. Can we take a break from arguing then, and can you create a wiki page that explains how you think Text should behave? This conversation is getting extremely long and repetitive. Can someone please show me how to create a wiki page on the Haskell proposals site (or suggest a different appropriate site)? ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
On Sun, Mar 25, 2012 at 5:39 PM, Gabriel Dos Reis g...@integrable-solutions.net wrote: On Sun, Mar 25, 2012 at 6:54 PM, Henrik Nilsson n...@cs.nott.ac.uk wrote: In any case, this is hardly the place to to discuss how to best teach Haskell or programming in general. Sure, I haven't seen any disagreement with that. As interesting as this discussion is, I think this agreement is the perfect segway to take it off list. Debating the usefulness of String = [Char] does not seem to be productive here anyways. What would be helpful is if alternatives were offered, tested out, and shared among the teaching community. If this requires any changes to the language (other than what is being discussed now), please let us know. The Prelude is still going to export list functions whether they are used on [Char] or not. So we are still in the position of requiring qualified imports for Text functions or needing to change the Text package or something about the language to avoid conflicts with list functions. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
Can we all agree that * Text can now demonstrate both CPU and RAM performance improvements in benchmarks. Because Text is an opaque type it has a maximum potential for future performance improvements. Declaring a String to be a list limits performance improvements * In a Unicode world, String = [Char] is not always correct: instead for some operations one must operate on the String as a whole. Using a [Char] type makes it much more likely for a programmer to mistakenly operate on individual characters. Using a Text type allows us to choose to not expose character manipulation functions. * The usage of String in the base libraries will continue as long as Text is not in the language standard. This will continue to make writing Haskell code a greater chore than is necessary: converting between types, and working around the inconvenience of defining typeclasses that operate on both String and []. These are important enough to *try* to include Text into the standard, even if there are objections to how it might practically be included. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
On Sat, Mar 24, 2012 at 7:26 PM, Gabriel Dos Reis g...@integrable-solutions.net wrote: On Sat, Mar 24, 2012 at 9:09 PM, Greg Weber g...@gregweber.info wrote: Problem: we want to write beautiful (and possibly inefficient) code that is easy to explain. If nothing else, this is pedagologically important. The goals of this code are to: * use list processing pattern matching and functions on a string type I may have missed this question so I will ask it (apologies if it is a repeat): Why is it believed that list processing pattern matching is appropriate or the right tool for text processing? Nobody said it is the right tool for text processing. In fact, I think we all agreed it is the wrong tool for many cases. But it is easy for students to understand since they are already being taught to use lists for everything else. It would be great if you can talk with teachers of Haskell and figure out a better way to teach text processing. -- Gaby ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
I would really just like for someone to show me how to create a wiki proposal page :) This proposal doesn't have to break any codebases. One possibility is to add the Text type to the standard while keeping String and marking it as deprecated. On Fri, Mar 23, 2012 at 6:13 AM, ARJANEN Loïc Jean David arjanen.l...@gmail.com wrote: 2012/3/22 Greg Weber g...@gregweber.info: I am not trying to win an argument with anyone. Just trying to do what is best for the community. Many others here have a better grasp of the issue than me and can help answer questions and come up with a solution. I am also not saying this proposal is done. A lot of thought and work is needed to ensure it can be implemented as smoothly as possible. It does seem though that everyone thinks it is a good proposal. Sorry for the misunderstanding, but when you said that someone should take this proposal up and help make sure it gets in the next batch, I believed you thought we could take this proposal as is. Deeply sorry for my error. But now we have at least two tasks to do before we can put up the proposal: define what operations should be supported by String and should we apply this proposal in the next batch. Given that this proposal will break many codebases (we shouldn't hope to apply all of list's syntax to this string type) should we apply it alone or wait until we have more other codebase-breakers to apply ? -- ARJANEN Loïc Jean David http://luigiscorner.wordpress.com --- Computer science is no more about computers than astronomy is about telescopes, biology is about microscopes, or chemistry is about beakers and test tubes. Science is not about tools. It is about how we use them, and what we find out when we do. Michael R. Fellows and Ian Parberry ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
Does Python 3 have the equivalent of LANGUAGE pragmas? That is, as a
GHC user i can add {-# LANGUAGE OLD_STRINGS -#} and my program works
with the new language standard!
I think what ruined Perl 6 is that it is still under development!
Avoiding breakage is important. But throwing around comparisons to
Perl 6 is not going to help move the discussion along!
On Fri, Mar 23, 2012 at 6:33 AM, Christian Siefkes
christ...@siefkes.net wrote:
On 03/23/2012 02:13 PM, ARJANEN Loïc Jean David wrote:
2012/3/22 Greg Weber g...@gregweber.info:
But now we have at least two tasks to do before we can put up the
proposal: define what operations should be supported by String and
should we apply this proposal in the next batch. Given that this
proposal will break many codebases (we shouldn't hope to apply all of
list's syntax to this string type) should we apply it alone or wait
until we have more other codebase-breakers to apply ?
I very much hope that the Haskell committee will never ever accept a
proposal that will break many codebases! That's what ruined Perl 6 und
Python 3, and quite unnecessarily so.
Even if I a future Haskell standard defines String as something that doesn't
have to be implemented as a list of Char, it still would have to behave as
if it was [Char] for most practical purposes (except performance-wise, of
course!). That's necessary for compatibility. Or String could just be
complemented with an additional standardized Text type, as Greg suggested.
Best regards
Christian
--
|--- Dr. Christian Siefkes --- christ...@siefkes.net ---
| Homepage: http://www.siefkes.net/ | Blog: http://www.keimform.de/
| Peer Production Everywhere: http://peerconomy.org/wiki/
|-- OpenPGP Key ID: 0x346452D8 --
Just so that nobody takes his guess for the full truth, here's my standing
on keeping control, in 2 words (three?):
I won't.
-- Linus Torvalds, The Tanenbaum-Torvalds Debate
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
This proposal seems fairly uncontroversial at the moment. I would really like it if someone more familiar with the proposal process can take this proposal up and help make sure it gets in the next batch. I can't even figure out how to create a wiki page for the proposal right now :) ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
I actually was not able to successfully google for Text vs. String benchmarks. If someone can point one out that would be very helpful. On Sat, Mar 17, 2012 at 1:52 AM, Christopher Done chrisd...@googlemail.com wrote: On 17 March 2012 05:30, Tony Morris tonymor...@gmail.com wrote: Do you know if there is a good write-up of the benefits of Data.Text over String? I'm aware of the advantages just by my own usage; hoping someone has documented it rather than in our heads. Good point, it would be good to collate the experience and wisdom of this decision with some benchmark results on the HaskellWiki as The Place to link to when justifying it. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
This is the best I can do with Bryan's blog posts, but none of the graphs (which contain all the information) show up: http://web.archive.org/web/20100222031602/http://www.serpentine.com/blog/2009/12/10/the-performance-of-data-text/ If someone has some benchmarks that can be ran that would be helpful. On Mon, Mar 19, 2012 at 7:51 AM, Johan Tibell johan.tib...@gmail.com wrote: Hi Greg, There are a few blog posts on Bryan's blog. Here are two of them: http://www.serpentine.com/blog/2009/10/09/announcing-a-major-revision-of-the-haskell-text-library/ http://www.serpentine.com/blog/2009/12/10/the-performance-of-data-text/ Unfortunately the blog seems partly broken. Images are missing and some articles are missing altogether (i.e. the article is there but the actualy body text is gone.) -- Johan ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
String != [Char]
the text library and Text data type have shown the worth in real world Haskell usage with GHC. I try to avoid String whenever possible, but I still have to deal with conversions and other issues. There is a lot of real work to be done to convert away from [Char], but I think we need to take it out of the language definition as a first step. I can only see one issue with the proposal: it can be convenient to operate on a list of characters. But I think there are plenty of solutions at our disposal. A simple conversion from Text to a list of characters might suffice. In GHC, OverloadedStrings means users would still be free to use String the same way they are now. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
I am sorry that I made the huge mistake in referencing future possible proposals. If this proposal passes, that has no bearing on whether the other proposals would pass, it just makes them possible. Please help me fix my error by stopping all discussions of future proposals and focusing solely on the one at hand. Thank you! Greg Weber On Sat, Feb 11, 2012 at 5:39 PM, Roman Leshchinskiy r...@cse.unsw.edu.au wrote: On 12/02/2012, at 01:29, Nate Soares wrote: If - was introduced for accessing fields, we'd have to discuss whether it should have spaces around it. I'd lean towards requiring that it have no spaces when used for field access, for symmetry with . when used for module access. I'm not spaces matter in this case, - is a reserved token so we would just have expressions of the form expr - field with no special lexical rules. BTW, if - doesn't work for some reason then there is also = which AFAIK isn't used in expressions at all currently. Roman ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Proposal: require spaces around the dot operator
Similar to proposal #20, which wants to remove it, but immediately less drastic, even though the long-term goal is the same. This helps clear the way for the usage of the unspaced dot as a record field selector as shown in proposal #129. After this proposal shows clear signs of moving forward I will add a proposal to support a unicode dot for function composition. After that we can all have a lively discussion about how to fully replace the ascii dot with an ascii alternative such as ~ or After that we can make the dot operator illegal by default. This has already been discussed as part of a records solution on the ghc-users mail list and documented here: http://hackage.haskell.org/trac/ghc/wiki/Records/DotOperator ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
There are 2 compelling reasons I know of to prefer dot for record access 1) follows an almost universal convention in modern programming languages 2) is consistent with using the dot to select functions from module name-spaces We can have a lot of fun bike-shedding about what operator we would prefer were these constraints not present. Personally I wouldn't care. However, I find either one of these 2 points reason enough to use the dot for record field access, and even without a better record system the second point is reason enough to not use dot for function composition. It is somewhat convenient to argue that it is too much work and discussion for something one is discussing against. The only point that should matter is how existing Haskell code is effected. On Thu, Feb 9, 2012 at 8:27 PM, Daniel Peebles pumpkin...@gmail.com wrote: I'm very happy to see all the work you're putting into the record discussion, but I'm struggling to see why people are fighting so hard to get the dot character in particular for field access. It seems like a huge amount of work and discussion for a tiny bit of syntactic convenience that we've only come to expect because of exposure to other very different languages. Is there some fundamental reason we couldn't settle for something like # (a valid operator, but we've already shown we're willing to throw that away in the MagicHash extension) or @ (only allowed in patterns for now)? Or we could even keep (#) as a valid operator and just have it mean category/lens composition. Thanks, Dan On Thu, Feb 9, 2012 at 9:11 PM, Greg Weber g...@gregweber.info wrote: Similar to proposal #20, which wants to remove it, but immediately less drastic, even though the long-term goal is the same. This helps clear the way for the usage of the unspaced dot as a record field selector as shown in proposal #129. After this proposal shows clear signs of moving forward I will add a proposal to support a unicode dot for function composition. After that we can all have a lively discussion about how to fully replace the ascii dot with an ascii alternative such as ~ or After that we can make the dot operator illegal by default. This has already been discussed as part of a records solution on the ghc-users mail list and documented here: http://hackage.haskell.org/trac/ghc/wiki/Records/DotOperator ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
