On 09/20/11 17:57, Steve Bennett wrote:
I agree that if your are going to integrate some language with fossil then Jim
Tcl is nearly an ideal fit. It is small, modular, self contained, can replace
TH1 easily and should be licence compatible.
But... let's see a design proposal, or at least a prototype implementation. I
think that understanding some core use cases and designing a good API is
important.
Regarding someone's concern over Tcl vs Jim Tcl differences - yes there are
differences, but in practice they are unlikely to be a problem. Take a look at
the online doc http://repo.or.cz/w/jimtcl.git/blob_plain/HEAD:/Tcl_shipped.html
I did. That's not enough to make an informed decision though as to:
- which tcl code will run unaltered on jim?
- -"- with the tclcompat package loaded?
both of which are critical questions IMO.
E.g.:
"5. Builtin dictionary type (dict) with some limitations compared to Tcl 8.6 "
Yes thank you, but WHICH limitations?
Then you follow the link, and see a couple of subcommands, and most
importantly, a couple of them missing when comparing to Tcl 8.6. That's not
"some limitations", that's "some commands are not implemented/supported at
all". There's no dict with; there's no dict for; no dict remove; no dict
replace; no ... the list goes on. What about tcl code that uses these
subcommands? will the tclcompat package bring in the missing dict subcommands?
Will the tcl code have to be rewritten? In practice, with not supporting "dict
with", about 90% of the tcl code I've written in the past five years would NOT
run unaltered on jim, thus being very likely to be a problem in practice.
As I've written earlier, I'd really like to see a list of all the commands and
subcommands of tcl on one side, and all of the commands and subcommands of jim
on the other side, and an indicator whether a) jim does not support given
command and/or subcommand, b) jim supports it but with differences, c) jim
supports it and it behaves idempotent to the tcl command/subcommand, d) a) or
b) is the case but by loading package x it becomes c). Without this
information IMO it is impossible to do an informed choice on whether to use
jim or tcl.
If I wanted to come up with a design proposal (and I do want), the only choice
I have is basically scavenge all unit tests of tcl and run them on jim, and
say "c)" for each failure. And then compare the parts which aren't covered by
that. I.e., a LOT of manual work. It sucks. Sigh.
Regards,
-Martin
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
