Hi Patrick, thank you for your thoughts. I needed a bit more time
for the response ;-)
* 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.
> > 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.
> 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.
> 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.
--
MarkOv
------------------------------------------------------------------------
Mark Overmeer MSc MARKOV Solutions
m...@overmeer.net soluti...@overmeer.net
http://Mark.Overmeer.net http://solutions.overmeer.net
