[ATARI BASIC] POK. abbreviation? Any purpose?

[Fabrizio Caruso]

Some Atari BASIC abbreviations are not shorter than the extended form.

What is the purpose of these abbreviations? Are they useless?

For example POK. for POKE.

[Rybags]

There's one set of coding that covers all - the requirement is sufficient unique characters before the full-stop.

 

The order of statements in the Rom affects which gets precedent.

REM is first, so . on it's own gives you REM.

 

The ordering in some cases gives precedence for rarely used statements over commonly used ones, which is a bit of an annoyance in some cases.

 

POINT is before POKE so P. gives POINT instead of POKE. You could program for 20 years and never use POINT but use POKE into the tens of thousands.

PL. nice and short for PLOT since it only needs the 2 unique character sequence instead of 3 for POKE.

 

The only other instance might be S. which puts SAVE in front of SOUND but you only need SO. for that so it's not real inconvenient.

[vitoco]

Abbreviations in BASIC are just a feature to save typing, but it is simply based on the statements list and the order of the statements in that list. When the parser/tokenizer finds a word ending with a point, it searches in the list for the first instruction that matches the previous letters and has at least another one.

 

As a result, there are some statements that cannot be abbreviated ("NEW"), some that can be abbreviated in many ways ("I.", "IN.", "INP." or "INPU." but not "INPUT.") and only one that could be completely abbreviated ("." for "REM").

 

In your example, "P." and "PO." are for "POINT", so at least you need "POK." to abbreviate "POKE".

 

So, is it useful to have "POK." that does not save typing? At least for me, my tenliners are clearer when I use a point when the address is a variable ("POK.R,A" instead of "POKER,A").

[Fabrizio Caruso]

So, POK. is a useless abbreviation. Right?

[Roydea6]

If I use basic abbreviations I get in the habit of always using the '.'. So if I type POKE or POK. then POK. is the habitually used form.

[dmsc]

Hi!

 

Some Atari BASIC abbreviations are not shorter than the extended form.

 

What is the purpose of these abbreviations? Are they useless?

 

For example POK. for POKE.

Also, in addition to the good advice from Rybags and Vitoco, I encourage you to try my BASIC parser, at https://github.com/dmsc/tbxl-parser, it let you write the code "expanded" and without line numbers, and converts it to a tokenized BAS or to a Atari compatible short listing, with the best abbreviations possible.

 

I recently added an option to disable interpreting extended TurboBasicXL code, to aid in writing Atari BASIC only programs.

[Nukey Shay]

You could reorder the command table so that the instructions that you use the most are listed earlier. Or rename all the commands to have 2 unique starting letters. Doing so, you can create lines impossibly long when listed using regular (unhacked) Atari Basic. Too many arguments on 1 line may cause the stack to overflow, however.

[Nukey Shay]

The ordering in some cases gives precedence for rarely used statements over commonly used ones, which is a bit of an annoyance in some cases.

 

That may have been intentional...due to the reason above.

[Rybags]

Maybe they were worried about giving POKE first priority since it can cause problems if not used properly.

[carlsson]

Regarding the order of tokens, out of curiously I looked up the Commodore/Microsoft BASIC tokens and cross referenced those to Atari BASIC. The tokens not obviously present in Atari BASIC are marked as n/a, though I didn't include the ones unique to Atari. For the statements, barely two are in the same order across the dialects. For the functions (the one I call Atari secondary tokens), they're individually swapped around but grouped similarly. I know that string handling on the Atari is different (better? worse?) but as this is not meant as a Rosetta stone how to convert programs, I didn't pay attention to that.

 

basic-tokens.xls

 

Eventually I might look up other 8-bit BASIC implementations and add those in columns too, just for the fun to determine if there was one order of statements and functions more common than the other (and yes, I would assume all Microsoft derived versions are fairly similar).

 

Note that this is NOT another "this is better than that" comparison, just a comparison of order of tokens. Please respect that.

[Rybags]

I'm not really aware of any other Basics than C=, Atari and that for BBC that allow such abbreviations. Maybe Amstrad?

Pretty sure also that Atari is the only Basic that retains ? for PRINT, others tend to convert it to the long form

[carlsson]

Hm, true. For BASIC versions that don't have abbreviations the order of tokens is not as important. While Locomotive BASIC on the Amstrad CPC doesn't seem to support abbreviations, most of the statements are ordered alphabetically so AFTER is $80 and ZONE is $DA.

 

While I think a number of oddball models are missing from the listing, here is a good document for me or someone else to start from to determine more BASICs to compare.

Edited March 22, 2019 by carlsson

[sanny]

So, POK. is a useless abbreviation. Right?

 

Yes, more or less.

 

I don't know the source code, but I guess that the parser looks for the first "." and then looks up the first matching word with the characters it's got so far (the chars preceeding the "."). With "POK." it'll find "POKE". So "POK." is not an 'intentional' abbrevation, but just a side effect from how the parser works.

[phaeron]

 

Yes, more or less.

 

I don't know the source code, but I guess that the parser looks for the first "." and then looks up the first matching word with the characters it's got so far (the chars preceeding the "."). With "POK." it'll find "POKE". So "POK." is not an 'intentional' abbrevation, but just a side effect from how the parser works.

 

Close -- this is done during the the search itself by accepting immediately if the dot is encountered. The matching code has to handle a partial match anyway because no space is necessary after a statement, e.g. POKEX,1 is parsed as POKE X,1. The keyword table is also stored in token order, so the abbreviations are implicit from the names and the token values. This means that reordering the table to change the abbreviation also breaks binary compatibility.

 

Later BASICs deviate from this somewhat due to difficulties this causes for ENDIF and ENDPROC, which otherwise would never work due to always being parsed as END first and the inability to place them earlier in the table. BASIC XL/XE and Turbo-Basic XL differ in how they solve this.