Skip to content

Bitlash limitations #211

@matthijskooijman

Description

@matthijskooijman

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions