develooper Front page | perl.perl5.porters | Postings from May 2013

Re: Proposal: initial type annotation in SV

Thread Previous | Thread Next
Nicholas Clark
May 8, 2013 10:08
Re: Proposal: initial type annotation in SV
Message ID:
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".

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)

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?

Nicholas Clark

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About