I broke out the dot operator section of the proposal to its own page since
it is actually fairly independent of the different proposals.
http://hackage.haskell.org/trac/ghc/wiki/Records/DotOperator
On Sat, Jan 14, 2012 at 7:26 PM, wren ng thornton w...@freegeek.org wrote:
On 1/13/12 11:31 PM,
On Fri, 2012-01-13 at 15:16 +1100, Morten Brodersen wrote:
Unfortunately most unix/windows/tools/source controls/editors out
there are Ascii only.
So after about 20 years the unicode standard has been around, the
quantification most still applies? Maybe I'm using a
non-representative platform,
Let me suggest that a simple non-nuclear alternative would be for people
interested in Unicode symbols to use an editor that auto converts from
Haskell Ascii to Haskell Unicode when loading and (of course) back again
when saving. You can do that today. You can even pick your own Ascii
On 12/01/2012, Morten Brodersen morten.broder...@constrainttec.com wrote:
Even if Unicode is not required, there is still a fallout. Let's look at
a simple scenario:
Somebody uploads a nice useful Haskell module that include a number of
Unicode symbols.
Unfortunately most
On 13/01/2012, Herbert Valerio Riedel h...@gnu.org wrote:
On Fri, 2012-01-13 at 15:16 +1100, Morten Brodersen wrote:
Unfortunately most unix/windows/tools/source controls/editors out
there are Ascii only.
So after about 20 years the unicode standard has been around, the
quantification most
On 01/12/2012 07:06 AM, Matthew Farkas-Dyck wrote:
On 09/01/2012, Greg Weber g...@gregweber.info wrote:
Note that a move to a different operator for function composition
(discussed in dot operator section) would make things easier to parse:
b~ .a
where the unicode dot might be even nicer.
On Thu, Jan 12, 2012 at 13:20, Isaac Dupree
m...@isaac.cedarswampstudios.orgwrote:
way***. If we use the proper Unicode operator ∘, then let's make a wiki
page for all the common OSes/input methods, saying how to input it (aside
from copy/paste). Is there anything on the Web somewhere
I told you so (^_^)
Unicode dot (∘) would be optimal, since that's what it's for. If to
type '∘' is awkward, then one can use (Control.Category.). We need
not (and, in my opinion, should not) define another operator.
Is ∘ (U+2218 RING OPERATOR)* in Prelude yet? We should propose that.**
Quoth Evan Laforge qdun...@gmail.com,
...
... Groups that are reluctant to
make formatting changes for fear of confusing revision history are
really going to hate that one.
I think a lively discussion would also be possible over whether exotic
characters are suitable at all.
But this is a
But this is a more or less academic discussion, taking place on
ghc-users, nominally out of view of the general Haskell community,
right? So I don't need to intrude with mundane objections of
that nature.
True, true, there is that.
However, I think there's at least a little bit in the idea
On 12 Jan 2012, at 18:41, Evan Laforge wrote:
Unicode dot (∘) would be optimal, since that's what it's for.
Is ∘ (U+2218 RING OPERATOR)* in Prelude yet? We should propose that.**
However, changing the composition operator from (.) will involve huge
amounts of changes to source code.
Quoth Greg Weber g...@gregweber.info,
On Thu, Jan 12, 2012 at 6:23 PM, Malcolm Wallace
malcolm.wall...@me.comwrote:
So, who is up for proposing centred dot as the new record-field syntax?
We don't need to make this change overnight. The new records system will be
turned on by an extension.
On Thu, Jan 12, 2012 at 17:14, Donn Cave d...@avvanta.com wrote:
Spaces or unicode would be the worst idea yet, but hopefully that
isn't what you meant.
Thing is, I think the spaces idea is considered acceptable because it's
*already there*. Take a look at how GHC decides whether (.) is the
Quoth Brandon Allbery allber...@gmail.com,
On Thu, Jan 12, 2012 at 17:14, Donn Cave d...@avvanta.com wrote:
Spaces or unicode would be the worst idea yet, but hopefully that
isn't what you meant.
Thing is, I think the spaces idea is considered acceptable because it's
*already there*. Take
On Thu, Jan 12, 2012 at 17:33, Donn Cave d...@avvanta.com wrote:
Quoth Brandon Allbery allber...@gmail.com,
On Thu, Jan 12, 2012 at 17:14, Donn Cave d...@avvanta.com wrote:
Spaces or unicode would be the worst idea yet, but hopefully that
isn't what you meant.
Thing is, I think the
Quoth Brandon Allbery allber...@gmail.com,
...
Seems obvious to me: on the one hand, there should be a plain-ASCII
version of any Unicode symbol; on the other, the ASCII version has
shortcomings the Unicode one doesn't (namely the existing conflict between
use as composition and use as
On Thu, Jan 12, 2012 at 18:15, Donn Cave d...@avvanta.com wrote:
Quoth Brandon Allbery allber...@gmail.com,
...
Seems obvious to me: on the one hand, there should be a plain-ASCII
version of any Unicode symbol; on the other, the ASCII version has
shortcomings the Unicode one doesn't
I also wish to note that I have never been a member of the anything beyond
plain ASCII is fundamental evil set; if we're going to think that way, just
go back to BAUDOT and punched cards.
Well, it's similar to the 80 columns debate. You have to draw the
line somewhere. It's not about
On Thu, Jan 12, 2012 at 22:32, Morten Brodersen
morten.broder...@constrainttec.com wrote:
Requiring unicode characters for the Haskell syntax to solve a
*relatively* simple problem is a bad bad idea.
Nobody said anything about requiring it.
--
brandon s allbery
Even if Unicode is not required, there is still a fallout. Let's look at
a simple scenario:
Somebody uploads a nice useful Haskell module that include a number of
Unicode symbols.
Unfortunately most unix/windows/tools/source controls/editors out there
are Ascii only.
So people who wants
20 matches
Mail list logo
