Skip to content
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

Bitlash limitations #211

Open
matthijskooijman opened this issue Nov 14, 2014 · 2 comments
Open

Bitlash limitations #211

matthijskooijman opened this issue Nov 14, 2014 · 2 comments

Comments

@matthijskooijman
Copy link
Collaborator

In the past, we've found that bitlash isn't always perfect and is limiting to what we need. In order to find out what would need changing, or what we'd need from an alternative, I'll try and collect the problems we have with bitlash here.

  • There is no proper string support. String literals can be passed to builtin functions, but functions cannot return strings, user-defined functions cannot accept strings as arguments (or at least not meaningfully use them), strings cannot be modified or inspected.
  • There is no support for labmdas (anonymous functions). This is a limitation when passing callbacks to builtin functions. You can now either pass in a full command to execute, or a function that gets arguments passed, but there is no way to easily support both.
  • Error messages are often not clear.
  • There are no variables, other than 26 globals with single-character names and read-only, nameless function arguments.
  • It's impossible to represent structured data such as (nested) lists, dictionaries, etc. The only way to allow structure is in function arguments, which cannot be returned or stored.
  • Related to the previous one, reports are a bit messy now. There are a lot of report commands, which both send a report and display it, while you usually just need to do either of those.
  • There is no easy way to manipulate the stack directly. In particular, to call a specific function with some arguments, you have to serialize them into a bitlash commandline, which has to be parsed by bitlash again, while you just want to skip these steps.
@quartzjer
Copy link
Contributor

I'd also say that we're using it well outside of it's designed intent, we want it to be a simple library that we can pass strings into and it parses/acts on them, but it's fundamentally structured to use/expose quite a bit of embedded hardware directly (like serial, pins, etc) and be the main interface.

It also has a built-in process manager and pseudo-filesystem, whereas we're often trying to work around those things and do them ourselves.

@eshanmherath
Copy link

Hello.
Just wanted to update on the "user-defined functions cannot accept strings as arguments "
There is a work around for using string as arguments for user defined functions.

#include <bitlash.h>

void setup() {
  initBitlash(9600); 
  addBitlashFunction("my_function", (bitlash_function) my_function);
}

void loop() {
  delay(2000);
  runBitlash();
  doCommand("my_function(1, 2, \"hello my name is bitlash\")");
}

numvar my_function(void){

 if (isstringarg(3)) {
   String pattern = my_second_function((const char *) getstringarg(3));
   Serial.println(pattern);
 }

return 1;
}

String my_second_function(const char * x){
   return (String)x;
}

Output

 v2.0 (c) 2013 Bill Roy -type HELP- 5648 bytes free
> bitlash here! v2.0 (c) 2013 Bill Roy -type HELP- 5648 bytes free
> hello my name is bitlash
hello my name is bitlash
hello my name is bitlash
hello my name is bitlash
hello my name is bitlash

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants