Message-ID: <6192@rochester.UUCP>
Date: Tue, 5-Feb-85 17:22:43 EST
Article-I.D.: rocheste.6192
Posted: Tue Feb  5 17:22:43 1985
Date-Received: Fri, 8-Feb-85 03:27:07 EST
References: <345@snow.UUCP> <335@enmasse.UUCP>
Organization: U. of Rochester, CS Dept.
Lines: 109

[color=blue]>  [squelch][/color]
[color=blue]>  [/color]
[color=teal]>>   o  Discussions of programs and languages (e.g. the brain-damaged 'records'[/color]
[color=teal]>>      in Action.[/color]
[color=teal]>>  3. Let's whine about Action; I love the fact that it is in ROM, that it[/color]
[color=teal]>>     compiles fast, and *is* fast, but why can't you have pointers in records?[/color]
[color=teal]>>     I hate using CARDs. And why are all variables static? Just try writing[/color]
[color=teal]>>     recursive programs! (I know you can use arrays, but I want to be[/color]
[color=teal]>>     difficult)  >-{[/color]
[color=blue]>  [/color]
[color=blue]>  	Really the problem is that for fast code Action doesn't use[/color]
[color=blue]>  	a stack frame- on a 6502 you only get 256 bytes of stack so[/color]
[color=blue]>  	if you want truly recursive procedures you have to use the[/color]
[color=blue]>  	hardware stack to hold pointers to a software stack. C65[/color]
[color=blue]>  	does this, but as we all know, that language is truly brain[/color]
[color=blue]>  	damaged, and SLOOOOOOWWWW. [/color]


The real problem is that the 6502 doesn't really support a stack.  ACTION!
doesn't support recursion for just this reason.  Come on now, how often do
you really write recursive routines?  How many of them need to be?  Not too
many I'll bet.  I think most people would rather have the speed advantage.
If you don't, used Deap Blue C or C/65 (which are missing several other
features).

[color=blue]>  	Not only won't Action! let you have pointers in records, but[/color]
[color=blue]>  	I ran into the following bug:[/color]

True, ACTION! on the Atari doesn't support pointers in records, but there
were some features that had to be left out to fit it in the 16K cartridge.

[color=blue]>  	;* excuse syntax errors, I can never switch from c to action too well[/color]
[color=blue]>  	[/color]
[color=blue]>  	CARD ARRAY dur(4)[/color]
[color=blue]>  	BYTE count[/color]
[color=blue]>  			init_dur();[/color]
[color=blue]>  			FOR i=0 to 3 DO[/color]
[color=blue]>  				dur(count) == -1;[/color]
[color=blue]>  				if (dur(count) = 0) then[/color]
[color=blue]>  				  do_something();[/color]
[color=blue]>  				fi;[/color]
[color=blue]>  			OD[/color]
[color=blue]>  	[/color]
[color=blue]>  	This code was supposed to decrement card values in the card array dur,[/color]
[color=blue]>  	except that the compiler got all confused... refused to byte reverse[/color]
[color=blue]>  	values in dur before decrementing. It didn't matter what I used to point[/color]
[color=blue]>  	into the array.... same results. I fixed it by calling a function to[/color]
[color=blue]>  	perform the decrement, i.e. decr(dur,count)!!!!![/color]
[color=blue]>  [/color]
[color=blue]>  	WORSE YET- this was entirely context sensative!!!!! Similar code[/color]
[color=blue]>  	worked fine in different situations.[/color]

I sure wish I knew what you did.  My guess is that the program was incorrect
(like this one is).  I tried the following and it works just fine:

  CARD ARRAY dur(4)
  BYTE count, i

  count = 1
  dur(count) = 3
  FOR i = 0 TO 3 DO
    dur(count) ==- 1
    IF  dur(count)=0 THEN
      PrintE("works")
    FI
  OD

[color=blue]>  	Add this to the inability of the compiler to operate on cardinal[/color]
[color=blue]>  	values greater than 0x7fff, and you have a piece of software[/color]
[color=blue]>  	that should never be used by anyone.[/color]

I only know of one place where hex values do not work properly.  That is for
declaring the size of an array.  This is a known (and documented by OSS) bug
that has been fixed for the next revision of ACTION!.  If you would like to
provide an example (other than that mentioned above) where hex constants or
CARDinals don't work properly, I would like to see it.  Reported bugs in
ACTION! ARE FIXED!!!  But it is hard to fix a bug if you don't know that it
exists.

[color=blue]>  	What really bugs me is that OSS has no intention of fixing any of[/color]
[color=blue]>  	this sh*t. And if they do... you can bet that it won't be the free[/color]
[color=blue]>  	upgrade that it should be.[/color]

I normally don't post messages here, but I could not let this one go by
without a response.  First, OSS does support its product.  They have come
out with 4 revisions to ACTION! since its initial release.  The current
version is 3.6.  They also will give you a bug list if you request it and
many of these have been described (with fixes) in their newsletter.  If
you didn't get a news letter, then you probably didn't send in the
registration card (how are they going to send you a copy if they don't know
who you are).  They provide upgrades for old versions of the cartridge for
$30.00.  Now I know that isn't exactly cheap, but they do have to give you
a whole new cartridge when they do it.  (Let's face it, ACTION! isn't the
biggest selling program in the world and low volume items carry a lot of
overhead.) 

      - Clinton Parker
        Action Computer Services

ps:  ACS really does like to here reports of bugs in ACTION!, but to be fair
many of the reported bugs are actually programmer errors.  I know this does
not make the programmer feel too good when he/she is told this, but you
should realize that it is very hard to fix something that isn't broken.
Many reported bugs (that aren't) also deal with misunderstandings of what
the user think ACTION! can do and what it really can do.  For these, I am
sorry, and again, would be willing to listen on how the manual could be
improved (yes I know it's not that great) to correct these misunderstandings
(specific examples would really help here).  Thanks.