[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Jan 1 18:22:50 1993 
Subject:More Misfeatures 
From:Steve Knight 
Volume-ID:930101.05 

On the subject of misfeatures, Aaron writes:
> However, I suspect that as regards mis-features this issue of
> quotation in list and vectore expressions is minor compared with
> others, including letting commas be optional in variable
> declarations (which should be phased out as soon as possible) 

I agree.  This is a completely horrid aspect of POP-11's overly
flexible syntax.  I would add that optional commas should be replaced
by mandatory commas in all other contexts, too.  This includes
formal parameters, dlocal expressions, and so on.

> making
> input and output locals default to dynamic rather than lexical and

I agree very strongly.  I want to go even further, as I've written
elsewhere, and have any declarations of these variables moved to
the point of introduction.  In other words:
    define f( x, dlocal y ) 
rather than
    define f( x, y ); lvars x; dlocal y;
However, making the default lexical is the main thing.

> many other permitted alternative forms for the same thing, including
> the dreadful toleration of "do" in place of "then" in unless
> expressions:
>     unless foo(x) do x else y endunless -> z

I've never understood this point.  It has always seemed to me to be
a positive feature of POP-11.  Many conditionals read better with "then"
others with "do".  Since both are reserved words, why not make it 
optional?  

My own love-to-hate favourite at the moment is the abomination of
an empty expression used as the target of assignments, especially
in the context of tuples.  e.g.
    EXPR -> ( x, , z )
The above should be a syntax error in my view, not a convenient way
of popping the 1st and 3rd items off the stack.  If you are really a 
purist then I would concede that it might be legal but equivalent
to
    EXPR -> ( x, z )
This must be true since the natural interpretation to assigning to
the empty expression is the null action.  i.e.
     EXPR -> ;
becomes
     EXPR
Of course, in today's POP-11 the latter is actually interpreted
as
     erase( EXPR )


Why is it wrong?  Basically, it creates a needless exceptional behaviour
in the middle of the language.  (Excluding active variables, for the moment)

     ( x, y, z )     pushes 3 things on the stack
     -> ( x, y, z )  pops 3 things off the stack
     ( x, y )        pushes 2
     -> ( x, y )     pops 2
     ( x )           pushes 1
     -> ( x )        pops 1
     ()              pushes 0
     -> ()           pops 1 ?! 

And the requirement for a convenient way of erasing an arbitrary element
could just as easily be served through an anonymous variable.  The great
advantage of an anonymous variable is that it could be used in any 
context to good effect.  For example, using '_' as the anonymous
variable:


     define K( x ); lvars x;
         procedure( _ );      ;;; why give it a name?
             x
         endprocedure
     enddefine;

     for k, _ in_property P do .... endfor
  
     -> ( x, _, z )

It might even make sense to use it in push-mode as well as pop-mode.  
For example ....

     ident _

As you can see, the presense of an anonymous variable would be an
elegant device.  The two proposed names for it are _ and undef.
The advantage of "_" as a name is that it is exactly the same
name as used by Prolog and SML which support an extremely similar
idea.  The advantage of "undef" is that it is a reserved word with
approximately the right associations.
The problem with "_" is that it binds to "->", although I regard
this is pretty insignificant.  The problem with "undef" is that
it is visually bulky which I feel inappropriate.

But I'd prefer either to the ghastly assignment to empty expressions!

Steve