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
On 09/01/2012, Greg Weber g...@gregweber.info 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.
On 09/01/2012, Isaac Dupree m...@isaac.cedarswampstudios.org 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
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 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 12/01/2012 17:55, Johan Tibell wrote:
On Thu, Jan 12, 2012 at 12:54 AM, Simon Marlowmarlo...@gmail.com 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
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
On Thu, Jan 12, 2012 at 10:25 AM, Simon Marlow marlo...@gmail.com 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
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.**
On 12/01/2012 18:37, Johan Tibell wrote:
On Thu, Jan 12, 2012 at 10:25 AM, Simon Marlowmarlo...@gmail.com 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
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
On 12/01/2012, Greg Weber g...@gregweber.info 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
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
23 matches
Mail list logo
