Sun Microsystems Laboratories Experimental Stuff [Fortress-interest] Mathematical Notation - coding, ASCII conversion, scanning and re ndering

[Fortress-interest] Mathematical Notation - coding, ASCII conversion, scanning and re ndering

Bill Callahan bcallahan@cra.com
Thu, 28 Sep 2006 08:49:17 -0400


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C6E2FC.826A7A50
Content-Type: text/plain

I attended Guy's talk yesterday at Harvard and was very impressed with
Fortress and the work his team is doing.  I know that most of the
concentration now is the language specification, I have some specific ideas
about implementation.
 
Traditionally, programming languages are linear.  The text of a program
exists as a string of characters.  In the case of Fortress, they are Unicode
5.0 codepoints which can be rendered as glyphs.  But mathematical notation
is inherently two dimensional.  This why representing formulae in
programming languages seems so unnatural.  An example of this is how the
division bar in an expression serves not only to indicate an operation, but
to imply the order of operations by placing one expression above it and one
below it, with no need of brackets.  I think that Fortress should be able to
capture this two-dimensionality.  It's true that some languages use two
dimensionality minimally to indicate nesting (such as Python does), but the
two dimensionality in mathematical notation is much richer.
 
Guy said in his presentation that the ASCII conversion could be represented
in a Wiki style.  I think that this Wiki style representation needs to
capture not only which Unicode characters to insert, but also two
dimensional orientation, as Wiki does with tables, for example.  In fact,
the Wiki table pattern would be a very good way to represent a matrix in the
ASCII conversion.
 
I also think that that the scanner used for the compiler should also be
available for use by the renderer.  That way, an IDE could use the scanner
for its presentation so that the coder gets instant feedback on how Fortress
is interpreting the code.  Without a tie-in like this (or a similar tie-in),
finding a bug that is due to the difference between the compiler's
interpretation of the code and the user's could be quite tedious, especially
if the user could only discover the difference through testing.  I think
that this concept is more important in Fortress than other languages because
of the subtlety of the interpretation of mathematical notation as it is used
in the field, as Guy demonstrated very well in his presentation.
 

Bill Callahan 
Senior Software Engineer 
Cognitive Systems Division 
Charles River Analytics 
625 Mt. Auburn St., Cambridge, MA 02138 
Tel: 617-491-3474 x623 | Fax: 617-868-0780 
Email:  <mailto:bcallahan@cra.com> bcallahan@cra.com | http://www.cra.com
<http://www.cra.com/>  

 

------_=_NextPart_001_01C6E2FC.826A7A50
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">


<META content="MSHTML 6.00.2900.2963" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=484571312-28092006><FONT face=Arial size=2>I attended Guy's 
talk yesterday at Harvard and was very impressed with Fortress and the work his 
team is doing.&nbsp; I know that most of the concentration now is the language 
specification, I have some specific ideas about 
implementation.</FONT></SPAN></DIV>
<DIV><SPAN class=484571312-28092006><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=484571312-28092006><FONT face=Arial size=2>Traditionally, 
programming languages are linear.&nbsp; The text of a program exists as a string 
of characters.&nbsp; In the case of Fortress, they are Unicode 5.0 codepoints 
which can be rendered as glyphs.&nbsp; But mathematical notation is inherently 
two dimensional.&nbsp; This why representing formulae in programming languages 
seems so unnatural.&nbsp; An example of this is how the division bar in an 
expression serves not only to indicate an operation, but to imply the order of 
operations by placing one expression above it and one below it, with no need of 
brackets.&nbsp; I think that Fortress should be able to capture this 
two-dimensionality.&nbsp; It's true that some languages use two dimensionality 
minimally to indicate nesting (such as Python does), but the two dimensionality 
in mathematical notation is much richer.</FONT></SPAN></DIV>
<DIV><SPAN class=484571312-28092006><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=484571312-28092006><FONT face=Arial size=2>Guy said in his 
presentation that the ASCII conversion could be represented in a Wiki 
style.&nbsp; I think that this Wiki style representation needs to capture not 
only which Unicode characters to insert, but also two dimensional orientation, 
as Wiki does with tables, for example.&nbsp; In fact, the Wiki table pattern 
would be a very good way to represent a matrix in the ASCII 
conversion.</FONT></SPAN></DIV>
<DIV><SPAN class=484571312-28092006><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=484571312-28092006><FONT face=Arial size=2>I also think that 
that the scanner used for the compiler should also be available for use by the 
renderer.&nbsp; That way, an IDE could use the scanner for its presentation so 
that the coder gets instant feedback on how Fortress is interpreting the 
code.&nbsp; Without a tie-in like this (or a similar tie-in), finding a bug that 
is due to the difference between the compiler's interpretation of the code and 
the user's could be quite tedious, especially if the user could only discover 
the difference through testing.&nbsp; I think that this concept is more 
important in Fortress than other languages because of the subtlety of the 
interpretation of mathematical notation as it is used in the field, as Guy 
demonstrated very well in his presentation.</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV><!-- Converted from text/rtf format -->
<P align=left><FONT face=Arial size=2>Bill Callahan</FONT> <BR><FONT face=Arial 
size=2>Senior Software Engineer</FONT> <BR><FONT face=Arial size=2>Cognitive 
Systems Division</FONT> <BR><FONT face=Arial size=2>Charles River 
Analytics</FONT> <BR><FONT face=Arial size=2>625 Mt. Auburn St., Cambridge, MA 
02138</FONT> <BR><FONT face=Arial size=2>Tel: 617-491-3474 x623 | Fax: 
617-868-0780</FONT> <BR><FONT face=Arial size=2>Email: </FONT><A 
href="mailto:bcallahan@cra.com"><U><FONT face=Arial color=#0000ff 
size=2>bcallahan@cra.com</FONT></U></A><FONT face=Arial size=2> | <A 
href="http://www.cra.com/">http://www.cra.com</A></FONT> </P>
<DIV>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C6E2FC.826A7A50--


This page is: http://www.experimentalstuff.com/pipermail/fortress-interest/2006-September/000021.html
Last Modified: Thu, 28 Sep 2006 18:42:01 GMT
copyright (c) 2000-2009, Sun Microsystems