Help File
Wish List


Hosted by:
  VA Linux


Hawk / Ftwalk Wish List

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

Table of Contents

  • Program Structure/Packaging
  • Language
  • Exceptions
  • Directives
  • Input Generators
  • Data Types
  • Built-In Functions
  • C/C++ Interface
  • Extensions
  • Interactive Monitor
  • On-Line Help
  • Program Structure/Packaging

    • 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:

      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 ( ... ) {
    • Interfaces for user-defined directives to #divert and conditional compilation controls.

    Input Generators

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

    Data Types

    • 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.)

    Built-In Functions

    • 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.).

    C/C++ Interface

    • 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).

    Interactive Monitor

    • 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).

    On-Line Help

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