Jump to content

Recommended Posts

Hi all!

 

I have a new beta (test) version of the next FastBasic release (4.4), I need your help testing the IDE - specially the editor, as it has many changes under the hood to make it smaller.

 

The changes in this version are:

- Adds BREAK key handling to the IDE - this was long overdue, now you can press BREAK key to return to the IDE from your program.

- Adds COPY/PASTE to the editor, you need to press CONTROL-M to "mark" a line in the editor, then when you press CONTROL-C that line is copied after the current one. Pressing CONTROL-C multiple times copies multiple lines.

 

Changes to the language:

- Adds "CLR" statement, that un-dimension arrays and sets all variables to 0.

 

Changes to the cross-compiler:

- Allows to compile to code that can be put in a cartridge - by removing all uses of self-modifying-code and adding a stub to copy the zeropage interpreter from ROM to RAM at startup.

- Allows accessing to DATA's from external assembly files.

- The CC65 tools are included in the distribution, you don't need to install CC65 to use the cross-compiler anymore.

 

Have Fun!

 

EDIT: See newer beta version at: 

 

 

 

fastbasic-v4.4-beta-macosx.zip fastbasic-v4.4-beta-win32.zip fastbasic-v4.4-beta.atr fastbasic-v4.4-beta-linux64.zip

Edited by dmsc
  • Like 11
  • Thanks 6

Share this post


Link to post
Share on other sites

Great to see another update, I knew something was going on when I got all those alert emails from github last night.  Looking forward to 5.0 :)

Share this post


Link to post
Share on other sites

Hi!

10 hours ago, Preppie said:

Great to see another update, I knew something was going on when I got all those alert emails from github last night.  Looking forward to 5.0 :)

Well, I still plan to do some additions before releasing the final 4.4 version.

 

It was really hard to squeeze the new functionality and keep the IDE bellow 8kB, but I already added a few more optimizations and fixed one little bug, so now the integer IDE is 8155 bytes, I still have 37 bytes available 😛 

 

I think that now, the main functionality missing in the editor is a "go to specific line", or other means to move around the file faster - this is needed as the scroll speed is low using the standard Atari screen handler.

 

Also, I'm not convinced the keys I selected for the copy operations are good, currently is "CONTROL-M" for "mark" a position as source, and then "CONTROL-C" to copy from the marked position to the current position. I accept suggestions!

 

Have Fun!

 

  • Like 1

Share this post


Link to post
Share on other sites

I think the standard windows keys for copy&paste would work fine.  They're usable with a single hand and everyone is comfortable with them already.  Forget about Mark&Copy, it's Copy&Paste :)

  

Edited by Preppie

Share this post


Link to post
Share on other sites

Hi!

7 hours ago, Preppie said:

I think the standard windows keys for copy&paste would work fine.  They're usable with a single hand and everyone is comfortable with them already.  Forget about Mark&Copy, it's Copy&Paste :)  

 

There are two problems with that:

- The current operation is not the same as COPY/PASTE, as the first key only selects a line as source, so if you modify the area before the copy, you will copy the modified text. I suppose that this could be explained in the manual.

- I'm currently using CONTROL-V as "page down" key 😛

 

Also, I intended to write a "go to mark" command, (this is really simple to implement), but don't know it it is that usefull.

 

I don't remember why the current page-up and page-down keys are CONTROL-U and CONTROL-V, perhaps that should also can be changed.

 

Have Fun!

 

Share this post


Link to post
Share on other sites
10 hours ago, dmsc said:

I don't remember why the current page-up and page-down keys are CONTROL-U and CONTROL-V, perhaps that should also can be changed.

Hi Daniel, its been a while since we last conversed.

 

And I haven't had the time to really get into your FastBasic creation, but I fully intend to do so by the end of the year because it looks to be very useful. So I'm not sure if you are talking about editing in a PC or on the Atari. But if you are talking about the Atari side of things, then it would be really nice to also recognize the Page-Up and Page-Down of the 1200XL function keys. These keys are fully supported in all of the TK-II iterations, as well as being built into the 1088XEL and XLD projects, and the upcoming 576NUC+.

 

I am specifically referring to the key codes that are put out when using SHIFT with F1-F4 on a 1200XL, which have been assigned to the actual navigation keys on a PS/2 keyboard with the matching function. These key definitions are included in all versions of the XL and XE OS, but without a TK-II or a 1200XL they are not normally available. However there are probably enough people using systems that are TK-II based by now to make this addition worthwhile.

 

1200xl-keys.png.fd753b47a8cbc7088b3e1971db8eac0b.png

 

I don't recall the actual key codes off the top of my head, but I can get you those for you by Thursday.

 

Take care :) .

 

  • Like 2

Share this post


Link to post
Share on other sites

Hi!

11 hours ago, mytek said:

Hi Daniel, its been a while since we last conversed.

Yes, but I have seen that you have been busy with the new great Atari projects!

 

11 hours ago, mytek said:

And I haven't had the time to really get into your FastBasic creation, but I fully intend to do so by the end of the year because it looks to be very useful. So I'm not sure if you are talking about editing in a PC or on the Atari. But if you are talking about the Atari side of things, then it would be really nice to also recognize the Page-Up and Page-Down of the 1200XL function keys. These keys are fully supported in all of the TK-II iterations, as well as being built into the 1088XEL and XLD projects, and the upcoming 576NUC+.

Sadly, this can't be done with the current architecture of the editor. When Atari added those keys, they did not assign an ATASCII value to the new functions, you need to manually process the CH location to detected F1 to F4 with or without shift.

 

edit: ... reading a bit more ...

 

It seems you *can* read the shifted-function keys, you just need to read location $3E8 (SUPERF) just after the keyboard GET, it is set to 1 if the shifted-F* keys are pressed.

 

So, I need to replace the code with:

  GET key
  ' Process keys
  ' ... snipped code ....

  '--------- Down / PgDown --------
  elif key = $1D
    if peek($3E8)
      for y=0 to 20
        exec CursorDown
      next
    else
      exec CursorDown
    endif
    exec ChgLine
  '
  '--------- Up / PgUp ------------
  elif key = $1C
    if peek($3E8)
      for y=0 to 20
        exec CursorUp
      next
    else
      exec CursorUp
    endif
    exec ChgLine

 

I will test this and if the generated code is not big, I can include it in the v4.4 release.

 

Have Fun!

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Hi!

 

Adding support for Page-Up and Page-Down function keys was not as easy, as I still need to support two other keys for the majority of users that don't have those keys in the standard Atari keyboard. So, after trying hard to minimize the code, it was 20 extra bytes for those two keys 😞

 

After also adding the CONTROL-G key as "go to line" command, now the integer-only IDE is 8198 bytes. I still need to find 6 extra bytes to remove before a release!!

 

As always, last code is over github: https://github.com/dmsc/fastbasic

 

Have Fun!

 

    Daniel.

 

  • Like 1
  • Thanks 2

Share this post


Link to post
Share on other sites
On 7/8/2020 at 8:27 PM, dmsc said:

Hi!

 

Adding support for Page-Up and Page-Down function keys was not as easy, as I still need to support two other keys for the majority of users that don't have those keys in the standard Atari keyboard. So, after trying hard to minimize the code, it was 20 extra bytes for those two keys 😞

 

After also adding the CONTROL-G key as "go to line" command, now the integer-only IDE is 8198 bytes. I still need to find 6 extra bytes to remove before a release!!

 

As always, last code is over github: https://github.com/dmsc/fastbasic

 

Have Fun!

 

    Daniel.

 

Hi Daniel,

 

Here are the key codes for the navigation keys as produced by the PS/2 keyboard without invoking Shift or Control (see note below).

 

TK-II_Nav-Key_codes.png.a6b5b6445d49887663e2826c307d8573.png

 

The upper decimal number as seen when peeking at location 764 in Basic, with the hex equivalent below.

 

Edit: please note that although these are not shifted or controlled on the PS/2 keyboard, some of them are controlled or shifted 'Atari' equivalents.

 

 

  • Like 1

Share this post


Link to post
Share on other sites

I just tested the BREAK key and it works OK when I RUN a program, but if I press it while in the IDE, it breaks the line at the cursor position. I guess that it is because it also inserts a RETURN key to go back to the IDE without waiting for an extra keypress.

 

Is this a bug or a feature?

 

Share this post


Link to post
Share on other sites

Hi!

1 hour ago, vitoco said:

I just tested the BREAK key and it works OK when I RUN a program, but if I press it while in the IDE, it breaks the line at the cursor position. I guess that it is because it also inserts a RETURN key to go back to the IDE without waiting for an extra keypress.

 

Is this a bug or a feature?

It is an unintended effect. The editor simply ignores errors on the "GET KEY", and the Atari OS keyboard handler return an EOL (155) when the BREAK key is pressed.  Note that this does not happens in Altirra OS, as that OS returns zero when the break key is pressed.

 

Have Fun!

 

Share this post


Link to post
Share on other sites
1 hour ago, dmsc said:

It is an unintended effect.

Well, at least BREAK key "breaks" the line in the IDE. ;-)

 

About M&C (or C&P), in either way I'd suggest to copy multiple lines in a very simple way: every time you append the copied line bellow the current line, perform an automatic "mark" in the next line from the previously marked one, so you can paste a range of lines just pressing the paste key multiple times. Of course, there are two border conditions: when the destination is over the source (you might need to increase the source line number twice), and when the source reaches the end of file. To multiplicate a line, copy it and append it many times without moving the cursor.

 

On 7/7/2020 at 1:05 PM, dmsc said:

I don't remember why the current page-up and page-down keys are CONTROL-U and CONTROL-V, perhaps that should also can be changed.

I'd prefer to move page-down keys from CTRL-V to CTRL-I (besides CTRL-U) and use CTRL-C and CTRL-V for C&P.

 

Share this post


Link to post
Share on other sites

Do you think an Atari Basic conversion tool would be practical?  There are many thousands of Atari Basic programs that potentially could run under FB.  (Maybe this has been mentioned before?)  Not asking you to provide one -- just what do you think.  Or... is there any reasonable way that FB could be made to accept line numbers. That seems to be the major obstacle.

  • Like 1

Share this post


Link to post
Share on other sites

Hi!

1 hour ago, vitoco said:

Well, at least BREAK key "breaks" the line in the IDE. ;-)

 

About M&C (or C&P), in either way I'd suggest to copy multiple lines in a very simple way: every time you append the copied line bellow the current line, perform an automatic "mark" in the next line from the previously marked one, so you can paste a range of lines just pressing the paste key multiple times. Of course, there are two border conditions: when the destination is over the source (you might need to increase the source line number twice), and when the source reaches the end of file. To multiplicate a line, copy it and append it many times without moving the cursor.

This is already done, try it! :) 

 

1 hour ago, vitoco said:

I'd prefer to move page-down keys from CTRL-V to CTRL-I (besides CTRL-U) and use CTRL-C and CTRL-V for C&P.

I think I will do this, as nobody else has proposed other keys yet.

 

Have Fun!

 

  • Like 2

Share this post


Link to post
Share on other sites

Hi!

1 hour ago, Larry said:

Do you think an Atari Basic conversion tool would be practical?  There are many thousands of Atari Basic programs that potentially could run under FB.  (Maybe this has been mentioned before?)  Not asking you to provide one -- just what do you think.  Or... is there any reasonable way that FB could be made to accept line numbers. That seems to be the major obstacle.

 

A conversion utility could work, but line numbers per se are not the biggest problem, problems that I see in order of difficulty are:

- Same with DATA, FastBasic DATA's are like FORTRAN data, or C  constant arrays, you would need to detect where data end up via tracing the READ statements.

- Strings are not compatible at all, as FastBasic has automatic strings and string arrays but does not have long strings.

- Usage of variable GOTO / GOSUB (like GOTO 10*A). Those are very difficult to convert properly.

- To really gain speed, you would need to detect which variables can be converted from floating point to integer, doing this automatically is very difficult.

 

You can use my basic parser tool (at https://github.com/dmsc/tbxl-parser ) to remove the unused line numbers from a program, using options "-l -O line_numbers" you end up with a program easier to translate to FastBasic.

 

Have Fun!

Share this post


Link to post
Share on other sites
57 minutes ago, dmsc said:

This is already done, try it! :) 

How didn't I noticed it? 😳

 

Well, that's good news... there are still 6 bytes available for another feature, might it be for "Cut" and paste?

 

What about abbreviations for functions?

 

Share this post


Link to post
Share on other sites

How about Shift+Control up & down for the Page Up & Page Down?  

 

So Control+Up moves the cursor up, Shifted does Page Up.  Similar for Control+Down moves cursor down, Shifted does Page Up.

 

  • Like 1

Share this post


Link to post
Share on other sites

Hi!

46 minutes ago, StickJock said:

How about Shift+Control up & down for the Page Up & Page Down?  

 

So Control+Up moves the cursor up, Shifted does Page Up.  Similar for Control+Down moves cursor down, Shifted does Page Up

That is not possible as those key combinations don't return from a "GET KEY" call from the K: handler.

 

57 minutes ago, vitoco said:

Well, that's good news... there are still 6 bytes available for another feature, might it be for "Cut" and paste?

Sadly, after I added the SHIFT-F! and SHIFT-F2 as page-up and page-down keys and the "CONTROL-G" to go to an arbitrary line number, I'm 6 bytes over the 8K, so I need to find a way to make the code smaller before a release :P 

 

57 minutes ago, vitoco said:

What about abbreviations for functions?

I plan to add those, but I still don't decide on proper abbreviations. ¿what are the function names that are used the most?

 

Have Fun!

Share this post


Link to post
Share on other sites
2 hours ago, dmsc said:
Quote

What about abbreviations for functions?

I plan to add those, but I still don't decide on proper abbreviations. ¿what are the function names that are used the most?

 

This is my proposal. I took all the functions from the docs, sorted them and selected the abbreviation based on my experience. This is the result:

function        abbreviation   optional      unabbreviated
ABS(num)                       AB.(num)                   
ADR(arr)        A.(arr)                                   
ADR(str)        A.(str)                                   
ASC(string)                    AS.(string)                
ATN(n)                         AT.(n)                     
CHR$(num)       C.$(num)                                  
COS(n)                         CO.(n)                     
DPEEK(addr)     D.(addr)                                  
ERR()           E.()                                      
EXP(n)                                       EXP(n)       
EXP10(n)                       EX.(n)                     
FRE()           F.()                                      
INT(num)        I.(num)                                   
KEY()           K.()                                   
LEN(string)     L.(string)                                
LOG(n)                                       LOG(n)       
LOG10(n)                       LO.(n)                     
PADDLE(n)       PA.(n)                                    
PEEK(address)   P.(address)                               
PMADR(n)        PM.(n)                                    
PTRIG(n)        PT.(n)                                    
RAND(num)       R.(num)                                   
RND()                          RN.()                      
SGN(num)                       SG.(n)                     
SIN(n)                         SI.(n)                     
SQR(n)                         SQ.(n)                     
STICK(n)        S.(n)                                     
STR$(num)                                    STR$(n)      
STRIG(n)                       STR.(n)                    
TIME            T.                                        
USR(***)        U.(***)                                   
VAL(string)     V.(string)                                
$(addr)                                      $(addr)

The second column is my proposal, the third one is optional as the abbreviation would not save typing, and the forth one includes the unabbreviated functions because it might conflict with another one.

 

I selected to abbreviate "EXP10()" and "LOG10()" instead of "EXP()" and "LOG()", because the later ones won't save typing, and this way an extra char is saved for the selected ones.

 

This might change a bit depending on some other features or the way that the parser interprets functions. For instance, is "$" part of the name for string functions? If it is, then "CHR$()" could be abbreviated as "C.()", but it will create a conflict between "STRIG()" and "STR$()" if the later is also abbreviated.

 

It could be interesting if "(" is also part of the abbreviation, but "D.88)" would look strange.

 

I'm not sure if ".()" could be a valid abbreviation as numbers can also start with "." in a floating point expression, like in ".25", but if it is possible, I'm also not sure to assign it to "PEEK()" or "DPEEK()".

 

BTW, it seems that the docs require some "normalization" in arguments (addr vs address; n vs num). Also, there are some function descriptions with a space between the function name and the colon, and "SGN()" has a semicolon instead of a colon.

 

Share this post


Link to post
Share on other sites

Hi!

25 minutes ago, vitoco said:

This is my proposal. I took all the functions from the docs, sorted them and selected the abbreviation based on my experience. This is the result:

[snip]

The second column is my proposal, the third one is optional as the abbreviation would not save typing, and the forth one includes the unabbreviated functions because it might conflict with another one.

 

I selected to abbreviate "EXP10()" and "LOG10()" instead of "EXP()" and "LOG()", because the later ones won't save typing, and this way an extra char is saved for the selected ones.

Sounds reasonable.

 

25 minutes ago, vitoco said:

This might change a bit depending on some other features or the way that the parser interprets functions. For instance, is "$" part of the name for string functions? If it is, then "CHR$()" could be abbreviated as "C.()", but it will create a conflict between "STRIG()" and "STR$()" if the later is also abbreviated.

Basically, when a dot is found, the parser skips the rest of the string in the current rule. This means that depending on the rule some parts are included and others not. In the case of "CHR$" and "STR$", the "$" is part of the rule, so the dot will also skip it, making it "C.()".

 

The parser rules also means that certain cases the parser also considers the "(" as part of the match, this is the function list as seen by the parser:

 # Floating point result
	ABS
	ATN
	SGN
	EXP10
	EXP
	LOG10
	LOG
	SQR
	SIN
	COS
	VAL
	RND()

 # Integer result
	NOT
	TIME
	ABS
	SGN
	PEEK
	PADDLE
	PTRIG
	STICK
	STRIG
	PMADR
	INT
	RAND
	DPEEK
	FRE()
	ERR()
	USR(
	ADR(
	LEN
	VAL
	ASC
	KEY()

 # String result
	CHR$
	STR$
	$
	STR$

 

The above means the "X = KEY()" could be abbreviated simply as "X = K." without both parenthesis, "X = DPEEK(88)" would be "X = D.(88)" with both parenthesis, and " ADR(X$) " could be abbreviated "A.X$)" skipping the first parenthesis but keeping the second one.

 

Also, the parser currently accepts spaces between the function name and the open parenthesis in all the above functions that don't have the parenthesis in the name (as the parser will skip spaces between two different rules), currently you can write "X = DPEEK    (560)".

 

It just occurred to me that I could rewrite the parser to not depend on the parenthesis on some of the functions, this could allow this type of code

A = PEEK 123 + 7   ' This is the same as "X = DPEEK(123) + 7"
B = STICK 0
C = PEEK DPEEK 88  ' This is "C = PEEK( DPEEK( 88 ) )"
C=P.D.88           ' The same abbreviated

 The above would work only for the above functions that don't have the parenthesis in the list.

 

25 minutes ago, vitoco said:

It could be interesting if "(" is also part of the abbreviation, but "D.88)" would look strange.

There are only two:

- ADR: The parameter is not a standard expression, making the parenthesis optional would make the parser slightly bigger and would make multiple parenthesis valid, like "ADR( ( ( X$ ) ) )".

- USR: Here the parameter is a list, so the parenthesis are always needed to know where the list stops. Think on " DPOKE USR 123, 45, 67, 89 ", the parser does not know where to separate the arguments to USR to the arguments to DPOKE.

 

25 minutes ago, vitoco said:

I'm not sure if ".()" could be a valid abbreviation as numbers can also start with "." in a floating point expression, like in ".25", but if it is possible, I'm also not sure to assign it to "PEEK()" or "DPEEK()".

I think that could work, but also think that is too confusing, so I prefer to avoid that.

 

Another confusing detail is that the parser only search for the function names in the correct context. This means that "X$ = ST.(123)" would search for "STR$" and not "STICK".

 

This does not work the other way around, as you can write "X = ST.(0) < ST.(1)", this could be interpreted as "X = STR$(0) < STR$(1)" or "X = STICK(0) < STICK(1)", both would be valid so the parser will always pick the INTEGER expression instead of the STRING expression, for example if I make both STR$ and STICK abbreviate to "S." this is the result:

? S.(0)       ' Valid, parser will pick INTEGER -> STICK(0)
? "A" > S.(0) ' Valid, parser will pick STRING -> STR$(0)
? S.(0) < "A" ' Invald, parser will pick INTEGER and then throw an error after the <
X$ = S.(0)    ' Valid, parser will pick STRING

 

25 minutes ago, vitoco said:

BTW, it seems that the docs require some "normalization" in arguments (addr vs address; n vs num). Also, there are some function descriptions with a space between the function name and the colon, and "SGN()" has a semicolon instead of a colon.

I gladly will accept a pull requests :) 

 

 

Share this post


Link to post
Share on other sites

AFAIR, Atari BASIC's parser searches in a statements table for the first one that matches the abbreviated word (some letters followed by a dot), but in FastBasic, there is no statement list but a series of parser rules, where the minimal abbreviation is defined using uppercase letters and, with the context in mind, it is possible to have different reserved words with the same abbreviation.

 

Said that, I'm not sure that string functions could be abbreviated, because there is no lowercase "$", as well as you cannot abbreviate "?" and the minus sign in "-MOVE". The same for those fuctions with the parenthesis. This way, all the problems with "STRIG()" and "STR$()" functions are avoided.

 

But I'm sure I am wrong, and you have an ace under your sleeve, and the non-letters chars are also lowercase... If so, you probably have a special case for "REM".

 

How many changes (and extra bytes) are required to make both parenthesis from a function optional? I guess that it could not be too hard as "NOT" seems to be a function without them (from your list of functions with an integer result).

 

After I sent my previous post, I thought about another approach, but then I discarded it because I think it would require much more space.

 

1 hour ago, dmsc said:

I gladly will accept a pull requests

How can I help?

 

Share this post


Link to post
Share on other sites

Hi!

9 hours ago, vitoco said:

AFAIR, Atari BASIC's parser searches in a statements table for the first one that matches the abbreviated word (some letters followed by a dot), but in FastBasic, there is no statement list but a series of parser rules, where the minimal abbreviation is defined using uppercase letters and, with the context in mind, it is possible to have different reserved words with the same abbreviation.

Yes!

9 hours ago, vitoco said:

Said that, I'm not sure that string functions could be abbreviated, because there is no lowercase "$", as well as you cannot abbreviate "?" and the minus sign in "-MOVE". The same for those fuctions with the parenthesis. This way, all the problems with "STRIG()" and "STR$()" functions are avoided.

Yes, you can't abbreviate symbols or numbers, this means that you can't replace a symbol with a dot. But, after matching the dot, the parser will skip all letters, numbers and symbols.

 

9 hours ago, vitoco said:

But I'm sure I am wrong, and you have an ace under your sleeve, and the non-letters chars are also lowercase... If so, you probably have a special case for "REM".

 

How many changes (and extra bytes) are required to make both parenthesis from a function optional? I guess that it could not be too hard as "NOT" seems to be a function without them (from your list of functions with an integer result).

No extra bytes, perhaps even could be less bytes than the current. The change is minimal, as I only need to change the rule from "PAR_EXPR" (an integer expression inside parenthesis) to "T_EXPR" (the "terminal" expression).

 

Note that the precedence also can be controlled, using "T_EXPR" the precedence is the highest so "PEEK 1 + 2 < 3" means "(PEEK(1) + 2) < 3", if I use "INT_EXPR", the precedence changes so that "PEEK 1 + 2 < 3" means "(PEEK(1+2)) < 3", and if I use "EXPR", this means "PEEK( (1 + 2) < 3 )".

 

Current precedence table for integer expressions should be like:

- Assignment        =
- Coma              ,
- Comparisons       < > <> <= >= =
- Additive          + -
- Multiplicative    * / MOD
- Bitwhise ops      & ! EXOR 
- Unitary           + - NOT

The function evaluation could be inserted on any part of that.

 

9 hours ago, vitoco said:

After I sent my previous post, I thought about another approach, but then I discarded it because I think it would require much more space.

 

How can I help?

 

The easiest, just download the MANUAL.md file and post here the modified one. Note that the manual sources should be formatted to a width of less than 40 chars, because it is used as is in the Atari.

 

Have Fun!

Share this post


Link to post
Share on other sites
12 hours ago, dmsc said:

Yes, you can't abbreviate symbols or numbers, this means that you can't replace a symbol with a dot. But, after matching the dot, the parser will skip all letters, numbers and symbols.

Ah! Simple and beauty...

 

12 hours ago, dmsc said:

The change is minimal, as I only need to change the rule from "PAR_EXPR" (an integer expression inside parenthesis) to "T_EXPR" (the "terminal" expression).

That could be interesting, because "T_EXPR" can also be a "PAR_EXPR", totally backwards compatible. I like it!

 

Anyway, "INT_EXPR" couldn't be a choice because it introduces ambiguity like in "PEEK DPEEK 88 + 1", which it will be the same than both "PEEK(DPEEK(88)+1)" and "PEEK(DPEEK(88+1))". You would need to write "PEEK(DPEEK(88))+1" to get the second byte from screen and "(PEEK(DPEEK(88)))+1" to get the first byte increased by one. Totally insane!

 

I agree that "USR()" and "ADR()" should require the parentheses, as well as "STR$()" shouldn't have an abbreviation to avoid context misbehaviour using "STR." abbreviation.

 

I haven't check deeper to see if there will be another strange or unwanted behaviour with the remaining functions, as well as implicit functions in "PRINT" statement arguments.

 

BTW, I never tried to create a variable using a reserved word, and today I discovered that I can define a variable with the name of a statement, assign it a value and use it in expressions, and the statement is still valid, but I cannot say the same with functions, because once I define an array using the name of a function, I cannot use the function anymore. Just check this:

PRINT=1
PRINT PRINT
DIM STICK(0)
STICK(0)=PRINT
WHILE PRINT
  INC STICK(0)
  PRINT STICK(0);" ";
WEND

I guess this is because there is no variable name validation against reserved words and, in the case of functions, the array rule is before the functions in "T_EXPR" rules list.

 

13 hours ago, dmsc said:

just download the MANUAL.md file and post here the modified one.

I'll do that...

 

BTW, I just read about "EFAST" driver to speed up editing in the IDE. Does it remain available for the running program? I guess so, because the IDE is an embedded FastBasic program, our own programs should run faster when they are intensive in "PRINT" statement. Aren't they?

 

Share this post


Link to post
Share on other sites

Hi!

On 7/18/2020 at 2:16 AM, vitoco said:

Ah! Simple and beauty...

 

That could be interesting, because "T_EXPR" can also be a "PAR_EXPR", totally backwards compatible. I like it!

 

Anyway, "INT_EXPR" couldn't be a choice because it introduces ambiguity like in "PEEK DPEEK 88 + 1", which it will be the same than both "PEEK(DPEEK(88)+1)" and "PEEK(DPEEK(88+1))". You would need to write "PEEK(DPEEK(88))+1" to get the second byte from screen and "(PEEK(DPEEK(88)))+1" to get the first byte increased by one. Totally insane!

Yes, I also think that would be confusing.

 

On 7/18/2020 at 2:16 AM, vitoco said:

I agree that "USR()" and "ADR()" should require the parentheses, as well as "STR$()" shouldn't have an abbreviation to avoid context misbehaviour using "STR." abbreviation.

 

I haven't check deeper to see if there will be another strange or unwanted behaviour with the remaining functions, as well as implicit functions in "PRINT" statement arguments.

 

BTW, I never tried to create a variable using a reserved word, and today I discovered that I can define a variable with the name of a statement, assign it a value and use it in expressions, and the statement is still valid, but I cannot say the same with functions, because once I define an array using the name of a function, I cannot use the function anymore. Just check this:

PRINT=1
PRINT PRINT
DIM STICK(0)
STICK(0)=PRINT
WHILE PRINT
  INC STICK(0)
  PRINT STICK(0);" ";
WEND

I guess this is because there is no variable name validation against reserved words and, in the case of functions, the array rule is before the functions in "T_EXPR" rules list.

Yes and this is intentional - you can define an array that "overrides" a FastBasic function, this means that I can add new functions and old programs will keep working.

 

On 7/18/2020 at 2:16 AM, vitoco said:

I'll do that...

 

BTW, I just read about "EFAST" driver to speed up editing in the IDE. Does it remain available for the running program? I guess so, because the IDE is an embedded FastBasic program, our own programs should run faster when they are intensive in "PRINT" statement. Aren't they?

Yes, EFAST is a standard "E:" accelerator, so it will work with any program that writes to the "E:" device.

 

Have Fun!

 

Share this post


Link to post
Share on other sites
On 7/18/2020 at 2:16 AM, vitoco said:
On 7/17/2020 at 12:26 PM, dmsc said:

just download the MANUAL.md file and post here the modified one.

I'll do that...

Please, let me know if you allow the abbreviatons in the syntax, in order to try them in my new tenliners and to check if something goes wrong and then to include them in manual.md.

 

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...