> * Patrick R. Michaud (pmich...@pobox.com) [151013 01:05]:
>> 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. :)
> Yes, I like the typed undef... as real undef. Let's call it "Car:undef"
> when it fits in a Car typed variable which is not used yet. Easy to
> understand for Perl5 people.
Why do we need to add an adverb on a type to talk about the type? If you
want to pass a class around
for example, do you alsway want to but an ":undef" on it? Then somebody
would ask: "What do I get when
I dont put said :undef on it?" - And the answer might be "Well, you get
basically the same."
Also please keep in mind that Perl 6 does not have to be seen from a
Perl 5 perspective. There are more
valid views.
>>> 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.
> This is a different view on the syntax layer: implementor vs programmer.
> As programmer, knowing of optimizations of this kind adds to the
> confusion, not to the understanding. As long as
> my Int $a; my Int $b; $a = $b = 1; $b = 2; $a.say, $b.say
> produces 1\n2\n, I'm fine with any implementation. I don't want to know
> how it is done internally.
No, rot really. You stated that you have two dirrenent types there, but
it really is the very same type.
It is just so that two variables containing it.
>> 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
> I use it in JavaScript. I reread a few tutorials about OO/prototype
> in Javascript yesterday. They smoothly speak about adding methods to
> objects etc. They speak about types and objects in a very natural way.
> They don't speak about undef objects to contain types, which are used
> as object factory. I have not found the need for :U there.
I've also not used :U in Perl 6 yet. There might be scenarios where you
want to accept, say, class definitions
only but these cases are rare I'd say. More often you call a
construction on a type, or smartmatch a value
agains a type. And this really happens regularly in idomatic Perl 6 code.
>> 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.
> Trying to reformulate this without spoilers of internal details:
>
> Perl6 has classes, instances, and prototypes. Commonly used
> types, like Int, are prototypes based on classes. Therefore,
> they can easily absorb features via Roles and Mixins.
>
> Note about the internals: we are not keeping a separate
> administration of type features, but keep that inside the
> instantiated objects. As all prototype-based languages do.
>
> Acceptable?
>
>> 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.
> Yes, disambiguation either via a keyword (class method/instance method)
> or via the invocant (being a type :T or instance... multi methods to
> the rescue)
>
> For me, prototypes in JavaScript work well, because all graphical
> elements on the screen are slightly different in behavior. I am a bit
> afraid to get into swamps when programs are large, where it is already
> hard to keep track on all the cleanly organized classes.
>
> So... my hessitation seems to be limited to the explanation and name
> of the flag :U, which tell me that a type is an undef. Type defining
> features are loaded into a base object which does not carry a value: yes.
> Via specialization you get objects which carry a value.
>
> Maybe this comes back to the distiction between implicit and explicit
> undefinedness.
