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]\>\"", "->", "\"\<∨\>\""}], ",", "\[IndentingNewLine]", RowBox[{"\"\<\[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

**Follow-Ups**:**Re: Re: Re: 2.9.2 How Input and Output Work***From:*Andrzej Kozlowski <akoz@mimuw.edu.pl>

**Re: Re: Re: 2.9.2 How Input and Output Work***From:*Andrzej Kozlowski <akoz@mimuw.edu.pl>

**References**:**2.9.2 How Input and Output Work***From:*"Steven T. Hatton" <hattons@globalsymmetry.com>

**Re: 2.9.2 How Input and Output Work***From:*"Steven T. Hatton" <hattons@globalsymmetry.com>

**En:Re:String filtering problem**

**Re: Inconsistent evaluation**

**Re: Re: 2.9.2 How Input and Output Work**

**Re: Re: Re: 2.9.2 How Input and Output Work**