On Tue, Jun 4, 2019 at 10:11 AM Stephen J. Turnbull
email@example.com wrote: >
Yanghao Hua writes:
On Fri, May 31, 2019 at 3:48 PM Rhodri James firstname.lastname@example.org wrote:
It really doesn't. If the end user is going to implement the logic of this anyway, implementing signal linkage as a method call or class all of its own is not a significant extra burden.
There are very constructive discussions in terms how this could be handled and which turns out not really elegant. Your justification could be used to reject features like descriptors, decorators, meta classes,
And has been so used. The question is always "does the use case justify increasing complexity for a couple hundred maintainers and a few hundred million readers?"
That's a valid question. and let's address the items one by one.
Complexity & hundreds of maintainers. It is nothing complex and it is almost a direct copy of the implementation of @= operator, all logic behind <== are the same of @=. With some refactoring @= and <== implementation might even be able to share 99% of the code, so I think it is not complex at all, and there is not much additional overhead for maintenance.
hundred million readers. I can only guess you mean python developers here? Just like @=, <== is not enforced on anyone, but can be used by anyone who wants to. As it is today I can choose to give @= a complete different meaning if I chose to, other uses may chose (and most importantly, being able to) give <== the meaning they see fit when they want to preserve all number operators and matrix operators. It is merely a new possibility for end user with very limited effort.
I am glad that this question comes, which means at least the python community is no longer denying there is a problem (a small one by the way), and it can be improved in terms of allowing end user to write more readable code in this specific domain.
As far as I can tell, here we have (a) one person strongly in favor of adding just one new operator token, who justifies it based on personal preference over style of expression for one specific DSL, and (b) a few supporting a generic facility for adding new operators.
The former (a) is obviously insufficient, considering past practice in Python. One person can probably use MacroPy or a preprocessor. If the DSL becomes popular, as with "@", first applied for matrix multiplication, it might become justification for a new operator token, but the popularity has to come before more than a tiny fraction of committers (if any) will sign on. The other possibility would be to present a complete implementation of a toy language using existing Python facilities, and then show the alternative with the new operator. Preferably at the same time showing how the preprocessor/ MacroPy strategy falls short.
The latter (b) has been discussed and rejected a number of times, on the grounds that unfamiliar symbols are harder to read than functions, and that Python is not in the DSL-producing industry. Some features are clearly more descriptive than procedural in nature (eg, comprehensions), but they are justified on the ground that they increase readability when expressing algorithms.
Please let's be constructive and be specific, this kind of conclusion without any reasoning behind it
In Python practice, the conclusion of "reject" needs no reasoning, unfortunately. Python adds new features in response to a demonstrated need that overcomes a general conservatism, a conservatism that extends far past backward compatibility to a certain amount of forward compatibility as well.
So you should take your own advice. We have seen you express your preference for a new operator numerous times, but there is no visible logic behind it. Show us the best you can do with actual working hardware description classes (say a NAND gate and the composition into a half-adder, or perhaps you need more to demonstrate the relevant difficulties -- I know little about hardware, quite a bit about how the Python enhancement process works). Then show us the syntax you want to use to express the same thing.
I will come up with a complete working implementation of HDL-in-Python with <== to show the differences, how it enhances readability, and how it compares without it.
It's possible that people with wizard-level Python skills can find a way around the difficulties you describe with descriptors and other features that have been suggested in this thread. If not, your case for a new operator token would be much stronger (though still insufficient IMO -- fortunately for you, few committers listen to me about language features ;-).
I'd like to take any recommendations that can achieve the same logical integrity and readability.
Without such a test, or a few tens of thousands of hardware designers lobbying for a decade or so (which is what happened with the numerical community, although this time around I bet Python will be substantially more forward-leaning, say 5 years and 5000 hardware designers), it's your taste against Python's conservatism. I'll take long odds that conservatism wins.
Thanks for the advice, I will (I was) working on it and will show you the ideas behind it. I knew it is going to be difficult and probably I have failed to use some cool features and I think a completely working system will help to demonstrate the ideas better. Stay tuned.