On Mon, Nov 18, 2002 at 11:22:00AM -0800, Michael Lazzaro wrote:
: Here are some issues we need the design team to decide.
I shall presume that I can speak for the design team. :-)
: (A) How shall C-like primitive types be specified, e.g. for binding
: to/from C library routines, etc?
:
: Option 1: specify as property
:
: my numeric $a is ctype("unsigned long int"); # standard C type
: my numeric $b is ctype("my_int32"); # user-defined
: my numeric $c is ctype("long double");
:
: my int $a is range(1000..1255) is unchecked; # auto-infer 8bit
:
: Option 2: specify as type
:
: my u_long $a; # standard C type
: my long_double $c;
:
: Option 3: ???
:
: (See p6d discussion, "Numeric Types")
These options are not mutually exclusive in the presence of type
aliasing. However, my overall preference is to keep the base language
clear of lots of type names, but allow you to add in any number of
properties that constrain or clarify the basic types. There's no
reason we couldn't say
use ctypes;
and get in all the short definitions, for some definition of "all".
But I don't want to inflict all these names on ordinary Perl programmers.
That would just be cruel.
: (B) Need to know the root of the numeric types
:
: Option 1:
: numeric (mostly abstract base class)
: - num
: - int
:
: Option 2:
:
: num (floating point 'num' is the base class)
: - int
:
: Option 3: ???
I'd lean towards option 1, insofar as low-level types can be considered
objects at all. I suppose there might also be an abstract Numeric type...
: (C) If C-like primitives are builtin, need to know what their type
: names/aliases will be, and need to verify whether _ALL_ will have
: promoted counterparts, e.g. numeric -> Numeric, u_long -> U_Long, etc.
This seems like trying to count how many species of mammal have wings.
You can't have a type that is simultaneously constrained and not
constrained to fit within a certain representation specification.
: # (TEMPORARY) need final list of numeric types & any aliased names,
: # assuming we don't want to support *all* of these names (tho we could)
:
: # the base numeric type
:
: numeric
:
: # signed integers
:
: int
: int8 char
: int16 short short_int
: int32 long long_int
: int64 quad long_long long_long_int
Are these actual sizes, or minimal sizes? If you ask for int8, is
the implemenation allowed to stick it into an int16?
: # unsigned integers
:
: bit
: uint u_int
: uint8 u_int8 u_char byte
: uint16 u_int16 u_short u_short_int
: uint32 u_int32 u_long u_long_int
: uint64 u_int64 u_quad u_long_long u_long_long_int
:
: # floating point numbers
:
: num (== double)
: float
: double
: long_double
I'd say generating this list is the job of whoever writes the ctype
module. And that's a bit of a crock anyway, since the available types
will really depend on the underlying C/Java/C#/whatever implemenation.
Larry
