On Feb 9, 2010, at 12:56 AM, Rich Cooper wrote:
> Chris,
>
> Actually, it's more complicated than that. Value is simply one property of
> a Thing in a universe. Identity wrt a Definition property is a complete
> different issue. You are confusing a logical specification of value with a
> logical instance of a value. (01)
No, really I'm not. You are bringing concepts out of the semantics of
programming languages into the semantics of first-order languages. (02)
> For example, in the equation
>
> F(x) = x^3+27*x^2
>
> The left hand side is 'equal' to the right hand side, and evaluation of both
> sides leads to the same results. (03)
Well, not necessarily; in first-order logic, that depends on the value that has
been assigned to the function symbol "F". And, in first order logic, we
wouldn't put "equal" in single quotes as if there were multiple meanings to the
word. (04)
> But if I want to represent the symbolic function F(x), for example, as a
> Lisp structure of operators and operands that can be used in evaluation of
> F(x), or that can be manipulated algebraically to create new expressions, it
> might be better to state it this way (forget the messy Lisp notation):
>
> Define( F(x), (x^3+27*x^2) ) (05)
I think you are referring to the LISP operator "defun", in which case you want: (06)
(defun F (x)
(* (+ (expt x 3) 27) (expt x 2)))) (07)
> Which states that the identify of the symbol F(x) is defined to be equal to
> the evaluable structure (x^3+27*x^2) which can be used to calculate the
> value of F(x) bound to any x.
>
> Those are two different views of '=' - by value and by defined structure
> (expression or object, perhaps). (08)
No, they aren't. Equality and defun are two entirely different things in LISP.
If you're going to appeal to LISP, you might be able to make your point more
profitably by appealing to its several related but distinct notions: -- "eq",
"eql", "equal", and "equalp". But the general problem, again, is that you are
conflating the semantics of first-order logic with the semantics of programming
languages. (09)
> The interpretation can be calculated to get the value, but the interpretation
>is distinct from the value it gets at any given time. (010)
You illustrate my point nicely. LISP is a programming language; it is not a
first-order language. The semantics of programming languages is far more
specialized and, generally, far more complex than the semantics of first-order
languages; consider, e.g., the mathematics of domain theory that underlies the
denotational semantics of Scott and Strachey. The semantics of LISP, in
particular, is a very rich and difficult subject that involves not only general
issues in the semantics of programming languages such as support for recursion
but also issues related to list processing and the semantics of LISP's
distinctive operators like "defun", "cons", "car", "cdr", "setq", etc. These
issues are light years removed from vanilla first-order model theory. (011)
> HTH, (012)
Likewise. (013)
-chris (014)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (015)
|