DJ suggested a really cool idea.  I think If I use my hooks correctly, I can have the Axe Tokens automatically enabled whenever the basic editor detects the program it is editing is an Axe source file and then revert back to normal when you quit so that the tokens never get mixed up or confused when you're dealing with regular BASIC.

I'm just worried if I eventually want to switch to Axe Tokens as the default tokens, then computer coding might get more complicated since programs like SourceCoder only use the original tokens.

You could always ask Kerm to add Axe support to Sourcecoder

Why not just keep things as they were? Sure, Conj() sounds weird, but think about new members who are gonna ask for help. They're gonna get told to copy bytes they need Conj. Experienced users all ggot used to Conj. I feel like you are forcing this on people and despite what I said regarding that stuff you did not care.

So for now I am sticking to Axe 0.2.6 and am no longer going to provide new feature suggestions.

True but he's planning to quit documenting the old commands...

I like the idea of just being able to toggle them off and on when you want. That way both sides are happy. What you could do on like the command list to show what both names are is just have one column that says "TI Token" and then the other "Axe Token" and then just state in documentation or something which is which. Just a thought

That would only be from unoptimized code by the programmer.  Like this:

A+1->A
Disp A>Dec

In the above example you first increment the value of A and then save it.  Immediately after, the next instruction is to load A again to display it.  Since you have just saved it and now are immediately loading it, that is obviously an inefficiency.  You can optimize it like this:

Disp A+1->A>Dec

So that way, it doesn't need to load the value of A a second time.  I might be able to have this be done automatically, I don't know how hard that would be though becasue that type of optimization is not dependent on the source, rather, it would need to make checks on  the assembly code written.  I haven't tried that yet, but it might be possible in the future.

I doubt you can shrink it that way because I think then the OS is unaware of the change and it will say you have less RAM available on your calculator than you really do and it will not correct itself until the next ram clear.

I hope to have the Parser itself optimize as much as possible.  The reason you don't really see C or Java optimizers is that its really really hard to optimize code at the higher levels, even for a medium level like Axe.

Quote from: Quigibo on June 18, 2010, 04:54:31 pm

Code: [Select]

Disp A+1->A>Dec


Gotta love how we can do that . I always wished we could do stuff like this in TI-BASIC too (or in xLIB)

Yes, I also like the syntax after understanding the implications.
It is bit like the Ans (some differences) but even faster.
I also wish in TI-BASIC we could do some expressions that did not change Ans for faster code. Like lines started with colons instead of enter did not change Ans. I see lots of optimization coming from this.

Even more important would be TI-BASIC be faster interpreting. I will experiment a simple interpreter that looks like TI-BASIC but adds some BBC BASIC, Axe Parser and some of my ideas to it. The floating point operations could be easily added later with bcalls to the TIOS routines. Until that I would use integers for numbers, lists, etc..
The main advantage of a interpreter against Axe Parser is stability and source code is also the code. It would be slower anyway, but I believe is possible to come with a bit faster than BBC Basic.
Also 1000th post. ^^

You can do matrices already, albeit indirectly. For a matrix with X columns and Y rows, for example, you can access (A,B) (with A being the column and B the row, indexed from 0) with {B*X+A+GDB1} (assuming the data is ordered a row at a time, beginning at GDB1)
As for a direct method, it might cause too much overhead, though, even if it didn't (I can already think of an implementation where everything that can be figured out is at compile time), I'm not sure it would be added. That would be up to Quigibo.
So, rather, you would like a direct, simple-looking way to use matrices. (Actually, these are really just two-dimensional arrays, but w/e. You're not getting matrix multiplication in Axe except by your own subroutine )