Re: proposal for trailing comma and semicolon
I think Tilmann's way is the right way (because it is very clear when a
comma is missing since they align, unlike trailing commas), although the
original proposal is the popular way. I would rather get rid of commas
altogether (make them optional actually) and just have a newline +
consistent indentation signal a new list item: coffee-script does that.
On Fri, May 17, 2013 at 11:23 AM, Tillmann Rendel <
ren...@informatik.uni-marburg.de> wrote:
> Hi,
>
> Garrett Mitchener wrote:
>
>> There's a weird idiom that I see all the time in Haskell code where
>> coders put commas at the beginning of lines:
>>
>> data Thing = Thing {
>>x :: Int
>>,y :: Int
>>,z :: Int
>>,foo :: String
>> } ...
>>
>> items = [
>>"red"
>>,"blue"
>>,"green"
>> ]
>>
>
> (I don't think this is valid Haskell. The closing } and ] should be more
> indented).
>
> I like to put commas at the beginning of lines, because there, I can make
> them line up and it is visually clear that they are all at the same nesting
> level. I like how the commas look a bit like bullet points. For example, I
> would write:
>
> items =
> [ "red"
> , "blue"
> , "green"
> ]
>
> Could we extend Garett's proposal to also allow prefixing the first
> element of a list with a comma, to support this style:
>
> items = [
> , "red"
> , "blue"
> , "green"
> ]
>
> Allowing an optional extra comma both at the beginning and at the end
> would allow programmers the choice where they want to put their commas.
>
> Tillmann
>
> __**_
> 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: Proposal: Scoping rule change
sounds good. will there be a shadowing warning? On Mon, Jul 23, 2012 at 5:28 PM, Lennart Augustsson 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 wrote: >> "Gabriel" == Gabriel Dos Reis 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 the unicode experts here propose a Text API whose functions work for all Unicode (start by removing list functions)? If there is such a satisfactory API and it does not conflict with the Prelude we could use it unqualified. On Mon, Mar 26, 2012 at 10:21 AM, Johan Tibell wrote: > On Mon, Mar 26, 2012 at 10:12 AM, Ian Lynagh wrote: >> I am very unicode-ignorant, so apologies if I have misunderstood >> something, but doesn't Text do the same thing? >> >> Prelude T> import Data.Text.IO as T >> Prelude T T> T.putStrLn (T.take 5 (T.pack "Fro\x0308hßen")) >> Fröh >> >> Maybe your point is that neither "take" function should be used with >> unicode strings, but I don't see how advocating the Text type is going >> to help with that. > > We already covered this. Text inherited a list-based API, even if that > sometimes doesn't make sense. > > To work with Unicode you need more specific functions for different > tasks. Text only implements a few so far, like case conversion and > case-less comparison, and asks you to use text-icu for the rest. > > -- Johan > > ___ > 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 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]
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]
On Sun, Mar 25, 2012 at 5:39 PM, Gabriel Dos Reis wrote: > On Sun, Mar 25, 2012 at 6:54 PM, Henrik Nilsson 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]
On Sat, Mar 24, 2012 at 7:26 PM, Gabriel Dos Reis wrote: > On Sat, Mar 24, 2012 at 9:09 PM, Greg Weber 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]
# Switching to Text by default makes us embarrassed!
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
* avoid embarassing name clashes and the need for qualified names
(T.split, etc)
The second point is Haskell's festering language design sore rearing
its ugly head.
Lets note that the current state of Haskell is not any more beautiful
than what will happen after this proposal is implemented. It is just
that we currently have partly hidden away a deficiency in Haskell by
only exporting list functions in the Prelude. So our real goal is to
come up with conventions and/or hacks that will allow us to continue
to hide this deficiency of Haskell for the purposes of pedagogy.
If you can't tell, IMHO the issue we are circumventing is Haskell's
biggest issue form a laguage design perspective. It is a shame that
SPJ's TDNR proposal was shouted down and no alternative has been
given.
But I am not going to hold out hope that this issue will be solved any
time soon. Just limiting solving this to records has proved very
difficult. So onto our hacks for making Text the default string type!
## Option 1: T. prefixing
using Text functions still requires the T. prefix
For pedagogy, continue to use [Char], but use an OverloadedText extension
This is a safe conservative option that puts us in a better place than
we are today.
It just makes us look strange when we build something into the
language that requires a prefix.
Of course, we could try to give every Text function a slightly
different name than the Prelude list functions, but I think that will
make using Haskell more difficult that putting up with prefixes.
## Option 2: TDNR for lists
(Prelude) list functions are resolved in a special way.
For example, we could have 2 different map functions in scope
unqualified: one for lists, and one for Text. The compiler is tasked
with resolving whether the type is a list or not and determining the
appropriate function.
I would much rather add a TDNR construct to the language in a
universal way than go down this route.
## Option 3: implicit List typeclass
We can operate on Text (and other non-list data structures) using a
List typeclass.
We have 2 concers:
* list pattern matching ('c':string)
* requiring the typeclass in the type signature everywhere
I think we can extend the compiler to pattern match characters out of
Text, so lets move onto the second point.
If we don't write type signatures anywhere, we actually won't care about it.
However, if we add sparse annotations, we will need a List constraint.
listF :: List l => ...
This could get tiresome quickly. It makes pedagogy immediately delve
into an explanation of typeclasses. A simple solution is to special
case the List class.
We declare that List is so fundamental to Haskell that requiring the
List typeclass is not necessary.
The Prelude exports (class List where ...).
If a List typeclass function is used, the compiler inserts the List
typeclass constraint into a type signature automatically.
This option is very attractive because it solves all of our problems
at the cost of 1 easy to explain piece of magic. It also makes it
possible to unify list behavior across different data types without
the hassle of typeclass insertions everywhere.
___
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]
> With regards to performance of fromString, I feel like if it was a > serious problem (and how many really big strings are going to be built > that way?) then an effort to do some special-case inlining (after all, > the parameters are constant and specified at compile time) might be > beneficial. Actually, inlining is a already a big problem with Text https://github.com/bos/text/issues/19 ___ 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
wrote:
> On 03/23/2012 02:13 PM, ARJANEN Loïc Jean David wrote:
>> 2012/3/22 Greg Weber :
>> 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]
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 wrote: > 2012/3/22 Greg Weber : >> 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]
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. On Thu, Mar 22, 2012 at 2:06 PM, ARJANEN Loïc Jean David wrote: > Le 22/03/2012 04:29, Greg Weber a écrit : > >> 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 :) > > > Well, this proposal seems uncontroversial because we didn't arrive to the > difficult part: what operations should we define on this String type for it > to be useful. > Because with only this proposal as it stands now (String defined as an > implementation-defined newtype, a typeclass defined for conversion from/to > String and [Char] as an instance of this typeclass), we're in a worse > situation than before: not only String became useless given there is no > operations defined on it, the only mean we have to portably work with it is > to translate it to [Char] before doing anything. > So now, the fun part begins...what operations should String support ? I > propose obtaining the length of a String, taking a substring of a given size > beginning at a given index, taking the character at index i in a String, > concatenation, converting a string to upper/lower case and determining if a > string is contained in/a prefix/a suffix of another. > I am sure I am forgetting some useful operations and some operations I said > are better placed in the typeclass or in a typeclass instance or are > particular cases of general operations we should define rather than the > particular cases. So, what are the operations we should define according to > you ? > > > Regards, > ARJANEN Loïc > > ___ > 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]
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 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
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 wrote: > On 17 March 2012 05:30, Tony Morris 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
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
This proposal stands on its own * the dot operator is inconsistent with Module function selection. * we are allowed the option of expanding the usage of the dot without spaces if this proposal goes forward. The point is that we will decide whether or not to expand the usage of the dot in the *future*. We could decide on a completely different usage than record field selection. If this proposal is not compelling enough on its own we should merge it with other proposals and discuss them together as a single new concrete proposal. Let me know if that doesn't make sense. I am unfamiliar with the process for this mail-list and obviously led things in the wrong direction. On Sat, Feb 11, 2012 at 6:21 PM, Roman Leshchinskiy wrote: > On 12/02/2012, at 02:04, Greg Weber wrote: > >> 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. > > But if we don't consider those future proposals, then what is the > justification for this one? It does break existing code so there must be some > fairly compelling arguments for it. I don't think it can be considered in > isolation. > > Roman > > ___ 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 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
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 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 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
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
