Commander X16

This thing is going to need a "highly" productive and workalike interpreted scripting language, as handicapped as it might be in many areas. The spirit can still be captured. I suggest the names,

BERL

or

BAWK

. Start a new thread if you want to discuss silly-talk like,

BYTHON

That said it'd be nice to be able to do some inspired one-liners, like:

LOAD"*",8 && run

Might atleast make for a good April 1st joke this year.

If xForth ever gets up to a beta level, that'd be a good basis for developing an awk-like userland scripting language. Though if I am doing it, I doubt that I would have a full general regular expression parser.

c64c46c wrote: ↑Sat Mar 18, 2023 9:30 pm This thing is going to need a "highly" productive and workalike interpreted scripting language, as handicapped as it might be in many areas.

Perhaps you could elaborate why you feel the need for this feature request? In the 8 bit 80's my teenage brain never thought of a scripting language, but I've learn't so much since those days 40 years ago. I feel we all have.

In your example, the typical case for loading a program is to run it, or at least for most end users. Why not consider changing what load does? The programmer/student may want to load to code or list it; perhaps a different command would be needed.

I realize this example is a simple one liner and doesn't reflect all the potential a scripting language can do. It also breaks with the past and one of the project goals its to create a machine with links to the magic of the early home computer days.

Are you talking about the sort of scripting that calls other programs, or the type of scripting that does everything internal to the script interpreter? Because the latter is already present, in BASIC.

The former requires someone to basically build an entire pipe system so that data can be passed from one tool to another in a script.

Does this mean you are volunteering?

kelli217 wrote: ↑Tue Mar 21, 2023 12:51 am Are you talking about the sort of scripting that calls other programs, or the type of scripting that does everything internal to the script interpreter? Because the latter is already present, in BASIC.

The former requires someone to basically build an entire pipe system so that data can be passed from one tool to another in a script.

Another way for the first to work within BASIC would be to have a system that works with Basic programs of, say, 8KB or less, data included, which installs a FN to call Basic programs where the FN packs the calling BASIC program, including the next line to be executed, into a designated HighRAM Bank, calls the Basic language being executed, and then on return restarts the calling Basic program from the next line to execute.

In other words, flip the normal "sub-program" call where instead of the calling program being a normal basic program which is chaining to a subprogram, the called program is a normal basic program, and the calling program is a special program which uses a special facility (loading and installing the machine language routines that make it work would be the first few lines of the BASIC program.

Then a pipe system is not hard ... before the Basic calling routine starts a BASIC program, it looks for an INPUT.SEQ file. If it doesn't find it, it looks for an OUTPUT.SEQ file and renames it to INPUT.SEQ. Then the called BASIC program just works with INPUT.SEQ and creates an OUTPUT.SEQ file from it if it has output. Then a utility menu program can be loaded by the "scripting Basic" program that selects a file and copies it to OUTPUT.SEQ.

If the scripting Basic program leaves breadcrumbs which HighRAM segment it is using to save itself while a Basic subprogram is running, then the scripting Basic programs can nest.

Interesting discussion...

Having been a C-shell/awk programmer in the past fusing disparate legacy data into custom-/purpose- built products, I feel like we are talking pineapples and bananas here, as the reason why Unix shell scripting was "revolutionary" was/is largely based upon scripts leveraging IO "channels" with magnetic media storage on a Unix cluster as "unlimited 'RAM'."

Anyone who has -- or knows of someone who has -- crashed a Unix cluster can appreciate the benefit of more disciplined programming vis-à-vis "real" RAM!

I look forward to somebody providing & explaining a reasonable use case. I don't foresee my (future) X16 using a UNIX cluster or shell scripting. Maybe I don't get what limitations of NOT having this feature means.

I'm not against having a scripting feature on the X16, it just isn't part of my "userland" at the moment.

I am right there with you, Edmond!

Edmond D wrote: ↑Wed Mar 22, 2023 2:23 am I look forward to somebody providing & explaining a reasonable use case. I don't foresee my (future) X16 using a UNIX cluster or shell scripting. Maybe I don't get what limitations of NOT having this feature means.

I'm not against having a scripting feature on the X16, it just isn't part of my "userland" at the moment.

Most of the things that would come to my mind would be doing things when doing hosted development for the X16 on the X16 itself. There are a number of features of the Windows text editor I use which would be easier to support with a script in a scripting language than to add to the existing X16 text editor.

Hence something like AWK, which is kind of a jack of all trades, rather than all of the different specialized tools in the Unix scripting toolbox.