Conference turris::languages

    In most 3gl's functions are essentially n-ary operators.

    IF..THEN..ELSE is a ternary operator.
        
    		-John Bishop

C's "foo ? bar : baz" is infix ternary.
				/AHM

How about  with:with:with:with in Smalltalk ?

/Ashok

    re: .4
    
    I'm not terribly familiar with Smalltalk, but from a syntactic point
    of view, isn't that simply a sequence of three applications of the
    binary message operator ":"?
    
       Gary

>    I'm not terribly familiar with Smalltalk, but from a syntactic point
>    of view, isn't that simply a sequence of three applications of the
>    binary message operator ":"?

It's more like a function call with 3 parameters.

Thanks very much for your responses.  To summarize, 

	Functions calls are typically n-ary prefix operators;

	Conditional expressions such as "IF ... THEN ... ELSE ..." are ternary
	expressions;

	C's "... ? ... : ..." is another ternary expresson.

[RE: .4, I'm not familiar with Smalltalk, so I've no idea what
	 with:with:with:with means.]

It would seem that these conditional expressions can be easily mapped onto 
LISP's rather general conditional expression, COND:

	(COND	((test-1) result-1)	! If test-1 is true, evaluate result-1
					! Otherwise,
		((test-2) result-2)	! If test-2 is true, evaluate result-2
		.			! Otherwise,
		.
		.
		(T result-n))		! If all else fails, evaluate result-n

This is a sequence of pairs, so could be viewed as a sequence of binary
operations.

One "conditional expression" which would be difficult to map onto COND is C's
switch statement, because the cases do not have to be terminated, but can "fall
into" one another.

It is fairly easy to see how one can specify a language such that a parser
generator can produce code which will automatically generate a syntax tree
for an expression of unary and infix binary operators.  I don't imagine that
the parser generator doesn't need to be very sophisticated to analyze

	expression ::= expression '+' expression;
	expression ::= expression '-' expression;
	expression ::= expression '*' expression;
	expression ::= expression '/' expression;
	expression ::= '+' expression;
	expression ::= '-' expression;
	expression ::= '(' expression ')';
	expression ::= identifier;

and recognize the tree structure, especially given additional hints such as
a list of operators.

But how is the parser generator going to recognize the variety of ternary
and n-ary operators?

	expression ::= 'IF' expression 'THEN' expression 'ELSE' expression;
	expression ::= expression '?' expression ':' expression;

We'd like to be able to build a virtually identical syntax tree for both of
these expressions.

Generalizing, it would be nice to be able to parse a language with an ELSIF:

	expression ::=
		'IF' expression 'THEN' expression elsif 'ELSE' expression;

	elsif ::= elseif 'ELSIF' expression 'THEN' expression;
	elsif ::= ;

and automatically generate a sequence of pairs, rather than a deeply nested
tree.


I'd like to be able to build a parser generator that required as few clues
as possible about how the syntax tree is to be structured (i.e. I don't want
the productions of the grammar to be obscured by syntax tree related
information).  So I'm hunting for ideas on how to express (or specify) the
syntax of a language (and perhaps some of the semantics) in such a way that
the language is quite recognizable, even with the additional information
which the parser generator requires.

I've looked at the methods used by YACC, GALILEO and some other parser
generators, and haven't found them very palatable.  It requires significant
formatting discipline in both of those "languages" to leave the productions
clearly visible.


Thanks in advance for any help you can lend,

James Synge

    Is an IF...THEN...ELSE...ENDIF expression really an operator?  Consider
    how an operator is evaluated - The operands are evaluated and their
    values are combined in a manner that is operator-specific to give
    the result.  That's not what happens in an IF...THEN...ELSE...ENDIF
    expression, since only one of the THEN or ELSE expressions is actually
    evaluated, although the IF expression is always evaluated.  This
    sequentiality of evaluation makes the IF clause (along with
    short-circuit forms of AND and OR) not really operators;  More
    correctly, they're concise ways of specifying a program's control
    structure.

Control structures are really LAZY operators -- in the sense that the operands
are evaluated when needed. Languages that support lazy evaluation directly often
drop many control structures, since they become unnecessary.

    re: .8, .9
    
    In a functional language, with no side effects, evaluation of
    subexpressions is irrelevant to the semantics.  It is certainly
    possible to have a functional language that uses the IF-THEN-ELSE-ENDIF
    syntax to denote a function IF(C,X,Y) whose semantics are specified
    as being the value X, if C has the value true, and the value Y,
    if C has the value false.  The end result will be the same, whether
    or not both X and Y are evaluated.
    
    In this model, IF-...-ENDIF is really and truly an operator, both
    syntactically and semantically.  You just hope that any real
    implementation of this is smart enough to avoid unnecessary
    computations, perhaps by treating it as a control structure in the
    traditional sense, or perhaps by lazy evaluation as George explained in
    .9.  The LISP COND expression has these semantics, though I imagine
    most real implementations treat it as a control expression.
    
    Somehow I thought the original discussion was concerned with syntactic
    issues, and not the semantic or implementation issues.  If so, we
    should try to keep this discussion on track (he says, after having
    continued the digression himself).
    
       Gary