Minutes June 10th

Minutes from June 10th, 1996, conference call.

Paraphrased and condensed. Some inessential topics omitted.
(Perhaps I also forgot some topics or misremembered who said what.)

Present:

bruce smith
patrick ion
ron whitney
rob miner

--

prefix embellishment:
not important enough to let the other work wait for it.

--

rob: in e.g. the expression "sin x", how does renderer know to put it in roman
and not italics?

bruce: up to renderer, but by convention, multichar identifiers are in roman,
 single char in italics. Thus no need for a dictionary entry for "\sin".

rob: what if you want a dictionary entry so that it could be a prefix operator?

bruce: in Wolfram proposal, "sin x" can be represented as an identifier "\sin",
then an invisible function application operator, then an identifer "x".
It wouldn't be good for "sin" or "\sin" to be a prefix operator.
No problem if someone wanted to propose an extended character &sin;
which could be a prefix operator, assuming no name conflicts,
except knowing where to stop in adding more and more common functions.
Also seems not important enough to clutter up the language
provided there's a short name for the invisible function application operator.

rob: this would be a good use for macro packages once we have them.
[Then the main proposal needn't have this kind of convenience definition.]

bruce: yes, that's what Dave has suggested too;
we all agree this should be possible
but no one has yet proposed all the details of a macro system.
Also, plugins might need macro definitions (directly or via a file or URL
reference)
with every math element.

ron: this might be slow.

rob: probably not a problem in HotJava browser -- you can redefine how it treats
every HTML tag.

[not discussed: can macros define new "extended characters" themselves,
without a direct rendering but for use as new operators?]

--

rob: does absence of comment on Wolfram proposal's mrow, mterm, etc,
mean people think they're ok, and I can start implementing classes for them
in Java?

bruce: I guess so, but you better ask them to be sure.

[We then discussed what we can assume about the layout schema for tables,
since these are not yet in Wolfram proposal, and Dave will be proposing
a spec for these based on his earlier work. We concluded that whatever
the final proposal, it ought to be able to work with two new layout schema,
one for table columns, one for table rows. For now we can call these
mtablecolumn and mtablerow when using them with the other layout schema
of the Wolfram proposal, but these names might change. The reason to have
mtablerow != mrow is that they are rendered quite differently, and also to
allow an mcolumn to be used alone (without mtablerows in every entry)
and to contain an mrow, without ambiguity.]

--

end