Hawk / Ftwalk Wish List

This list is old (vintage 1.4, i.e. 1999, like last century), with minor cleanup.

Table of Contents

• Package Ftwalk interpreter into library for embedded use in other programs. Need finer control over inclusion/exclusion of built-in functions. May need to isolate yacc parser so as not to conflict with other parsers.

• Perl-like tainting for more secure scripts.

  Break all Ftwalk error messages out into a message catalog. (Should we use X/OPEN or own message catalogs? Probably the latter.)

• A mechanism (possibly an enhancement of executable or preface files) to hide normal Ftwalk command line options and permit programs to use normal getopt(3) command line processing.

• Some method to dump and load compiled code and/or symbol table definitions. (This leads to a number of interesting ideas, from a speed-up of normal run-time startup to building compact setuid binary programs that load the interpreter machinery as a DSO to networked Ftwalk's that pass binary code around like stored procedures. Not that we have any interest in wrestling with Java.)

• Some form of operator to complement in. Easiest would be something like not_in. Harder but perhaps more interesting would be something like not in or !in.

• Make delete an operator returning void (not a statement).

• Qualifiers to variable/parameter definitions (in static, auto, and function), which would be specified in parentheses before the expected variable/parameter name. Qualifiers provide run-time checks on assignment. In particular:

  const

  Once initialized variable is constant (cannot assign to).

  type name

  Limits variable to values of specified type name.

  functor ...

  Limits variable to values that functor evaluates to true.

  match-op ( expr )

  Limits variable to values that satisfy operator expression (where match-op is: ==, !=, >, >=, <, <=, ~, !~, in). This could be extended to allow compound expressions like case.

  >> ( expr )

  Provides a string conversion format to use for output instead of the default conversion for the data type.

  Qualifier violations would result in run-time errors (exceptions).

• A nextfile operator, like gawk, to terminate processing of current command line argument, moving on to the next one. BEGIN_FILE and END_FILE events would also be useful.

• General syntax for handling exceptions (modelled on Java):

      try                 { statements }
      catch ( exception ) { statements }
     [catch ( exception ) { statements }]
      finally             { statements }

  The try block defines a block of code to try to execute. If any exception occurs during its exception, a corresponding catch block is executed or, if none is defined, the exception is raised to the caller and ultimately caught by a default handler. The finally block is executed to clean up if any part of the try block is executed. Lower code could also explicitly throw an exception. Exceptions would be a new data type, with an identifier, optional values, and context information.

• The TRAP event provides a simpler global method for trapping exceptions.

• A number of run-time conditions should generate exceptions (but very few do at present). Primo examples include: assignment to non-lvalue objects; call of non-function/functor; undefined type operations; eval compilation errors; data-dependent errors (index out of bounds, divide by zero, etc.). Some run-time errors should only be thrown if there is a trap; others should always be thrown. The list, obviously, needs work.

• Directives to enable/disable use of optional namespaces:

      #namespace [identifier ...]
      #using namespace [identifier]

  #namespace specifies that all new unqualified symbols belong to the specified namespace (or global namespace if none specified). #using specifies that a namespace be used for possible lookup of unqualified symbols ahead of the global namespace (possibly limited to an explicit list of symbols).

• Top-level syntax to define new directives: basically a Ftwalk function which is invoked when a non-built-in directive is scanned. The scan would break arguments on whitespace, with each argument available as a named parameter. #pragma identifiers could be also be defined. For example:

      directive [pragma] identifier ( ... ) {
          statements
      }

• Interfaces for user-defined directives to #divert and conditional compilation controls.

• Option to file search to handle files in sorted order.

• Change to current typeof type classification scheme to define types hierarchically by a series of colon-separated names, with partial matches. (The matches could be limited to using a new instanceof operator, such as Java has.) This would replace the current two-level scheme.

• New method to assign an arbitrary typeof identifier to any data type.

• A wide string class consisting of C wchar_t: wstring.

• Replace regexp(3) library dependency with own implementation of regular expressions, which would provide support for alternation. Should also support X/OPEN internationalization, and possibly some Perl features.

• Ability to attach a sort vector to a map. Possible sort methods might include: insertion order, update order, key comparison order, key collation order, value comparison order, value collation order, user-specified functor.

• Support for sub-second date/time resolutions (e.g., gettimeofday, timeval for file stats, usleep. These would generally be done transparently under current calls, converting where applicable to floating-point seconds.

• New date/time literal input conversion, which would generate intervals for ambiguous values above some threshold (seconds or minutes?). For example, T"Feb. 1992" would define an interval from 00:00:00 Feb. 1, 1992 through 23:59:59 Feb. 28, 1992. (How should subtraction of date/time intervals behave? Probably by subtracting the low bounds.)

• Options to glob: $all returns all filenames; $hide hides normally hidden filenames; $sort returns filenames in sorted order.

• Options to backup to provide support for compressed and/or version-controlled backup files (time-synched but different sizes).

• New restore to reverse backup, with checks for overwriting more recent files (options: $force; $interactive, with optional functor).

• Conversion formats for scanf to match on regular expressions, character sets, balanced quote definitions. (The latter should be able to match balanced parentheses with various types of quoting and/or ignored comments.)

• New functions to deal with SVR4 security functions (acl, filepriv, procpriv, etc.).

• Need to make some general attempt at specifying a long-term viable extension API. The present <ftwcall.h> is woefully inadequate, which people can now avoid by working directly against the full source code header files. However, the latter are subject to change.

• Data types to map to native C variable types, so that native C variables could be directly accessed/assigned from Ftwalk. Why not go "whole hog" and do struct, union, and pointers as well?

• A method for attaching C variable type declarations to shared memory segments and mmap files.

• A method for declaring external C/C++ functions and for calling them from Ftwalk without implementing explicit wrappers.

• Functions for mangling and de-mangling C++ function names.

• A TK library interface, for development of X-Windows applications.

• A gdbm interface, similar to the current ndbm interface.

• An interface to the gzip data compression routines.

• A CGI library.

• A URL data type.

• A module for determining file types like file(1), possibly with an optional database that could be used instead of re-reading the file each time.

• Input generators for reading tar and cpio archives.

• Input generators for deciphering various languages (e.g., C, C++, SGML).

• Read in a user-specific preferences file at startup.

• Add monitor commands for debugging (breakpoints, tracing).

• Add support for vi editor keys (possibly make editor mode programmable, with adequate support for all desired configurations).

• Preprocess help file to handle platform-variant help information.

• Build a TK-based on-line help viewer (front end to fthelp). This would support multiple windows, could support script editing and management, interface to interactive monitor, and man pages.