On Tue, Oct 13, 2015 at 12:32:01AM +0200, Mark Overmeer wrote:
> Yes, that what I started realizing when I saw all the pain Perl6 goes to
> ignore the existence of a real "undef" in the language. (I follow Perl6
> from a short distance since its start, read all original designs, but
> this penny did not drop before, sorry)
Actually, it's the other way around. Perl 6 is not trying to ignore
the existence of an "undef", it's recognizing that there are in fact
many different kinds of undef. It's the languages that think there's
only one "real undef" that are confused. :)
> The reasoning behind the output of
> my $a; $a.say; $a = 1; $a.say being (Any) \n 1 \n
> Which actually means
> "unstantiated (Any)" versus "instantiated (Int) value=1"
> for me personally painfully imbalanced.
>
> my Car $a; my Car $b; Now I have two different types.
Not really, you have two variables, both of which have been
initialized to the same (undefined) Car object. It's not
much different than
my Int $a; my Int $b; $a = $b = 1;
where $a and $b end up being variables that contain the same
Int object.
> Is there any precedence in a succesful programming language where types
> and values get mixed-up this way?
I think Self would be the (pardon the pun) prototypical example, and
it's also a common feature of JavaScript. As to whether there is
precedence in other "successful" programming languages -- to me part
of Perl's legacy has always been that it offers exotic (at the time)
features that other "successful" languages didn't provide. Perl has
often been the tip of the spear in making "exotic" features commonplace. :)
Larry and the other OO experts can probably comment on this in more
detail; but this construction of types allows Perl 6 to incorporate
a lot more features of prototype-based languages than the traditional
class-based model. I suspect it's also related to a proper
implementation of mixins and roles.
> For me, a "Car" is not "a vehicle which is not yet there", but is a
> featural and functional template of a thing. The template describes the
> interface of a car, not the instance of a car. A type is scientific,
> an object is dull facts. Is that an old-fashioned, traditional idea
> to be abandoned?
Perl 6 still has classes and instances, but Perl 6 also adds the
ability to represent undefined instances of a type (or, rephrased,
to have typed "undefs"). Perl 6 then binds the commonly-used
identifier (e.g., C<Int>) to an undefined instance rather than the
class object that defines the instances. Once you accept that model,
it seems to work out very well in practice.
When we need to communicate with the class definition (rather than
an instance), there's a convenient .^foo syntax that allows us to
accomplish this, which works on any instance (defined or undefined).
That becomes important when you want to do something like:
my Research $a;
say $a.methods(); # invoke "methods" defined by Research
say Research.methods(); # same as above
say $a.^methods(); # return a list of methods for Research objects
If Research refers instead to the class definition, then the
method namespaces for instances and classes begin to clash, and
we have to introduce all sorts of disambiguation for that.
Pm
