Coercive Scalar Type Hints RFC

9 years ago by Anthony Ferrara — view source

unread

Adding in a thread that was started in private, but absolutely is
worth sharing with the group:

---------- Forwarded message ----------
From: Etienne Kneuss colder@php.net
Date: Sun, Feb 22, 2015 at 8:42 AM
Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
To: Zeev Suraski zeev@zend.com
Cc: Anthony Ferrara ircmaxell@gmail.com, Dmitry Stogov dmitry@zend.com

On Sun Feb 22 2015 at 14:23:58 Zeev Suraski zeev@zend.com wrote:

There have been several attempts:
for JS: http://users-cs.au.dk/simonhj/tajs2009.pdf
or similar techniques applied to PHP, quite outdated though:
https://github.com/colder/phantm

Looks like WebKit's type inference is doing some pretty good job at
analyzing code, although I'm not sure how much of it is static vs. dynamic.
My guess is that a lot of it is static:
twitter.com/kangax/status/558974257724940288

My guess would be that it's almost entirely dynamic, or probabilistic
(e.g. this nice recent work done at ETH: http://www.jsnice.org/).

I think you underestimate the difficulty of statically recovering
precise types from no-annotations without runtime witnesses ;) You
don't want webkit anlysing the JS for 10 minutes until it renders the
page. It is much more profitable to JIT these.

You are right that the lack of static information about types is (one of
the) a main issue. Recovering the types has typically a huge performance
cost, or is unreliable

We're not really talking about performance issue here, as static analysis is
a separate activity that is unrelated to runtime performance.

What I meant was: it is a performance issue for the static analyzer,
not PHP itself.

But seriously, time is getting wasted on this argument; it's actually a
no-brainer: more static information helps tools that rely on static
information. Yes. Absolutely. 100%.

There's still disagreement between us on whether the different behavior of
Strict STH constitutes additional static information or not, as it doesn't
give you any extra information on the value being fed to the function, and
it doesn't give you any extra information on what the function will receive.
It only gives you information about how the function would behave if it gets
a wrongly-typed value.

for forward analyses (which are the most common for these
applications): it gives you precious information from the beginning of
the function and forward. You can consider it similarly to a cast: You
don't necessarily know what the value coming in is, but you know which
type you are having from that point forward.
backward analyses could piggy-back the type constraints from the
functions (strict or no strict) and check that they are met when
constructing the value fed to the function.

Having worked several years on static analysis tools for languages
such as PHP, I can guarantee you that this information would help a
lot. However, the other dynamic feature of PHP would still make
analyses slow/unreliable/imprecise. Let's not imagine that this is the
only thing missing for PHP to be static-analysis-wonderland, far from
it.

But my the bottom line is exactly the bottom line you ended with, and what I
answered you on-list - how much weight should Static Analysis improvements
have on our decision to introduce new language features? My answer is not
that much, if they have downsides. Static Analyzers should be designed for
languages and not vice versa.

I fully agree in general that the flow should be this way. But it
remains a bonus if a certain feature, as a plus, would help external
tools. I believe it is worth mentionning..

Thanks,

Zeev

9 years ago by Pierre Joye — view source

unread

Can you all of you stop this madness with moving discussions off list?

It is detestable, against almost all openness and principles behind an oss
project like php. If we can't discuss anymore design, plans, ideas etc on
the list then we are doomed, for good.

Adding in a thread that was started in private, but absolutely is
worth sharing with the group:

---------- Forwarded message ----------
From: Etienne Kneuss colder@php.net
Date: Sun, Feb 22, 2015 at 8:42 AM
Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
To: Zeev Suraski zeev@zend.com
Cc: Anthony Ferrara ircmaxell@gmail.com, Dmitry Stogov dmitry@zend.com

On Sun Feb 22 2015 at 14:23:58 Zeev Suraski zeev@zend.com wrote:

There have been several attempts:
for JS: http://users-cs.au.dk/simonhj/tajs2009.pdf
or similar techniques applied to PHP, quite outdated though:
https://github.com/colder/phantm

Looks like WebKit's type inference is doing some pretty good job at
analyzing code, although I'm not sure how much of it is static vs.
dynamic.
My guess is that a lot of it is static:
twitter.com/kangax/status/558974257724940288

My guess would be that it's almost entirely dynamic, or probabilistic
(e.g. this nice recent work done at ETH: http://www.jsnice.org/).

I think you underestimate the difficulty of statically recovering
precise types from no-annotations without runtime witnesses ;) You
don't want webkit anlysing the JS for 10 minutes until it renders the
page. It is much more profitable to JIT these.

You are right that the lack of static information about types is (one
of
the) a main issue. Recovering the types has typically a huge
performance
cost, or is unreliable

We're not really talking about performance issue here, as static
analysis is
a separate activity that is unrelated to runtime performance.

What I meant was: it is a performance issue for the static analyzer,
not PHP itself.

But seriously, time is getting wasted on this argument; it's actually a
no-brainer: more static information helps tools that rely on static
information. Yes. Absolutely. 100%.

There's still disagreement between us on whether the different behavior
of
Strict STH constitutes additional static information or not, as it
doesn't
give you any extra information on the value being fed to the function,
and
it doesn't give you any extra information on what the function will
receive.
It only gives you information about how the function would behave if it
gets
a wrongly-typed value.

for forward analyses (which are the most common for these
applications): it gives you precious information from the beginning of
the function and forward. You can consider it similarly to a cast: You
don't necessarily know what the value coming in is, but you know which
type you are having from that point forward.

backward analyses could piggy-back the type constraints from the
functions (strict or no strict) and check that they are met when
constructing the value fed to the function.

Having worked several years on static analysis tools for languages
such as PHP, I can guarantee you that this information would help a
lot. However, the other dynamic feature of PHP would still make
analyses slow/unreliable/imprecise. Let's not imagine that this is the
only thing missing for PHP to be static-analysis-wonderland, far from
it.

But my the bottom line is exactly the bottom line you ended with, and
what I
answered you on-list - how much weight should Static Analysis
improvements
have on our decision to introduce new language features? My answer is
not
that much, if they have downsides. Static Analyzers should be designed
for
languages and not vice versa.

I fully agree in general that the flow should be this way. But it
remains a bonus if a certain feature, as a plus, would help external
tools. I believe it is worth mentionning..

Thanks,

Zeev

9 years ago by Rowan Collins — view source

unread

Can you all of you stop this madness with moving discussions off list?

It is detestable, against almost all openness and principles behind an
oss
project like php. If we can't discuss anymore design, plans, ideas etc
on
the list then we are doomed, for good.

I'm sorry, but I just don't agree. This list is extremely high traffic at the moment, and the idea that recording every word of every discussion is the be all and end all of an open project is nonsense. Just as the entire list doesn't need to hear every word you say to your rubber duck, it doesn't need to see every quickfire thought of a collaboration or personal debate. Saying "I was just chatting to X about..." isn't that far removed from "I was just thinking about..."

Now, that's not to say that people should disappear off into private discussion for weeks and emerge with a polished product; clearly, important points need to be brought to the list promptly, and extra views solicited. And if the intention of going off-list was to hide a discussion from other participants, that is wrong. But I see no evidence of either fault here.

It seems to me perfectly desirable for people to go away and hash a few things out over a whiteboard or a beer, virtual or otherwise, then present a full and prompt summary to the wider community. Done right, it actually gives a better chance for other participants to follow the discussion, because they don't have to devote hours to reading every word, but are instead alerted to salient points they might want to think about and respond to further.

Regards,

Rowan Collins
[IMSoP]

9 years ago by Zeev Suraski — view source

unread

-----Original Message-----
From: Rowan Collins [mailto:rowan.collins@gmail.com]
Sent: Tuesday, February 24, 2015 12:48 AM
To: Pierre Joye; Anthony Ferrara
Cc: PHP internals
Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC

On 22 February 2015 23:56:18 GMT, Pierre Joye pierre.php@gmail.com
wrote:

Can you all of you stop this madness with moving discussions off list?

It is detestable, against almost all openness and principles behind an
oss project like php. If we can't discuss anymore design, plans, ideas
etc on the list then we are doomed, for good.

I'm sorry, but I just don't agree. This list is extremely high traffic at
the
moment, and the idea that recording every word of every discussion is the
be
all and end all of an open project is nonsense. Just as the entire list
doesn't
need to hear every word you say to your rubber duck, it doesn't need to
see
every quickfire thought of a collaboration or personal debate. Saying "I
was
just chatting to X about..." isn't that far removed from "I was just
thinking
about..."

Now, that's not to say that people should disappear off into private
discussion for weeks and emerge with a polished product; clearly,
important
points need to be brought to the list promptly, and extra views solicited.
And
if the intention of going off-list was to hide a discussion from other
participants, that is wrong. But I see no evidence of either fault here.

It seems to me perfectly desirable for people to go away and hash a few
things out over a whiteboard or a beer, virtual or otherwise, then present
a
full and prompt summary to the wider community. Done right, it actually
gives a better chance for other participants to follow the discussion,
because they don't have to devote hours to reading every word, but are
instead alerted to salient points they might want to think about and
respond
to further.

I literally couldn't have put it better myself. Wholeheartedly agree.

Zeev

9 years ago by Pierre Joye — view source

unread

On 22 February 2015 23:56:18 GMT, Pierre Joye pierre.php@gmail.com
wrote:

Can you all of you stop this madness with moving discussions off list?

It is detestable, against almost all openness and principles behind an
oss
project like php. If we can't discuss anymore design, plans, ideas etc
on
the list then we are doomed, for good.

I'm sorry, but I just don't agree. This list is extremely high traffic at
the moment, and the idea that recording every word of every discussion is
the be all and end all of an open project is nonsense. Just as the entire
list doesn't need to hear every word you say to your rubber duck, it
doesn't need to see every quickfire thought of a collaboration or personal
debate. Saying "I was just chatting to X about..." isn't that far removed
from "I was just thinking about..."

Now, that's not to say that people should disappear off into private
discussion for weeks and emerge with a polished product; clearly, important
points need to be brought to the list promptly, and extra views solicited

What happened for phpng.

And my reply to this exact post makes clear what I refer to. It is not a
quick chat like we see everywhere, irc, conferences or UGs. This is about
an on going discussion going off list for no valid reason.

The same applies to private mails about open topics, rfc or patch to try to
get one to change her mind. This is not acceptable and will never be, to my
eyes at least.

Sorry for the noise, but it has to be said.

9 years ago by Stanislav Malyshev — view source

unread

Hi!

The same applies to private mails about open topics, rfc or patch to try to
get one to change her mind. This is not acceptable and will never be, to my
eyes at least.

I think it's completely OK to discuss whatever matters people like to
discuss anywhere, as long as this does not hurt the discussion on the
list (and so far it doesn't look like we're suffering from the lack of
discussion, judging by over 50 emails still waiting to be read in my
mailbox just from the recent round of typing discussion). I.e. saying
something like "we must accept this proposal because of reasons we
discussed on IRC" is not OK. But talking to people in private and
arguing and maybe getting them to change their mind (isn't it the
ultimate goal of discussion?) - there's nothing wrong with that. Of
course, if you have a good argument that could convince people, airing
it in public could be more effective since it could convince more
people, but I don't see why that would prohibit private conversations or
make them somehow "madness".

--
Stas Malyshev
smalyshev@gmail.com

9 years ago by Rowan Collins — view source

unread

Pierre Joye wrote on 24/02/2015 01:57:

On Feb 23, 2015 2:48 PM, "Rowan Collins" <rowan.collins@gmail.com
mailto:rowan.collins@gmail.com> wrote:

On 22 February 2015 23:56:18 GMT, Pierre Joye <pierre.php@gmail.com
mailto:pierre.php@gmail.com> wrote:

Can you all of you stop this madness with moving discussions off list?

It is detestable, against almost all openness and principles behind an
oss
project like php. If we can't discuss anymore design, plans, ideas etc
on
the list then we are doomed, for good.

I'm sorry, but I just don't agree. This list is extremely high
traffic at the moment, and the idea that recording every word of every
discussion is the be all and end all of an open project is nonsense.
Just as the entire list doesn't need to hear every word you say to
your rubber duck, it doesn't need to see every quickfire thought of a
collaboration or personal debate. Saying "I was just chatting to X
about..." isn't that far removed from "I was just thinking about..."

Now, that's not to say that people should disappear off into private
discussion for weeks and emerge with a polished product; clearly,
important points need to be brought to the list promptly, and extra
views solicited

What happened for phpng.

Yes, that is what I had in mind when writing that paragraph. To make
absolutely clear: I agree that that is a bad thing.

And my reply to this exact post makes clear what I refer to. It is not
a quick chat like we see everywhere, irc, conferences or UGs. This is
about an on going discussion going off list for no valid reason.

The thread you replied to contains no timestamps outside Sun 22 Feb, and
was forwarded back to the list that same day, so there is no evidence of
a long hidden discussion. It doesn't contain any evidence of trying to
reach a back room deal, or otherwise deliberately exclude others from
the discussion.

What it looks like to me is an attempt by someone to get a better
understanding of a particular detail without creating extra noise on the
list; as the conversation evolved, it became clear that it was useful to
the list, and Anthony forwarded it here. This all seems to be entirely
the right thing to do.

The same applies to private mails about open topics, rfc or patch to
try to get one to change her mind. This is not acceptable and will
never be, to my eyes at least.

I would like to repeat that I do agree there are lines that should not
be crossed, and guidelines that should be followed. But I do not see how
any such lines were crossed in this instance.

Regards,

Rowan Collins
[IMSoP]