Re: what if "languages" don't respond to 754R ?

[Jason Riedy <ejr@xxxxxxxxxxxxxxx>]

And David Hough writes:
> > There are a few unresolved issues including interactions with
> > dynamic typing
>
> If you have an expression evaluation rule that is a function of
> various input formats and perhaps other information, what new
> issue does dynamic typing introduce?  The format of an
> operation would become dynamic too.

One example is from the last sentence of B.3:
    Languages define rules for types of generic function return
    values according to the function parameters.

Then consider (setq var (read-from-file filename)).  There is no
declared type and no applicable rule.  Or consider dynamic typing
and laziness (e.g. R and S+).

If made into a "shall", these examples conspire with the rules in
B and limit the scope of an expression in a dynamic language to
*only* a single operation.  But when limited to a single
operation, the reproducibility requirement becomes redundant and
practically useless!

So within a dynamic language, the question of defining what we
really want and how to achieve it still is open.

> Although typical dynamic scripting languages might have only
> one floating-point type, and then expression evaluation gets
> pretty simple.

I know that Matlab, Octave, R, S+, Perl, Python, and Lisp have
multiple floating-point types available either by default or
through modules.  They're not going away or lose features because
you keep ignoring them.  And numerical programmers certainly
write applications and libraries in a few of them.

I'm not sure about scripting languages; they typically only have
one type (strings) available to users anyways.

> I personally would be happy to leave out (or make "should") the
> widenTo stuff if we retained a requirement that each language
> define a reproducible expression evaluation mode - [...]

"Mode" is not the right word.  It will be confused with rounding
modes, etc.  I'm well aware that you'd prefer all uses of modes
to become static, but that's a separate topic.  I can't think of
a sane way to implement a dynamic "reproducible evaluation mode"
without extreme limitations on the rest of the runtime system.

Besides, if you want reproducible evaluation for debugging a
production system, you don't want to reproduce *some* evaluation,
you want to reproduce the one that exhibits the bug.

The language in B.1.Reproducible Results is better except for
the glaring typo; use either em-dashes or commas but not both.

But again, which results are reproducible?  What is the extent of
a reproducible expression?  What are the allowable constraints?
If a language restricts a reproducible expression from calling
functions, is it still conformant?  This last question has a
*huge* impact on both the definition and uses of the language.

I honestly don't think answering these questions correctly and
clearly is feasible for *this* version of 754.  There is more
work to be done, and I suspect that simply declaring that someone
else must do it won't fly with potential adopters.

> I think the larger issue that has not been explicit very much
> is that it would be a good thing if portable source code could
> include programmers notations in some form about what
> non-default modes should govern sections of program text.

Amen.  That requires a bit more work to determine which notations
and notions make sense within different language semantics, and
then suggestions of how to include them in the syntax...  None of
this is fundamentally difficult (or even qualifies as publishable
research to much of the language community), but it requires a
ton of nit-picking.

Jason, really being quiet now, and unfortunately not debugging
the lack of threading in the archives...  urgh.