Runer, how do you suggest I do the token replacement?  The first problem I had was that you have to know ahead of time what Axioms are being used in the program so it knows what to replace.  That can easily be solved with your first suggestion of always requiring the Axioms to come first, but this does remove a possible convenience, however its probably worth it.  The next problem is that for each token the Axioms have to be searched for in the symbol table to find their pointers, which could be costly with a large number of programs.  Then, when finally found, each Axiom would have to be scanned completely to find if the token matches by transversing the offset list (again, for each token).  So if you had 2 Axioms with 25 new commands each, and about 20 tokens on the screen, that's 40 symbol table searches + 1000 checks + the built in checks.  I could definitely see this causing lag in the scrolling.  There might be another way of caching the data in ram somewhere, and maybe setup a binary search, but this would greatly complicate things.  The token hook is only called when tokens are being printed and I don't want to use other hooks so its difficult to have some sort of "pre-parsing".  I am however still open to suggestions of what to name the rest of the custom override tokens.

If there's a way to only parse any #Axiom( tokens immediately when the program editor is opened, that seems like a good route to take. You could get their pointers from the symbol table and cache them at the start, and you'd only need 3 bytes * 5 Axioms of cache storage. If there isn't a specific event that can be triggered upon opening the program editor, you can always fake it by hooking into an event that periodically occurs, but only acting upon it the first time it is triggered.

Your other suggestion, If I'm reading this correctly, is a static offset to optimize doing ld hl,dynamic_ptr; ld de,offset; add hl,de; correct?  This might be an option in the future.  There are other useful features I can think of too, like adding the ability to create Axioms that take a label as their first argument, like how the current interrupt setup command works.

Yeah, something like that. It would be more useful for doing offset calls though, like:
OFS_NEXT(7)
call sub_Axiom1
This is the sort of thing you often do with drawing commands so they can work with different buffers.

Some more Axiom feature requests: the ability to specify commands that must be followed by a store token, and the ability to specify that the Axiom should be searched before the internal commands.

I understand that you didn't make Axioms parsed first because it would slow down parsing of normal commands, which would probably account for most of the program. But having it as an option would be useful. That way if your Axiom didn't supplement/replace any built-in commands, you wouldn't specify this option and parsing speed would be normal. But if your Axiom was designed to replace internal commands, you could do so by specifying this option.


Also, if you're going to modifying the Axiom system with any feature additions (not necessarily the ones above), it would probably be a good idea to start adding more information to the Axiom header, namely version information. This would signal to the Axe application parsing the Axiom whether or not the application's version is compatible. Adding an expanded header would also allow for the addition of more information, like whether or not to parse with a higher priority than internal commands. Perhaps:
.db $C0,$DE ;Header bytes reversed so old Axe applications won't accept the Axiom
.db Axiom_version
;Possibly additional header data


As an addition to the signed For Loop, Could there be a loop that automatically increments negatively or positively so that the loop always runs?
Like, say,
For(Q,A,B,C)^rr
where C>0, would increment by -C if A>B and C if A<B

Quote from: Compynerd255 on April 26, 2011, 10:29:02 am

Oh, and I would also like to specify custom steps in For loops, like we can in TI-BASIC.

I've been wondering why Quigibo hasn't added that as well.

I suggested that awhile ago and got shot down hard. =/
Apparently, it was thought that While loops were an acceptable substitute.

Quote from: Freyaday on April 26, 2011, 10:42:15 am

As an addition to the signed For Loop, Could there be a loop that automatically increments negatively or positively so that the loop always runs?
Like, say,
For(Q,A,B,C)^rr
where C>0, would increment by -C if A>B and C if A<B

This doesn't seem like a loop structure that would be widely used, especially since modern programming languages don't have loops like this. This is the kind of thing that you would best build a custom loop for.

Why shouldn't Axe be the first, then?

Quote from: Compynerd255 on April 26, 2011, 10:29:02 am

Here's a request that shouldn't be hard to implement: adding If conditionals to sub and Goto.

I agree, that would be nice. I think Quigibo was contemplating adding this feature not long ago.

His post:

For the goto-if and goto-!if I think I will auto-optimize the existing commands instead of creating entirely new syntax.  It would actually be easier I think to read and write and no one would have to change their syntax.  Same thing with sub().

Still not sure: does that mean this is now optimized? If so, I still want to suggest a Goto LBLIf CONDITION syntax, if only to have it look better. If Quigibo doesn't want to add it he doesn't have to though, if conditional Gotos are already optimized.

EDIT: Doesn't seem to be optimized yet... Goto LBLIf CONDITION, please?

EDIT2: Another suggestion: a hotkey to quit from compiling.

Actually I was planning to have for-loops have a step size parameter, but it will most likely have to be a non-negative constant in order to actually optimize.

How about optimizing constants and having a less optimized version for non-constants?

Not really a feature per se, but might it be possible to release a version of axe 0.5.1 that has the dispgraph bug fixed?

btw on the poll voted no, it would break compatibility with older programs.  As for easier reading, at least to me it's weird seeing a Pt-On( or For( with closed parenthesis

0.5.2 is coming out this week and I haven't actually gotten to fixing it yet so I think you'll have to wait until then.  Yeah, I forgot to mention that I added a new poll.  This is something big that I was thinking about since the start of the project.  I was avoiding the topic for a while though because I was afraid it was already too late to make a change like that, but I figured I would ask it anyway.  Even though it would break compatibility, it would be fairly easy to fix, and Axe could conceivably add extra closing parenthesis for you automatically as it compiles.

I actually already have been enforcing closed parenthesis on some commands.  I thing getkey(), all the # commands, and a few others currently require them closed right now.

EDIT: And ZippyDee, sig related!