Tim Bunce wrote:
On Wed, Jul 15, 2009 at 03:46:08PM +0100, Sentra Systems wrote:
Do you want these to be typecast to 'Any'?
In the short term, yes. In the longer term we'll need to be more
flexible. I envisage a 'type map' file that, for each Java type,
specifies the corresponding Perl6 type (either builtin or in a module).
Any types not in the file would generate a warning and map to Any.
Feel free to add that in! I'd guess it would be straight-forward.
On that note, I've been using what influence I have over the Perl 6 language
design in the last few years to try and improve its savvy for relational
database features and semantics.
I currently believe, as also documented indirectly in my Muldis D language spec,
that every SQL data type of any consequence already has a direct Perl 6
counterpart, but that in general Perl 6's version is better where different.
For examples:
Perl 6 | SQL
---------+-----
undef | NULL
Bool | BOOLEAN, INTEGER(1), NUMBER(1), ...
Int | SMALLINT, MEDIUMINT, INTEGER, BIGINT, ...
Rat | NUMERIC, DECIMAL, ...
Num | FLOAT, DOUBLE, ...
Blob | BLOB, BINARY, VARBINARY, BIT, BYTEA, RAW, ...
Str | CHAR, VARCHAR, TEXT, CLOB, NATIONAL, VARCHAR2, LONG, ...
Instant | TIMESTAMP, ...
Duration | INTERVAL, ...
<Syn32> | DATETIME, DATE, TIME, ...
Now, spatial types aren't in the Perl core of course, but I'm sure that direct
analogies to GIS in SQL can be had reasonably in an extension.
And distinguishing various constrained versions of SQL types such as VARCHAR(10)
or what have you is just a "subtype Str10 of Str where { 0 <= $_.graphs <= 10 }"
or some such.
-- Darren Duncan
