On 21/09/2011, at 8:06 AM, "Martin S. Weber" <martin.we...@nist.gov> wrote:
> 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. The simple answer is, No, you will not be able run (any) Tcl code unaltered. If that is what you want, you have no choice but to use full Tcl. It may not be unreasonable to allow an arbitrary language binding to fossil. Python anyone? But I think the proposal here is to have a full scripting language built in to fossil. This is a different proposition. Lua is another reasonable alternative here, and that won't run *any* of your existing Tcl scripts. > > 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. I understand, but this is not trivial since there are some subtle differences which go beyond commands existing or not. But in general, if it isn't in the manual, it doesn't exist. dict for, dict replace, etc. > > 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. I don't think the design proposal needs to care too much about the language features. It is the interface to fossil which is important. Cheers, Steve > > Regards, > -Martin > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
