🚀 go-pugleaf

In article <1992Oct6.172929.22566@yrloc.ipsa.reuter.COM> rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) writes:
>In article <1992Oct5.105741.26289@bnr.co.uk> pgh@bnr.co.uk (Peter Hamer) writes:
>>In the referenced article izahi@bsc.no (Raul Izahi Lopez Hernandez) writes:
>>>In article <1992Sep29.232852.22456@CS.ORST.EDU> crowl@jade.CS.ORST.EDU (Lawrence Crowl) writes:
>>>>>This is one of the problems with the current HLLs, the inability to use
>>>>>"mathematical" type notation.


>>I desperately want to be able to code at a suitable level of abstraction,
>>and maths has traditionally done this. However transcribing formulae from
>>books can be difficult ...

			................

>That old "user-convenience feature" of eliding the multiply sign comes
>back to haunt...


>>3) Often excessively subtle clues are given to indicate important facts.
>>   The thickness of the blanks indicates if `cos abcd' means (cos(a*b))*c*d
>>   or any of the other potential parsings. Deciding where summations,
>>   integrals, etc end can be similarly difficult.

>Very hard on blackboards as well as in books. This is why there is a big
>advantage in abandoning de facto rules on evaluation precedences. The 
>other big win on abandoning those rules is that you don't have MEMORIZE
>Big Tables of them, only to screw them up in your most critical application.
>J, like APL, says a function is a function is a function. 

On this, I completely agree.  About the only one I find reasonable is that
unary operators should be used first unless parenthesized otherwise.  But
there is a problem here; I frequently want to use &~ as a binary operator.

Just what is the relative precedence for << and +?  Most people would use 
the << operator first, but I believe that C uses + first.

>>   *Many* times I have had to re-derive a published formula to understand
>>   how it should be parsed.

There is unclear writing everywhere.  I have had to rederive C code to 
understand what it does.  And the great bulk of programmers would have
to write out APL or J (which Mr. Bernecky is propounding so highly) in
a more extensive form to understand what it does in its concise language.

>>4) The notation used in any particular book is often, at least in part,
>>   unique to that book. This is probably also true of the type-setting rules.

>And, sometimes, they even document what it is..

>>So. I would like to be able to code in the most appropriate notation.
>>Often this will be maths-like. To do so properly would require at least
>>the layout facilities of something like [La]TeX; and [La]TeX source is
>>hardly the model of clarity [I use it, its the best game in town]. Even
>>then traditional maths type-setting rules probably do not always make the
>>meaning of the formula sufficiently clear (this may not be true if you are
>>a professional typesetter), and the current type-setting rules almost
>>certainly break-down for `long' names.

>I have not tried this, but it might be interesting to generate LaTeX
>from J scripts. 

I do not think it is that bad.  Again, it is ASCII which makes the problems.
There is no good reason for this now.

My opinion is that the number of conventions in [La]TeX is greater than
that in all of mathematics.  These should be considered as stopgaps required
by the limitations of ASCII, but even here, much better can be done.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@pop.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!pop.stat!hrubin(UUCP)