Switch branches/tags
Nothing to show
Find file
Fetching contributors…
Cannot retrieve contributors at this time
124 lines (122 sloc) 6.99 KB
# 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
- 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
"";>. 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
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
- 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
- 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)>.