On Tue, Jun 10, 2003 at 12:04:14PM -0700, Michael Lazzaro wrote: > J: (scalar junctive to typed scalar) > > A scalar junctive, e.g. an "untyped" scalar, can always be silently > used as and/or converted to a more specific primitive type. This will > quite frequently result in the loss of information; for example, saying: > > my $a = 'foo'; > my int $b = $a; # $b is now C<0> > > works, but silently sets $b to 0, because the numeric value of C<'foo'> > is C<0 but true>.
On the subject of untyped scalars...what does it mean to say that the conversion is 'lossless'? For example: my $a = 'foo'; my Int $b = $a; # legal; $b is now 0; is there a warning? my $c = $b; # is $c 0, or 'foo'? my Str $d = $a; # no loss my $a = $d; # no effective change in $a my $e = $b; # what is $d? In the above, I would expect that $c is 0 and my $a = 7 but false; my Str $b = $e; # ??? What value does $f end up with? (My vote would be '7'.) Does it have any properties? Are any warnings emitted? > > (iv) ---- Pragma-Controlled Conversions ---- > > Given the above, and given the fact that our general answer to > everything is to Use A Pragma ;-), we have the following tentative list > of needed pragmas. For each possibility, we need to be able to declare > that a given implicit type conversion will be silently allowed, will > result in a warning, or will result in an exception. > > A (very) rough proposed pragma form, for the sake of argument, is: > > use strict conversions; # all on (exceptions) > no strict conversions; # all off > > use strict conversions allow => << cv1 cv2 ... >>; # selected > conversions are allowed > use strict conversions warn => << cv1 cv2 ... >>; # selected > conversions give warnings > use strict conversions fail => << cv1 cv2 ... >>; # selected > conversions give exceptions Seems generally, but I'd like to see this be organized into hierarchies, like Perl 5 (recent versions) warnings: the Numeric group would control every form of numeric conversion, the Truncation subgroup would control everything in the Numeric group that could end up truncating data (e.g. int -> short), etc. > S: (string to numeric) My vote for default: C<allow> > F: (float to int) My vote for default: C<warn> > N: (numeric range) My vote for default: C<allow> I also suggest adding an extra pragma: use rangechecking warn => << Int_to_int >>; use rangechecking warn => << Num_to_num >>; use rangechecking fail => << Int_to_int >>; use rangechecking fail => << Num_to_num >>; This lets you trade speed for safety on a lexically-scoped basis. > (vi) ---- Conversions of User Defined Types/Classes ---- > > It may be useful to allow the same level of pragma-based control for > user-defined types and classes. For example, a given class Foo may > wish to be "silently" convertable to an C<int>. One proposed syntax to > declare the method of coercion/conversion might be: > > class Foo { > ... > > to int {...} # or C<as int {...}>? > } > > However, users of such a class could adjust the warning level of the > given conversion using the alternate syntax given above (v): > > use strict conversions warn { Foo => int }; Adding to the 'hierarchical pragmas' idea that I mentioned above...how about a 'to_int' group, which controlled any type (user defined or system) that was attempted to convert itself to an int? The extensions are obvious. --Dks