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 to
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
Requiring unicode characters for the Haskell syntax to solve a
*relatively* simple problem is a bad bad idea.
It is the equivalent of shooting birds with nuclear missiles. Yes you do
solve the "bird" problem but it is nothing compared with the fallout
consequences.
Morten
On 13/01/12 10:15,
On Thu, Jan 12, 2012 at 19:38, Donn Cave wrote:
> >> > 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 c
>> > Quoth Brandon Allbery ,
>> ...
>> > 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 mo
> 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 fun
On Thu, Jan 12, 2012 at 18:15, Donn Cave wrote:
> > Quoth Brandon Allbery ,
> ...
> > 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
> Quoth Brandon Allbery ,
...
> 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 module and now recor
On Thu, Jan 12, 2012 at 17:33, Donn Cave wrote:
> Quoth Brandon Allbery ,
> > On Thu, Jan 12, 2012 at 17:14, Donn Cave 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 bec
Quoth Brandon Allbery ,
> On Thu, Jan 12, 2012 at 17:14, Donn Cave 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 decid
On 12/01/2012, Greg Weber wrote:
> I added this and your Control.Category.<<< to the wiki.
Thanks.
> I am not sure about the tuple proposal - tuples normally imply an ordering,
> which would imply that all record fields must be accounted for at least
> with an empty comma or an underscore, parti
On Thu, Jan 12, 2012 at 17:14, Donn Cave 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
composition o
Quoth Greg Weber ,
> On Thu, Jan 12, 2012 at 6:23 PM, Malcolm Wallace
> wrote:
>> 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. If you use the new records system, t
On Thu, Jan 12, 2012 at 6:23 PM, Malcolm Wallace wrote:
>
> 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
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 c
> 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 id
Quoth Evan Laforge ,
...
> ... 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 more or less acad
On 12/01/2012 18:37, Johan Tibell wrote:
On Thu, Jan 12, 2012 at 10:25 AM, Simon Marlow wrote:
I think by (1) you mean mutable variables containing unboxed values, right?
Yes.
I normally use an unboxed array of length 1 for these. There's not much
overhead - only an extra word in the heap
>> 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 pro
On Thu, Jan 12, 2012 at 10:25 AM, Simon Marlow wrote:
> I think by (1) you mean mutable variables containing unboxed values, right?
Yes.
> I normally use an unboxed array of length 1 for these. There's not much
> overhead - only an extra word in the heap compared to implementing them
> natively
On Thu, Jan 12, 2012 at 13:20, Isaac Dupree
wrote:
> 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 already? Did
> Perl do this ( - I t
On 12/01/2012 17:55, Johan Tibell wrote:
On Thu, Jan 12, 2012 at 12:54 AM, Simon Marlow wrote:
For boxed arrays you need a PrimOp of course (like catMutVar#). For unboxed
arrays you could get away with FFI, but a PrimOp would be better because it
could be inline. But to get it inline would me
On 01/12/2012 07:06 AM, Matthew Farkas-Dyck wrote:
On 09/01/2012, Greg Weber 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.
I told you so (^
On Thu, Jan 12, 2012 at 2:23 PM, Greg Weber wrote:
> I added this and your Control.Category.<<< to the wiki.
>
> I am not sure about the tuple proposal - tuples normally imply an ordering,
> which would imply that all record fields must be accounted for at least with
> an empty comma or an undersc
On Thu, Jan 12, 2012 at 12:54 AM, Simon Marlow wrote:
> For boxed arrays you need a PrimOp of course (like catMutVar#). For unboxed
> arrays you could get away with FFI, but a PrimOp would be better because it
> could be inline. But to get it inline would mean modifying the native and
> LLVM bac
I added this and your Control.Category.<<< to the wiki.
I am not sure about the tuple proposal - tuples normally imply an ordering,
which would imply that all record fields must be accounted for at least
with an empty comma or an underscore, particularly if updating the last
field in a record. For
On 09/01/2012, Isaac Dupree wrote:
> You mean this wiki page, right?:
> http://hackage.haskell.org/trac/ghc/wiki/Records/NameSpacing
>
>> That is, there are no fundamental
>> objections to the implementation of this records implementation.
>
> I think that might be overly optimistic... I think the
On 09/01/2012, Greg Weber wrote:
> Thank you for all your feedback! I updated the wiki page accordingly.
>
> Let us stop and take note of what this feedback is about: the most
> convenient syntax for manipulating records, and much of this feedback
> applies to any records proposal. That is, there
On 10/01/2012 17:19, Ryan Newton wrote:
Hello there,
I was wondering what the recommendations would be for getting CAS on
[mutable] vector elements?
I thought that as a first step I might create an a library that does the
trick only for unboxed vectors, by using bits-atomic (i.e. FFI + GCC
intr
29 matches
Mail list logo
