additional features

[schaefer01]

It would be nice if the equals sign, or other operators could be identified as tokens, the problem would be that there might be no space character, 1+2 would be one token compared to 1 + 2, which would be 3 tokens. If you did this, too, the argument list could not be edited on top of itself during the tokenizing process because the tokens would end up longer than the input string, destroying the input string before tokenizing completes.

Just an idea, I'm going down this path using your code as a starting point. Please let me know what you think,

[funbiscuit]

I'm not sure I understand how this can fit into whole command and arguments concept nicely. Always treating + or = as a separate token seems like only a partial feature which is not useful on its own. While target feature is introducing some kind of expression language. My idea of this library is keeping it minimal while being useful. Adding support for expression language inside a lib for now seems out of scope.

I can give some suggestions maybe they will help so you don't need to edit internals of lib and keep your changes separate.

1. You can disable tokenization completely for a binding and then you'll be given full args string without any modifications. So you can run your on logic on it.
2. If you always need to keep 1+2 as one token you can qoute it: "1+2" and "1 + 2" will always end up as single token.

[schaefer01]

Hi, Sviatoslav,

I’ve created a scripting language for a limited memory embedded device and my item-by-item parser works but is messy, your cli goes part way towards me cleaning up my code. I still need to extract mathematical operators and convert numbers-as-strings to numbers-as-values.

I need 1+2 to be recognized as 3 tokens, and I need a lex but not a full blown lex.

I was thinking of taking your tool to the next level where mathematical operators are recognized as tokens, and then another pass to separate strings as labels from strings as numbers.

You know a tool is good when it can go beyond the imagined uses defined by the tool-maker.

bob s.

On Aug 9, 2022, at 1:51 PM, Sviatoslav Kokurin @.@.>> wrote:

I'm not sure I understand how this can fit into whole command and arguments concept nicely. Always treating + or = as a separate token seems like only a partial feature which is not useful on its own. While target feature is introducing some kind of expression language. My idea of this library is keeping it minimal while being useful. Adding support for expression language inside a lib for now seems out of scope.

I can give some suggestions maybe they will help so you don't need to edit internals of lib and keep your changes separate.

1. You can disable tokenization completely for a binding and then you'll be given full args string without any modifications. So you can run your on logic on it.
2. If you always need to keep 1+2 as one token you can qoute it: "1+2" and "1 + 2" will always end up as single token.

— Reply to this email directly, view it on GitHubhttps://github.com/funbiscuit/embedded-cli/issues/11#issuecomment-1209691777, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AMS2KEKA4O4YM2LI7O62VTLVYKLAVANCNFSM56BIBITQ. You are receiving this because you authored the thread.Message ID: @.***>

[funbiscuit]

Ok, I think I see what you want. For now I don't think it's possible in current version of lib. But I plan in some future to make it more modular, maybe then some kind of scripting may seem relevant as a separate optional module/feature. I don't want everyone to be dependent on this since it will add memory footprint and probably won't be removed by compiler.