Mercurial > repo
diff interps/clc-intercal/CLC-INTERCAL-Base-1.-94.-2/MISSING @ 996:859f9b4339e6
<Gregor> tar xf egobot.tar.xz
author | HackBot |
---|---|
date | Sun, 09 Dec 2012 19:30:08 +0000 |
parents | |
children |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/interps/clc-intercal/CLC-INTERCAL-Base-1.-94.-2/MISSING Sun Dec 09 19:30:08 2012 +0000 @@ -0,0 +1,77 @@ +This list applies to all the optional modules one can install for CLC-INTERCAL, +not just to the Base package. It would be better to split this list and have +each item listed in the most relevant package. + +The following files are intended to be in the distribution but have not +been included in this pre-escape: + + IPv6 support in INTERNET library (this has, however, been designed, + and will appear in the documentation in the near future). + Language/INTERCAL.pm (no longer needed, but useful for compatibility) + bin/oo,\ ick (ditto -- use bin/sick) + Language/INTERCAL/Backend/Uncompile.pm - attempt to get INTERCAL source + by any means possible: if the object has some source code, it is + extracted; any compiled code without a source is disassembled. + doc/examples/computed-labels.li (try "(.1) DO .1 <- #1 ... PLEASE COME FROM (1)") + doc/examples/next-from.i (if you never used NEXT FROM do it now!) + doc/examples/quantum/next-from.i + more doc/examples/*.i + some of the test scripts (which will say "Skipped: not implemented" + or words to that effect during "make test"); also, some of the + ones provided could do with more tests + +The following are known bugs: + + using intercalc --line, command completion works but shows a weird list + of possible completion if there is more than one match; this is + because the completion variables described in the readline + documentation don't have the effect described there. + using quantum statements in the calculator can produce unexpected results + events defined in the calculator don't work (of course, they work in sick) + reloading the compiler while using the calculator is fully supported, for + example to switch between 'sick' and 'ick'; however at present changes + made to the compiler before reloading do not correctly propagate to + the reloaded compiler: the correct behaviour is to reapply all changes + to the new compiler, taking into account the fact that the new compiler + may be completely different from the old one. This is not as simple as + it sounds. + +The following functionality is missing: + + The documentation is not currently installed by "make install"; moreover, + there is no Makefile target to install it. + Politesse checking + The user interfaces work with intercalc but are not yet powerful enough + for use with sick. + The optimiser (optimise.iacc is provided, empty, as a placeholder) + Additionally, "iacc.iacc" (and "iacc.io") do not currently provide + syntax to create optimisers (you can, of course, write your own + extensions for that) + Interface-specific configuration in sickrc + The Curses interface requires some sort of scrollbars. It works fine if + the top window fits in the screen, but makes a mess if it doesn't. + In a standard 80x25 terminal this means: oic yes, anything else no. + The X interface also needs some sort of scrollbars, but this is not as + urgent as the problem only appears with a large text window, such as + the trace window after a few commands are traced, or the history + window after a lot of commands. + The compiler could be made to do a lot more work at compile time, leaving + less for the runtime. For example, if a program contains CREATE + statements, it is possible to avoid recompilation at runtime in most + cases, by recompiling the program with the extended grammar but + recording that the new rules introduced are not enabled. See function + find_code in Language::INTERCAL::Object to see why this would work. + Maybe this could be enabled only if optimisation is requested. + Related to the previous point, the compiler compiler just stores the list + of CREATE statements necessary to recreate the compiler when a user + program is compiled. This could be improved by running the code + generated by the compiler compiler and storing the completed grammar. + However this turns out to be a small fraction of the compile time, so + it isn't a priority to do anything about that. + +Patches to implement any of the above will be gratefully received: please +email them to intercal@sdf.lonestar.org, including the word INTERLEAVING in +the subject (or the message may be ignored as spam). Please specify whether +you wish your contribution to remain anonymous, and if not, what name do +you want to be added to the CLC-INTERCAL hall of shame. +