Path: ...!news.mixmin.net!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Rainer Weikusat <rweikusat@talktalk.net>
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Command Languages Versus Programming Languages
Date: Sun, 13 Oct 2024 21:25:51 +0100
Lines: 102
Message-ID: <878quryckw.fsf@doppelsaurus.mobileactivedefense.com>
References: <uu54la$3su5b$6@dont-email.me> <87edbtz43p.fsf@tudado.org>
	<0d2cnVzOmbD6f4z7nZ2dnZfqnPudnZ2d@brightview.co.uk>
	<uusur7$2hm6p$1@dont-email.me> <vdf096$2c9hb$8@dont-email.me>
	<87a5fdj7f2.fsf@doppelsaurus.mobileactivedefense.com>
	<ve83q2$33dfe$1@dont-email.me>
	<87wmighu4i.fsf@doppelsaurus.mobileactivedefense.com>
	<ve8s6d$3725r$1@dont-email.me>
	<87o73rj3sr.fsf@doppelsaurus.mobileactivedefense.com>
	<20241010120827.867@kylheku.com>
	<87frp3itsk.fsf@doppelsaurus.mobileactivedefense.com>
	<ve9mrh$3aiao$2@dont-email.me>
	<87jzee3ded.fsf@doppelsaurus.mobileactivedefense.com>
	<vebffc$3n6jv$1@dont-email.me> <vec3hi$3q4ms$2@dont-email.me>
	<vedcp9$3nu6$1@dont-email.me>
	<87h69hfnmz.fsf@doppelsaurus.mobileactivedefense.com>
	<slrnvgldkr.31hh.naddy@lorvorc.mips.inka.de>
Mime-Version: 1.0
Content-Type: text/plain
X-Trace: individual.net hMYE+zg0qeBFYg93XQbehA2Bdr+DuMfNW6kc8GXEsRGkuncHE=
Cancel-Lock: sha1:nN7knmjoEZRYwS3H5Rzm0WIKjSg= sha1:RNyZvvYtbhRUsTvgRoxlQ+Bh4J4= sha256:cztZrgm6TzekNIW6EFKIfwl/QF3dLAT9bbpvt0gCf2E=
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
Bytes: 6576

Christian Weisgerber <naddy@mips.inka.de> writes:
> On 2024-10-12, Rainer Weikusat <rweikusat@talktalk.net> wrote:
>> Indeed. As far as I know the term, an interpreter is something which
>> reads text from a file, parses it an checks it for syntax errors
>> and then executes the code as soon as enough of it has been gathered to
>> allow for execution of something, ie, a complete statement. This read,
>> check and parse, execute cycle is repeated until the program
>> terminates.
>
> I don't really want to participate in this discussion, but what
> you're saying there is that all those 1980s home computer BASIC
> interpreters, which read and tokenized a program before execution,
> were actually compilers.

If they contained something which compiled all of the source code prior
to execution in order to transform it some actually executable
intermediate representation whose execution didn't require future access
to the source code and thus, also didn't include checking the source
code for syntactical correctness, this something can be called a
compiler and the execution engine some sort of virtual machine which
could principally execute programs compiled from source code in any
programming language.

But judging from Wikipedia, Murkysoft Basic stored programs as linked
list of preprocessed lines and interpreted these, ie, doing string
lookups of keywords from the source code at run time in order to
determine what code to execute. Insofar I vaguely remember this from
Apple //c BASIC (has been a while) syntax errors would also be found at
runtime, ie, once execution reached the line with the error. This would
make it an interpreter.

In constrast to this, this somewhat amusing small Perl program:

while (<>) {
    while (length) {
        s/^(\w+)// and print(scalar reverse($1));
        s/^(\W+)// and print($1);
    }
}

[reads lines from stdin and prints them with each word reversed]

gets translated into an op tree whose textual representation (perl
-MO=Concise,-basic)  looks like 
this:

y  <@> leave[1 ref] vKP/REFC ->(end)
1     <0> enter v ->2
2     <;> nextstate(main 1 a.pl:1) v:{ ->3
x     <2> leaveloop vKP/2 ->y
3        <{> enterloop(next->r last->x redo->4) v ->s
-        <1> null vK/1 ->x
w           <|> and(other->4) vK/1 ->x
v              <1> defined sK/1 ->w
-                 <1> null sK/2 ->v
-                    <1> ex-rv2sv sKRM*/1 ->t
s                       <#> gvsv[*_] s ->t
u                    <1> readline[t2] sKS/1 ->v
t                       <#> gv[*ARGV] s ->u
-              <@> lineseq vKP ->-
4                 <;> nextstate(main 3 a.pl:2) v:{ ->5
q                 <2> leaveloop vKP/2 ->r
5                    <{> enterloop(next->m last->q redo->6) v ->n
-                    <1> null vK/1 ->q
p                       <|> and(other->6) vK/1 ->q
o                          <1> length[t4] sK/BOOL,1 ->p
-                             <1> ex-rv2sv sK/1 ->o
n                                <#> gvsv[*_] s ->o
-                          <@> lineseq vKP ->-
6                             <;> nextstate(main 5 a.pl:3) v:{ ->7
-                             <1> null vK/1 ->f
9                                <|> and(other->a) vK/1 ->f
8                                   </> subst(/"^(\\w+)"/) sK/BOOL ->9
7                                      <$> const[PV ""] s ->8
e                                   <@> print vK ->f
a                                      <0> pushmark s ->b
-                                      <1> scalar sK/1 ->e
d                                         <@> reverse[t6] sK/1 ->e
b                                            <0> pushmark s ->c
-                                            <1> ex-rv2sv sK/1 ->d
c                                               <#> gvsv[*1] s ->d
f                             <;> nextstate(main 5 a.pl:4) v:{ ->g
-                             <1> null vK/1 ->m
i                                <|> and(other->j) vK/1 ->m
h                                   </> subst(/"^(\\W+)"/) sK/BOOL ->i
g                                      <$> const[PV ""] s ->h
l                                   <@> print vK ->m
j                                      <0> pushmark s ->k
-                                      <1> ex-rv2sv sK/1 ->l
k                                         <#> gvsv[*1] s ->l
m                             <0> unstack v ->n
r                 <0> unstack v ->s

Each line represents a node on this tree and the names refer to builtin
'ops'. In the actual tree, they're pointers to C functions and execution
happens as preorder traversal of this tree and invoking the op functions
from the leaves to root to produce the arguments necessary for invoking
op functions residing at a higher level in this tree.

Modules for writing this internal representation to a file and loading
it back from there and even for translating it into C exist. They're
just not part of the core distribution anymore.