Front page | perl.perl5.porters |
Postings from August 2012
On 07/30/2012 01:42 AM, Rev. Chip wrote: > On Sun, Jul 29, 2012 at 11:30:22AM +0200, Vincent Pit wrote: >> On 29/07/2012 05:31, Rev. Chip wrote: >>> 4. Feature in sv.h: Provide macros to C code that can distinguish original >>> value of an SV (string vs number), now that SVf_POK is correct. Macros >>> are SvPOK_pure, SvNIOK_pure, etc. >> >> I thought scalar types in Perl (the language) were only specified by >> how the scalars are used and not by how they are represented >> internally. From that point of view, I feel like less of such macros >> are needed, not more. > > Agreed generally, but as often occurs, there are exceptions. > > 1. We must interface with the outside world as YAML, JSON, etc. High > quality serialization of Perl into these formats is best done with > certain knowledge of provenence (for example, whether the value in > question started as number vs. string). 1.1. Interfacing with the outside world in the shape of another programming language that distinguishes between and overloads based on types such as integers/floating point numbers/strings. *cough* C++ *cough* > 2. Perl has operators that depend on provenance: the bitwise ops and smart > match. Unless these operators are to be eliminated from the language, > which is *not* an argument I wish to have here, we do not serve users > well by giving them rules that depend on internal details. The current > bitop rule is "was ever used as a string", which requires the user to > know what Perl operations and XS code call SvPV(). Telling them instead > "if it came from math then it's a number; if it came from a string > operation then it's a string," is better. This test can already be > performed by examining SV flags[*]. The macros merely give names to them. > > [*] once the bug fix for SVp_POK, which everyone seems to like, is applied --SteffenThread Previous | Thread Next