Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #135 > unrolled thread

Applesoft syntax

Back to article view | Back to comp.sys.apple2.programmer

Contents

  Applesoft syntax Deckard <boutillon@free.fr> - 2012-02-05 14:58 -0800
    Re: Applesoft syntax magnusfalkirk <dean.phares@gmail.com> - 2012-02-05 15:52 -0800
      Re: Applesoft syntax Deckard <boutillon@free.fr> - 2012-02-06 16:01 -0800
    Re: Applesoft syntax BLuRry <brendan.robert@gmail.com> - 2012-02-05 22:02 -0800
      Re: Applesoft syntax Joshua Bell <inexorabletash@gmail.com> - 2012-02-06 00:06 -0800
        Re: Applesoft syntax Deckard <boutillon@free.fr> - 2012-02-06 15:41 -0800
          Re: Applesoft syntax Joshua Bell <inexorabletash@gmail.com> - 2012-02-06 21:31 -0800
    Re: Applesoft syntax "Michael J. Mahon" <mjmahon@aol.com> - 2012-02-08 11:28 -0800
      Re: Applesoft syntax Antoine Vignau <antoine.vignau@laposte.net> - 2012-02-08 12:07 -0800
        Re: Applesoft syntax David Schmidt <schmidtd@my-deja.com> - 2012-02-08 15:30 -0500
          Re: Applesoft syntax Jerry <awanderin@yahoo.ca> - 2012-02-08 21:19 -0700
      Re: Applesoft syntax Deckard <boutillon@free.fr> - 2012-02-08 13:40 -0800
    Re: Applesoft syntax "Anton Treuenfels" <teamtempest@yahoo.com> - 2012-02-08 19:43 -0600
      Re: Applesoft syntax BLuRry <brendan.robert@gmail.com> - 2012-02-08 22:49 -0800
        Re: Applesoft syntax "Michael J. Mahon" <mjmahon@aol.com> - 2012-02-09 00:41 -0800
          Re: Applesoft syntax Joshua Bell <inexorabletash@gmail.com> - 2012-02-09 20:56 -0800
            Re: Applesoft syntax Jerry <awanderin@yahoo.ca> - 2012-02-10 01:43 -0700
      Re: Applesoft syntax Deckard <boutillon@free.fr> - 2012-02-09 14:08 -0800
        Re: Applesoft syntax Vladimir Ivanov <vladitx@XXXyahooXXX.com> - 2012-02-10 12:04 +0200
          Re: Applesoft syntax Deckard <boutillon@free.fr> - 2012-02-11 15:16 -0800
            Re: Applesoft syntax Vladimir Ivanov <vladitx@XXXyahooXXX.com> - 2012-02-12 11:57 +0200
        Re: Applesoft syntax Deckard <boutillon@free.fr> - 2012-02-11 14:55 -0800
    Re: Applesoft syntax finksterj <finkjsc@yahoo.com> - 2012-02-11 16:58 -0800
      Re: Applesoft syntax Deckard <boutillon@free.fr> - 2012-02-12 01:02 -0800

Page 1 of 2  [1] 2  Next page →

#135 — Applesoft syntax

How do you check the syntax of a big Applesoft basic program without
running it?
Is there vintage or modern tools for that?

JM

[toc] | [next] | [standalone]

#136

On Feb 5, 4:58 pm, Deckard <boutil...@free.fr> wrote:
> How do you check the syntax of a big Applesoft basic program without
> running it?
> Is there vintage or modern tools for that?
>
> JM

Not sure if it will do what you want or not but I'd suggest trying
Beagle Bros Program Writer on whatever Apple II you're using.

Dean

[toc] | [prev] | [next] | [standalone]

#141

> Not sure if it will do what you want or not but I'd suggest trying
> Beagle Bros Program Writer on whatever Apple II you're using.

Program Writer is a powerful applesoft basic program editor with a lot
of features (macros, renumber, insert control characters, copy/paste,
40/80c switch, list all the variables in the program, search&remplace,
mouse support, insert/delete/find/split line into 2 lines/combine
lines/convert to upper or lower case, ...)

But like a word processor, it doesn't check the syntax of the basic
program.

And no luck, my program has large lines which are not displayed:
According to the manual, "a program may contain lines that are too
long to edit. Normally lines this long can only be obtained by using a
program that compacts a BASIC program to its smallest size by
concatenating lines. A line that is too long to edit from the keyboard
is shown by the editor as a single asterisk (*) following the line
number. Most programmers will never see this".
My program was compacted and I've a lot of lines with asterisks  :-(

JM

[toc] | [prev] | [next] | [standalone]

#138

I would think that you should be able to enter in the program, then use a basic disassembly (or listing) to confirm that the disassembled version matches up.  This won't catch everything, but it could at least call out any tokenization issues.

A long while back I started implementing an applesoft grammar parser, with the hope of going beyond that.  Though I didn't implement a tokenizer, I did write a disassembler that can take a binary basic file and render it back to ascii text.  The code for this is buried in the jace.appelesoft package of the JACE codebase -- and it's what I used to disassemble lemonade stand and convert everything to lowercase.  For retokenization, I'm currently going the slow route: Copy all to clipboard and then from the basic prompt press ctrl+ins to paste it in line by line for applesoft interpretation.  Not exactly ideal, but a start...

-B

[toc] | [prev] | [next] | [standalone]

#139

Running the source through a BASIC compiler would check that the
syntax is correct, since that would do a full token lex/grammar parse
of the program.

My "Applesoft in JavaScript" page http://calormen.com/applesoft does
this - it compiles each statement into JavaScript before the program
starts, so it will catch syntax errors even in lines that will never
execute. (Which could be considered a bug!) So you could copy/paste
your source into that page and try running it.

You may hit bugs in my code, of course, or limits of the execution
environment since it is not a full emulator.

[toc] | [prev] | [next] | [standalone]

#140

A great tool Joshua. Thank you.

Unfortunately, my program has a lot of commands which refer to
assembly routines (poke, peek, call) and the compilation stops after
the first "call" with message "Unsupported POKE location".
And as a lot of applesoft basic program, the program also has extended
commands which begin with ampersand and produce the message
"ParseError: Native interop statement not supported: & in line xyz"

I've notice a strange thing:

when I try to run the following pgm, a message is displayed with a bad
number line: ParseError: Native interop statement not supported: & in
line 30

10 print "A"
20 &
30 print "B"

On an Apple IIe computer, this program works.

JM

[toc] | [prev] | [next] | [standalone]

#143

On Feb 6, 3:41 pm, Deckard <boutil...@free.fr> wrote:
> A great tool Joshua. Thank you.
>
> Unfortunately, my program has a lot of commands which refer to
> assembly routines (poke, peek, call) and the compilation stops after
> the first "call" with message "Unsupported POKE location".

Actually, if it makes it that far, it's done compiling and trying to
execute. Try this:

10 PRINT "Hello World!"
20 END
30 POKE 0,0

This is syntactically correct, but 0 is not a supported POKE location.
It will run without reporting any errors, unless you remove line 20.

So, as far as my page is concerned, your code is syntactically
correct.

> And as a lot of applesoft basic program, the program also has extended
> commands which begin with ampersand and produce the message
> "ParseError: Native interop statement not supported: & in line xyz"

Yeah, my page is not an emulator so it's not going to be able to
validate that the runtime POKE, CALL or &--routines are valid. But
then again, there's provably no way to do that for arbitrary code
without running it, so I don't feel too bad. :)

(Back in the day, I don't think I ever used & routines. Possibly, if I
had, I never would have put that page together.)

> I've notice a strange thing:
>
> when I try to run the following pgm, a message is displayed with a bad
> number line: ParseError: Native interop statement not supported: & in
> line 30
>
> 10 print "A"
> 20 &
> 30 print "B"

Thanks, it should be reporting the parse error in line 20, of course.
I see the bug in the code (token lookahead is conflicting with the
line reporting), and I'll try to fix it soonish.

> On an Apple IIe computer, this program works.

My page flags unsupported commands (&, WAIT, HIMEM, etc) as errors at
parse time rather than runtime. It could arguably do it at runtime for
WAIT, HIMEM and so on, but IIRC I don't believe I could do so for & in
the non-trivial case since the parsing of tokens after the & is under
the control of the assembly routine and anything up the next line
number (or beyond, technically) could have a nonstandard meaning. That
said, I prefer the early errors for my use cases, so I'm not planning
on changing it. There are plenty of true emulators out there.

(I'm very much looking forward to BLuRry giving JavaScript and WebGL a
try. JSACE, anyone?)

[toc] | [prev] | [next] | [standalone]

#150

Deckard wrote:
> How do you check the syntax of a big Applesoft basic program without
> running it?
> Is there vintage or modern tools for that?

I'm curious--why would you want to use something other than
Applesoft itself to check a program?

I've always thought of syntax checking as a (very) preliminary
step to actual debugging/testing, which will result in Applesoft
doing a complete syntax check, assuming good test coverage.

-michael

NadaNet 3.1 for Apple II parallel computing!
Home page:  http://home.comcast.net/~mjmahon/

"The wastebasket is our most important design
tool--and it's seriously underused."

[toc] | [prev] | [next] | [standalone]

#151

Can't LIST and one's eyes be the perfect debugging tool for Applesoft
programs?
Antoine

[toc] | [prev] | [next] | [standalone]

#152

On 2/8/2012 3:07 PM, Antoine Vignau wrote:
> Can't LIST and one's eyes be the perfect debugging tool for Applesoft
> programs?

Yes, of course.  CiderPress and AppleCommander have Applesoft listers - 
if it comes out correctly (i.e. no strange nonsense "code" in the middle 
of a line because of strange tokens) then the code is demonstrably 
syntactically correct.

I suspect Deckard wanted to know about semantic correctness, though.  I 
seem to remember a static analyzer out there that considered dangling 
line references and other low-hanging fruit.  A line renumberer would 
have the kind of framework in place to check for some referential 
correctness.

[toc] | [prev] | [next] | [standalone]

#155

David Schmidt <schmidtd@my-deja.com> writes:

> On 2/8/2012 3:07 PM, Antoine Vignau wrote:
>> Can't LIST and one's eyes be the perfect debugging tool for Applesoft
>> programs?
>
> Yes, of course.  CiderPress and AppleCommander have Applesoft listers
> - 
> if it comes out correctly (i.e. no strange nonsense "code" in the
> middle of a line because of strange tokens) then the code is
> demonstrably syntactically correct.
>
> I suspect Deckard wanted to know about semantic correctness, though.
> I seem to remember a static analyzer out there that considered
> dangling line references and other low-hanging fruit.  A line
> renumberer would have the kind of framework in place to check for some
> referential correctness.

There were some Nibble programs from ~1982 that did some stuff like
this: Line Cruncher and Variable cruncher by Alan & Valerie Floeter,
IIRC.  I don't think they really checked semantic correctness, but they
might have been able to spot dangling GOTOs.

The PDFs of the magazines are for sale from the original publisher, but
he has disk images of many of his programs available free on his site:
http://www.nibblemagazine.com.



-- 
--
Jerry    awanderin at yahoo dot ca

[toc] | [prev] | [next] | [standalone]

#153

On 8 fév, 20:28, "Michael J. Mahon" <mjma...@aol.com> wrote:
> I'm curious--why would you want to use something other than
> Applesoft itself to check a program?

The full story:

More than 20 years ago, I wrote a rpg game with a friend.
I've resurrected it and I'm playing the game to take snapshots.

The "conflict" program is written in basic with 2 kind of & routines
(games functions and I/O access with a patched RDOS).
And this program is ... a nightmare (spaghetti code).
With "conflicts", there are a lot of combinations (various monsters
reactions, user's actions, and a lot of other parameters). So it's
hard to test all the cases.

I had a crash last week:
http://boutillon.free.fr/Forum/m2/m2_crash_conflict_p01.png
A ":" was missing in a line 20710:
http://boutillon.free.fr/Forum/m2/m2_crash_conflict_p02.png

And I'd like to know is there are other similar bugs or bad applesoft
syntax sentences which have not been tested.
I don't think I can run every line of code when I'm playing the game.
So I'm looking for a way to have a first check.

If Antoine has a hawk's eye, the program is here (extracted with
CiderPress):
http://boutillon.free.fr/Forum/m2/Conflict.txt
The packed version which is used by the game is here:
http://boutillon.free.fr/Forum/m2/Conflict_packed.txt

And a dsk with both:
http://boutillon.free.fr/Forum/m2/Conflict_dos3_3.dsk

I'm going to test Blurry's disassembler with the 2 "raw" applesoft BAS
files which are here:
http://boutillon.free.fr/Forum/m2/Conflict.BAS
http://boutillon.free.fr/Forum/m2/Conflict_packed.BAS
but as Brendan said, it's a start.
I first have to remove the static hard coded filename (/home/brobert/
Documents/Personal/a2gameserver/lib/data/games/LEMONADE#fc0801) and
look what is done when & is met.
(Thanks Brandan for your java classes.)

JM

[toc] | [prev] | [next] | [standalone]

#154

"Deckard" <boutillon@free.fr> wrote in message 
news:89aca5f9-7923-41cf-9331-e6f7ae9230c6@k10g2000yqk.googlegroups.com...
> How do you check the syntax of a big Applesoft basic program without
> running it?
> Is there vintage or modern tools for that?
>
> JM

You might find "Applesoft Programming Helper" by Grant Stevens in "Applesoft 
Power Tools" (Nibble Publications, 1987) to be what you're looking for. It's 
provided as an assembly language listing. It performs a static syntax check 
of an Applesoft program in memory.

To check your running program you might find "Microscope" by Ong Tee Yong in 
the same book to be helpful. It's also provided as an assembly language 
listing. Single step, set breakpoints, etc.

MicroSPARC is pretty huffy about letting anyone other than the purchaser of 
the book use anything in it, though. Says so at the front of the book. They 
don't even want to let it be reproduced by any means "...now known or 
hereafter invented..." without their explicit permission.

Wonder if they even exist anymore. They certainly don't show up on the first 
page of Google.

- Anton Treuenfels 

[toc] | [prev] | [next] | [standalone]

#157

You're very welcome.  :-)  I seem to recall that everything after & is interpreted as a string (perhaps?) though it is possible that the stuff inside the ampersand command portion also gets tokenized.  The ampersand routine is passed a pointer to where the command itself starts in memory, and then it has to finish out the parsing on its own.  This is nice in that it makes it very flexible, but from a grammar validation standpoint this is awful because you have no way of knowing something is valid until it works or it fails.

[toc] | [prev] | [next] | [standalone]

#158

BLuRry wrote:
> You're very welcome.  :-)  I seem to recall that everything after & is interpreted as a string (perhaps?) though it is possible that the stuff inside the ampersand command portion also gets tokenized.  The ampersand routine is passed a pointer to where the command itself starts in memory, and then it has to finish out the parsing on its own.  This is nice in that it makes it very flexible, but from a grammar validation standpoint this is awful because you have no way of knowing something is valid until it works or it fails.

The only things in Applesoft program that don't get tokenized are
strings (and possibly DATA statements--I've never looked ;-).

Tokenization doesn't check syntax, nor does listing a tokenized
program check syntax.  POKE POKE POKE tokenizes perfectly and
lists fine, but it isn't good syntax and obviously won't execute.

Correct syntax is a *very* weak test for program correctness, since
astronomically many semantic errors can exist without any syntax
errors.

No static analysis of a program can ever determine that it is free
from errors--that's the "stopping problem".

And while dynamic analysis can, in principle, determine that a
program is free from errors, in practice, any program complex
enough to be interesting is almost certainly beyond being able to
try all permutations of data values and flows in a practical time.

Debugging/testing is intrinsically hard, but it's the best we
have.  Analysis tools can help, but not as much as one would hope.

-michael

NadaNet 3.1 for Apple II parallel computing!
Home page:  http://home.comcast.net/~mjmahon/

"The wastebasket is our most important design
tool--and it's seriously underused."

[toc] | [prev] | [next] | [standalone]

#161

On Feb 9, 12:41 am, "Michael J. Mahon" <mjma...@aol.com> wrote:
>
> The only things in Applesoft program that don't get tokenized are
> strings (and possibly DATA statements--I've never looked ;-).

From my testing, DATA statements do get tokenized. Quoting is optional
but needed to avoid reserved word handling. So IIRC (no emulator
handy) this:

10 DATA a,b,c : FOR I = 1 TO 3 : READ A$: PRINT A$ : NEXT

will print:

a
b
c

... but you almost always want to quote strings to avoid reserved word
tokenization.

And don't forget REM statements, which are not tokenized, including
any colons!

[toc] | [prev] | [next] | [standalone]

#162

Joshua Bell <inexorabletash@gmail.com> writes:

> On Feb 9, 12:41 am, "Michael J. Mahon" <mjma...@aol.com> wrote:
>>
>> The only things in Applesoft program that don't get tokenized are
>> strings (and possibly DATA statements--I've never looked ;-).
>
> From my testing, DATA statements do get tokenized. Quoting is optional
> but needed to avoid reserved word handling. So IIRC (no emulator
> handy) this:
>
> 10 DATA a,b,c : FOR I = 1 TO 3 : READ A$: PRINT A$ : NEXT
>
> will print:
>
> a
> b
> c
>
> ... but you almost always want to quote strings to avoid reserved word
> tokenization.
>
> And don't forget REM statements, which are not tokenized, including
> any colons!

Nope, DATA statements are not tokenized.  They are copied as-is until
the next colon that is not part of a token.

Example:

]10datatext,hgr,lomem::text
]list

 10  DATA text,hgr,lomem:: TEXT




-- 
--
Jerry    awanderin at yahoo dot ca

[toc] | [prev] | [next] | [standalone]

#160

Thank you Anton and Jerry.

According to the Nibble Program Index, theses programs were first
printed in the nibble magazines.

"Applesoft Programming Helper" by Grant Stevens => volume 4 number 7
(1983)
"Microscope" by Ong Tee Yong => june 1986

I have the both magazines (and the dvd I bought long time ago), so I'm
going to read them to see what they can really do.

JM

[toc] | [prev] | [next] | [standalone]

#163

Hi J-M,

On Thu, 9 Feb 2012, Deckard wrote:

> According to the Nibble Program Index, theses programs were first
> printed in the nibble magazines.
>
> "Applesoft Programming Helper" by Grant Stevens => volume 4 number 7
> (1983)
> "Microscope" by Ong Tee Yong => june 1986

I have used a lot a BASIC optimizer/compacter, whose name I can't remember 
right now. I think it was 35 sectors in size, was operated by & commands 
(like &OPT ??), and was probably Beagle Bros product. It allowed creating 
longer BASIC lines than with manual entering because of the limitation of 
the input buffer.

Does that ring a bell?

[toc] | [prev] | [next] | [standalone]

#166

On 10 fév, 11:04, Vladimir Ivanov <vlad...@XXXyahooXXX.com> wrote:

> I have used a lot a BASIC optimizer/compacter, whose name I can't remember
> right now. I think it was 35 sectors in size, was operated by & commands
> (like &OPT ??), and was probably Beagle Bros product. It allowed creating
> longer BASIC lines than with manual entering because of the limitation of
> the input buffer.
>
> Does that ring a bell?

Hi Vlad,

Beagle Bros D CODE's COMPACT program?

JM

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.sys.apple2.programmer

csiph-web