Daniel Ruoso wrote:
Em Seg, 2008-12-01 às 18:21 -0800, Darren Duncan escreveu:
I'm wondering how to write anonymous value literals of some Perl 6 basic types,
and I didn't see mention of this in synopsis 2.
Getting away from your question entirely, I think the issue here is that
while Perl 6 has support for strong typing, it is not really expected
that you approach your code with such strong typing...
<snip>
I'm not sure this is an aspect that everybody got, but there isn't
really a way to tell the actual implementation type of an Object in Perl
6, you can introspect the object as long as you wish, but you'll be
always asking something to that object, and the object itself is the one
giving the answers, therefore it can lie about itself, and that's fine.
There are even rumors that $obj.WHAT should return a canonical type,
even if its implemented by some low-level optimized version...
So, how to write anonymous value literals of that values? Well, you
won't need to do that...
I think some people misunderstand the purpose of strong typing as far as users
are concerned.
In a high level language like Perl, strong typing isn't about physical
implementation details, but rather it is about applying alternative user
interpretations to data. If a user declares a piece of data an Int or a Str or
a Blob (or as any other type), it means that they want to interpret that data as
an integer or a string of characters or a string of bits (or whatever the type
represents).
Strong typing in Perl means that Perl is conveniently and reliably keeping track
of this user-intended interpretation of the data, so it is easy for any piece of
code to act on it in a reasonable way. Strong typing lets user code be clean
and understandable as it doesn't have to do a lot of manual book keeping or
error checking that Perl can do for it, such as detecting the error of passing a
character string to a numeric multiplication operator.
It is expected that the physical representation of data behind the scenes may be
arbitrarily different from the user conception, depending on what the
implementation decides to do, and as you say users don't generally need to know
about that.
On a tangent, as a thought exercise, if you want to have a conceptual level type
representation hierarchy that is very portable and future proof, then there
would be exactly one primitive scalar type, which is the ('big' / unlimited
size) integer, essentially the Int type of Perl 6. You can then say a Bool is
an object with a single Int attribute whose value is zero or one, a Blob is an
object with a single attribute that is a dense array of Int that are 0..1, a Str
is an object that is also a dense array of Int that each represents a character
codepoint or something, a Rat/float is an object with 3 Int attributes for
[radix,mantissa,exponent] and so on. And if you ask, aren't bits lower level on
a computer than integers, I say not if you implement a non-binary computer, such
as one where each memory cell can hold 3 or 4 distinct values rather than 2; so
the concept of integer is more fundamental and universal than bit. Once again,
actual implementations could be more efficient, and users don't usually have to
think down to this level of abstraction, as Perl 6 would provide special syntax
for those other types so users don't have to write them as integers.
Carl Mäsak wrote:
> Darren Duncan (>):
>> Regarding Blob, that's not a collection type and its a fundamental type and
>> it still needs special syntax; I did suggest one in my previous message.
>
> Frankly, I don't see why it should need special syntax. Blobs are,
> most of the time, not typed in through the keyboard (too much/too
> error-prone). They might be a "fundamental" type (whatever that means
> in Perl 6), but they have this feel of low-level, internal,
> close-to-the-metal bitwise stuff that the user would rather not have
> to handle directly, but abstract away in some library.
>
> In the rare cases in code where a blob is directly assigned to a
> variable from a literal value, that code might be auto-generated by
> some script that doesn't get confused by a deluge of digits. For this,
> a list of integer values and a cast or a conversion function (maybe
> &pack) will do as syntax, in my opinion.
Blobs aren't any more close to the metal than Ints or Strs, they're just the
users stated preferred interpretation of data.
For example, if you want to represent a bitmap image as an opaque value, say a
16x16 icon, it probably makes more sense to represent that as a Blob than as a
Str or an Int. Or if you want to represent an arbitrary (small) hex dump of
something as a value, that would make sense to be a Blob value literal.
Note that Blob literals would most likely and should have separator characters
to make it easier to write and read, such as an underscore (like with number
literals), or such as whitespace (if a Blob literal has delimiters).
Even if their use is relatively rare by users compared to numbers or character
strings, Blob value literals should have their own special syntax, and you
shouldn't have to resort to a &pack expression or something.
Its not like this is without precedence. Other languages such as SQL have
special syntax for binary strings as distinct from char strings and numbers and
this makes a lot of sense, as users conceive of them very differently.
-- Darren Duncan
