On 09/20/11 19:20, Steve Bennett wrote:
The simple answer is, No, you will not be able run (any) Tcl code unaltered.
Thanks for that info.
It may not be unreasonable to allow an arbitrary language binding to fossil.
Indeed. I've been looking into jim / tcl mostly because of Th1. j/t are a
superset of Th1 - the logical alternatives (python, ruby, lua, forth, guile,
...) aren't.
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.
Exactly that's why I'd expect the implementors of jim to document that as they
go along implementing it. They are the ones who know best about the compatibility.
I don't think the design proposal needs to care too much about the language
features.
Hmm, somewhat. If there will be language bindings, there will be a first one,
perceived as the default. Choosing that first one (and/or the one that fossil
uses on its own fossil) is tricky. But that's step #2 ...
It is the interface to fossil which is important.
Yep. That's where step #1 comes in - librarization of fossil. Luckily I'll
have time for that (at least rounding up an API suggestion) next week.
-Martin
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
