On 04/19/2015 07:38 AM, BartC wrote:
....
Perhaps you don't understand what I'm getting at.
Suppose there were just two syntaxes: C-like and Python-like (we'll put
aside for a minute the question of what format is used to store Python
source code).
Why shouldn't A configure his editor to display a Python program in
C-like syntax, and B configure their editor to use Python-like tabbed
syntax?
A can write code in the preferred syntax, and B can view/modify exactly
the same code in /their/ preferred syntax. What would be the problem?
(The actual stored representation of the program would be in one of
those two styles, or something else entirely; Lisp-like syntax for
example. It doesn't matter because no-one would care.
(I think much of the problem that most languages are intimately
associated with their specific syntax, so that people can't see past it
to what the code is actually saying. a=b, a:=b, b=>a, (setf a b),
whatever the syntax is, who cares? We just want to do an assignment!)
If you make enough simplifying assumptions, of course it's easy and natural.
Assume that a text editor is the only way you'll be viewing the source
code. You and your coworkers are willing to each use a prescribed text
editor, rather than your previous favorite one that doesn't happen to
support the customization you're suggesting here. You're not going to
use a version control system, nor diff programs. You're not going to
post your code in messages on the internet.
You're not going to display error messages showing source code, from a
running system. You're not going to use the interactive debugger.
You're not going to copy code from one place to another without copying
sufficient context to be able to reconstruct the funny syntax.
You're going to permit only one such variation, and it's just big enough
that it's always obvious which version of the code is being examined (by
programs or by humans) [1]
You're not going to use eval() [good]. You're not going to examine
source code that comes from 3rd party or the standard library.
The changes you want are all completely reversible, regardless of
interspersed comments, and when reversed, preserve spacing and
characters completely in the way that each user expects to see the code.
And they are reversible even if you only have a small fragment of the
code.
I implemented something analogous to such a system 40 years ago. But on
that system, nearly all of the restrictions above applied. There was no
clipboard, no version control, no internet. Programs had to fit in 64k.
Each line stood completely on its own, so context was not a problem. i
wrote the text editor, much of the interactive debugger, the listing
utility, the pretty printer, the cross reference program, etc. So they
were consistent. Further, we had a captive audience -- if they didn't
like it, they could buy the competitor's product, which had similar
constraints. Would I do things differently now? You bet I would. At
least if I could upgrade the memory addressability to a few megs.
For the purposes you've described so far, I'd suggest just writing two
translators, one a mirror image of the other. Invoke them automatically
on load and save in your personal editor And learn to live with both
syntaxes, because it will leak. And if it's really not reversible,
don't use them when you're editing somebody else's code. And even if it
is reversible, don't use them when you edit code you plan to post on the
internet.
[1] So for example a=b can not mean assignment in one version, and a
comparison in the other. Because then you'd need to either discover
that it's a line by itself, or within an if expression, or ... But you
could arrange two disjoint sets of symbols readily enough. In your
version, require either := or ==, and make = just plain illegal.
PS. I haven't examined the costs in tool development to support this.
Just whether it's practical. You can easily discount any one of these
constraints, but taken as a whole, they very much limit what you can do.
--
DaveA
--
https://mail.python.org/mailman/listinfo/python-list
