Front page | perl.perl5.porters |
Postings from May 2013
Re: Proposal: initial type annotation in SV
Thread Previous
|
Thread Next
From:
Sébastien Aperghis-Tramoni
Date:
May 13, 2013 23:34
Subject:
Re: Proposal: initial type annotation in SV
Message ID:
CB2A8904-BCE7-450A-80CC-E95961D31AE7@cpan.org
Nicholas Clark wrote:
> On Mon, May 06, 2013 at 09:20:25AM +0200, Sébastien Aperghis-Tramoni wrote:
>> Steffen Mueller a écrit :
>>
>>> On 05/05/2013 11:45 PM, Sébastien Aperghis-Tramoni wrote:
>>>> Now, did I miss something so blindingly obvious that I didn't see why
>>>> it cannot work? is it silly?
>>>>
>>>> Thanks in advance for your comments and critics.
>>>>
>>>> In the mean time, I'll try to write a proof of concept.
>>>
>>> I'm not sure that what you want to do is possible, but I'd sure love to see you try since it's been a sore spot wrt. Sereal[1] since the beginning.
>>>
>>> Before you start prototyping, I would strongly suggest that you look up Chip's emails and branches/patches such as "chip/magicflags7". He'd worked towards the same goal: Being able to tell whatever type a scalar originated as. I even did some CPAN smoking then and there wasn't too much breakage.
>>
>> Oh, nice to know there was already some ongoing work.
>
> So, you have a proof-of-concept already written :-)
>
> Note, IIRC, that it only makes the distinction between "strings" and
> "numbers", not to the level of "string" vs "float" vs "integer".
Agreed. Distinction between integers and floats mostly is a bonus over the main issue with is distinction between numbers and strings.
> My gut feeling is
>
> a) that it's that two-way distinction which matters in most places, not the
> greater subtleties about what sort of a number it is. After all, floating
> point is merely an implementation detail of how computers fake up storing
> real numbers. It's an artefact of computers, not something more
> fundamental to what the data represent.
> b) that simply storing the "type" of the last write to the scalar is useful
> (Whereas what we have currently with the SV type and the flags is some
> combination of the history of the reads from the scalar)
Yes. That's why my first hope was to find a free bit somewhere in the flags to store this information. But...
> On Mon, May 06, 2013 at 03:08:25PM +0200, Sébastien Aperghis-Tramoni wrote:
>
>> Yes, as I discovered through quick experiments, I was a bit too optimistic.
>> But this wasn't a surprise, because I guess that if it had been that simple,
>> it would have been implemented years ago.
>
> Yes, generally. But sometimes it's the insight that is missing.
>
> It would be very useful if you could take Chip's branch and figure out what
> still needs doing. I guess that's
>
> a) does it actually help solve your problem?
> b) what does it break?
> c) how many different classes of breakage does it have?
> d) of those, can any (should any?) be fixed by changing the code?
> e) or do they need the downstream code to adapt?
My naive plan was like this: annotate the SV, keep everything unchanged for the outside world to avoid breaking external code, provide a set of macros (+ B methods) so serializers can use the hints. I've still not completely abandoned all hope to achieve this. Color me still naive :)
I did a first read of Chip's diff, and that's precisely what I feared: using a complex mechanism like magic behind the scenes is hard to get right. And if Chip can't do it, the probability for me to do it is very low.
It still have one or two stupid ideas that needs to be crushed against the bedrock of reality.
--
Sébastien Aperghis-Tramoni
Close the world, txEn eht nepO.
Thread Previous
|
Thread Next