eX version 0.4b User's Manual                         File eXMan13.txt
(C) Copyright 1995, 1996 William E. Wilgus III.   All rights reserved.


Miscellany


Oh, NO!

eX is pretty good at giving functions and operators the correct
argument and operand.  There's a hierarchy involved, of course: 

  1. an operated address on the right side of an assignment statement
  2. a parenthesized argument 
  3. a filter on the right side of an assignment statement
  4. an operated address assignment 
  5. an operated assignment 
  6. an assignment itself 
  7. an operated address 
  8. an operation/filter

But it isn't perfect. 

It isn't impossible to cause what I term `crossed addresses'---the act
of a task being performed with a (the) value(s) intended for another. 
As with most things that go wrong, eX doesn't tell you that one
occurred because it doesn't recognize one.  The culprit is a task with
a lower priority in the hierarchy that is used to provide a task with
a higher priority in the hierarchy with a value.  But, not all such
situations cause crossed addresses, thanks to the hierarchy. 

The best information I can provide at this time is that they can occur
with operated addresses and filter functions, and the following is an
example: 

                 show "test" % + ucase "ing"

which displays "test" instead of "testING".  (I suspect I need to provide
another hierarchy level.)  The cure---once you've diagnosed the
disease---is usually something simple like parenthesizing an argument
or adding an aggregation: 

               show "test" % + ucase("ing")
               show "test" % + (ucase "ing")


I've discussed un-fulfilled operators and un-exited accumulator planes
and levels; and `eX word not found' errors can do the same thing to
you.  Unfortunately, eX still lacks a `reset' to fix the resulting
problem(s), and the only sure cure currently available is to exit eX. 
Sometimes though, you can fix the problem by simply typing in an eX
command that is just an aggregation terminating delimiter or a value,
and eX's monitor can help show what needs to be done.  These problems
are usually pretty easy to avoid, however. 



Sometimes Useful Techniques

I don't use the following technique much, but it can come in
handy. 

                    _y := [{_x := + 1 < 10} + _x]

Here, the loop is made to accumulate through the addition operator in 
the do portion of the loop.  It can be used with an if ... then as
well: 

                    _y := [{_x < 10} + _x ~]


The `cheapest' way I know to display the integers 1 through 10 is the 
do ... while loop 

                    [{show# (; + 1) < 11}]

(It assumes the `standard' aggregation's numeric accumulator is 0
prior to execution, of course.)  I thought I'd see how much more
`expensive' a while ... do version would be, so I tried 

                    [{(; + 1) < 11 show# [; ]}]

and it works too. 

Both of these work also: 

          [{_x := + 1 < 11} show _x]

          :>label EndMac{_x := + 1 > 10} show _x jump "label"

But I've already stated that conditional execution statements in a
test can cause things to go wrong, and the point is that conditional
execution in a test is easily avoided. 



That's Crazy!

There's one thing I haven't shown you because I don't use it much
myself.  You can do a program branch or call a sub-program just about
anywhere.  If you'd like a little more excitement than the simple loop
above, you might like to try this:

               _x := 0
               :>1
                    jump{show _x := call 2 < 10} 1
                    EndMac
               :>2
                    + 1

Please note that the program directive arguments are numeric and the 
label identifiers are alpha-numeric!  (I should have written the
labels :> "1", etc. or the directives call "2", etc. for clarity. 
But I often write them that way for myself and perhaps you're a bit
more awake now.)  

Both of these produce identical output: 

                    jump "main"                                    (1)
                    :>sub
                         "string", 3
                         return
                    :>main
                         show left(call "sub")


                    jump "main"                                    (2)
                    :>sub
                         "string", 3)
                          EndMac
                    :>main
                         show left(jump "sub"



The Only Things You REALLY Need Remember About eX
     and a Few of the Things You Don't NEED to Remember About eX

-- It executes directives.
-- It performs tasks.
-- Anything that can provide value(s) always does.

   You don't need to remember that tasks can be stacked to use the
   same value or its modification, because you don't need to write
   macros so that they take advantage of the fact.

   You don't need to remember that eX interprets a stream of language
   components that can `come from anywhere' because you don't need to
   use program branching or sub-programming.

   You don't need to remember that eX is context in-sensitive and you
   can do virtually anything anywhere.


-- Some things return both a numeric value and a string value, and any
   un-wanted data class can usually be ignored.
-- You can get rid of an un-wanted data class with a filter, or render
   it temporarily impotent with a data class suffix.

   I think it's un-likely that anyone will forget that eX's operators
   can perform numeric by numeric and string by string operations 
   simultaneously and can optionally perform a string by numeric
   operation, so you don't need to remember this.  Besides, you don't
   need to write macros to take advantage of the fact.


-- Un-like a parens aggregation, accumulation (and therefore
   aggregation) is not automatic in a bracket aggregation [ ].

-- Conditional tests are written in brace { } aggregations.

-- Iteration structures (loops) are formed by placing a conditional
   test { } in a bracket structure [ ].
-- Non-iterative execution structures are created by adding an else
   token ~ to a loop (iteration) structure.

   You don't have to remember all the conditional execution structure
   variations possible.


-- Program branching and sub-programming is provided for.

   You don't have to remember that every type of branch and call
   except relative jumps and relative calls are provided; and you
   don't have to remember that the end of the macro is an implied
   return (but it's nice if you do).



Fluency

I admit to not being fluent in eX.  

There are really two aspects to fluency in any language---computer or 
otherwise.  The first is syntax.  I'm quite fluent in its
syntax---after all, I created what little there is.  I think you'll
quickly become competent in eX's syntax and find that level of fluency
sufficient.  

The second aspect is vocabulary.  I'm quite deficient in vocabulary
because I regularly use only a small percentage of it, but that level
of fluency is sufficient for me.  Being lucid with that segment of a
lexicon habitually exercised should satiate all intellects.  

