Unevaluated

[mmatera]

In #58 I tried to fix this issue:

In WMA

In[1]:= F[a, Unevaluated[a]]
Out[1]:=F[a, Unevaluated[a]]

In Mathics

In[1]:= F[a, Unevaluated[a]]
Out[1]:=F[Unevaluated[a], Unevaluated[a]]

This happens because as now Symbols are singletons, the old mechanism of setting a property does not work anymore. In #58, I tried to fix this using a table. However, this does not work in general, if F has the attributes Orderless or Flat, because the order is lost.

[rocky]

This feels more of the kind of confusion we've been having. A Lisp or WL Symbol is unique. In other words the name "a" is unique. What is meant by a in the expression Unevaluated[a] is a symbolic variable (or maybe "symbolic value") whose name is Lisp/WL Symbol a. Note that the a in Unevaluated[a] is no different than the a in a + 5. Both are expressions. The difference is that Unevaluated has a property that indicates for any variable just use its name.

Often people shorten "symbolic variable" to "symbol".

Possibly Mathics' Symbol class should be renamed to Variable or maybe SymbolicValue which consists of a name ("Symbol") and a binding value ("Definition"?) or a indication that the binding is "unbound" . And in the process, a new Symbol class should be added that matches Lisp/WL Symbol in that stricter narrower definition.

Unfortunately the name "Symbol" has been used to mean both the a Symbol name (but SymbolName is another WL function) as well as a symbolic variable/value. Variables can be unbound, or bound. Variables also have a scope attached to them.

[mmatera]

@rocky, in WL there are no "symbolic variables" (in the sense of something that has at some point a value), just Symbols, and lists of rules (organized as Definitions) associated with the symbols.

[mmatera]

https://www.ibm.com/docs/en/zos/2.3.0?topic=variables-what-is-symbolic-variable
https://www.mathworks.com/matlabcentral/answers/320690-what-are-symbolic-variables

[rocky]

@mmatera By "symbolic variable" I mean unbound variable.

[rocky]

An unbound symbol is what Lisp calls a Symbol. And saying a Symbol is unbound implies that a Symbol can be bound. I suspect that this is the missing concept, variable binding, in Mathics.

[mmatera]

In WMA, bindings are given through the ownvalues associated with the symbol.
Is it possible in LISP to set something like

In[1]:=a:=1/;x>0;
In[2]:=a:= 0;
In[3]:=a
In[4]:=0
Out[4]=0
In[5]:= x=1; a
Out[5]=1   

In that case, how this would work here using that concept?

[rocky]

the getter function for variable "a" would be a lambda function that returns 1 if x is greater than 0.

Is this how #628 works?

[mmatera]

Nop. It was just to narrow the idea about what would be here a "bounded variable". #628 avoids to monkey patch a symbol by changing the expression Unevaluated[symb] by a wrapper surrounding symb, which produces the right behavior under sort and flat. I can add a more detailed explanation about how the wrapper works, or add more examples/tests.

Otherwise, just keep this here as a draft, like several other PRs, until we have a clearer picture, and then check against the tests a fix from another approach. The effort here was put in localizing the change just in the method we need to fix in order to get the right behaviour.

[rocky]

Yes, let's keep this as a draft.

[rocky]

@mmatera While waiting on #1432 I looked at what's up with Unevaluated. The original implementation has some fundamental flaws, in my opinion.

Regarding all the discussion about how Symbols or other Atoms are singletons, so we can't have two that have the "unevaluated" property, well, this property does not belong on the Symbol. It belongs to the collection of parameters under Unevaluated.

From Mathematica 5, page 340:

Unevaluated[expr] effectively works by temporarily giving a function an attribute like HoldFirst, and then supplying expr as an argument to the function.

A property like HoldFirst does make sense on symbols, but rather on the parameters of functions. We already have elements_properties for a compound expression, and that has "elements_fully_evaluated". And this seems like the same idea.

Sort of related, or maybe saying the same thing differently, is the fact that setting "element.unevaluated" is wrong because this property (as I currently understand, but I don't fully understand Unevaluated), is a local property of the expression, not something that belongs to an element.

Ideally, it would be nice to contain everything inside the evaluation method of Unevaluated. Similarly, it feels wrong to put in knowledge about specific functions inside the main rewrite/apply/evaluate step. Adding a property to an element turns some local feature about a particular expression into a global feature regarding some element. Recall that Atoms are elements too.

I don't see how to not alter rewrite/apply/evaluate since that is precisely the routine that can look at the local context around an expression. But if I can't remove it, we can at least reduce that and try to put in as much stuff in the eval method as we can, which right now is not very much.

Lastly, I come to the test case:

"ClearAll[f];
"Attributes[h] = Flat;h[items___] := Plus[items];
h[1, Unevaluated[Sequence[Unevaluated[2], 3]], Sequence[4, Unevaluated[5]]]

It is currently failing in the PR, but honestly, I wouldn't understand why it gets the results it does in WMA.

Please explain how this works. How one should think about the Flat attribute interacting with Unevaluated and Sequence. Why do we need Unevaluated, especially when combined with Plus on a single (fully evaluated or constant) integer argument like 2 or 5?

Is this a made-up contrived example, or has this come up? If it is useful, under what circumstances would someone need and write something like this? From looking at what I can in WMA or the Mathematica 5 book, I just don't see how this fits in.

There is one further example from the examples in https://reference.wolfram.com/language/ref/Unevaluated.html?view=all where "Unevaluate stops Evaluate". We don't have this, but that can be easily added, I think.