Future Directions

 

  There are many areas in which the Glish language or system may evolve in the future. We list here the likely changes (or, in some cases, changes at least being considered), some of which will not be backward-compatible:

1. A way for providing ``type signatures", both for Glish functions     and whenever statements, and for programs using the Client Library. The signature would provide run-time type-checking, and also automatic partition of a value into its components. For example,

       whenever a->b(numeric c, string d) do
           ...

   would respond to any b event generated by agent a by first checking whether its value had a numeric ``c" field and a string ``d" field, and if so then assigning those fields to local variables ``c" and ``d".

   Similarly, in a Glish client, something along the lines of:

       client->Register( "b", "numeric c, string d",
                         my_func );

   which would register the client as responding to the same sort of b event by calling my_func with arguments ``c" and ``d".
2. Perhaps a ``module" facility to support precompiled script   libraries.
3. Support for   timeouts and   exception handling when using await and request/reply events (§ 7.4, page ).
4. print needs to be more sophisticated, to support       printf()-style formatting.
5. Perhaps   an ``in" operator for determining whether a field is in a record, rather than has_field() (§ 9.1, page ), which is somewhat inefficient and clumsy to use.
6. Additional   C-style operators, such as ``? :" and perhaps ``++".
7. A mechanism   for ``adding" one record to another, including all of its fields.
8. Making the implicit semi-colon insertion algorithm (§ 5.11, page ) never insert a semi-colon if there is a pending close-parenthesis (i.e., more open-parentheses have been seen than close-parentheses).
9. An ``Incomplete()" member function for Client, similar     to Unrecognized(), for reporting events that arrive without all the necessary values (record fields). The various Value:Field() member functions would record the last field they were asked to find but couldn't, so Incomplete() could generate an event identifying which field was missing (or had the wrong type).
10. The ability   to compare records element-by-element using the ``==" operator.
11. An ascii=T optional argument to read_value() to make   the resulting file human-readable. Of course, write_value() should be able to read the result.
12. Similarly, making the input= argument to shell() and client() more imaginative about how it turns event values into text. For example, 1:10 should generated 10 lines, one integer per line, instead of a single line of the numbers surrounded by []'s.
13. Sprucing up the limited stdin interface provided to stand-alone clients (§ 13.5.1, page ).
14. Additional mathematical functions,   such as sgn()
15. Additional functions for manipulating strings: extracting substrings,     searching for patterns, substitution. Perhaps the ``+" operator should perform spaste() (§ 9.5, page ) when invoked with string operands.
16. Perhaps allow assignment between multiple record fields and a   single vector with the same number of values:

        r["x y z"] := [0, 0, 10]

    would assign r.x to 0, r.y to 0, and r.z to 10.
17. Perhaps make   await an expression (returning $value) instead of a statement.
18. Perhaps redefine ref so that it ``distributes" across   records. For example, ``a["b c"] := ref d["x y"]" would make a.b a reference to d.x and a.c a reference to d.y.
19. A more flexible record-constructor that expands any   records inside it, so that [a=1, [b=2, c=3]] becomes equivalent to [a=1, b=2, c=3], just as [1, [3, 5]] is presently equivalent to [1, 3, 5].
20. A ``trace"   feature that reports when large internal copies are done, so inefficiencies in Glish scripts can be tracked down.
21. Functions for ``walking" records or vectors and applying other functions to each element or field.
22. num_args() and nth_arg() should default to apply to ``..." if no arguments are given.
23. A mechanism   for efficiently deleting a field from a record.
24. Perhaps a   ``compound-assignment" statement for extracting pieces of a vector or a record:

        a, b, c := d

    would assign the first field (or element) of d to a, the second field to b, and the remainder to c.
25. A mechanism for   recording events and later playing them back or displaying them for analysis.
26. More   flexible use of uninitialized variables, rather than just generating a warning and assigning them to F. Perhaps simply do away with the warning message.
27. Event-designators   for ``an x event generated by any agent" (``*->foo") or ``any event whatsoever" (``*->*'').
28. Presently there is a division between functions that are actually built into the Glish interpreter and those that are defined in the glish.init file (§ 14.6, page ). The former do not support named arguments or variable argument lists. This restriction should be removed, as it will make it much easier to add more built-in functions.
29. for loops should work for iterating over record's as well as vectors.
30. Probably for loop indices should be implicitly local unless explicitly made global.
31. A mechanism for   dealing with out-of-band events, and for flushing event queues under exceptional conditions.
32. The ``..." ellipsis should ``remember" its name=value   bindings so they are preserved if the ellipsis is passed as an argument to another function.
33. A mechanism   for allowing ``unexpected" clients to ``join" a Glish script. The present mechanism (using async=T in a call to client(); see § 7.8.1, page ) requires that the script anticipate that a client may wish to join.
34. Probably the full set of ANSI escape sequences will be   supported in string literals.
35. Executing the same link statement more than once should not cause the link source to send multiple copies of the given event, but instead do nothing if the link is already established.
36. A mechanism for terminating a subsequence.
37. More flexible type conversion in Value::Polymorph().
38. Perhaps split() should return empty strings if it finds multiple, adjacent split characters.
39. Changing the environ global should probably change the environment.
40. Errors in executing shell commands and asynchronous shell clients should probably result in events being generated.
41. The ``short-circuit" && and || operators should complain if one of their operands is not a scalar, instead of just using the first element of the operand. The same holds for values tested in conditionals.