In article ,
Gareth's Downstairs Computer  
wrote:

>However, it remains that my computing interest, resulting
>from my first real job 45 years ago, is to produce an
>interactive programming language (the interactivity
>of BASIC or FORTH) but that runs at the speed of compiled
>code and yet is fully reconstructable as the original source.

I'm not convinced this would be possible and I think a lot will depend
on the underlying architecture (although you've "fixed" that for now,
so it may be less of an issue).

One of many issues regarding speed, might be the efficiency of the current
compilers for e.g. C which can perform instruction re-ordering, register
re-use and so on - de-compiling that into something that resembled the
original source code may well be impossible - that is, if you're trying to
achieve the speed and efficiency of a modern compiler. If you take a more
linear/simplified approach then you might get something that can work.

FWIW: My experience of BASICs over the past 40 years is that most of
the interactive ones (but not all) tokenise the input, line at a time,
as you enter it. So the LIST command essentially "de-compiles" the
tokenised code. The tokenised code is effectively pseudo-code for some
"perfect" BASIC CPU (or not, in some cases).

Having written my own BASIC interpreter in recent years, I found that
this way was not always perfect - you lose things like indentation and
your own personal style of capitalisation (PRINT, Print, ?, GoTo and so on) and
you only need to look at something like AppleSoft BASIC for another example
where it tries to line statements up on the left, but when you miss out the LET
command it looks weird... You type in:

  100 REM Test
  110 A = 5
  120 FOR I = 1 to A

and you get

  LIST
  100  REM Test
  110 A = 5
  120  FOR I = 1 to A

and so on.

In my BASIC, I thought I'd be clever and store the binary form of numbers to
speed-up
run-time execution. That worked well until:

  100 a = 3.3

  LIST

  100 a = 3.300000001

(contrived example, but I'm sure most folks here know instantly what's
happening)

Then there's expression evaluation - In a fit of CompSci, I used Dijkstra's
Shunting Yard to turn expressions into an RPN stack when could then be executed
at run-time, so

  100 a = b + c * d

becomes

  c d * b + => a

how to de-compile that into the original? It's harder as the ordering
has now been changed.

but a lot will depend how you choose to evaluate expressions as to how
de-compilable they become.

I have looked at compiling my BASIC to native code - and there is more
or less a 1:1 relationship with a line of BASIC and a Line/Block of ASM
- it's no-where near efficient as C though (and 'compiling' BASIC into
C is just as easy and may actually result in faster code, but that's a
job for another day)

Another thing you might want to look at is the Gigatron computer. It's
a kit computer project, but part of it features code for a virtual CPU
which runs on-top of the (very) RISC 8-bit computer. The syntax is
somewhat eseoteric though, but I suspect it could be de-compilable.

This is a horizontal/or vertical line drawing function in their GCL
(Gigatron Control Language)

[def
{-
  DrawLine -- Draw line
-}
  Count i=   // Take value of Count, store in i
  [do if>0   // While Acc > 0
    Color Pos.   // Fetch Colour, store @ Pos: poke (pos, colour)
    Pos Step+ Pos=  // Add Step to pos, store in pos.
    i 1- i=   // i = i - 1
    loop]
  ret
] DrawLine=

"Acc" is the virtual machines accumulator - which is effectively the last
variabled used - it's sort of like a 1-deep Forth type stack.

More at https://gigatron.io/ I've no commercial interest in this other than
just having bought and built one.

Sounds like an interesting project to embark on though. I've written
many scripting type lanuages over the years and a full-on BASIC,
not sure I want to do another!

Cheers,

-Gordon

--- SoupGate-Win32 v1.05