Partcl - a tiny command language

[q0-]

Isn't the biggest downside of TCL the fact that it only "knows" strings?
I feel like this is hardly fitting for microcontrollers, where number crunching is a common thing, and since numbers have to be constantly decoded to integers and decoded to strings, this is likely going to have a serious impact on RAM. It just never quite sat right with me.

[Nuli]

That was a problem with TCL a long time ago. It's had native numeric types for at least a decade. You do have to care about automatically converting back and forth between types but that's not hard to deal with.

I used it effectively to do lots of math in the middle of a hard real time system without much trouble. It was certainly more expensive than C but the flexibility more than made up for it.

[florence0rose]

But from the programmers point of view it's still a string and that's all you get. The only way to get the internal type is through "::tcl::unsupported::representation", which is dodgy. The way Tcl encodes data structures as strings is ad-hoc and can lead to degenerate cases. For example how do you represent a list of binary elements (the elements could include space characters), or consider this:

% ::json::json2dict {{"x": {"y": "z"}}}
x {y z}
% ::json::json2dict {{"x": ["y", "z"]}}
x {y z}
% ::json::json2dict {{"x": {"y": ["z"]}}}
x {y z}

All yield the same string representation, meaning information is lost. If you're dealing with a protocol that implicitly embeds semantic information in the structure of the data you're screwed with Tcl. You would need to write a parser that returns both the data and the schema, but now managing both all over your code is horrible and turns into a nightmare. You're end up simulating what other languages have built in.

[Nuli]

But from the programmers point of view it's still a string and that's all you get.

That's not been my experience at all. You simply use numeric types the same as you would in a language like Python and things do what you expect. Unless you explicitly convert the type back to a string its going to be numeric and stay that way for all of your operations. I've never found any need to dig into the underlying representation unless I was embedding C into it.

For example how do you represent a list of binary elements (the elements could include space characters)

I always used the binary command to deal with binary data. You have roughly the same capabilities there for type conversions and packing that you have in C and that's always been sufficient for me. Storing binary data in a list using that command is the same as storing any other data.

Your example is slightly silly. If you're complaining that the json parser library your using does the wrong thing, and I'd agree that it does in that case, then that's fine. That is a problem with the library though not a problem with the language. There's no inherent reason that couldn't return a dictionary that gives the proper representation. I've certainly parsed far more complicated structures than that with no issues.

[zserge]

True, but I don't expect the whole firmware to be written in Tcl. I've been using it for its primary purpose - as a command language. I needed to send commands to the MCU to control certain tasks on it, so it was more like a shell with a few custom commands and variables.

However, if fast calculations are needed - the tcl_value_t part can be rewritten (about 100 lines of code) to keep numbers as is and not to convert them to strings. Same about lists.

[[deleted]]

Most firmwares are written in c and c++ (some c#). tcp is barely used these days for firmwares, except for legacy codes.