Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unevaluated #122

Open
mmatera opened this issue Jan 20, 2022 · 9 comments · May be fixed by #628
Open

Unevaluated #122

mmatera opened this issue Jan 20, 2022 · 9 comments · May be fixed by #628

Comments

@mmatera
Copy link
Contributor

mmatera commented Jan 20, 2022

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
Copy link
Member

rocky commented Jan 21, 2022

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
Copy link
Contributor Author

mmatera commented Jan 21, 2022

@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.

@rocky
Copy link
Member

rocky commented Jan 21, 2022

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

@rocky
Copy link
Member

rocky commented Nov 21, 2022

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
Copy link
Contributor Author

mmatera commented Nov 21, 2022

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
Copy link
Member

rocky commented Nov 21, 2022

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
Copy link
Contributor Author

mmatera commented Nov 21, 2022

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
Copy link
Member

rocky commented Nov 21, 2022

Yes, let's keep this as a draft.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants