Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Christopher Reimer <christopher_reimer@icloud.com>
Newsgroups: comp.lang.python
Subject: Re: Creating a calculator
Date: Fri, 01 Jul 2016 06:19:00 -0700
Lines: 55
Message-ID: <mailman.157.1467379145.2358.python-list@python.org>
References: <a0ed0591-dcbb-4ad2-b69a-58feef50153a@googlegroups.com> <nl4t1n$qgp$2@dont-email.me> <lf5oa6hhn9x.fsf@ling.helsinki.fi> <0E77E5BC-E8CC-4951-B520-37BF2E596D3A@icloud.com> <mailman.156.1467375975.2358.python-list@python.org> <lf5poqxmsqc.fsf@ling.helsinki.fi> <81839B88-3F2B-4E28-9E59-F4B1AAAF058D@icloud.com>
Mime-Version: 1.0 (1.0)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
In-reply-to: <lf5poqxmsqc.fsf@ling.helsinki.fi>
Precedence: list
Xref: csiph.com comp.lang.python:110896

> On Jul 1, 2016, at 5:46 AM, Jussi Piitulainen <jussi.piitulainen@helsinki.=
fi> wrote:
>=20
> Christopher Reimer writes:
>=20
>> For my BASIC interpreter, each line of BASIC is broken this way into
>> tokens.
>>=20
>> line_number, keyword, *expression =3D line.split(' ', 2)
>>=20
>> For a line like 10 PRINT "HELLO, WORLD!", this works as expected.
>>=20
>> For a line like 20 END, which doesn't have a third element for
>> expression, an empty list is assigned.
>>=20
>> By using * to unpack the split line, my program no longer crashes and
>> no try/except block is needed to work around the crash. A later line
>> of code will test the expression, ignore if empty or run regex if
>> full.
>=20
> Yes.
>=20
> Consider line.split(None, 2) or line.split(maxsplit=3D2). You may still
> need to strip the third component, but at least it will *be* the third
> component even if the user happens to type extra spaces like this:
>=20
> 10   PRINT  "Hello, world."
>=20
> And you won't get a spurious third component if the user types this:
>=20
> 20 END  =20
>=20
> (There's trailing spaces.)

This is a BASIC interpreter. Any extra spaces for line_number or keyword wil=
l raise an incomprehensible syntax error, as the line number must convert to=
 an integer and the keyword much match the KEYWORDS list. As for trailing sp=
aces for expression, regex will keep them whole if enclosed in double quotes=
 or convert them to a list element. Depending on the keyword grammar, extra s=
paces are likely to be ignored.

A C interpreter would be more difficult as the same line of code could be wr=
itten several different ways and be valid.

FILE *source
FILE * source
FILE* source
FILE*source

The first line is how I normally see this statement written. The last line I=
 found in a 1991 book with a strange dialect of C that I've never seen befor=
e and doesn't always compile correctly without modification. Writing a C int=
erpreter is not on my to do list.=20

Chris R.=