[PHP-DEV] P-- or when less is more

[Umberto Salsi]

P-- or when less is more
Dreaming under the August Sun
=

1. Defining a simpler scripting language, basically PHP 5.0 but without
type-hints.

2. Developing an interpreter for the scripting language above. Basically,
a trimmed-down version of the current interpreter. This is the
"Interpreter project".

3. Developing an official static analyzer implemented using the same
scripting language above. People interested into strictness, safety and
security, could contribute with only the knowledge of the P-- language;
no C skills required. This is the "Analyzer project".

4. Developing an official compiler, capable to translate the validable
source code into directly executable code, or pseudo-code or whatever,
so to get faster and more efficient programs suitable for serious
applications. A compiler could be realized starting from the analyzer
above and could be based on the P-- language itself, so again no C skills
required. This is the "Compiler project".



The three projects in more detail
=

Interpreter project
---
- Formally defined syntax.
- All case-sensitive scanner, with keywords and simpler syntax.
- No type-hints (99% of the users do not care|hate them).
- No type-juggling (99% of the users will finally have to learn types
do really exist and for several good reasons).
- A true Object base class implementing hashing and equality comparison.
- Generic (or template) classes like "class Array { ... }". The
scripting shall language ignore this syntax; only the analyzer will take
care of it.
- Single-quotes '\x00\x01' creates instance of a Bytes object; all the
low-level bytes-related functions go in this class.
- Double-quotes "Abcd" create instance of a String object; and yes,
strings are immutable sequences of Unicode codepoints; all the
character-related functions go in this class.
- Arrays are regular objects with syntax sugar.
- No php.ini.
- No errors, only exceptions. Any function either do what it is expected
to do, or it fails with exception.
- No locale-aware behavior.
Expected audience interested or involved in this project: 99%.


Analyzer project

The analyzer will parse the source (including generic classes),
DocBlocks and annotations, checks for syntax errors, trying to figure
out how data and their types will flow through the code at run time. A
source either validates successfully or do not validate at all. If
it validates successfully, chances are that the program is (at least
formally) correct, safe and secure, and this make people like me very
satisfied and confident. The analyzer could be implemented using the
P-- scripting language itself, no C skills required. My PHPLint project
could be an example of such an implementation.
Expected audience interested or involved in this project: 1%.


Compiler project

Based on the analyzer above, this program may generate fast, efficient
executable code or pseudo-code. In perspective, the interpreter,
the analyzer and the compiler could be implemented starting from
the P-- language itself, an all may take advantage of the improved
performances. Again, no C skills required.
Expected audience interested or involved in this project: 0.1%.


Continuing dreaming...

 ___
/_|_\  Umberto Salsi
\/_\/  www.icosaedro.it

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[Olumide Samson]

On Fri, Aug 16, 2019, 5:08 PM Mark Randall  wrote:

> On 16/08/2019 11:18, Christoph M. Becker wrote:
> > It is not necessarily required to have an implementation for an RFC
> > available, see item (6) in .
>
> I have enormous respect for Derick, but I can't help but feel this "RFC"
> was bodged from the start.
>
> There's certainly a place for straw polls, the ability to receive quick
> feedback on opinions and sentiment can be a positive thing in a lot of
> circumstances. This however, seemed more like an invitation for
> internals developers to express that they wouldn't entertain spending
> any time on the proposal, in effect forcefully slamming the door shut on
> it before a proper discussion had been had.
>
> The end result did seem to be like watching Zeev be thrown to the lions
> in the colosseum. While entertaining for a short time, I believe it left
> something of a sour taste in the mouth, and it certainly did not present
> internals well to the outside world. The hasty edits to the Wiki then
> made it worse, and so on.
>

On this last paragraph written below, I'm seriously with you on this.

I believe for anything remotely positive to come out of this whole
> affair.


Things need to quickly and visibly pivot to a meaningful
> discussion about the long term game plan for PHP, and build a consensus
> on things such as strict typing(Optional through declare directive) ,
> overloading in the core functions, and
> perhaps most divisively, if "cleaning up the language" is in itself a
> viable justification for backwards compatibility breaks, and if so, what
> weight(the biggest weight ever) it should carry.
>

Just in case a poll is needed, I added my +1 on the whole section you wrote
last.

>

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[Mark Randall]

On 16/08/2019 11:18, Christoph M. Becker wrote:

It is not necessarily required to have an implementation for an RFC
available, see item (6) in .


I have enormous respect for Derick, but I can't help but feel this "RFC" 
was bodged from the start.


There's certainly a place for straw polls, the ability to receive quick 
feedback on opinions and sentiment can be a positive thing in a lot of 
circumstances. This however, seemed more like an invitation for 
internals developers to express that they wouldn't entertain spending 
any time on the proposal, in effect forcefully slamming the door shut on 
it before a proper discussion had been had.


The end result did seem to be like watching Zeev be thrown to the lions 
in the colosseum. While entertaining for a short time, I believe it left 
something of a sour taste in the mouth, and it certainly did not present 
internals well to the outside world. The hasty edits to the Wiki then 
made it worse, and so on.


I believe for anything remotely positive to come out of this whole 
affair, things need to quickly and visibly pivot to a meaningful 
discussion about the long term game plan for PHP, and build a consensus 
on things such as strict typing, overloading in the core functions, and 
perhaps most divisively, if "cleaning up the language" is in itself a 
viable justification for backwards compatibility breaks, and if so, what 
weight it should carry.


Mark Randall

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[Chase Peeler]

On Fri, Aug 16, 2019 at 12:08 PM Mark Randall  wrote:

> On 16/08/2019 11:18, Christoph M. Becker wrote:
> > It is not necessarily required to have an implementation for an RFC
> > available, see item (6) in .
>
> I have enormous respect for Derick, but I can't help but feel this "RFC"
> was bodged from the start.
>
> There's certainly a place for straw polls, the ability to receive quick
> feedback on opinions and sentiment can be a positive thing in a lot of
> circumstances. This however, seemed more like an invitation for
> internals developers to express that they wouldn't entertain spending
> any time on the proposal, in effect forcefully slamming the door shut on
> it before a proper discussion had been had.
>
> The end result did seem to be like watching Zeev be thrown to the lions
> in the colosseum. While entertaining for a short time, I believe it left
> something of a sour taste in the mouth, and it certainly did not present
> internals well to the outside world. The hasty edits to the Wiki then
> made it worse, and so on.
>
> I agree (although I didn't really find it entertaining for a short time).
As I said (or at least tried to say) in my previous comments on this
thread, I don't think Zeev's ideas were necessarily bad, just unwarranted
at this time. Unless I'm misunderstanding him, I think he, at least
somewhat, feels that way as well. He sees some issues coming down the road
and made this proposal as an attempt to prevent them. Others, myself
included, seem to feel that the problems he foresees aren't going to
happen, or at least aren't inevitable. As such, I wasn't so much saying
that P++, editions, or other similar ideas are totally off the table
forever and ever... just that we should wait until we reach a point where
one of them is necessary, since there is a good chance we won't ever reach
that point.

I encourage Zeev to continue refining and fine tuning his ideas, so that if
we do reach that point, we can hit the ground running. Until then, I think
any discussion on this mailing list goes beyond the level of "informal" and
takes focus away from advancing the language.


> I believe for anything remotely positive to come out of this whole
> affair, things need to quickly and visibly pivot to a meaningful
> discussion about the long term game plan for PHP, and build a consensus
> on things such as strict typing, overloading in the core functions, and
> perhaps most divisively, if "cleaning up the language" is in itself a
> viable justification for backwards compatibility breaks, and if so, what
> weight it should carry.
>
> I personally don't see this as necessary. I think it's safe to say that
anything is on the table. Every change needs to properly weigh the
positives and negatives. A new feature might be in high demand and cause no
BC issues, but, the resources required to build it prevent 10 other
slightly less highly demanded features. As was mentioned earlier, a lot of
the more sought after features (union types, enums, annotations, etc) don't
require BC breaks at all. What's holding them back isn't a lack of vision
or purpose either - it's the difficulty of implementing them.

A BC break to clean up the language might be justified in one case, and not
in another. To make a blanket statement that we will or will not attempt to
clean up the language is not wise in my opinion. It puts the project in a
bad place if it's forced to stick to it's decision, or, it makes the whole
reason for having made a decision pointless if we keep finding certain
items that are exceptions.


> Mark Randall
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[Mark Randall]

On 16/08/2019 17:40, Chase Peeler wrote

A BC break to clean up the language might be justified in one case, and not
in another. To make a blanket statement that we will or will not attempt to
clean up the language is not wise in my opinion. It puts the project in a
bad place if it's forced to stick to it's decision, or, it makes the whole
reason for having made a decision pointless if we keep finding certain
items that are exceptions.



Re: Entertainment, I'd liken it to something like watching the replay of 
a car crash. One really shouldn't, but one can't help but be mesmerised.


Onto the matter of nuance in decisions, I agree that things should be 
done on a case-by-case basis, however, you have to have something to 
weigh the pros and cons against.


Right now, so far as I can tell, the value of cleanup and improvement in 
any particular decision is undefined, because there's no general 
consensus on it.


Take short open tags, there are cases made for and against, and in my 
opinion the strongest case for it is language cleanup, to have one fixed 
way of doing something that can be taught so future developers don't 
start wondering what the difference is between them.


But what base weight does cleanup have? Is cleanup hugely important, or 
a complete non-factor that shouldn't be considered at all? If it's 
somewhere in between, where in between.


It would never be used in absolute terms, it's always something that 
would strengthen or weaken other arguments. BC breaking cleanup for 
cleanups sake isn't really going to fly, but cleanup because a 
particular set of functions are inconsistent, or exhibit unintuitive 
behaviour, those ultimately all have to start with a consensus on if 
it's worth breaking something, or making something more complex 
(namespaced function aliases?) for the sake of making the language as a 
whole "better".


My worry is that those with voting privileges on internals may end up 
splitting into two camps, and voting ideas up or down based on personal 
bias towards or against an underlying principle of clean-up and 
improvement or BC-supreme.


I doubt it will come up _often_, but when it does, it seems to be 
incredibly disruptive. I would argue it needs a wider debate and then 
people should use the result of that debate to inform their voting, 
knowing that "PHP" has agreed to weigh certain general concepts in a 
particular way.




Mark Randall

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[M. W. Moe]

Hello,

if you would drop zend engine as is and the idea behind it (which is most
difficult thing to admit and accept),
then use llvm-core. Making:
-- lexer, parser grammar
-- reference counting
-- type hint policies
-- builtins container
-- JITTER for compatibility.
-- bytecode
-- LLVM bytecode
-- symbolicated machine code
-- and so on

it's like picking your nose; meaning easy-peasy: when you have that in
place creating an other
dialect and 1 of them will be same; or even experimenting new
features...

it  will benefit the language at all:
- runtime execution, memory, exception handler  (`normally` handled)
- extension ecosystem you could autopen biddings without introducing bugs
from people.

Best.




On Fri, Aug 16, 2019 at 10:38 AM Mark Randall  wrote:

> On 16/08/2019 17:40, Chase Peeler wrote
> > A BC break to clean up the language might be justified in one case, and
> not
> > in another. To make a blanket statement that we will or will not attempt
> to
> > clean up the language is not wise in my opinion. It puts the project in a
> > bad place if it's forced to stick to it's decision, or, it makes the
> whole
> > reason for having made a decision pointless if we keep finding certain
> > items that are exceptions.
>
>
> Re: Entertainment, I'd liken it to something like watching the replay of
> a car crash. One really shouldn't, but one can't help but be mesmerised.
>
> Onto the matter of nuance in decisions, I agree that things should be
> done on a case-by-case basis, however, you have to have something to
> weigh the pros and cons against.
>
> Right now, so far as I can tell, the value of cleanup and improvement in
> any particular decision is undefined, because there's no general
> consensus on it.
>
> Take short open tags, there are cases made for and against, and in my
> opinion the strongest case for it is language cleanup, to have one fixed
> way of doing something that can be taught so future developers don't
> start wondering what the difference is between them.
>
> But what base weight does cleanup have? Is cleanup hugely important, or
> a complete non-factor that shouldn't be considered at all? If it's
> somewhere in between, where in between.
>
> It would never be used in absolute terms, it's always something that
> would strengthen or weaken other arguments. BC breaking cleanup for
> cleanups sake isn't really going to fly, but cleanup because a
> particular set of functions are inconsistent, or exhibit unintuitive
> behaviour, those ultimately all have to start with a consensus on if
> it's worth breaking something, or making something more complex
> (namespaced function aliases?) for the sake of making the language as a
> whole "better".
>
> My worry is that those with voting privileges on internals may end up
> splitting into two camps, and voting ideas up or down based on personal
> bias towards or against an underlying principle of clean-up and
> improvement or BC-supreme.
>
> I doubt it will come up _often_, but when it does, it seems to be
> incredibly disruptive. I would argue it needs a wider debate and then
> people should use the result of that debate to inform their voting,
> knowing that "PHP" has agreed to weigh certain general concepts in a
> particular way.
>
>
>
> Mark Randall
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[Christoph M. Becker]

On 16.08.2019 at 01:39, Peter Kokot wrote:

> Off topic question/request if it's maybe possible and doable unless
> I've missed something. Current RFC process is in short something like
> writing a text document together with the implementation itself via a
> pull request already and at the same time the discussion phase is
> happening. After discussion there is a voting phase based on the
> feedback from the comments. There, many times people who vote also
> sometimes don't add reasons why they vote against something and they
> stop the RFC from passing. RFC author, not only cannot implement it
> but they also waste their time with the implementation.
>
> Would it be a good thing if the RFC author would have a similar option
> to get voting results feedback before starting to code (implementation
> phase) on the RFC? So, they can see the results before the voting
> phase and if the time investment is worth the trouble of adding a
> feature or not.

It is not necessarily required to have an implementation for an RFC
available, see item (6) in .

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php