The C is a call demand: C(d) means this function is called and its result is
consumed with d.
U(ddd) means this three-field product is evaluated, and its three field are
evaluated with d,d,d
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-
| I'm not sure but the trailing m in g's signature.
That says that the result has the CPR property.
S
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
This worries me:
3. The syntax of record updates must be changed to include the class:
r {Rcls| n1 = x1, n2 = x2}
And if I understand correctly this proposal is still uncertain on some
edge cases.
I think it is time to close down the records discussion on the mail
list and ask for an
This worries me:
3. The syntax of record updates must be changed to include the class:
r {Rcls| n1 = x1, n2 = x2}
This is really the core of the proposal. If my understanding of the problem is
at all accurate, the whole reason we have trouble is that update is dependent
on the
I think it is time to close down the records discussion on the mail
list and ask for an implementation
The implementer should use any means at their disposal, probably by
adding a new construct to the language. However, for now any new
constructs or other implementation details should be kept
On Thu, Mar 8, 2012 at 1:00 PM, Greg Weber g...@gregweber.info wrote:
This discussion has largely centered around trying to come up with a
hack that desugars to Haskell's existing language constructs.
There is an alternative to a desugaring hack: add a real record
construct to the language.
On Thu, Mar 8, 2012 at 12:37 PM, Chris Smith cdsm...@gmail.com wrote:
On Thu, Mar 8, 2012 at 1:00 PM, Greg Weber g...@gregweber.info wrote:
This discussion has largely centered around trying to come up with a
hack that desugars to Haskell's existing language constructs.
There is an
On Thu, Mar 8, 2012 at 2:09 PM, Greg Weber g...@gregweber.info wrote:
The semantics that will be exposed to users have already been largely
decide upon.
Admittedly I haven't had time to carefully read some parts of this
thread, and if that claim is true, then of course implementation
should be
Since it is impossible for anyone to have read and kept in their mind
all the discussion that has gone I will fill you in as I know it. We
would like the syntax of record updates to be the same as they are
today. That is separate from this proposal. This proposal is the only
solution so far that
Just because Haskell currently resolves its types through type-classes
does not mean we are forced to stop at type-classes for every aspect
of the implementation.
No, we are not forced to use type classes for everything. But it makes the
language much cleaner, more flexible, easier to learn
On Thu, Mar 8, 2012 at 4:52 PM, Greg Weber g...@gregweber.info wrote:
syntax we would like. Does that make sense? I take it that you agree
that we should separate the discussion of semantics from
implementation: this is a perfect example of why.
If we can describe semantics without concern for
Hi,
I just ran across some code that calls unsafeThawArray#, writeArray#,
and unsafeFreezeArray#, in that order. How unsafe is that?
* Is it unsafe in the sense that if someone has a reference to the
original Array# they will see the value of that pure array change?
* Is it unsafe in the
I'm currently working with a lot of very short arrays of fixed length and
as a thought experiment I thought I would try to play with fast numeric
field accessors
In particular, I'd like to use something like foreign prim to do something
like
foreign import prim cmm_getField unsafeField# :: a -
On Thu, Mar 8, 2012 at 8:12 PM, Edward Kmett ekm...@gmail.com wrote:
I'm currently working with a lot of very short arrays of fixed length and as
a thought experiment I thought I would try to play with fast numeric field
accessors
...
This becomes more reasonable to consider when you are
On Fri, Mar 02, 2012 at 01:04:13AM +, AntC wrote:
Let me explain better what I mean by two private namespaces, then we'll
try to understand how your proposal goes ...
Folks, it has been very difficult keeping up with all the twists and turns of
this thread.
So here's a summary
Hi,
Am Donnerstag, den 08.03.2012, 23:12 -0500 schrieb Edward Kmett:
But I can only pass unboxed types to foreign prim.
Is this an intrinsic limitation or just an artifact of the use cases
that have presented themselves to date?
funny, I just stumbled over this two days ago as well. In my
16 matches
Mail list logo
