Right now, there's not much support for struct properties at all in
Typed Racket. So this would probably be a non-trivial amount of work.
Sam
On Tue, Jul 29, 2014 at 3:46 AM, wrote:
> So, there is currently no way make math/array serializable at all -- even
> when it would be ok to get an ine
So, there is currently no way make math/array serializable at all -- even when
it would be ok to get an inefficient wrapped array as a result from
deserialize? As far as understand, what hinders me from writing a simple typed
wrapper for serialize/deserialize is that a typed struct does not sup
On Thu, Jul 24, 2014 at 7:21 AM, Berthold Bäuml wrote:
>> De-serializing an array of numbers and then passing it to typed code
>> would produce a wrapper, not a first-order check, and so would be very
>> expensive.
>
> Even when first-order checks would be possible the cost of such a check would
> De-serializing an array of numbers and then passing it to typed code
> would produce a wrapper, not a first-order check, and so would be very
> expensive.
Even when first-order checks would be possible the cost of such a check would
be significant in our application. We wan to use serialization
OK. I am beginning to wonder whether we're missing something in the contract
world.
On Jul 23, 2014, at 12:00 PM, Sam Tobin-Hochstadt wrote:
> De-serializing an array of numbers and then passing it to typed code
> would produce a wrapper, not a first-order check, and so would be very
> e
De-serializing an array of numbers and then passing it to typed code
would produce a wrapper, not a first-order check, and so would be very
expensive.
What you want is something that can tell that the untyped reference is
dead after value is passed to typed code, so that a first-order check
can be
That really depends what the contracts are, and if they're first-order.
Sam
On Wed, Jul 23, 2014 at 11:45 AM, Matthias Felleisen
wrote:
>
> Will these costs dominate the cost of I/O here?
>
>
> On Jul 23, 2014, at 11:37 AM, Sam Tobin-Hochstadt
> wrote:
>
>> Unfortunately, I think that strategy
Let's assume we serialize arrays of numbers, which is what I assume the
background to the question is. In that case, the answer isn't all that obvious
to me.
On Jul 23, 2014, at 11:47 AM, Sam Tobin-Hochstadt wrote:
> That really depends what the contracts are, and if they're first-order.
Will these costs dominate the cost of I/O here?
On Jul 23, 2014, at 11:37 AM, Sam Tobin-Hochstadt wrote:
> Unfortunately, I think that strategy would incur substantial overhead
> for things like serialization of large arrays.
>
> Sam
>
> On Wed, Jul 23, 2014 at 11:28 AM, Matthias Felleisen
Unfortunately, I think that strategy would incur substantial overhead
for things like serialization of large arrays.
Sam
On Wed, Jul 23, 2014 at 11:28 AM, Matthias Felleisen
wrote:
>
> On Jul 23, 2014, at 11:10 AM, Neil Toronto wrote:
>
>> On 07/16/2014 10:25 AM, Berthold Bäuml wrote:
>>> Hi,
>
On Jul 23, 2014, at 11:10 AM, Neil Toronto wrote:
> On 07/16/2014 10:25 AM, Berthold Bäuml wrote:
>> Hi,
>>
>> will there be serialization support for math/array and math/matrix in the
>> near future? As far as I understand in principle it should be possible at
>> leas in a straight forward
On 07/16/2014 10:25 AM, Berthold Bäuml wrote:
Hi,
will there be serialization support for math/array and math/matrix in the near
future? As far as I understand in principle it should be possible at leas in a
straight forward way as there are already the routines array->list and
list->array.
12 matches
Mail list logo
