Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

Posted by Michael Morris 
Ryan Jentzsch
Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax
January 10, 2018 07:20PM
I agree with Michael (to a large degree) and I think I see clearly
Michael's point:
Under the current system I will NEVER create an RFC (or find someone with
the Zend engine coding chops to help me) because the RISK vs. REWARD with
the current RFC system is too likely to be a colossal waste of everyone's
time.
Currently the tail wags the dog (implementation details govern top level
policy). The current process nearly insists I spend valuable time coding up
front with a good chance that if/when the RFC goes up for a vote someone
will still be bleating about syntax, or using tabs vs. spaces, or some
other minor detail -- with a 2/3 vote needed it may shoot all my
preliminary hard work to hell. No thanks.



On Wed, Jan 10, 2018 at 6:27 AM, Michael Morris <[email protected]> wrote:

> On Wed, Jan 10, 2018 at 12:53 AM, Rasmus Lerdorf <[email protected]>
> wrote:
>
> >
> > The difference here is that the end syntax is something like 10% of the
> > problem. 90% of it is fitting it into the engine in an efficient manner
> > giving that it is affecting the very core of the engine. An RFC on this
> > issue that doesn't address the bulk of the problem isn't all that
> helpful.
> >
> >
> It makes absolutely NO sense to do that 90% of the work to have it all
> burned up when the proposal fails to carry a 2/3rds vote because the syntax
> is disliked.
>
> Also, drawing the architectural drawings for a skyscraper is also like only
> 10% of the work, but it's a damn important 10%.
>
> That the implementation will be a major pain in the ass to do is all the
> more reason to create and pass a planning RFC before doing any related
> code/implementation RFC's. It will encourage people to do the research to
> try to figure out how to get this done because they know the syntax is
> approved and they aren't fiddling around in the dark trying to figure out
> how to do something that may not be accepted for inclusion at all, which is
> a huge waste of time.
>
Rasmus Lerdorf
Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax
January 10, 2018 07:30PM
On Wed, Jan 10, 2018 at 10:11 AM, Ryan Jentzsch <[email protected]>
wrote:

> I agree with Michael (to a large degree) and I think I see clearly
> Michael's point:
> Under the current system I will NEVER create an RFC (or find someone with
> the Zend engine coding chops to help me) because the RISK vs. REWARD with
> the current RFC system is too likely to be a colossal waste of everyone's
> time.
> Currently the tail wags the dog (implementation details govern top level
> policy). The current process nearly insists I spend valuable time coding up
> front with a good chance that if/when the RFC goes up for a vote someone
> will still be bleating about syntax, or using tabs vs. spaces, or some
> other minor detail -- with a 2/3 vote needed it may shoot all my
> preliminary hard work to hell. No thanks.


There is a middle ground here. I agree that doing months of work on a
rock-solid implementation doesn't make sense if you don't know the RFC will
pass. On the other end of the spectrum, RFCs that are essentially feature
requests with no specifics on the actual implementation also don't make any
sense. A good RFC strikes a happy balance between the two. For many/most
things, the actual work in figuring out the implementation isn't that bad.
As Sara said, a full implementation isn't needed, but a rough sketch of
what changes are needed along with their potential impact on the existing
code definitely is. And yes, unfortunately, if your RFC touches the basic
building block of PHP, the zval, then that rough sketch becomes even more
important. If you stay away from trying to change a 25-year old loosely
typed language into a strictly typed one, then the RFC becomes much simpler.

-Rasmus
Michael Morris
Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax
January 10, 2018 07:50PM
On Wed, Jan 10, 2018 at 9:04 AM, Rasmus Lerdorf <[email protected]> wrote:

>
>
> On Wed, Jan 10, 2018 at 5:27 AM, Michael Morris <[email protected]>
> wrote:
>>
>> Also, drawing the architectural drawings for a skyscraper is also like
>> only
>> 10% of the work, but it's a damn important 10%.
>>
>
> Wow, that's rather insulting to the amazing work Dmitry, Nikita, Xinchen
> and others are doing working on the core of PHP.
>

No insult was intended here. I apologize if any is taken.


> Describing the syntax/UI for a feature like this is nothing like the
> architectural drawings for a skyscraper.
>

In terms of time and effort spent it is. It often takes years to complete
plans drawn up over the span of weeks. The analogy becomes more firm when
you compare the man hours on each side - an architect can draw up plans for
a house in less than 100 hours (unless it's a freaking huge house). The
contractor labor hours will be 100 times that at a minimum. If anything I'm
off in scales, but I was being anecdotal - I wasn't aiming for precise
accuracy.

Plans still must precede work, and if the ramifications of those plans are
to be far reaching they need to be agreed upon as early as possible.
Michael Morris
Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax
January 10, 2018 07:50PM
On Wed, Jan 10, 2018 at 12:27 PM, Rasmus Lerdorf <[email protected]> wrote:

> If you stay away from trying to change a 25-year old loosely typed
> language into a strictly typed one, then the RFC becomes much simpler.
>
> -Rasmus
>

I have REPEATEDLY stated that is not the goal. I don't misrepresent what
you say, please do not do that to me.

I want to see strict typing as an option, not a requirement.

Arggh...

I said I'd stay away from implementation, but would this work? Working
this into z_val in any way is problematic. So, store elsewhere?

Create a symbol table that holds the strict variables and the types they
are locked into. The strict keyword pushes them onto that table, the var
keyword pulls them off. When an operation that cares about type occurs
check that table - if the var appears there than authenticate it.

I would hope that if a programmer doesn't want strict typing the overhead
of checking an empty table would be minimal, even if repeated a great many
times.
Rasmus Lerdorf
Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax
January 10, 2018 08:10PM
On Wed, Jan 10, 2018 at 10:48 AM, Michael Morris <[email protected]> wrote:

> On Wed, Jan 10, 2018 at 12:27 PM, Rasmus Lerdorf <[email protected]>
> wrote:
>
> > If you stay away from trying to change a 25-year old loosely typed
> > language into a strictly typed one, then the RFC becomes much simpler.
> >
> > -Rasmus
> >
>
> I have REPEATEDLY stated that is not the goal. I don't misrepresent what
> you say, please do not do that to me.
>
> I want to see strict typing as an option, not a requirement.
>

But the point is that whether it is an option or not, it still has to touch
the zval. Which means everything changes whether the option is enabled or
not. If you store this information elsewhere, that other location has to be
checked on every zval access. Basically the work is identical to the work
required to make PHP strictly typed. Making it optional might actually be
harder because we have to build both and add more checks in that case.

The only viable place I see to store this optionally is outside the runtime
in a static analyzer like Phan (which already does this) which matches how
HHVM solved it. Of course, there may be a cleaner way to do it. But that is
why an RFC on this topic has to give a clear plan towards this cleaner
implementation.

Now if the RFC was a plan for baking a compile-time static analysis engine
into PHP itself, that would be interesting. But that is a *massive* project.

-Rasmus
Andreas Hennings
Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax
January 10, 2018 08:30PM
On 10 January 2018 at 19:59, Rasmus Lerdorf <[email protected]> wrote:
>
> Now if the RFC was a plan for baking a compile-time static analysis engine
> into PHP itself, that would be interesting. But that is a *massive* project.

Even with my limited understanding of the engine, I can imagine this
to be a lot of work.
But it sounds much better to me than adding more expensive runtime type checks.
I think it would be worth exploring as a long-term direction.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Andreas Hennings
Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax
January 10, 2018 08:30PM
Whether we work with runtime type checks or compile-time static analysis:
The user-facing language design questions would still be the same, right?
E.g. we would still have to distinguish type-locked parameter values
vs dynamically typed parameter values.

On 10 January 2018 at 20:23, Andreas Hennings <[email protected]> wrote:
> On 10 January 2018 at 19:59, Rasmus Lerdorf <[email protected]> wrote:
>>
>> Now if the RFC was a plan for baking a compile-time static analysis engine
>> into PHP itself, that would be interesting. But that is a *massive* project.
>
> Even with my limited understanding of the engine, I can imagine this
> to be a lot of work.
> But it sounds much better to me than adding more expensive runtime type checks.
> I think it would be worth exploring as a long-term direction.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Rowan Collins
Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax
January 10, 2018 10:20PM
On 10/01/2018 18:39, Michael Morris wrote:
> On Wed, Jan 10, 2018 at 9:04 AM, Rasmus Lerdorf <[email protected]> wrote:
>
>> Describing the syntax/UI for a feature like this is nothing like the
>> architectural drawings for a skyscraper.
> In terms of time and effort spent it is. It often takes years to complete
> plans drawn up over the span of weeks. The analogy becomes more firm when
> you compare the man hours on each side - an architect can draw up plans for
> a house in less than 100 hours (unless it's a freaking huge house).

I don't think Rasmus was saying architects' plans aren't important, or
making any comment about the scale of the task. I think he was saying
that things like syntax and UI are not the appropriate part of the
process to compare to architects' plans. Architects know how buildings
work, and spend those weeks making sure the subsequent years aren't
going to be wasted because the plausible-looking shape the client asked
for can't actually support its own weight.

And just to be clear, this particular feature IS a freaking huge house.
Worse, it's a type of skyscraper nobody has ever tried to build before.
Sketching the kinds of shapes it might have is interesting; getting hung
up on what size the windows are (the exact keywords to use) is probably
a waste of time until we've figured out if there's a material that bends
that way. And saying "hey, could you make it out of carbon nanotubes?"
is a fun conversation to have over a beer, but probably isn't going to
be that helpful to people who are experts on skyscrapers and material
science.

Apologies for extending the metaphor somewhat beyond stretching point,
but I think it acts as a reasonable illustration of where people are
coming from in this thread.


> Plans still must precede work, and if the ramifications of those plans are
> to be far reaching they need to be agreed upon as early as possible.

Absolutely, and unfortunately, the biggest ramifications of this
particular type of change is going to be in the very core of the engine.
That's not true of every feature, but for this particular feature, one
of the parts that needs planning and agreeing as early as possible is
"how are we going to do this without killing performance".


Regards,

--
Rowan Collins
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Ryan Jentzsch
Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax
January 10, 2018 10:20PM
In my opinion The Strong Typing Syntax RFC will have less of a chance of
passing a vote than https://wiki.php.net/rfc/typed-properties.
Since the typed-properties RFC was confined to properties on a class (and
looking at the code it appears to me that it wasn't too difficult to
implement the type strictness constraints). Sadly, even after it was shown
to have minimal effect on performance the RFC was still shot down.

Strong Typing Syntax I would think is even more complicated given this
touches ALL zval processing internally. The concern of "expensive run-time
checks" can of course be mitigated by requiring declare(strict_types=1) to
enable/allow strong typing syntax.
I'd love to see Strong Typing Syntax in PHP but realistically, given the
past history, this RFC will need to target version 8.


On Wed, Jan 10, 2018 at 12:25 PM, Andreas Hennings <[email protected]>
wrote:

> Whether we work with runtime type checks or compile-time static analysis:
> The user-facing language design questions would still be the same, right?
> E.g. we would still have to distinguish type-locked parameter values
> vs dynamically typed parameter values.
>
> On 10 January 2018 at 20:23, Andreas Hennings <[email protected]> wrote:
> > On 10 January 2018 at 19:59, Rasmus Lerdorf <[email protected]> wrote:
> >>
> >> Now if the RFC was a plan for baking a compile-time static analysis
> engine
> >> into PHP itself, that would be interesting. But that is a *massive*
> project.
> >
> > Even with my limited understanding of the engine, I can imagine this
> > to be a lot of work.
> > But it sounds much better to me than adding more expensive runtime type
> checks.
> > I think it would be worth exploring as a long-term direction.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Stanislav Malyshev
Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax
January 22, 2018 10:20PM
Hi!

> I want to see strict typing as an option, not a requirement.

You seem to be under impression that this somehow makes things easier.
It does not. To explain: let's say you design a strictly typed language,
like Java. The compiler knows which variable is of which type at every
point, and if it's not clear for some reason, it errors out. You can
build a compiler on top of those assumptions.
Now let's say you design a loosely typed language, like Javascript. The
compiler knows variables have no types, only values have it, and builds
on top of that (as in, it doesn't need to implement type tracking for
variables).
Now, you come in and say - let's make the compiler have *both*
assumptions - that sometimes it's strict and sometimes it's not.
Sometimes you need to track variable types and sometimes you don't.
Sometimes you have type information and can rely on it, and sometimes
you don't and have to type-juggle.
Do you really think this just made things *easier*? To implement both
Java and Javascript inside the same compiler, with radically different
types of assumption? If you have desire to answer "yes", then a) please
believe me it is not true b) please try to implement a couple of
compilers and see how easy it is.

Having two options is not even twice as harder as having one. It's much
more. So "optional" part adds all work that needs to be done to support
strict typing in PHP, and on top of that, you also have to add work that
needs to be done to support cases where half of the code is typed and
the other half is not. And this is not only code writing work - this is
conceptual design work, testing work, documenting work, etc.

Without even going to the merits of the proposal itself, it certainly
looks to me like you are seriously underestimating what we're talking
about, complexity-wise. I am not saying it's not possible at all - a lot
of things are possible. It's just "it's merely an option" is exactly the
wrong position to take.

> Create a symbol table that holds the strict variables and the types they
> are locked into. The strict keyword pushes them onto that table, the var
> keyword pulls them off. When an operation that cares about type occurs
> check that table - if the var appears there than authenticate it.

And now every function and code piece that works with symbol tables
needs to be modified to account for the fact that there are two of them.
Every lookup is now two lookups, and no idea how $$var would even work
at all.

--
Stas Malyshev
smalyshev@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Andreas Hennings
Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax
January 25, 2018 06:20PM
I will not

On 22 January 2018 at 22:11, Stanislav Malyshev <[email protected]> wrote:
> Hi!
>
>> I want to see strict typing as an option, not a requirement.
>
> You seem to be under impression that this somehow makes things easier.
> It does not. To explain: let's say you design a strictly typed language,
> like Java. The compiler knows which variable is of which type at every
> point, and if it's not clear for some reason, it errors out. You can
> build a compiler on top of those assumptions.
> Now let's say you design a loosely typed language, like Javascript. The
> compiler knows variables have no types, only values have it, and builds
> on top of that (as in, it doesn't need to implement type tracking for
> variables).
> Now, you come in and say - let's make the compiler have *both*
> assumptions - that sometimes it's strict and sometimes it's not.
> Sometimes you need to track variable types and sometimes you don't.
> Sometimes you have type information and can rely on it, and sometimes
> you don't and have to type-juggle.
> Do you really think this just made things *easier*? To implement both
> Java and Javascript inside the same compiler, with radically different
> types of assumption? If you have desire to answer "yes", then a) please
> believe me it is not true b) please try to implement a couple of
> compilers and see how easy it is.

I do not doubt that it would be a lot of work, possibly so much that
it becomes unrealistic.

There are languages which have a number of strict types and then a
"variant" type.
https://en.wikipedia.org/wiki/Variant_type
https://msdn.microsoft.com/en-us/vba/language-reference-vba/articles/variant-data-type

In PHP, to allow a mix of strict statically typed variables and
dynamically typed variables, we could adopt such a model, where all
dynamically typed variables would have the type "variant".

The strict types would become the basic model, and the variant type
would be a special case within that model.

This does not make this any easier to implement, but it seems more
promising than seeing this as two parallel systems which have to be
maintained separately.


>
> Having two options is not even twice as harder as having one. It's much
> more. So "optional" part adds all work that needs to be done to support
> strict typing in PHP, and on top of that, you also have to add work that
> needs to be done to support cases where half of the code is typed and
> the other half is not. And this is not only code writing work - this is
> conceptual design work, testing work, documenting work, etc.
>
> Without even going to the merits of the proposal itself, it certainly
> looks to me like you are seriously underestimating what we're talking
> about, complexity-wise. I am not saying it's not possible at all - a lot
> of things are possible. It's just "it's merely an option" is exactly the
> wrong position to take.
>
>> Create a symbol table that holds the strict variables and the types they
>> are locked into. The strict keyword pushes them onto that table, the var
>> keyword pulls them off. When an operation that cares about type occurs
>> check that table - if the var appears there than authenticate it.
>
> And now every function and code piece that works with symbol tables
> needs to be modified to account for the fact that there are two of them.
> Every lookup is now two lookups, and no idea how $$var would even work
> at all.
>
> --
> Stas Malyshev
> smalyshev@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sorry, only registered users may post in this forum.

Click here to login