-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enhance: Named functions #15
Comments
I actually plan to add something just like that but with full names. Was thinking of a twist on the Postscript syntax.
But this is basically what you are suggesting. Nice to see that you have already caught on how this tiny script language works!
This has a dependency to storing scripts in PROGMEM or EEMEM. |
Yes, I like your plan to use PS syntax. I was trying to maintain the small footprint of the scripts by using songle chars - but your plan doesn't limit that. |
I started to modify your code so that I could define functions by storing the block-address in a variable. Then I realized that you already have this!!! Its documented in the Variable section. c{12.}2!,,2@x,,5{2@x}l clear { 12 print } 2! 5 { 2@x } loop works, too. |
First steps towards named functions; copy code block to heap. Please see commit c3a61b1. |
New format for allocating a code block.
|
Why did you add \and a, rather than a single operator? |
It is a symmetry thing :).
But things will change along the road. Need to work with it a while to see what "feels natural" and gives a good flow. Alloc and free may soon be removed when introducing a traditional forth |
OK. I do like the 'ultimate simplicity' of Arduino-Shell so far. Adding On Sun, Feb 28, 2016 at 12:00 PM, Mikael Patel notifications@github.com
|
Reopening this issue as it is soon time to implement. Current proposed design and syntax for named functions is:
This is more of less the forth style but with an explicit call operator "". This would replace the block allocate/deallocate. The ":" operator would add the "name" to a dictionary and copy the code block until ";". The "" is run-time lookup and execute of the "name". To make this even more interesting the "name" is associated with a variable and given the type code-block. This will give an internal mechanism much like forth "create-does>". |
Of the top: |
Yes, and no. It has to do with how much logic is behind the "\name". In forth this depends on the type of name; colon, variable, constant and create-does> to generalize this. The dict space is often just a linear address space, and "forget" steps back the allocation point. The construct ":name" is a nice postfix notation and might work well with the control structures. My concern is the state of the parse. In my original proposal "\name" is a lookup and execute. "\name@" implies that "\name" is actually a lookup and push of an address in the variable vector. In that case the block allocate and deallocate are still needed. The ":name code-block;" does away with all that. |
So, :fnc ... ; and \fnc and reclaim \ and a. Sounds good.
|
Please consider calling a trap on failure of the Shell to find a matching dict entry. This would allow quite easy extensions with useful names. Please also consider allowing any characters in a function name, as this would allow:
|
First version up and running. A small step forward.
Names are only alpha characters (for now). |
Boy, you are a moving target :-) (I discovered t-->Z, c -->C, S) Perhaps a different 'address-space' would be better, but I will have to play with it a bit. Might work very well in my application, since I plan to have multiple scripts, one for each event, and each of those will want to have parameters. Now I can name them, which will make life easier for the users. |
Yepp, it is all about refactoring. BW: c@, <c@ and c! will enter the word list with other string functions when things start to be more stable. The printable ASCII characters are almost covered. Some logical changes remain. I was reserving uppercase characters for the Arduino function but now it also included typical extensions such as C(lear), T(race toggle) and S(tack dump). Also I need to add a level of configuration so that the instructions can be add/removed depending on the applications. For most users the address of the variables/functions is not really of interest. Also in contrast to forth the dictionary is searched from first entry to last (latest). And there is only one entry per name. There is a simple transformation from \name to variable address which gives possible compression. The block scan is an issue for large blocks (as discussed before). There are a few possible optimizations; 1) cache resolved addresses (end of block), 2) replace "{" with offset (it is always forward and there are 128 8-bit values available for that, i.e. replace "{" with 0x80+offset). |
Hmmm -- the simplicity may be fading. At the moment I am impressed that If you exchange a '{' with a 0x80+offset, then the script is no longer Agree, the use of variable 0-n is useful, if compression is required. I kind of liked your idea of (forth-like) :fnc ... ; and \fnc executing My + + forms are problematic somewhat, as they would require what-space I expect you have a gameplay, and probably too complicated to explain ... I Great work. |
One example showed defining a function, and then it being used as a macro. Perhaps one could have named blocks and activate them with : as an escape character.
Eg:
{rot swap over swap > swap rot < or not};W
10 5 100 :W.
Script:
{rsos>sr<|~};W10,5,100:W.-10,5,100:W.110,5,100:W.
Obviously this impacts memory etc etc and may have complications and unintended consequencies.
The text was updated successfully, but these errors were encountered: