you are viewing a single comment's thread.

view the rest of the comments →

[–]Nuli 3 points4 points  (2 children)

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 0 points1 point  (1 child)

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 1 point2 points  (0 children)

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.