Re: New Syntax -- with an implementation

Thomas Kofler (kofler@ubilab.ubs.ch)
Fri, 3 Jun 1994 17:25:25 GMT

Michael McLay (mclay@eeel.nist.gov) wrote:
: Thomas Kofler writes:
: t> there is no satisfactory solution to all
: t> the problems related to newlines and indentation
:
: What problems? Please answer this question before proposing a
: departure from the current syntax. The LANGUAGE has no problems with
: newlines and indentation. Some people may have problems when they use
: their old programming habits to write code in Python, but the LANGUAGE
: is not at fault here. The LANGUAGE is not ambiguous. Flaws do not
: exist in the syntax that cause sequences of Python statements being
: interpreted incorrectly. It appears that you just don't like the
: syntax.

Let us be concrete:

1) No, it is not a question of liking the syntax or not. I can live
with the syntax as it is. I can live with Donald's syntax, and with
other conceivable syntaces. I do not care as long as I am writing
"small" Python programs. In my opinion, Python can be used for more
than writing "small" programs.

2) I am embedding Python into our application framework ET++. The
latter is written in C++. The goal is to script ET++ applications using
Python. One particular kind of usage is to use Python for
spreadsheet-like applications. Note: Not one spreadsheet, but a series
of spreadsheet-like apps. The basic infrastructure, however, is more
general. Currently, we have a Tcl embedding. Tcl has its problems, and
I want to get rid of it. I would like to substitute Tcl for Python as a
general scripting device.

The binding between ET++ and Python has a layer in Python that allows
to provide a nice interface to the underlying engine. Some of the code
of this layer will be generated. I also want/need (whatever you
prefer) to use macro processors for that purpose.

BTW: I do not see macro processors as an old-fashioned tool for
constructing software. If anybody is interested in this question, we
can discuss that further.

I cannot use m4 (or even cpp) for that purpose. Well, I could
invest some time to devise a macro processor working for
the Python syntax. Work-around 1.

For code generation, the current syntax does not pose a real problem.
It is simply annoying to carry the current required indentation level
all around the computations.

3) To recover lost indentation, there are some work-arounds. Solving
that problem leads to solutions like #end and an appropriate script,
for instance. Work-around 2.

4) For entering Python code in, say, a spreadsheet-like application, I
can use some code written by Guido that reformats the entered text. So
far, so fine. Now, I have to provide a way to tell the user in a
user-friendly way where, say, a syntax error occured. This means that I
have to write code that allows me that (Note: Python has nothing like a
line-directive). I have to take care all the time that preprocessing
and postprocessing code takes all that into account. Work-around 3 and
4. (You might also think of offering a debugging facility: The problems
never end...)

Some people stated in other postings that the burden of the proof is
due to those who want a syntax change. In my eyes, there is not much
to prove. It is rather a question whether what people want to do, and
how they want to solve issues like those described above if they need
to. The issue is a "political" one: Sacrifice a nice feature (the
current syntax) and impose some migration costs versus a Python that
scales.

----------------------------------------------------------
Thomas Kofler |Email: kofler@ubilab.ubs.ch
Union Bank of Switzerland |Tel: +41-1-236 4567
Bahnhofstr. 45 |Fax: +41-1-236 4671
CH-8021 Zurich, Switzerland |
----------------------------------------------------------