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
>
> 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
On Thu, Mar 8, 2012 at 8:12 PM, Edward Kmett 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 forced to ma
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
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 sense
On Thu, Mar 8, 2012 at 4:52 PM, Greg Weber 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 the possibility/
> 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
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 wo
On Thu, Mar 8, 2012 at 2:09 PM, Greg Weber 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 the major concern.
On Thu, Mar 8, 2012 at 12:37 PM, Chris Smith wrote:
> On Thu, Mar 8, 2012 at 1:00 PM, Greg Weber 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
On Thu, Mar 8, 2012 at 1:00 PM, Greg Weber 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.
I am not sure wh
>> 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 shoul
> 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
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 imp
On 06/03/2012, AntC wrote:
> Matthew Farkas-Dyck gmail.com> writes:
>> > Oh, and how do you deal with multiple record constructors as in H98:
>> >data T a = T1 { x :: a, y :: Bool }
>> > | T2 { x :: a }
>> >
>> Not sure what you mean. With an argument of such a multiconstructed
>>
| 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
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-haske
17 matches
Mail list logo
