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.
+