8
$\begingroup$

Reading the comments in this answer has motivated me to request a full solution to part of this problem.

What I'd like is an efficient solution that returns True if there exist an OwnValue and False in all other cases. This narrow behavior mirrors what folks coming from other programming languages expect of asking if something has a value or not.

A solution needs to be able to handle symbols with any number of OwnValue, UpValues, DownValues, SubValues, NValues, and FormatValues. The only evalution that should occur is that required to get the value of the symbol's OwnValue.

Motivation

My motivation for this request is twofold.

  1. There have been many queries on this topic, but none that appear to be specific enough to narrow down to one correct interpretation. I hope this question solves that.
  2. The behavior requested mirrors the behavior of most programming languages that folks are familiar with. That is, when we think of a symbol/"variable" having a value, we really mean to ask if the symbol has some OwnValues or not. Yes there are other interpretations of what it means to have a ValueQ that does not do extra evaluations, but this question does not cover them.
Improve this question
$\endgroup$
23
  • $\begingroup$ This is a rather complex problem. This inspired me to ask the same (thinking that a solution is ready), but it turned out to have some more subtle points. $\endgroup$
    – Szabolcs
    Mar 23, 2012 at 21:05
  • $\begingroup$ It is a duplicate indeed. However, those answers need a kind of a "philosophical" update, because what looks at the surface as a problem of evaluation leaks is in fact a problem of the impedance mismatch between Mathematica evaluation process and what we usually mean when saying that something has a value. One of the solutions by @Mr.Wizard can actually IMO serve as a definition for ValueQ consistent with Mathematica's evaluation semantics - but it turn out to not be very useful in practice, since it triggers even trivial evaluations. $\endgroup$
    – Leonid Shifrin
    Mar 23, 2012 at 21:08
  • 1
    $\begingroup$ In other words, the main problem is to distinguish between evalations which we consider leaks and those which we don't. The comments below the solution of @Mr.Wizard and this chatroom contain more on that. $\endgroup$
    – Leonid Shifrin
    Mar 23, 2012 at 21:11
  • 2
    $\begingroup$ let us continue this discussion in chat $\endgroup$
    – Leonid Shifrin
    Mar 23, 2012 at 21:50
  • 1
    $\begingroup$ @Mr.Wizard please see the chat conversation leo and I had. I was in the process of narrowing this question down to request a very specific behavior that has only one valid answer, leo agreed that doing so would be a worthwhile action. I really would like to have this re-opened so I may narrow the question down correctly so it is not a duplicate. $\endgroup$
    – nixeagle
    Mar 23, 2012 at 22:18

1 Answer 1

Reset to default
10
$\begingroup$

Leonid and I had a very productive chat with the end result of Leonid asking me to go ahead and post the answer. If others have a better answer to this narrowly phrased question please do not let my submission deter you!

Essentially the problem with these "safe" ValueQ questions is one of interpretation. What does it mean when we ask if a symbol has a value?

  1. Mathematica says a symbol has a value if it has any of the following: OwnValues, UpValues, DownValues, NValues, SubValues or FormatValues. This makes sense in the context of MMA being essentially a glorified pattern matcher.
  2. Folks that come from a non MMA background with prior programming experience will say that a symbol only has a value if it has some OwnValues. This mirrors the behavior of nearly every non MMA programming language in existence.

In order for MMA to implement #1 above, MMA chooses to do some evaluation in order to determine if any of the Up/Down/N/Sub/Format values actually contain a meaningful value. This is the heart of the problem. If the user expects behavior #2, that can be had with a very simple function that requires no evaluation at all.

SetAttributes[ownValueQ,HoldAll];
ownValueQ[s_Symbol] := ValueQ[s]; 
ownValueQ[_]        := False

The above includes no evaluation as the implementation of ValueQ when handling OwnValues on a symbol is: 

HoldComplete[sym]=!=(HoldComplete[sym]/.OwnValues[sym])
Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.