Objects. The semi-announcement that they'll put Cor in the Core is a good thing (as long as Cor actually delivers on its promises)

Actually, getting Cor into the core now that backward compatibility is going to be broken, IMO, doesn't make too much sense.

Moose creator, Stevan Little, pursued for a long time the idea of adding a powerful, modern and feature rich native OO framework to Perl, IIRC, he went into creating several prototypes, but time after time he hit the backward compatibility issue an at the end he throw in the towel (BTW, I recommend revisiting its Perl is not Dead, it is a Dead End talk as it is quite relevant to this discussion).

Ovid, who is a very clever but also practical guy, instead of persuading the perfect, but unrealisable OO system took a different view: could we get something that is useful, simple, cover most use cases and could be implemented without pervasive internal changes or breaking backward compatibility? And he come to Cor, which IMO is very good given the constraints, but definitively not state of the art.

So, in summary, we are getting the no-so-good solution now that the rule that had been making the really-good-ones infeasible is going to be lifted!

And he come to Cor, which IMO is very good given the constraints, but definitively not state of the art.

Hi salva. Thanks for your kind words. Version 1 of Cor is definitely trying to hit the “Minimum” in “Minimum Viable Product” because we don’t want to find ourselves building on a Jenga tower. That being said, when you say “not state of the art”, I would love to hear your thoughts on that. In particular, can you share solid examples of what you think state of the art should be?

Cheers,
Ovid

Hire me for training or software development.

I am quite biased here as I am a Lisp fan, but for me the state of the art continues to be mostly, the three decades old idea of having a metaobject protocol or an equivalent mechanism, allowing the programmer to redefine how objects behave (method resolution and composition and even maybe dispatching, storage, dynamic class creation, etc.).

Adding support for a proper MOP would require breaking backward compatibility for XS. If I recall it correctly, that was the main pain point found by Stevan Little when he tried to do it (or well, it has been a long time, so maybe that was my conclusion when I tried to imagine how to do it and I am now confused and attributing my thoughts to Stevan). In any case, my point was that if Perl 7 was going to break backward compatibility, then why not take advantage of the situation to also change the internals for something so important (in my opinion) as having a powerful and future proof OO system?

It seems that the idea of releasing a backward incompatible Perl 7 has now been reconsidered and so my point has become mot!

I also have to say that now, that you have forced me to review the Cor proposal with more attention, I see no reason why a MOP (or equivalent) couldn't be added in the future. So far, I can not find any place where you are closing doors, I find the syntax pretty flexible and consistent so, I am all in for Cor!

... and I was going to finish my message here, but you have asked me for solid examples, and so far I have just make vague request for a MOP, without really justifying what I thing we need one, so let me show an example of something solid: Class::StateMachine

That class is actually a metaclass. It uses the MRO hooks to redefine object resolution so that method dispatching takes into account the object class but also its current internal state. As an example, if you have a class Dog modeling a dog, with a on_head_touched method, you can declare several implementations for that method in such a way that the behavior when the dog is happy or angry is different.

Then there is Class::StateMachine::Declarative that exposes the functionality from C::SM in a more friendly and feature rich fashion though, still ugly because everything has to fit into a Perl data structure. The important thing here, is not that those modules allow you to do anything new (they don't), it is that they introduce a new way of modeling with objects, a different way of thinking and of structuring your code.

IMO, the ideal Cor (even if it is a future Cor), should be extensible enough to allow me to support things like Class::StateMachine::Declarative on top of it. And that means, controlling the class build process, including adding support for new keywords inside the class { ... } blocks, and then, also controlling what happens when some method is called or some object slot accessed.

To be fair, as far as I know, Class::StateMachine is the only class in CPAN besides those related to C3 resolution, making use of the mro hooks. That may be an indication of how unneeded a MOP is, or maybe it is just that it is to hard to use and that's why nobody is using it, who knows!!! But for me, Perl has been always about flexibility, a language that can be twisted to suit the programmer, not the other way around and so... I want a MOP!

Re: the dead end talk, thanks for that, I'll definitely check it out. I'm entirely ignorant of those prototype efforts, but am curious now how they compare to Cor.

The proposed changes don't thrill me enough to make me want to break existing code.

I'm mostly serious when I ask "what breaks".

If your code works with 5.32, why won't it work with 7?

If your code works with 5.32, why won't it work with 7?

If you aren’t inclined to change your code, plenty will break if the p7 announcement post is accurate—because flipping strict and turning off bareword file handles and indirect object calls breaks a lot of code.

If you are willing to change some pragmas, then nothing will break in 7. But what seems to bother me and almost no-one else is: they explicitly say you will lose compatibility promises when they move to 8–even guessed out loud that indirect object notation could be removed in 8 as an example. And they clearly don’t plan to wait too long to make that jump. What actually transpires may be very different, but I’m taking what was presented at face value, and I personally think it’s unwise. I could be convinced in the face of large gains (I listed a few that I would consider worth some breakage), but breaking compatibility because you think signatures look better where prototypes are? No thanks.

If your code only works properly without strict, wasn't your code already broken? And broken by design? Unless you're talking about one liners (which will likely be just fine with the automatic compatibility mode on -e), only people who write code that would be a nightmare to review and maintain anyway will be caught off guard by perl7.

Modernizations worth breaking existing perl code

In my list there are two kind of reasons why backward compatibility could be broken:

1. Sane behavior and completing already implemented features: for instance, all the bugs related to Unicode; Windows support; prototypes that really allow me to mimic any builtin; etc. There are lots of edge cases that perl does not handle correctly.
2. Extensions that let me solve problems in different ways, or in other words, support for other programming paradigms: massive multi-threading; async programming, co-routines; type declarations; a modern, full-fledged object system; multi-methods; a proper exception system, that is used from the core; support for new platforms as the JVM, Android, the browser; binary compilation; etc.

In general, I don't think backward compatibility should be broken for features that are merely syntax sugar, specially when they can be activated on demand using a use feature foo or use v13 pragmas.

isn't FFI::Platypus supposed to solve this?

XS has two typical uses: one is writing interfaces to external libraries, that's also what FFI::Platypus does.

But then, XS is also a way to extend Perl in its own. It is another way to write modules, for instance, when performance matters or when access to the runtime internals is required to do something. I don't thing Platypus supports that.

I have zero experience using Platypus, but I doubt any library exposing a clean FFI would allow me to do the tricks I have done in XS sometimes... though, I would never say that disallowing those would be an unacceptable trade off!

Great, thanks for explaining!

> the tricks I have done in XS sometimes... though, I would never say that disallowing those would be an unacceptable trade off!

well you know my opinion, that lexical macros would be the best way to go!

Hope to see you in one of the next conferences again. :)

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

Well, perhaps we could have a Platypus XS-emulator? It will not be able to modify runtime internals, unless through an API, but the rest of XS code can be run independently of current internals. Right now (with my minimal understanding, hence the hand-waving) these internals are accessed via macros and global variables. Introduce a layer to isolate the internals: macros become functions, global variables access replaced with accessor functions. Better still, a Perl interpreter behaves like an object. It is no longer the "centre of the universe" (as https://perldoc.perl.org/perlxs.html#CAVEATS says) but it is controlled by a meta-interpreter. This way, and with an API in place for controlling and accessing interpreters, a meta-interpreter can spawn as many Perls and many different Perl versions. As long as they adhere to the API. For older Perl's a wrapper will be needed to provide this API.

Also, again with my minimal understanding, perhaps it will no longer be needed to use XS for performance but, instead, write algorithm in any Platypus-supported language and use Platypus to access it from Perl.

Here is a funny idea: statically link XS code with Perl-X.Y.Z libraries and access it via Platypus from any other Perl version. Essentially one runs two different perl versions one inside the other. Though, again, one can't control the internals and do the tricks.

edit: also relevant to this thread Re^2: Modernizing the Postmodern Language?.

• A Perl REPL would be very nice, agreed, but I do not think that that would break much code, especially if input-dependent: present REPL if STDIN is a terminal, read program if STDIN is a pipe or file.
• I do not know if retiring XS is as good an idea as it sounds — XS contributes significantly to perl's performance with some extensions.
• I am not sure that there are any usable sigil characters left in ASCII, although caret might be usable if it can be disambiguated from bitwise-XOR. Ampersand is both code sigil and bitwise-AND, so this might be workable.
• Generating webassembly sounds like a role for a B:: module.

A Perl REPL would be very nice, agreed, but I do not think that that would break much code,

It is possible you're right, and that's preferable. But: if I were presented with a first-class repl with completion and introspection, and also acts as an LSP server for $EDITOR, but to get it I had to accept a couple syntax compromises enabled via 'use v7', I'd accept that.

I believe it was one of your initial replies that clarified that for me... the question of the justification/value-proposition. I believe the justification given is: this will help us appeal to new users. I'm not sure that the proposed syntax adjustments will accomplish that. After all, Raku polished several of Perl's rough edges. Where are its new users?

The conversation I'm really not looking forward to is:

Me: "Oh, and we're going to have to make a few changes to the Perl scripts, and re-test them sometime this year." Boss: "If we have to do that, let's just get $new_hire to re-write them in $flavor_of_the_month."

If $boss is inclined to rewrite existing code over making (relatively) small changes you might need to whack him with a copy of Brooks (ISBN 9780201835953) a few times . . .

The cake is a lie.
The cake is a lie.
The cake is a lie.

a first class API into the interpreter ... insulates ... 

I find this important. Also, modernising the guts (without breaking anything, is that possible?) is equally important and will pay off in the future.

without breaking anything, is that possible?

No.

It is impossible to change the internals in any important way and keep XS code working.

Several years ago, Nicholas Clark (a perl's internals guru) tried porting perl 5 to parrot (the Perl 6 runtime), and IIRC, he didn't get too far because of XS. See Ponie has been put out to pasture.

Also, once you remove the XS compatibility requirement, it would be very naive to reinvent a new guts just for running Perl 7.

When perl 5 came out, they were forced to invent everything from scratch, but now, there are lots of mature, efficient and feature rich runtimes you can reuse: .Net, JVM, MoarVM, etc.