mavangnIS

# vim:set ai sw=2 et tw=72 fo+=t2c com=fb\:-:
Things we have to do, or items to consider.

- yInargh 'last' and nargh 'quotemeta' possibly clash.
- yInargh 'last', yItaH 'next', yInIDqa' 'redo' on the one hand clash
  with jaH 'goto' on the other hand (which has no 'yI').
  Also, the 'go' verbs take a $sing in front of them, so currently even
  'yIyItaH' would be legal. This seems nonsense to me.
  Either make them all take a mandatory 'yI-' (including, then, yIjaH),
  or make 'yI-' optional on all of them, so %v_go contains only the keys
  qw/jaH nargh taH nIDqa'/. (Modulo possible clash on nargh
  'quotemeta'.)
- We can't goto anywhere since we can't do labels yet.
- Variables can't contain colons or underscores, since the rule for
  arbitrary variables uses EOW and that checks for [^a-zA-Z']. Which is
  fine for Klingon names, but sometimes you have to call subroutines or
  access variables in other packages which contain underscores (for the
  variable/subroutine name itself) or colons (for accessing the package
  containing the variable/subroutine). Proposed solution: EOW should
  probably be changed to accept ':' and '_' as well.
  Or do it like Lingua::Romana::Perligata and have special keywords for
  '::'.
- Match and search operations can't specify options (egimosx).
  This can be partially compensated by adding an (?egimosx:) inside the
  regular expression "line noise", but we might wish to consider
  allowing the user to specify the options somehow. Not sure whether to
  do so with a string ("egimosx"), a list ("e", "g", "i"), or through
  Klingon words.
  We could also decide always to set certain options (such as /x), but
  I'm not sure this is desirable.
- We can't call time() (or localtime, gmtime).
  This should probably be fixed.
- arg1 always pops the stack, even for obligatorily 0-arg functions.
  This should be fixed.
- We probably can't support both C<eof> and C<eof()> -- 0-arg functions
  will either have trailing parentheses or not, and 01-arg functions
  (that take one optional arg, which is probably where C<eof> belongs)
  will presumably always have parentheses.
  Unless we say that 0-arg functions do not have trailing parentheses
  (this is what -MO=Deparse,-p thinks, too) and invent a special alias
  for 0-arg C<eof>.
- split is classified as a 1-arg function??? Check whether this does the
  right thing.
- Check whether we can handle both C<require Pack::age;> and C<require
  "library.pl";>. Oh, and C<require 5.005_03;>.
- require "version" and require BAREWORD seem to be intended to be
  parsed in two different ways, but I don't think it works like that.
  Either split them up into two separate commands or unify the parsing
  (or something).
- Possibly handle subroutine prototypes -- perhaps via an optional 'acc'
  token after the 'block' token, a la C<< { ... } <$\@> name nab >>.
- Possibly do globs, perhaps with {-Du'}, the third plural suffix?
  (Internal rationale: a glob is like a body with various parts -
  scalar, array, hash, filehandle, etc. -, so it can take the body-part
  plural suffix.)
- Consider doing something about unary + -- at least have a HUH command
  for it.
- For debugging: translate as we go along, rather than in one fell swoop
  at the end of compilation. (This will also help catch syntax errors or
  other compilation mistakes, which otherwise simply abort the
  compilation, without our being able to figure out what, exactly, the
  problem was, since it's difficult to see how far the compiler got
  already.)
  We'll have to decide whether we translate at the end of each
  statement, or only when we get back to the top level (E.g. after a
  subroutine declaration.
  At the end of each statement is probably better for debugging. So this
  probably only involves adding a check and an output to done().
- I think we can't currently declare a variable and assign to it in one
  step; things such as {varwIjvaD <bla> nob!} don't work and have to be
  written {varwIj! varvaD <bla> nob!}.
  --> this may work as C<varwIj <bla> nob!> since variable declarations
  result in a 'dat' token. I still think that an optional C<-vaD> should
  at least be accepted.
- Need to test objects ('e'), especially in connection with calling
  methods on them ({a b c} turning into {a->c(b)} rather than {c(a, b)})
- Test noun conjunctions (conj_h, noun_conj)... there is some rather
  strange code there. See whether it's still needed; if so, test it, if
  not, dike it out. (I'm guessing it's a remnant from a translation from
  Lingua::Romana::Perligata's -que etc.)
- Are eval "string" and eval {BLOCK} both supported?
  --> apparently, yes -- they're in both the 1-arg command list and the
  blockop list! This should be remedied.
- What about C<grep EXPR, LIST> vs. C<grep {BLOCK} LIST> (and map)?
- I don't think we handle the file test operators ("-f" and friends)
  yet. Consider whether to add them.
- "wait" is in the list of 1-optional-arg commands, but it takes no args
  at all (you can't tell it what PID to wait for). Move it to the list
  of 0-arg commands.
- We have a command for 'link' but none for 'symlink'. Consider adding
  one.
- bless, chmod, chown, and index are all considered 2-arg functions.
  However bless's second argument (the package to bless the reference
  into) is technically optional; chmod/chown take a LIST of arguments
  (one mode plus 1..n filenames or - possibly - filehandles); and index
  can take a third argument (the position to search from). None of this
  is currently supported; some or all of this should, perhaps, be.
- Go over the command names; some of them could possibly stand to be
  altered (for example, by adding the causative -moH suffix) to be more
  "Klingon-like".
- DIch / Suq can also handle references to arrays or hashes. Test that.
- Can we handle @{ ... } / ${ ... } / %{ ... }?
- Do Klingon mathematics as revealed in HolQeD (boq & boq'egh for
  addition and multiplication, etc.). Doing this properly will entail
  supporting the number suffix -logh, IIRC. Note that C<logh> is already
  in use for C<x> (string repetition).
- Consider supporting C<exec PROGRAM LIST> somehow.
- to_args doesn't seem to handle functions that can take 0 parameters
  (for example, reverse() can take 0..n parameters).
  Perhaps we should also treat differently functions that "need" at
  least one parameter (exec), at least two (pack, kill, join), and at
  least 0 (reverse, split, return, die, warn).
  Note: die & warn & carp & croak are already in the list of 0/1-arg
  functions! They should probably be moved out of there since they can
  all take lists, not just a single error message string (though that's
  likely to be the most common way they're called); this makes them
  normal 0..n-arg functions.
- Maybe we should also separate the functions that take a handle as
  first parameter (print, open, seek) from those that take a dative
  argument as first parameter (substr, splice, tie, unshift).
- Consider supporting postfix controls (if unless while until foreach).
- Check whether both C<for(;;)> and C<foreach(LIST)> are supported.
  Ideally, also support C<foreach VAR (LIST)>.