W3C home > Mailing lists > Public > www-math@w3.org > June 2007

RE: How to handle a where-list in MathML

From: Stan Devitt <stan.devitt@gwi-ag.com>
Date: Thu, 7 Jun 2007 08:14:03 +0200
Message-ID: <1512B5F2ED998C4BB3E2688B8EBEDB799A0D2E@mxex-tr-01.gwi-ag.com>
To: <m.kohlhase@jacobs-university.de>, "David Carlisle" <davidc@nag.co.uk>
Cc: <r.muetzelfeldt@ed.ac.uk>, <www-math@w3.org>
Actually I would argue that the original solution (albeit with csymbol instead of cn) is in fact cleaner.

It comes down to this subtle but very important point.  I want to "see" that a where clause is being used.  I don't want to reverse engineer that fact out of what amounts to line macro expansions.


If a particular construct is intended to be used frequently it is important that it be recognized as such.  The lambda calculus solution does the job, but because lambda expressions can be used in very general ways, its use in this setting makes it less readable.  However, by actually introducing a where operator with the proposed semantics it makes it much easier to recognize what the author is doing and to pick out a particular style of use.

Good authoring and communication depend on introducing the right abstractions and do  not generally come out of using inline encodings which is what the other amounts to.

Now if you want to use the lambda calculus to introduce a machine readable definition of "where", then I would agree with the approach.

Stan



-----Original Message-----
From: www-math-request@w3.org on behalf of Michael Kohlhase
Sent: Thu 6/7/2007 6:14 AM
To: David Carlisle
Cc: r.muetzelfeldt@ed.ac.uk; www-math@w3.org
Subject: Re: How to handle a where-list in MathML
 

Dear all,

I really like David's representation it seems the cleanest so far, 
because it highlights the 'bound variables' character of a and b (for 
instance they can be renamed without changing the meaning of the 
expression).

To make things more explicit, it may be best to combine the two ideas 
and use a <csymbol > variant of lambda to make it clear that the 
beta-reduction David is talking about should maybe executed at different 
occasions than that for regular lambdas.

Michael

David Carlisle wrote:
> I agree with Robert that csymbol is probably better than ci but that
> otherwise that's a good encoding.
>
> An alternative viewpoint that I picked up in a previous life working in
> formal systems that essentially viewed everything as a lambda expression
> is that 
>    2*a+3*a^2+b+b^2 WHERE a=5+c*2, b=17-d
> is syntactic sugar for
>   (lamda a b. 2*a+3*a^2+b+b^2)(5+c*2, 17-d)
>
> that is first create the anonymous function of two variables
> representing the bound variables in your expression, then apply that
> function to the two  expressions which hold the definitions of the bound
> variables.
>
> This could be encoded directly in mathml as
>
> <apply>
> <lambda>
> <bvar><ci>a</ci></bvar>
> <bvar><ci>b</ci></bvar>
> <apply>
> <plus/>
> <!-- mathml for 2*a+3*a^2+b+b^2 -->
> </apply>
> </lambda>
> <apply>
> <plus/>
> <!-- mathml for 5+c*2-->
> </apply>
> <apply>
> <plus/>
> <!-- mathml for 17-d-->
> </apply>
> </apply>
>
>
> This has the advantage of being coded in core mathml without needing any
> csymbol defined operators, it has the possible disadvantages of being
> possibly harder to read by humans, and possibly more likely to be
> automatically "expanded out" by a system consuming the expression, just
> as
> <apply><plus/><mn>1</mn><mn>1</mn></apply>
> might not be the best encoding of the concept 1+1 if you want it to
> survive importing it into a CA system and not have it be seen as 2.
>
> David
>
>
>
>
> ________________________________________________________________________
> The Numerical Algorithms Group Ltd is a company registered in England
> and Wales with company number 1249803. The registered office is:
> Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.
>
> This e-mail has been scanned for all viruses by Star. The service is
> powered by MessageLabs. 
> ________________________________________________________________________
>
>   

-- 
----------------------------------------------------------------------
 Prof. Dr. Michael Kohlhase,       Office: Research 1, Room 62 
 Professor of Computer Science     Campus Ring 12, 
 School of Engineering & Science   D-28759 Bremen, Germany
 Jacobs University Bremen*         tel/fax: +49 421 200-3140/-493140
 m.kohlhase@jacobs-university.de http://kwarc.info/kohlhase 
 skype: m.kohlhase   * International University Bremen until Feb. 2007
----------------------------------------------------------------------
Received on Thursday, 7 June 2007 06:15:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 20 February 2010 06:13:00 GMT