search

EgonOlsen71 / basicv2

A Commodore (CBM) BASIC V2 interpreter/compiler written in Java
https://egonolsen71.github.io/basicv2/
The Unlicense
84 stars 15 forks source link

Support keyword abbreviations #67

Open EricCarrGH opened 1 month ago

EricCarrGH commented 1 month ago

Hello, great project! I'm interested in using this for future 10 Liner basic contests.

Would it be possible to have the CL compiler support abbreviations like the interpreter did as mentioned here: https://www.c64-wiki.com/wiki/BASIC_keyword_abbreviation

e.g.

12 poke 2042,13: poke 2043,13: poke 2044,13

can be shortened to effectively:

12pO2042,13:pO2043,13:pO2044,13

I could also add the code to add this functionality as a command line option, and submit a PR, if that is acceptable.

EgonOlsen71 commented 3 weeks ago

I'm not sure if I see the point...if you are compiling a PRG, the abbreviations have been converted to "long" commands anyway?

Do you want the ASCII-representation of the code support these abbreviations?

Marrin commented 3 weeks ago

On the original machine it's about entering more into a BASIC line than the 80 (or 88) character limitation of the screen editor would allow with unabbreviated commands.

The only reason I see here is to know that limit and not accidentally enter more commands on the PC that would be possible with the original screen editor.

EricCarrGH commented 3 weeks ago

The point is, admittedly, very narrowly useful as a convenience for coding competitions that allow abbreviations.

One could provide a minified ASCII representation of source to compile and know that it compiles "as-is" rather than type it onscreen, hope no mistypes are made, and capture that as "proof of X chars per line".

I understand this does not add any real world benefits (outside of Marrin's reason) to the cross compiler, so it's fine to close if nobody else sees the need.

EgonOlsen71 commented 2 weeks ago

The parser itself isn't prepared for alternative spellings of the same command. I could extend it to handle this, but looking at it briefly, I don't think that I want to...:-) It might be possible to add support for it as some kind of preprocessor instead. I'll look into it when I find the time.