3 ms·

This is what's coming next. I've so far been carried away building the environment around the tiny language, but it's time to start making the language usable -

by jmmv 4y ago

This is what's coming next. I've so far been carried away building the environment around the tiny language, but it's time to start making the language usable -- and user supplied functions are the very next work item to complete.

eatonphil 4y ago
Have you decided on the plan of attack? Switch to a VM or something more fun in the AST evaluator? :)
- jmmv 4y ago
  Not yet. I'm tempted to add custom functions first for which the AST evaluator should be sufficient. And anyway, even though not as retro, named functions are better than a mess of numbered GOSUBS... Which means that if I even get to GOTO/GOSUB, I may try to do it in a hacky way. Although, to be honest, in the spirit of making this a true "retro-computer", the idea of compiling the code into a custom bytecode is incredibly tempting. It'd be super fun to build, and also... that'd enable a DISASM command of some kind to dump arbitrary memory, as well as PEEK/POKE! Tons of work though.
  - eatonphil 4y ago
    > Tons of work though. You know your project better than I do but unless there's something I don't understand going on, it really shouldn't be that hard. You can also keep both backends around and just build a basic VM evaluator and start compiling simple expressions at a time to the VM version. I don't want to give you suggestions if you already know all that but also happy to chat if you are looking for a good plan. :D
    - jmmv 4y ago
      Ok ok, it's probably not thaaaat hard technically, but it's a fair amount of work :) I haven't looked into it at all yet. Once I start doing so, I will probably reach out to you. Need a few days off before taking this on though as publishing a new release is always exhausting.
  - int_19h 4y ago
    It would be interesting to make it an indirect threaded code interpreter targeting wasm. Should end up faster than typical bytecode.
    - jmmv 4y ago
      That’s a very interesting idea! But note that EndBASIC runs on the desktop just fine compiled to native code; no WASM involved. And it will not become an Electron app :P
ChicagoDave 4y ago
In the mature versions of BASIC, SUB was for routines that didn't return any value and FUNCTION was for returning a value. I'd 100% skip the line numbers and GOTO/GOSUB and build those two things. I grew up PDP BASIC and then VAX BASIC and the procedural aspect is what made it a great platform to write code. the line number/GOTO stuff is great for nostalgia, but a dead end for good coding practices.
- TedDoesntTalk 4y ago
  This is a great idea. I grew up with AppleBASIC, which had line numbers, but after decades coding with many other languages, there’s no reason to use line numbers. And if the purpose of this repl is to teach, then teaching line number programming in 2022 is pointless. Unfortunately it then requires an editor, otherwise how do you overwrite/change a line?
  - dragonwriter 4y ago
    To me the main use of line numbers is that they allow you to have a seemless combination of an immediate environment and a line-oriented program editor. With modern UI, there's pretty much no reason to do that, of course; with a retro style UI, there might be some marginal use. (Also, supporting line numbers and line-oriented GOTO/GOSUB means you can directly use any of the libraries or classic code in that style; unwinding GOSUB/RETURN into named subs is trivial enough if it is otherwise clean, but unwinding GOTO-heavy code without having a working starting point isn't pleasant.)
  - 7thaccount 4y ago
    Isn't saying "GOTO 40", where 40 is the line number a big deal with old-school BASIC? Something along those lines anyway?
- bhauer 4y ago
  Agreed. I'm not familiar with PDP or VAX Basic, but I did grow up on GFA Basic with its PROCEDURE and FUNCTION. Both could be called by just using their name without a GOSUB. PROCEDURE printfoo(bar%) PRINT "foo: " + bar% RETURN FUNCTION double(number%) RETURN number% * 2 ENDFUNC ' Prints "foo: 8" printfoo(double(4))

by jmmv 4y ago

eatonphil 4y ago

Have you decided on the plan of attack? Switch to a VM or something more fun in the AST evaluator? :)

jmmv 4y ago
Not yet. I'm tempted to add custom functions first for which the AST evaluator should be sufficient. And anyway, even though not as retro, named functions are better than a mess of numbered GOSUBS... Which means that if I even get to GOTO/GOSUB, I may try to do it in a hacky way. Although, to be honest, in the spirit of making this a true "retro-computer", the idea of compiling the code into a custom bytecode is incredibly tempting. It'd be super fun to build, and also... that'd enable a DISASM command of some kind to dump arbitrary memory, as well as PEEK/POKE! Tons of work though.
- eatonphil 4y ago
  > Tons of work though. You know your project better than I do but unless there's something I don't understand going on, it really shouldn't be that hard. You can also keep both backends around and just build a basic VM evaluator and start compiling simple expressions at a time to the VM version. I don't want to give you suggestions if you already know all that but also happy to chat if you are looking for a good plan. :D
  - jmmv 4y ago
    Ok ok, it's probably not thaaaat hard technically, but it's a fair amount of work :) I haven't looked into it at all yet. Once I start doing so, I will probably reach out to you. Need a few days off before taking this on though as publishing a new release is always exhausting.
- int_19h 4y ago
  It would be interesting to make it an indirect threaded code interpreter targeting wasm. Should end up faster than typical bytecode.
  - jmmv 4y ago
    That’s a very interesting idea! But note that EndBASIC runs on the desktop just fine compiled to native code; no WASM involved. And it will not become an Electron app :P

ChicagoDave 4y ago

In the mature versions of BASIC, SUB was for routines that didn't return any value and FUNCTION was for returning a value. I'd 100% skip the line numbers and GOTO/GOSUB and build those two things. I grew up PDP BASIC and then VAX BASIC and the procedural aspect is what made it a great platform to write code. the line number/GOTO stuff is great for nostalgia, but a dead end for good coding practices.

TedDoesntTalk 4y ago
This is a great idea. I grew up with AppleBASIC, which had line numbers, but after decades coding with many other languages, there’s no reason to use line numbers. And if the purpose of this repl is to teach, then teaching line number programming in 2022 is pointless. Unfortunately it then requires an editor, otherwise how do you overwrite/change a line?
- dragonwriter 4y ago
  To me the main use of line numbers is that they allow you to have a seemless combination of an immediate environment and a line-oriented program editor. With modern UI, there's pretty much no reason to do that, of course; with a retro style UI, there might be some marginal use. (Also, supporting line numbers and line-oriented GOTO/GOSUB means you can directly use any of the libraries or classic code in that style; unwinding GOSUB/RETURN into named subs is trivial enough if it is otherwise clean, but unwinding GOTO-heavy code without having a working starting point isn't pleasant.)
- 7thaccount 4y ago
  Isn't saying "GOTO 40", where 40 is the line number a big deal with old-school BASIC? Something along those lines anyway?
bhauer 4y ago
Agreed. I'm not familiar with PDP or VAX Basic, but I did grow up on GFA Basic with its PROCEDURE and FUNCTION. Both could be called by just using their name without a GOSUB. PROCEDURE printfoo(bar%) PRINT "foo: " + bar% RETURN FUNCTION double(number%) RETURN number% * 2 ENDFUNC ' Prints "foo: 8" printfoo(double(4))