Language issues meeting hosted by Joe Darcy at Sun in Santa
	Clara on Wednesday 11/16/05 at 1:00.  Jim Thomas & Dan Zuras
	attended & Chuck Stevens & Michael Ingrassia were on the phone.

	We began with people's wish list.  Chuck said he needed 32
	digits & since our decimal has 34 he's OK with it.  I asked
	about expressions in Cobol.  Associative expressions are
	defined to be left-to-right.  He wouldn't have any mixed
	expression problem because if he supported a 64-bit decimal,
	for example, all expressions (even purely 64-bit expressions)
	would be evaluated in 128-bit decimal.  Even FMA would have
	to be a new operation syntactically to be included.

	Joe brought up the LIA specifications as a possible approach.

	Chuck claimed that Cobol can conform to 754 by implementing
	only what his customers need.  Cobol is not interested in some
	of the features of 754.  Our position is that none of the
	optimizations that we might discuss will apply to Cobol due to
	its rigid syntax.  Cobol might support both Decimal128 &
	Binary128 (& conversions) but would NEVER support mixed radix
	expressions.

	I pointed out how all of reassociation, mixed expressions, &
	FMAs cause difficulties in other languages.

	Michael got to the central issue of (*,+,-,/) all having
	traditional meanings that are less well defined in the more
	modern context.  He quipped that the Fortran programmer cannot
	assume that 2 + 2 = 4.  Jim wanted to know whether this is a
	principle (i.e. desired) or just an acknowledgement of the
	current state of affairs (i.e. what must be lived with).

	(Michael mentioned that compiler options & directives are NOT
	part of the J3 standard but up to the implementer.)

	There is something like a "USE IEEE754_ARITHMETIC" statement
	that may effect the result of expressions in Fortran.  Jim
	mentioned that Fortran DOES honor parentheses.  Jim found out
	that Fortran would not disallow the synthesis of an FMA in the
	expression (x*y) + z because of the parentheses.  He asked if
	most Fortran implementations these days WERE, in fact, IEEE
	arithmetic.

	Joe mentioned sticky flags & rounding modes are also problems
	for languages WRT programmer intentions.

	Jim asked & Michael agreed that much of what might be required
	to give the programmer control over things like flags & modes
	would be an anathma to the 'optimization is king' principle of
	Fortran.  Michael said 'directive' is a dirty word for a Fortran
	guy.  He said Fortran2003 will support exceptions in a way that
	sounds ideosyncratic to the implementer.

	I proposed that the separation of syntax & semantics be the
	defining charecteristic of the boundary between the language
	standards & 754.  That is we (754) will define what operations
	must be possible & the languages will define how they give the
	programmer access to it.

	Chuck said that the rounding modes permitted in Cobol WITHIN
	an expression are nearest-away-from-zero, nearest-even,
	not-permitted, & truncation.  There are more for the RESULT
	of expression.  There is no such thing as a run time variable
	rounding mode.

	I think the issue of dynamic versus static may still be a
	problem but, perhaps, less so if we give the programmer more
	control over it.

	I think I got general agreement over the principle of separating
	language & arithmetic along the lines of syntax & semantics but
	I also think that everyone had his own idea of what I meant by
	that.

	We decided to call it a day at this point.

	One final administrative thing was I asked about possible venues
	for meetings past our December meeting hosted by David Hough at
	Sun in Menlo Park.

	Jim Thomas agreed to host us in January on Wednesday 1/18 &
	Thursday 1/19 at HP in Cupertino.  Joe agreed to host us at Sun
	in Santa Clara in March on Wednesday 3/15 & Thursday 3/16.  We
	had to leave February fallow as Joe will be in India that month.