Services & Resources / Wolfram Forums / MathGroup Archive

MathGroup Archive 2005

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Re: 2.9.2 How Input and Output Work

  • To: mathgroup at smc.vnet.net
  • Subject: [mg61947] Re: Re: 2.9.2 How Input and Output Work
  • From: "Steven T. Hatton" <hattons at globalsymmetry.com>
  • Date: Sat, 5 Nov 2005 01:52:51 -0500 (EST)
  • References: <200511010539.AAA15747@smc.vnet.net> <dk9vr5$6su$1@smc.vnet.net> <200511030958.EAA26520@smc.vnet.net> <dkfcnk$ep5$1@smc.vnet.net>
  • Sender: owner-wri-mathgroup at wolfram.com
Chris Chiasson wrote:

> The syntactic rules, to me, are rules for parsing input into FullForm
> expressions. There are some areas of Mathematica where these rules are
> not available, such as certain initialization files. In those files,
> only the regular head[arguments] scheme works.

This is all quite an interesting topic. There are languages that are written
left-to-right, some written right-to-left, and some top-to-bottom.  Until
the twentieth century nobody every conceived as anything so contrary to
normal human intellect as to read bottom to top.  But, as it happens, there
was particular software vendor who controlled the overwhelmgin majority of
the market, and whose software developers were incapable of placing the
edit point after the body of the message being replied to.  The users,
believing that such things were done for good reason, accepted the
substandard convention, and thus we have people who top-post.

> There are many rules for parsing... in addition to processing boxes
> into certain Mathematica operations, certain inputs are recognized as
> prefix, infix, matchfix or postfix operators... like um...
> prefix @@
> infix + or ==
> matchfix (like infix but has ends) {,,}
> postfix //
> 
> there are other *fix operators, but I am ignoring them.

The term used in highfalutin technical circles to talk about such *fixs, is,
I kid you not, fixity.  I'm finding the exercise of studying how
mathematics is expressed electronically to be quite revealing. I'm trying
to write some basic definitions for fundamental mathematical terms, and
when I started trying to describe the logical negation connective (not
operator), I found myself trying to describe how it behaves without talking
about it's fixity.  I am also trying to avoid the use of the term operator,
since it implies that the operator is modifying the operand, and that the
operator is somehow "more active" than the operand.  My objective is to
treat the symbolic expressions as inert, and only taking on meaning when
they are processed by the human or machine.  This is my current working
definition of !:

Logical Negation: A unary connective which when followed by a true
proposition forms a false proposition, and when followed by a false
proposition forms a true proposition.

Note that I don't define exactly what "followed by" means.  Basically any
string of semantically related symbols can be deconstructed into a "tree"
representation, and that tree can be traversed infix, prefix, postfix, or
in a context specified ordering.  "Followed by" can probably be expressed
in terms of these forms of traversal.

> These different operators all have a different precedence which leads
> to a different order of operations (just like regular Math defines
> 1-2/1=0 instead of -1/2). 

After sending out my message about the lack of a biconditional operator, I
tried using the infix Equal operator ==, and found it also does not bind as
I had expected.  !(P||Q)\[Equal]!P||!Q//FullForm.  After thinking about it,
I now realize it binds in a way that facilitates computer programming, not
symbolic logic expressions.

> Mathematica would be a ridiculous pain in 
> the butt for which to program without operators. One wouldn't even be
> able to write 2+2 and get out 4.

There is a school of Mathematics which favors the prefix functional operator
notation.  There is a certain elegance of simplicity which arises from the
exercise.  Personally, I find Lips virtually unintelligible, but I can
certainly understand how a person who has as strong grasp of the
fundamentals could find Lisp to be a very clean, regular and predictable
language.  Mathematica FullForm (aka InternalForm) is very much like Lisp. 
It is also very much like XML.
 
> There is a long description, somewhere in the documentation, about
> what happens to input as it is evaluated.

I believe I've read pretty much all of the discussion in The Mathematica
Book regarding of how the different stages of evaluation take place. (That
is different from saying I have mastered it.) I do not believe there is any
consideration of FullForm, per se, before the expressions get to the
kernel.  There are some kernel-like capability of the FrontEnd, but I don't
know the extent of these.  It is certainly the case that what you see in
the C-E view /could/ be processed by the kernel, and translated into
FullForm. 

WRI should really enhance that editing interface with highlighting, code
completion, error beeps, etc. The biggest reason I have avoided it until
recently is because everytime I looked stuff like the following, my eyes
just went crossed:

Cell[BoxData[
    RowBox[{"XML`MathML`ExpressionToMathML", "[", 
      RowBox[{
        RowBox[{
          RowBox[{"(", 
            RowBox[{"¬", 
              RowBox[{"(", 
                RowBox[{"P", "\[And]", "Q"}], ")"}]}], ")"}],
"\[DoubleLeftRightArrow]", 
          RowBox[{"(", 
            RowBox[{
              RowBox[{"¬", "P"}], "\[Or]", 
              RowBox[{"¬", "Q"}]}], ")"}]}], ",", "\[IndentingNewLine]", 
        RowBox[{"\"\<Formats\>\"", " ", "\[Rule]", 
          RowBox[{"{", "\"\<PresentationMathML\>\"", "}"}]}], ",",
"\[IndentingNewLine]", 
        RowBox[{"\"\<Entities\>\"", "->", 
          RowBox[{"{", "\[IndentingNewLine]", 
            RowBox[{"\"\<MathML\>\"", ",", "\[IndentingNewLine]", 
              RowBox[{"\"\<\[Implies]\>\"", "\[Rule]", "\"\<&Implies
\>\""}], ",", "\[IndentingNewLine]", 
              RowBox[{"\"\<\[SuchThat]\>\"", "\[Rule]", "\"\<&SuchThat
\>\""}], ",", "\[IndentingNewLine]", 
              RowBox[{"\"\<\[Or]\>\"", "->", "\"\<&or;\>\""}], ",",
"\[IndentingNewLine]", 
              RowBox[{"\"\<\[And]\>\"", "->", "\"\<&and;\>\""}]}],
"\[IndentingNewLine]", "}"}]}]}], 
      "\[IndentingNewLine]", "]"}]], "Input",
  CellLabel->"In[123]:="]

> Please let us know if you find out how the kernel and notebook FE
> interact when it comes to input.
> 
> Instructive places to start might be to look at how Mathlink tells the
> kernel to do calculations, or to look at how other front ends (like
> the old one for EMACS, I think, ~ version 2.0) handled talking to the
> kernel.

The MathLink documentation describes the lowlevel details of how expressions
are queued up, and sent between the client and the server.  It's really
quite straightforward.  The art is in determining strategies for making use
of the facilities.
-- 
"Philosophy is written in this grand book, The Universe. ... But the book
cannot be understood unless one first learns to comprehend the language...
in which it is written. It is written in the language of mathematics, ...;
without which wanders about in a dark labyrinth."   The Lion of Gaul
  • Prev by Date: En:Re:String filtering problem
  • Next by Date: Re: Inconsistent evaluation
  • Previous by thread: Re: Re: 2.9.2 How Input and Output Work
  • Next by thread: Re: Re: Re: 2.9.2 How Input and Output Work