'''What is the scope of this page''' This page is used to coordinate development of [Jim]. In order to avoid duplication of work, this is a list of the core commands/features that are actually missing (both already implemented in Tcl or new). Please if you plan to contribute one command write a short note about it: ---- '''COMMANDS AVAILABLE IN TCL''' ---- '''lsearch''' same logic of lsort I guess, few options like -nocase and -glob, all the rest is obtained via -command. Important: at the cost of less compatibility I don't want to introduce in lsearch the Tcl error of use -glob for default. In Jim's lsort -exact should be the default (but may be possible to specify -exact). Many Tcl scripts are broken because the programmer just user [[lsearch $x $y]] when he *mean* -exact, and of course the script will fail with "*" and other glob-special chars. assigned to: [Salvatore Sanfilippo] '''package''' Our package will be a bit different, I've some plan about how to implement it. As usually, semplicity should be our muse :) what I may like is that [[package require foobar]] will search in every path specified into $lib.libpath global var (that already exists for [[load]]) for files matching the name: jim-foobar.tcl or jim-foobar.[[so/dll]], in this order. I.e. what I want to avoid is to have to run something that generates a package index ala-Tcl. The problem is, how to deal with versions? One may require [[package require foobar 1.0]], or 2.0 and so on. How Jim version numbers should work? (both core and extensions). We thing that a form like Major.Minor is enough. Simply: Major changes only when the interface is no longer compatible with past versions, Minor is instead incremented at every new release. Given that, the package version can be put directly in the file name, so that package require can [[glob]] about jim-foobar-*.tcl and check all the versions available (the same for .dll/.so). The other approach is that package require sets a variable or an information inside the interp structure about the package we need to load, and the [[package provide]] (or equivalent C-level call for extensions) will just fail and avoid the package is loaded if the version does not match what the user is asking for. assigned to: [Salvatore Sanfilippo] '''source''' This is simple enough to implement, given that we have the Jim_EvalFile() that will care to set the filename info in order to make Jim able to assoicate filename/linenumbers in the encoded program representation to output absolute file/line errors. What there is to check is if evalfile returns with something like JIM_BREAK that has a special meaning for [[source]] (no error, but just the program is stopped from being sourced). IMHO it's not a good idea to put this logic inside EvalFile itself, it can be useful to evaluate a file and be able to get all the exceptions if need. If who implement [[source]] will like to have a very clean design it's always possible to implement Jim_Source() that does this for us, but seems like an overkill to me. assigned to: ? '''string''' The most important bits of the string command are already implemented, but there is some missing stuff like toupper, tolower, .... assigend to: [Salvatore Sanfilippo] '''clock''' I think the way to go with [[clock]] is to create a "clock" or "time" extension. assigned to: ? '''array''' This command should not be too hard to implement. It basically fakes the real [[array]] command features via dicts. I.e. it's just a compatibility command. Jim does not have any need of this command so it's mainly a compatibility problem. assigned to: ? '''dict''' there are things that are to be completed in Jim's [dict], expecially [[dicth with]]. Probably we'll not implement incr,for,... subcommands. assigned to: [Salvatore Sanfilippo] '''struct''' This command will substute the Tcl's [binary] command. This is more or less how it should work: struct get { version uint4n hdrlen uint4 tos uint8 totlen uint16 id uint16 flags uint3 fragoff uint13 srcaddr 4 uint8 dstaddr uint32 rest * } $binary struct set { } ... ... struct get returns a dictionary, accordingly to the given structure. it's possible to specifiy a variable name, followed by a type specifier or by a number of elements + a type specifier (being the type specifier non numerical this is always determined). The special type * means "all the rest". Struct set should work in a similar way, with exactly the same structure. so that it's possible for example to use struct get, modify some field because what we get is a dictionary, then use struct set to write the modified version of the binary data. assigned to: [Salvatore Sanfilippo] '''scan''' The Tcl scan command. assigned to: [Clemens Hintze] '''format''' The Tcl format command assigned to: [Clemens Hintze] and [Salvatore Sanfilippo] ---- '''JIM COMMANDS NOT AVAILABLE IN TCL''' ---- '''onleave''' This commands accumulate scripts to execute just before the current procedure is returning to the caller. Every new time '''onleave''' is called a script is accumulated. This scripts are executed in reverse order. If the command is called with an empty string as argument the current scritps list is cleared. If the command is called without arguments the current list of scripts registered is returned. assigned to: [Salvatore Sanfilippo] '''try/catch/else/finally''' That's a bit hard, this requires design, but I really I'm tired to use [catch] every time I need something of more simple to write. Note catch classical usage: if {[cath {error bau}]} { puts "something is burning around here" } all this {[ { }}}{}{}} are ok for an arabic decoration I guess :) Compare with: try { error bau } catch { puts "something is burning around here" } I'm *not* sure that try/catch/else/finally is what we really want, i.e. it's very complex as semantic. Maybe we can do with something a bit simpler that does not have three optional keywords? '''tail''' This should support tail recursion. For now just a plan. ---- '''JIM OOP SYSTEM''' ---- Design in progress, it may resemble the [Odys object system], but I've many changes in mind. The name will be obviously '''Josh''', Jim Object System H?. What you expected from the guy that called the language [Jim]? ---- '''JIM NAMESPACES''' ---- The will be for sure very different of Tcl's namespaces, i.e. designed to just resolve names collisions. Only one level of nesting. the dot as separator like in win32.beep. Ideally Jim namespaces should be similar in the semplicity of the concept to [C]'s ''static'' qualifier.