Stephen J. Turnbull wrote:
Note that signal matrices will almost certainly be a completely different type from signals, so as far as the compiler is concerned there's no conflict between "@=" for signal injection and "@=" for signal matrix multiplication.
Except that if @= represents signal injection for individual signals, it could plausibly represent elementwise signal injection for matrices of signals, conflicting with in-place matrix multiplication of signal matrices. My solution to this would be not to use @ for matrix multiplication of signals at all, and represent it some other way. But it seems that Yanghao doesn't even want to compromise that far.
This means that draconian discipline (such as restriction to one compact and intuitive DSL!) is required or readability will be dramatically adversely impacted.
Perhaps the interpreter should be made so that it would only run code containing user-defined operators if it is appropriately signed. To obtain a signing key, a user would have to take a training course administered by the PSF, and pass written and practical tests showing that they are able to use user-defined operators responsibly.
Hard to say. First, you have the problems of precedence and associativity.
It seems that Scala does this based on the first character of the operator, e.g. all operators beginning with "+" have the same precedence and associativity as the built-in "+" operator. This neatly avoids the need for declaring new operators, but it could be restrictive. E.g. the proposed "<==" operator would get the same precedence and associativity as comparison operators, which might not be what you want. To make matters worse, if it were treated as a true Python-style comparison operator, then x <== a < b and c < d would be interpreted as (x <== a) and (a < b) and (c < d) which is definitely not what we want here! Of course, we could avoid this problem by choosing a different operator symbol. By the first-character rule, "::=" would have the same precedence as ":=", which would probably give what we want. However, we might want to have a special rule for assignment-like operators, such as if an operator ends with "=" and doesn't start with "<", ">" or "=" then it's treated like an in-place operator. -- Greg _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/AI727SJVXNP47DETV3Y36DUKO3RELEZU/ Code of Conduct: http://python.org/psf/codeofconduct/
