[Python-ideas] Operator as first class citizens -- like in scala -- or yet another new operator?

[Yanghao Hua]

On Sun, May 26, 2019 at 8:00 PM David Mertz <mertz at gnosis.cx> wrote:
>
> On Sun, May 26, 2019, 1:12 PM Barry Scott <barry at barrys-emacs.org> wrote:
>>
>> You said this: "Well, depends on how we define narrow ... you are writing probablythis email on a HDL designed machine ... and the entire world is powered by HDL designed silicons. that is not small for me at all."
>>
>> Which I take to mean that because there are billions of chips in the world there are billions of python users. And the change you want is justified by the billions of python users.
>
>
> I think the analogy is more like saying there are billions of Verilog users. Chips designed using this software are probably more numerous than are human beings, and nearly all humans use one or more such chips. This seems like a poor line of reasoning though. There are really only maybe tens of thousands of people in the world who use Verilog, and that is a nice target.

Thank you. It is definitely more than tens of thousands. I count only
the 20 big names and it is already at least tens of thousands. All in
all it should be a few millions. We should argue really from technical
point of view, in the spirit of python, if this is worth or not rather
than saying HDL is just too small a problem to address.

> Pursuing the same indirect reasoning, we could also claim there are billions of users of PSS/E, something I had not heard of until a web search a few minutes ago. Apparently this is software used in design of electrical distribution systems, required to make all of those ICs operate at all. Or software used for building the construction equipment needed to construct the power lines and factories where chips are made. Or...

You know, Python and C are very close friends and operates almost like
natively together and you have things like Cython to ease the creation
of C-Python interface. If we look at the problem of building any
complicated piece of hardware, it almost certainly done in this way:
(1) C algo model -> (2) Virtual Prototype in SystemC (qemu-like
software model but with proper partitioning of sw/hw, hw is still kind
of a C model) -> (3) Verilog RTL model (Yes, RTL is actually just a
model too, which is easier to be translated to actual hardware
implementation). At each of the levels, it is a end-to-end complete
system, and yet in each level, there are a lot of things duplicated,
re-developed and eventually extremely difficult to have consistency.
The big picture I want to achieve is to replace those (1)(2)(3) with
Python + C  -> Python + C -> Python + C. Where the interface between
each layer can be easily unified through adapters and 99% of the
knowledge only need to be developed once (if it is developed in C
there will be a python interface).

> In any case, as I said, modifying the whole Python language to allow use of exactly the same symbols as Verilog users, seems foolish to me.

Agree, that would be foolish. I would just ask for any way that
overloads assign but not messing up existing operators (think of HDL
signals as integers).

> That said, '<=' is already perfectly well available for non-blocking assignment. '=' cannot be overriden, but it occurs to me that a custom class could perfectly well use '==' for blocking assignment just by customizing a class. Yes, that would require 'foo.eq(bar)' for the old meaning of equality (or something similar), but it seems like assignment is more common than equality checks in Verilog.

Not really, HDLs uses <= as less or equal than, as well as the
equality check VERY VERY often. The sad thing is when I went through
the entire python supported operators they can all be used with
signals ... including the matrix operator @/@=.