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...
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

Reply via email to