NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/database/informix/3042

Internet Message Format | 1993-01-24 | 49.1 KB

Path: sparky!uunet!gatech!emory!emory!not-for-mail
From: obelix.informix.com![e-mail] (Jonathan Leffler)
Newsgroups: comp.databases.informix
Subject: I4GL Modifications: Part 2 of 3
Date: 23 Jan 1993 23:28:05 -0500
Organization: Mailing List Gateway
Lines: 1052
Sender: [e-mail]
Distribution: world
Message-ID: <[e-mail]>
Reply-To: obelix.informix.com![e-mail] (Jonathan Leffler)
NNTP-Posting-Host: emory.mathcs.emory.edu
X-Informix-List-ID: <list.1814>

#!/bin/sh
# this is part 2 of a multipart archive
# do not concatenate these parts, unpack them in order with /bin/sh
# file i4glmods continued
#
CurArch=2
if test ! -r s2_seq_.tmp
then echo "Please unpack part 1 first!"
     exit 1; fi
( read Scheck
  if test "$Scheck" != $CurArch
  then echo "Please unpack part $Scheck next!"
       exit 1;
  else exit 0; fi
) < s2_seq_.tmp || exit 1
echo "x - Continuing file i4glmods"
sed 's/^X//' << 'SHAR_EOF' >> i4glmods
X    containing problem records which are apparently out of sequence.  The
X    program name has been placed on the second line, and so has the
X    function name where the error occurred.
X
XDate: 1993-01-21 15:57:41 GMT  User: johnl     TTY: /dev/console  PID:  3129
XProgram: rrr.4go  Error at "rrr.4gl", line number 7 in function "main".
XFORMS statement error number -1110.
XForm file not found
X
X    I4GL-L23 was rated in class B because it is easy to fix.
X
XI4GL-L24:
X    It would be useful to have a bottom tested loop:
X
X        REPEAT
X            <statements>
X        UNTIL <condition>
X
X    Even C, a minimalist language, provides a bottom tested loop, because
X    there are times when the algorithm requires the loop body to be
X    executed once.
X
X    I4GL-L24 was rated in class B because it should be easy to implement.
X
XI4GL-L25:
X    Because I4GL isn't like C, it is relatively difficult to write out a
X    FOREACH loop which needs a USING clause cleanly.  I4GL-S01 fixes that,
X    but there are other places where a N-plus-a-half iteration loop would
X    be useful.  The loop mght look like:
X
X            DO
X                FETCH c_cursor INTO varlist.*
X            WHILE STATUS = 0
X                OUTPUT TO REPORT r_report(varlist.*)
X            END DO
X
X    If we adding loops to I4GL, then maybe an UNTIL/END UNTIL loop
X    and a DO/UNTIL/END DO loop are both appropriate too.
X
X    I4GL-L25 was rated in class C because it is not provided by any other
X    language (though Ada and PL/I get close).
X
XI4GL-L26:
X    The underlying representation of DATE variables is an integer type, but
X    you cannot loop over the days between two dates unless you use a
X    circumlocution like the code below.  I4GL should allow the use of a
X    DATE variable as the index of a FOR loop.
X
X    MAIN
X
X        DEFINE
X            d, d1, d2   DATE,
X            i, j, k     INTEGER
X
X        LET d1 = MDY(01, 01, 1993)
X        LET d2 = MDY(01, 31, 1993)
X
X        LET i = d1
X        LET j = d2
X        FOR k = i TO j
X            LET d = DATE(k)
X            DISPLAY "Date: ", d USING "ddd dd mmm yyyy" AT 3, 1
X            SLEEP 1
X        END FOR
X
X    END MAIN
X
X    Incidentally, it would be useful if there was an explicit coercion
X    function called INTEGER to coerce a DATE into an INTEGER.  The
X    statement: LET j = INTEGER(d2) is clearer documentation of the fact
X    that something slightly peculiar is going on.
X
X    I4GL-L26 was rated in class A because it is should be easy to fix.
X
XI4GL-L27:
X    The mapping of function keys to purposes needs to be less direct.  This
X    is so that when the customer decides that the help key should no longer
X    be the key labelled HELP but the key labelled F1, the mapping can be
X    done in software, preferably without either recompiling the software or
X    rewriting the termcap/terminfo entry so it is a bundle of fibs.  If
X    recompilation is forced on us, at least using a bunch of macro names
X    such as KEY_HELP, KEY_ACCEPT, KEY_QUIT, etc. allows the mapping to be
X    altered by simply changing the central header file which defines these
X    mappings (I4GL-L16).  Then, of course, the vastly upgraded programmers
X    environment (I4GL-T05) can be told to recompile all the software
X    affected by the change, and at least everything is consistent.  If the
X    source would have to be edited instead, then it becomes simpler to lie
X    through your teeth by rewriting the termcap entry so that the key
X    defined as k0 (F1 in I4GL parlance, F10 anywhere else) is deemed to
X    produce the sequence associated the key labelled F6 because the help
X    key in the source code was assumed to be F1 (and the source is
X    unchanged) but the users now hit the key labelled F6 instead.
X
X    I4GL-L27 was rated in class C because it is can be largely fixed by
X    other requests, such as I4GL-L28, I4GL-L16.
X
XI4GL-L28:
X    Cursors, windows, forms, colour attributes, key names, field names
X    should all be treated as proper variables.  This would simplify many
X    operations.  For example, one of the systems I was working on recently
X    had a requirement for a screen array where the entries in the screen
X    array needed to be of different lengths depending on the amount of
X    information to be shown for the entry.  It is not sensible to try
X    upgrading INPUT ARRAY to handle that, but an ARRAY[8] OF WINDOW would
X    have simplified a lot of coding, as would the ability to use DISPLAY
X    Forty_odd_fields.* TO s_record.* ATTRIBUTE(attr_var) where attr_var was
X    a colour attribute variable holding either REVERSE or NORMAL.  Maybe
X    the forms weren't designed correctly (and, once more, time was of the
X    essence), but using the 4.10 OPTIONS DISPLAY ATTRIBUTE (NORMAL) didn't
X    do what was required, which was to override the colours in the form.
X
X    This change is fundamental to a number of the changes in the sections on
X    handling forms, windows, INPUT, DISPLAY ARRAY and INPUT ARRAY.
X
X    I4GL-L28 was rated in class C because it is important but difficult to
X    do properly.
X
XI4GL-L29:
X    There should be a mechanism which allows a user to define symbolic
X    constants.  This can either be provided by the preprocessor facility
X    (I4GL-L16) or by a constant declaration.  Either way, it is crucial
X    that the constant value can be computed from other constants if need
X    be, so that two arrays can declared, one with size N and the other with
X    size 2*N, and when N changes, only that constant definition has to be
X    altered.  Bear in mind that the constants may be defined in different
X    source files, using a common header file which contains the definition
X    of N.  If computed constants cannot be handled in declarations, then
X    the preprocessor must provide a mechanism to evaluate an expression on
X    demand (as in the M4 macro processor).
X
X    With the ability to pass arrays around (I4GL-L03), it would be helpful
X    if I4GL provided a function such as dimensionof() to determine the
X    number of elements in an array.  If generic sorting routines (analogous
X    to qsort(3) are to be written, then it is necessary to have a function
X    analogous to sizeof(), and offsetof() might not go amiss while were at
X    it.  These would be of little direct relevance to the I4GL programmer,
X    but would make the interface to C routines simpler in certain contexts.
X
X    I4GL-L29 was rated in class A because the constant facility would simplify
X    the maintenance of programs immensely.  The xxxxof() routines are less
X    critical.
X
XI4GL-L30:
X    A suggestion tacked onto the end of someone's e-mail message said that
X    I4GL should provide full object-orientated support.  Some of what this
X    would imply have been discussed alread (notably in I4GL-L05), but
X    allowing for C++ classes and inheritance (multiple inheritance) and so
X    on would need most of the features discussed so far and a good few
X    extras not discussed.  However, it would be better to get the basic 3GL
X    features sorted out before trying to create I4GL++.
X
X    I4GL-L30 was rated in class B because it is likely to very important in
X    the future, whether or not you also get nice things like a GUI
X    interface.
X
XI4GL-L31:
X    In ANSI C, the strings written as "ABC" "DEF" are treated as if they
X    had been written "ABCDEF".  When the strings are that short, there is
X    little advantage to it, but if you look at the sample code below, you
X    will see how it makes writing complex SELECT statements as literal
X    strings for PREPARE much easier, and avoid having to define a variable
X    simply to concatenate some constant strings together before handing
X    them off to a PREPARE statement.  It would also avoid the problems with
X    the defined variable turning out to be too short for the concatenated
X    string.
X
X    Old style:
X        DEFINE
X            brain_damaged   CHAR(256)
X        LET brain_damaged =
X                "SELECT T1.Col01 Column1, T1.Col03 Column2,",
X                " T2.Col19 Column3, T2.Col05 Column4, T2.Col01 Column5",
X                " FROM TableA T1, TableB T2",
X                " WHERE T1.Col02 = T2.Col04",
X                " ORDER BY Column1, Column2, Column5"
X        PREPARE p_stmt FROM brain_damaged
X        DECLARE c_stmt CURSOR FOR p_stmt
X
X    New style:
X        PREPARE p_stmt FROM
X                "SELECT T1.Col01 Column1, T1.Col03 Column2,"
X                " T2.Col19 Column3, T2.Col05 Column4, T2.Col01 Column5"
X                " FROM TableA T1, TableB T2"
X                " WHERE T1.Col02 = T2.Col04"
X                " ORDER BY Column1, Column2, Column5"
X        DECLARE c_stmt CURSOR FOR p_stmt
X
X    I4GL-L31 was rated in class A because it should be easy to implement.
X
XI4GL-L32:
X    In general, languages should allow defaults to be declared explicitly
X    as well as implicitly.  Even C does this -- you can declare an auto
X    variable, even though no-one ever does.  This modification affects lots
X    of things, but generally only in minor ways, such as:
X
X    OnLine should allow you to say:
X        CREATE DATABASE xxx WITH UNBUFFERED LOG;
X        CREATE DATABASE xxx WITH BUFFERED LOG;
X
X    Reports should allow you to say:
X        ORDER INTERNAL BY var1, var2
X        ORDER EXTERNAL BY var1, var2
X
X    Windows should allow you to say:
X        OPEN WINDOW w_window AT 2, 2 WITH 4 ROWS, 40 COLUMNS
X            ATTRIBUTE(NO BORDER)
X        OPEN WINDOW w_window AT 2, 2 WITH 4 ROWS, 40 COLUMNS
X            ATTRIBUTE(BORDER)
X
X    INPUT and INPUT ARRAY should allow you to say:
X        INPUT varlist BY NAME WITHOUT DEFAULTS
X        INPUT varlist BY NAME WITH DEFAULTS
X
X    I4GL-L32 was rated in class B because it involves a lot of changes and
X    therefore isn't necessarily all that easy to implement.
X
XI4GL-L33:
X    It would be useful if I4GL provided an ELSIF (or ELIF, but not ELSEIF
X    because that could too easily be confused with a nested IF statement in
X    an ELSE clause) option to allow a sequence of tests to be coded as IF
X    statements, instead of having to continually convert IF/ELSE into
X    CASE/WHEN.
X
X        IF <condition> THEN <stmts>
X      [ ELSIF <condition> THEN <stmts> ...  ]
X      [ ELSE <stmts> ]
X        END IF
X
X    I4GL-L33 was rated in class A because it should be simple to do.
X
XI4GL-L34:
X    The USING clause is good for dealing with numbers which are not too
X    large or too small (eg money quantities).  Sometimes the numbers are
X    much bigger and there is no mechanism to control the format of decimal
X    number (or float or smallfloat or money) when the value should be
X    printed in exponential notation.  Facilities analogous to either the
X    Fortran format specifiers or to the printf format specifiers should be
X    provided to do this.  What about:
X
X        str = dec_sprintf("%13.6g", dec_val)
X
X    I4GL-L34 was rated in class C because it should be simple to do and
X    useful but there has not been much demand voiced for it.
X
XI4GL-L35:
X    John Oliver (no email address) asked: How about dynamic use of I4GL
X    call command so that the programmer could say: "call func_name" where
X    func_name is a char variable storing the name of a function.  Under the
X    current I4GL, this is impossible.  The best you can do us use the run
X    command to run named stand alone executables.
X
X    Girard Chandler ([e-mail]) responded: I4GL sort of supports
X    this.  See "fgl_call(char *funcname, int nparams)" in pages S-198 ->
X    S-212 of the 4.1 4GL supplement.  This compiles to:
X
X        p4gl_call("funcname", nparams)  -- R4GL
X        funcname(nparams)               -- C4GL
X
X    So, using a very short C function with 4gl-rds, you can call functions
X    "by name." In C4GL the only method to do this would be to create a
X    lookup table of strings and function pointers.  In R4GL, you can load
X    individual pcode files dynamically and execute them (see the
X    fgl_start() function, page S-207).
X
X    fgl_call is not an I4GL-level facility, so it is not a complete answer
X    to John Oliver's question.  However, defining a suitable mechanism for
X    passing arguments to (and getting values back from) a function called
X    by name would need to be decided carefully.  The obvious solution is to
X    allow the argument list and return values to be specified as for any
X    other call; the only novel thing would be the use of a variable
X    (string?) to indicate the function to be called.  This is then exactly
X    analogous to the C call by pointer to function.  Another issue would be
X    how to obtain a mapping between function names and function pointers.
X    This would probably be more troublesome.
X
X    I4GL-L35 was rated in class D because it is not clear whether there is a
X    significant demand for this sort of capability.
X
X----------------------------------------------------------------------
X
XSQL
X
XI4GL-S01:
X    The FOREACH loop is very useful provided that the cursor it iterates over
X    does not need a USING clause when the cursor is opened.  This is a
X    ludicrous oversight, and a confounded nuisance, not least because it ought
X    to be trivial to fix.  The FOREACH loop should be extended to allow the
X    syntax:
X
X        FOREACH c_cursor [ USING variablelist-1 ] [ INTO variablelist-2 ]
X
X    I4GL-S01 was rated in class A because it should be easy to implement.
X
XI4GL-S02:
X    The existing version of I4GL does not allow recursive algorithms which
X    need to use different cursors with each new nested invocation because
X    there is no way to provide cursor variables -- the names are fixed.
X    ESQL/C Version 5.00 provides support for cursors named by strings,
X    which should be added to I4GL, partly in response to I4GL-L28, partly
X    because the underlying ESQL supports it (and the engines do), and
X    partly because the functionality is needed.
X
X    I4GL-S02 was rated in class B because it should be easy to implement.
X
XI4GL-S03:
X    A couple of the messages in the CDI discussion mention the idea of
X    providing an INPUT CURSOR and a DISPLAY CURSOR facility, but I have no
X    detailed description of the features available.
X
X    I am not at all clear how an INPUT CURSOR should work.  A DISPLAY
X    CURSOR may be intended to be similar to DISPLAY ARRAY except that the
X    data to be operated on is defined by a cursor of some sort, and the
X    programmer would not have to provide the data space.  I think this is
X    supplanted by the PICKLIST statement (I4GL-K01) documented below, but I
X    may have got hold of completely the wrong idea.
X
X    I4GL-S03 was rated in class E because there is insufficient available
X    infomration about what the requirement is.
X
XI4GL-S04:
X    One of the initial requests in the CDI discussion was for the facility
X    to be able to do:
X
X        CREATE TEMP TABLE LIKE record.*
X
X    Presumably, you should also be able to do:
X
X        CREATE TEMP TABLE LIKE var1, var2, rec1.field3 THRU rec1.field7
X
X    I argued against this suggestion; I don't seem to have a record of the
X    discussion (over-zealous cleaning out of mail files).  I would now
X    argue against it on the grounds that it is putting the cart before the
X    horse.  I4GL supplies the abilty to define records like tables which is
X    appropriate because it is designed to handle databases.  However, when
X    a temporary table is created, you should already know what it will look
X    like and therefore the facility seems redundant.  However, the CREATE
X    TEMP TABLE LIKE statement would presumably translate the variable types
X    into appropriate database types and translate the statement into a
X    normal CREATE TEMP TABLE statement.  As such, it can do no harm, but I
X    remain to be convinced of its value.
X
X    I4GL-S04 was rated in class E because the need for it is not clearly
X    understood.
X
XI4GL-S05:
X    Another of the initial requests in the CDI discussion was for the
X    facility to be able to do:
X
X    UPDATE Table01 SET r_var.* BY NAME
X        WHERE <condition>
X
X    This is a shorthand for:
X
X        UPDATE Table01
X            SET Col01 = r_var.col01,
X                Col02 = r_var.col02,
X                Col03 = r_var.col03
X            WHERE <condition>
X
X    There should presumably also be support for:
X
X    UPDATE Table01 SET var1, var2, r_var3.col4 THRU r_var3.col7 BY NAME
X        WHERE <condition>
X
X    I argued against this suggestion, but I don't seem to have a record of
X    the discussion (over-zealous cleaning out of mail files).  I now think
X    I was mistaken in the argument; it provides a potentially useful
X    shorthand, even though I have never found an urgent need for it.
X
X    I4GL-S05 was rated in class E because I remain to be convinced of it
X    general usefulness.
X
XI4GL-S06:
X    Hugh Grierson ([e-mail]) noted that there is a
X    "mismatch between semantics of some 4GL and SQL language constructs".
X    Paraphrasing his example slightly, consider the code segment:
X
X         DEFINE r_tab01 RECORD LIKE Table01.*       -- 1
X         SELECT *                                   -- 2
X             INTO r_tab01.*                         -- 1
X             FROM Table01
X
X    The stars in the lines marked 1 are expanded to the list of columns at
X    compile time, whereas the star in the lines marked 2 is expanded at run
X    time.  This is a correct observation, and can lead to trouble if the Table01
X    is altered between the time when the program is compiled and when it is
X    run.  Usually, the problem is obvious because the program crashes, but it
X    could be more subtle and simply cause the program to misbehave.  If you
X    look at books on database design, you find they uniformly recommend that
X    you avoid the use of star precisely because the meaning of star can
X    change.
X
X    I4GL-S06 was rated in class F because to change it would fundamentally
X    alter the nature of I4GL, and it would not be easy to provide a
X    suitable facility to deal with this.
X
X----------------------------------------------------------------------
X
XREPORTS
X
XI4GL-R01:
X    It should be possible to specify the shape of the report output page as
X    well as the destination when the report is started.  The preferred
X    mechanism for doing this would be something like:
X
X    START REPORT reportname
X           [ TO { SCREEN | PRINTER | FILE "file" | "file" | PIPE "program" } ]
X           [ WITH { PAGE LENGTH n | TOP MARGIN n |
X               BOTTOM MARGIN n | LEFT MARGIN n |
X               RIGHT MARGIN n } [ , ... ] ]
X
X    In this code, all the n's should be integer expressions (according to
X    I4GL-L09).  Both "file" and "program" can be string expressions in the
X    current versions of I4GL, which is good.  Note that the explicit option
X    of specifying TO FILE has been added, retaining the old TO "filename"
X    for backwards compatability.
X
X    This is likely to be fixed by the much less tidy expedient of allowing
X    the values in the OUTPUT section of the report be global integer
X    variables.  The values used will be those current when the START REPORT
X    statement is executed.  Forcing the programmer to use of globals is
X    distasteful.
X
X    I4GL-R01 was rated in class A because it is desparately needed.
X
XI4GL-R02:
X    This is the other bug fix -- misfeature fix -- which ought to be made.
X    In an I4GL report (or, indeed, in an ACE report), you cannot have two
X    fields printed with WORDWRAP on the same row.  For example, suppose
X    there are two long CHAR fields which should be printed wordwrapped
X    side-by-side.
X
X        PRINT   COLUMN  1, intval01 USING "####&",
X                COLUMN 10, longchar01 WORDWRAP RIGHT MARGIN 35,
X                COLUMN 40, longchar02 WORDWRAP RIGHT MARGIN 65,
X                COLUMN 70, intval02 USING "#####&"
X
X    The effect should be:
X
X  1234   This is the text from         This is the text from           5432
X         longchar01 wordwrapped in     longchar02, also
X         a width of 25 characters      wordwrapped in a width of
X         (35-10).                      25 characters (though the
X                                       limiting columns this
X                                       time are 40 and 65).
X
X    The effect you actually get is shown below, which make wordwrapped
X    fields in reports very limited in value.
X
X  1234   This is the text from
X         longchar01 wordwrapped in
X         a width of 25 characters
X         (35-10).                      This is the text from
X                                       longchar02, also
X                                       wordwrapped in a width of
X                                       25 characters (though the
X                                       limiting columns this
X                                       time are 40 and 65).            5432
X
X    I4GL-R02 was rated in class A because it is desparately needed.
X
XI4GL-R03:
X    There was a request for it to be possible to send the output of a
X    report to an I4GL window.  The window should provide a scrolling
X    capability, definitely vertically and possibly horizontal as well if
X    the report output is wider than the window.  This is likely to use the
X    same sort of technology as the horizontally scrolling character fields
X    (I4GL-F05), and would probably benefit from the search facility
X    proposed for display arrays (I4GL-D04) too.
X
X    Possible syntax for using this:
X
X        START REPORT reportname
X            TO WINDOW w_window
X            [ WITH PAGE LENGTH .... ]
X
X    This syntax requires the window to be pre-opened.  Alternatively, it
X    might be nice if an anonymous window could be created on the fly.  This
X    would require a syntax such as:
X
X        START REPORT reportname
X            TO WINDOW AT x, y WITH r ROWS, c COLUMNS ATTRIBUTE (BORDER)
X            [ PAGE LENGTH .... ]
X
X    I4GL-R03 was rated in class D because it is likely to be hard to implement
X    and it is not clear how widely used it would be.  Feedback please.
X
XI4GL-R04:
X    It would occasionally be useful to be able to have multiple concurrent
X    invocations of a single report.  An example would be when an invoice is
X    being printed to the screen and to a printer (using the dynamic
X    configuration facilities of I4GL-R01, of course to ensure that the
X    report dimensions are appropriate).
X
X    However, to support this, some equivalent to a FILE structure in C
X    (call it a report handle) would be necessary to identify which
X    invocation of the report was being referred to.  This would completely
X    mess up the existing language unless a default value of a report handle
X    could be inferred from the fact that only one copy of the report was
X    active on an existing system.
X
X    I4GL-R01 was rated in class F because it is not easy to implement it
X    without completely reworking the way reports are used, which is likely
X    to break existing code.
X
XI4GL-R05:
X    It would nice to be able to suppress trailing blank lines on the end of
X    a report when required.  This would be particularly useful when the
X    output is going to be mailed.  It would also be useful if trailing
X    blanks could be suppressed on all report output, though constant width
X    output is occasionally useful (for example if two reports are going to
X    be pasted together -- electronically by paste(1)).  A suitable syntax
X    for this might be:
X
X        OUTPUT
X            { WITH | WITHOUT } TRAILING LINES
X            { WITH | WITHOUT } TRAILING BLANKS
X
X    I4GL-R05 was rated in class C because it might not be all that easy to do
X    and it is not unbearable.
X
X----------------------------------------------------------------------
X
XMENUS
X
XI4GL-M01:
X    Ring menus are great when working with a screen form because they don't
X    take up much screen space, but for navigating around an application,
X    practically everyone prefers vertical menus, and practically everyone
X    has their own system for handling them.  It might be nice if there was
X    a variant on the MENU (presumably a VERTICAL MENU) which supplied a
X    VERTICAL menu by default.
X
X    However, such a facility is not necessary if the other modifications
X    proposed (especially fgl_getkey() -- I4GL-L10) were available.
X
X    I4GL-M01 was rated in class E because there is no clear requirement for
X    it given the other facilities added.
X
X----------------------------------------------------------------------
X
XPROMPT
X
XI4GL-P01:
X    PROMPT should include EXIT PROMPT and CONTINUE PROMPT.  The ON KEY
X    clauses can only exit from PROMPT if it is wrapped in some sort of
X    loop, whereas consistency suggests that both EXIT and CONTINUE should
X    be provided.
X
X    I4GL-P01 was rated in class A because it should be easy to implement.
X
XI4GL-P02:
X    PROMPT should include BEFORE PROMPT and AFTER PROMPT, again for
X    consistency with the other major statements.
X
X    I4GL-P02 was rated in class A because it should be easy to implement.
X
XI4GL-P03:
X    PROMPT should provide validation of data without requiring special
X    error handling techniques.  When the data type is not CHAR, the value
X    typed by the user is not validated sensibly; if the value cannot be
X    converted, an error is generated.  To recover, the PROMPT has to be
X    wrapped in some sort of loop, which is messy.
X
X    I4GL-P03 was rated in class A because it should have been fixed long
X    ago.
X
XI4GL-P04:
X    It should be possible to use a construct such as:
X
X        PROMPT "Password: " FOR passwd WITHOUT ECHO
X
X    to get a password without the users response appearing on the screen.
X    Again, the only reliable way around this at the moment is to wrap the
X    PROMPT in a loop.
X
X    I4GL-P04 was rated in class A because it should be easy to implement.
X
X----------------------------------------------------------------------
X
XFORMS
X
XI4GL-F01:
X    It would be useful if I4GL forms could be extended to allow for
X    multi-screen input with a single screen record which spans multiple
X    screen layouts -- as supported by ISQL.  It is possible to provide the
X    seamless transfer from the bottom of one screen to the top of the next,
X    and it is considerably more difficult but still possible to provide a
X    seamless transfer from the top of one screen to the bottom of the
X    previous one, but to do so requires reams of code, keeping careful
X    track of where the cursor is and so on.  But it would be so much easier
X    if the language supported it intrinsically.
X
X    This would not require any syntactic changes to the I4GL code, and only
X    semantic changes to the I4GL forms.
X
X    I4GL-F04 was rated in class C because it will probably be rather hard
X    to do properly.
X
XI4GL-F02:
X    The existing syntax for I4GL forms does not distinguish between a
X    word-wrapped field and array elements.  This means that it is not
X    possible to use a word-wrapped field in an array, because the
X    word-wrapped field is deemed to have the wrong dimension compared to
X    the rest of the fields in the array.
X
X    Unfortunately, fixing this is non-trivial, but it is urgently required.
X    The syntax change must try to allow for backward compatability.  Since
X    word-wrapped fields in arrays aren't supported at the moment, then a
X    mechanism should be used which modifies these and allows everything
X    else to be unchanged.  My suggestion is that the field label notation
X    be extended so that the example below shows an array of two
X    word-wrapped fields, each of which has three components.  This notation
X    would be allowed, but not mandatory, on any word-wrapped field,
X    obviously.  If the dot-digit is an annotation, then any un-annotated
X    field which repeats can either be a single word-wrapped field or an
X    array of un-wrapped fields, depending on how the form defines its
X    screen records.
X
X        [f000.1                   ]
X        [f000.2                   ]
X        [f000.3                   ]
X
X        [f000.1                   ]
X        [f000.2                   ]
X        [f000.3                   ]
X
X    Note that this would not allow for an array of word-wrapped fields
X    where each element of the wrapped field was shorter than two
X    characters.  This cannot honestly be regarded as a serious problem, but
X    see I4GL-F03 for more discussion.
X
X    I4GL-F02 was rated in class A because it is urgently required.
X
XI4GL-F03:
X    I4GL (and ISQL) provide no way for making two fields run into each
X    other.  The pipe "|" requires a space between the fields, and using
X    brackets "[]" requires two spaces between fields.  On some forms, some
X    people think it would be helpful to have separate fields run together,
X    particular when a string of single-character codes are being entered.
X    In I4GL, it is possible to handle this (sort of) by defining a single
X    field which takes all the codes and then splits them up after the input
X    has been accepted, but it isn't easy to provide a pop-up facility for
X    the fourth character alone, and a different one for the fifth
X    character.  The ideal solution is to eliminate the need for "[|]"
X    markers in forms.  This is radical as the whole of the form description
X    technology would need to be revised.  While we are at it, we can then
X    fix all the other problems, especially the one addressed by I4GL-F02.
X
X    The technology of forms as currently implemented basically dates back
X    to the very early '80s (and Informix 3.30 and its predecessors), and it
X    was great for that era.  For the '90s, it manages to look dated and
X    needs rewriting.
X
X    I4GL-F03 was rated in class D because it is quite important to bring
X    the technology up to date, but it is a major change.
X
XI4GL-F04:
X    The PICTURE clause is pitifully limited for validating data.  For
X    example, you cannot specify digit or blank for a column unless you
X    allow any character, and you cannot specify a literal A, X or # in the
X    field.  You cannot say that the field must match one of the templates
X    because the PICTURE control what characters can be entered, and
X    literals are skipped.
X
X    PICTURE needs upgrading by providing one or two alternative features.
X    One of these could be called MASK (though it could be an upgraded
X    version of PICTURE), and the other could be called REGEXPR.  It would
X    be very useful to be able to validate the input according to one of a
X    number of MASK or REGEXPR controls, too.  The sort of thing I have in
X    mind for MASK would be:
X
X    Mask    Meaning                                 REGEXPR
X    A       alphabetic                              [a-zA-Z]
X    U       upper-case alphabetic                   [A-Z]
X    L       lower-case alphabetic                   [a-z]
X    N       alphanumeric                            [a-zA-Z0-9]
X    D       decimal digit                           [0-9]
X    O       octal digit                             [0-7]
X    X       hexadecimal digit                       [0-9a-fA-F]
X    P       punctuation                             [^a-zA-Z0-9_] (approx)
X    K       keyword character (N + '_')             [a-zA-Z0-9_]
X    .       any character                           .
X    \x      x                                       x
X
X    a       alphabetic or space                     [a-zA-Z ]
X    u       upper-case alphabetic or space          [A-Z ]
X    l       lower-case alphabetic or space          [a-z ]
X    n       alphanumeric or space                   [a-zA-Z0-9 ]
X    d       decimal digit or space                  [0-9 ]
X    o       octal digit or space                    [0-7 ]
X    x       hexadecimal digit or space              [0-9a-fA-F ]
X    p       punctuation or space                    [^a-zA-Z0-9_] (approx)
X    k       keyword character (n + '_') or space    [a-zA-Z0-9_ ]
X
X    Other classes could be added.  One possibility would be I/i for ISBN
X    character, meaning [0-9X].
X
X    The REGEXPR string would be a full Unix regular expression, though
X    which version would have to be decided.  The obvious one to support is
X    the one provided by regexpr(3) in System V Release 4.  Anyway, the
X    MASK attribute could be converted by a simple set of rules into a
X    REGEXPR, so that the internal code need only handle REGEXPR's.
X
X    These could be used in a form as shown below:
X
X    ATTRIBUTES
X    f001 = table01.uk_postcode, ..., UPSHIFT,
X         MASK = ("UD DUU", "UDD DUU", "UUD DUU", "UUDD DUU", "UUDU DUU");
X    f002 = table01.number_plate, ..., UPSHIFT,
X         REGEXPR = ("[A-Z]?[0-9]\{1,3\}[A-Z]\{1,3\}",
X                    "[A-Z]\{1,3\}[0-9]\{1,3\}[A-Z]?");
X
X    A few words of explanation are in order.  The set of masks are correct
X    for British postcodes; these can take the forms "B1 7BU", "B12 9AJ",
X    "IP2 3JB", "IP10 9WQ", "EC1A 7YG", and these are encoded appropriately
X    in the mask values.  The regular expressions are correct for British
X    civilian (non-military) non-diplomatic car number plates.  These can
X    take the form of an optional single letter (denoting year of
X    manufacture) followed by a 1 to 3 digits, followed by 1 to 3 letters,
X    or it can be 1 to 3 letters followed by 1 to 3 digits and an optional
X    single letter (also denoting year of manufacture).  The military
X    numbers would use "[0-9][0-9][A-Z][A-Z][0-9][0-9]", and the diplomatic
X    plates would use "[0-9][0-9][0-9]D[0-9][0-9][0-9]".  This covers most,
X    if not all, valid British registration numbers.  Some could be matched
X    by either of the patterns (J9K) and that is probably not a valid
X    number, but J1 probably is valid, and 1J probably would be valid too.
X
X    The PICTURE facility limits the data that can be entered as it is being
X    entered, character by character.  The MASK facility could do the same
X    when a single MASK was specified.  If alternative MASKs were specified,
X    it would still be possible to provide character by character
X    validation, but there would be problems presenting the template if they
X    had different literal characters embedded in them; the MASK could not
X    then present the literal characters at the start of the input, but what
X    is entered could still be validated against the alternative MASKs.  If
X    a full REGEXPR with wildcarding was specified, or if multiple REGEXPRs
X    were, the task of calculating whether the entered character is a valid
X    prefix of the final string is probably non-computable; it would
X    certainly be very hard.  Thus, MASK is an upward extension of PICTURE,
X    but REGEXPR cannot provide.  All masks and regular expressions would
X    completely ignore trailing blanks when matching.
X
X    I4GL-F04 was rated in class B because it should be fairly easy to
X    implement and is certainly needed.
X
XI4GL-F05:
X    Screens have limited space on them, and long character strings are a
X    nuisance if they are normally short but can be long.  It would be
X    useful if I4GL forms could have an attribute SCROLLING which would mean
X    that if the user needed to enter more characters in the data than
X    appeared on the screen, the field would scroll horizontally.  To move
X    onto the next field, the TAB key, UP key or DOWN key would have to be
X    pressed to move onto the next field.  The ultimate limit on the amount
X    of data that could be typed into the field would be the length of the
X    underlying field.  If the field was a formonly field, the length of the
X    underlying type would have to be specified if SCROLLING was used (but,
X    for backwards compatability, not if the SCROLLING attribute was not
X    used.  The interaction between SCROLLING and WORDWRAP or WORDWRAP
X    COMPRESS would need to be carefully considered.  If the field is
X    WORDWRAPPED, then the obvious jump-quantum for the scroll is the size
X    of the last element of the set of fields.  It may be simplest if, in a
X    first release, SCROLLING and WORDWRAP cannot both be specified.  A
X    subsequent release could add the extra functionality as required.
X
X    I4GL-F05 was rated in class C because it would be moderately difficult
X    to implement but would be very valuable.
X
XI4GL-F06:
X    One of the correspondents in CDI simply specified the requirement
X    2-dimensional screen arrays with no further explanation.  See I4GL-F07
X    for one possible explanation.  Otherwise, more information is needed.
X
X    I4GL-F06 was rated in class F because the requirements are not clear.
X
XI4GL-F07:
X    If a screen array has, for example, 3 columns of fields, then I4GL
X    assumes that they are to be accessed in row-major order (so it goes
X    across the screen before it goes down).  It would frequently be
X    preferable if they could be processed in column-major order (so the
X    cursor would move down before going across).  This should probably be
X    controlled by a definition appended to the screen record.
X
X    [f000  ]   [f000  ]  [f000  ]           1
X    [f000  ]   [f000  ]  [f000  ]           2
X    [f000  ]   [f000  ]  [f000  ]           3
X    [f000  ]   [f000  ]  [f000  ]           4
X
X    f000 = table01.column02;
X
X    SCREEN RECORD s_array[12] MOVE BY COLUMN SCROLL BY COLUMN
X                (table01.column02)
X
X    MOVE BY COLUMN means that the cursor will move in down before across;
X    MOVE BY ROW is the default.  SCROLL BY COLUMN means that when the user
X    tries to go beyond the last field, the entries in the middle column
X    will be displayed in the same row in the first column, and the entries
X    in the last column will appear in the middle column, and either a new
X    column full of entries will be displayed or an empty column would be
X    displayed, with the cursor at the top of the last column in either
X    case.  SCROLL BY ROW (the default) would shuffle everything back on
X    place in the order of the cursor movement.
X
X    The perverse will wonder what happens if the array looks like the one
X    below and column major order is specified.  Row major order does not
X    present any particular problem (though the rows have different numbers
X    of fields in them).  If the array was not rectilinear, then maybe
X    column major order should be disallowed.  I have numbered the fields in
X    the order that I think they would be processed if column major order
X    was specified (and allowed).
X
X                                        1 [f000  ]
X    2 [f000  ] 6 [f000  ] 9 [f000  ]
X               3 [f000  ]
X    4 [f000  ]            7 [f000  ]
X    5 [f000  ] 8 [f000  ]         10 [f000  ]
X
X    I4GL-F07 was rated in class C because it should be easy to implement
X    and is quite desirable.
X
XI4GL-F08:
X    Sometimes, some people should not be able to enter data in a particular
X    field on a form whereas other users should be able to do so.  This can
X    be controlled relatively easily by a test in the BEFORE FIELD and using
X    the NEXT FIELD SAME DIRECTION (I4GL-F09) feature to skip the field.
X    However, there are also occasions when certain users should simply not
X    be allowed to see the field (except perhaps by the absence of any other
X    information in the space on the form).  It should be possible to
X    dynamically hide screen fields completely.  This feature is closely
X    related to the the other dynamic form attributes requests (such as most
X    of the DISPLAY ARRAY features).
X
X    I4GL-F08 was rated in class C because it would be moderately difficult
X    to implement.
X
XI4GL-F09:
X    NEXT FIELD NEXT always goes to the field after the current field, and
X    NEXT FIELD PREVIOUS always goes to the field before the current field.
X    It is difficult to write pop-up code (where NEXT FIELD must be called
X    for the value to "take") such that if the cursor was moving backwards,
X    NEXT FIELD PREVIOUS is used, and if the cursor was going forwards, NEXT
X    FIELD NEXT is used, because the program has to keep track of which
X    field the cursor was in previously (duplicating I4GL's efforts, too).
X    An extra option NEXT FIELD SAME DIRECTION could be provided to make
X    this much easier.
X
X    I4GL-F09 was rated in class B because it should be easy to implement
X    and would be very useful.
X
XI4GL-F10:
X    The INFIELD function can determine which field the cursor is currently
X    in when it is called outside the scope of an INPUT or INPUT ARRAY
X    statement.  I4GL should allow the programmer to specify "NEXT FIELD
X    fieldname" outside the scope of an INPUT or INPUT ARRAY statement, and
X    should allow the fieldname to be a string variable.  There should also
X    be a direct CURRENT_FIELD() function which returns the name of the
X    current field -- the INFIELD may have to be called many times to find
X    the name of the correct field.  Assuming field names as strings is
X    supported, INFIELD should accept a string as well as a plain field
X    name.
X
X    I4GL-F10 was rated in class B because it would be very useful and
X    should not be very hard to do.
X
XI4GL-F11:
X    It would occasionally be useful to know the size of the current form.
X
X    I4GL-F11 was rated in class E because it is of debatable value.
X
XI4GL-F12:
X    Assuming form variables are allowed, it should be possible to discover
X    the name of the current form so that a  new form can be displayed in the
X    current window and then the original form can be restored after the new one
X    has been finished with.
X
X    I4GL-F12 was rated in class E because although it should be easy to
X    implement but since windows are cheap and quick to open, the
X    functionality is of debatable value.
X
XI4GL-F13:
X    It would often be useful to get the size (declared dimension) of a
X    named screen array, so that the code could display no more than the
X    correct number of values to the array.
X
X    I4GL-F13 was rated in class A because it should be easy to implement
X    and would be immediately useful.
X
XI4GL-F14:
X    It would sometimes be useful to be able to obtain the names of the
X    fields in a given screen record or screen array.  It would also be
X    useful to be able to discover type and attribute information.  Some
X    sort of interface to this information would probably be necessary to
X    support dynamic attribute setting, anyway, but handling a variable
X    length list of items presents some problems in current I4GL.
X
X    I4GL-F14 was rated in class E because it would be difficult to provide
X    an appropriate return mechanism and because it is not immediately clear
X    how useful it would be.
X
XI4GL-F15:
X    I4GL currently supports two screen dump mechanisms, neither of which is
X    totally satisfactory, and neither of which is properly documented.  The
X    two mechanisms are very similar: one uses the environment variable
X    DBSCREENOUT and puts a screen dump in the named file when the users
X    presses control-P, the other uses DBSCREENDUMP and the same key stroke.
X    If both variables are defined, both dumps are done.  There is a
X    difference in the format of the two dumps; DBSCREENDUMP is likely to
X    include control characters missing from DBSCREENOUT.  One of these two
X    mechanisms is documented in that best-seller -- the QuickStep Reference
X    Manual.
X
X    I4GL should seriously look at these two mechanisms, scrap one of them
X    (probably) and document the other.
X
X    I4GL-F15 was rated in class A because it should be easy to do.
X
XI4GL-F16:
X    It would occasionally be used to be able to distinguish between a blank
X    entered in a field and a null field.  It would occasionally be useful
X    to be able to distinguish between trailing blanks typed by the user and
X    trailing blanks which are simply padding.
X
X    However, neither of these facilities can be changed without very major
X    overhaul of both I4GL and the engines.
X
X    I4GL-F16 was rated in class F because it would be very difficult to do
X    without breaking all sort of existing code.
X
XI4GL-F17:
X    When a form is displayed, the display attributes of the fields in the
X    form should be set.  At the moment, these attributes get set when a
X    value is displayed to the field.  This makes CONSTRUCT look very messy,
X    and doesn't help INPUT or DISPLAY fields either.  DISPLAY FORM should
X    probably do an implicit display of a null value to every field on the
X    form.  It is not clear whether there are any backwards compatability
X    issues; if there are, then maybe the syntax should be extended as
X    shown, with the default of WITHOUT NULL DISPLAY.
X
X        DISPLAY FORM f_form [ { WITH | WITHOUT } NULL DISPLAY ]
X
X    I4GL-F16 was rated in class C because it should not be difficult to do.
X
X----------------------------------------------------------------------
X
XWINDOWS
X
XI4GL-W01:
X    It is possible to reduce a window with a form in it to two lines, one
X    for the input field and one for the comment line, with the prompt and
X    comment lines doubling up with one or other of the lines.  It would
X    frequently be useful to be able suppress the comment line too, so that
X    the window could use simply one line.  For consistency, the other lines
X    should be suppressible too, by specifying
X
X        ATTRIBUTES (MENU LINE OFF, PROMPT LINE OFF, COMMENT LINE OFF)
X
X    It might also be useful to be able to specify that errors should be
X    displayed in a window, but there are probably good reasons for not
X    allowing ERROR LINE OFF, because even if error messages should not be
X    displayed in the current window, they should be displayed to the
X    screen.
X
X    I4GL-W01 was rated in class A because it should be easy to do.
X
XI4GL-W02:
X    It would be useful to be able to determine the size of the current
X    window.
X
X    I4GL-W02 was rated in class B because it should be easy to do.
X
XI4GL-W03:
X    It would be useful to be able to determine the name of the current
X    window so that it can be restored subsequently by CURRENT WINDOW IS
X    w_variable.  This assumes, of course, that window variables are
X    supported.
X
X    I4GL-W03 was rated in class B because it should be easy to do and
X    would be useful.
X
XI4GL-W04:
X    It would be nice if boxes could be drawn properly.  It would be even
X    better if overlapping boxes were drawn with the correct characters --
X    at the moment, if you draw box B which sits over the top part of box A,
X    there is a small gap where the bottom corners of B remove the boundary
X    of box A.
X
X       +-----------------------+
X       |                       |
X       |  B                    |
X       +-----------------------+
X
X       |                       |
X       |  A                    |
X       +-----------------------+
X
X    The gap which has been shown as a whole line is actually about half a
X    line if box drawing characters are available.  On a Sun, you don't
X    necessarily get the nice box lines so you don't notice the effect.  It
X    means that you need to have the cross, left-tee, right-tee, up-tee and
X    down-tee characters available.  These can be defined in terminfo and
X    have been retrofitted to termcap (and could be added to the gb
X    capability which we have defined).
X
X    I4GL-W04 was rated in class C because it would improve the appearance
X    of I4GL windows, but it would not be particularly simple to do.
X
X----------------------------------------------------------------------
X
XINPUT
X
XI4GL-I01:
X    It would often be helpful to be able to change the display attributes
X    of a screen field dynamically (see I4GL-I02, I4GL-F08, I4GL-F14, etc).
X    The existing OPTIONS DISPLAY ATTRIBUTES facility is not sufficiently
X    general to satisfy this requirement because if a particular field
X    required a particular attribute to be set (which was different from
X    that of other fields also being displayed), then OPTIONS DISPLAY
X    ATTRIBUTES would have to be called both before and after a value was
X    displayed to the field.  The proposed facility would allow the display
X    attribute for the field to be set permanently.
X
X    Of course, the mechanism should allow the field name to be specified as
X    a string, and the necessary attributes and attribute values could also
X    be variables.
X
X    I4GL-I01 was rated in class B because it would be very useful.
X
XI4GL-I02:
X    It would sometimes be helpful to be able to change the status of some
X    screen fields dynamically (see I4GL-F08, I4GL-F14).  I4GL should allow
SHAR_EOF
echo "End of part 2"
echo "File i4glmods is continued in part 3"
echo "3" > s2_seq_.tmp
exit 0