Dear All,
Is there a way in reduce to query if a name is already defined, e.g., as an operator?
Why I am asking is that I tried to run an old reduce file written by a late colleague, and it did not run. I localised the error to be a definition of an operator de, e.g.,
operator de;
for all f let de(f)=df(f,r);
and I get the rather cryptic error message
+++ Error attempt to take car of an atom: nil
Changing the name de to, e.g., den everywhere solves the problem.
I am using the jan 20 snapshot on Linux.
Thank you: Arpad
Last edit: arpi 2019-02-06
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
At least if you use low-level facilities it is possible to see all sorts
of things.
Eg you can go
lisp getd 'de;
which may say (fexpr . de), where you vam contrast that with the output
from lisp getd 'nothing_in_particular;. And
lisp prop 'de;
where the presence of the "number-of-arguments" property tends to be a
signature of something that has been defined.
The way I would check yet further would be to start by loading up
bootstrapreduce rather than the main (production) version.
bootstrapreduce is slower but has extra information saved within it.
Then I would go
lisp;
load!-source();
plist 'de;
and that would reveal to me a suggestion that someting might be defined
on line 628 of the file [.../packages/]misc/rcref.red and while in this
case that is not actually very interesting in other case it might be and
could point you are the location in the Reduce sources to investigate
further.
The cryptic error message is not as it should be - obviously. One can sort
out a bit more by setting "on backtrace;" before attempting the
systatement that fails. Here I see
4: for all f let de(d) = df(f, r);
+++ Error attempt to take car of an atom: nil
Inside: formde
Arg1: (de d)
Arg2: nil
Arg3: algebraic
Inside: form1
Arg1: (de d)
Arg2: nil
Arg3: algebraic
Inside: formlet1
Arg1: ((equal (de d) (df f r)))
...
where the formfn you saw mentioned on the property list of 'de is
expectiing the system-style use of "de" that has a form like
"(de increment (x) (plus x 1))" or some such - and when it gets just "(de
d)" it gets upset. It is easy to find the code concerned - it is in
packages/rlisp/proc.red and formde does not validate the form of the
expression it is given at all - it just assumes it is a list of length 4
or more. I think this case is not one that makes me rush to update the
code for formde.. perhaps becuse name clashes between things the user uses
and deeply internal parts of the Reduce will have similar bad behaviour -
eg try using the word "prog" where you have used "de".
This issue of namespaces has been part of Reduce "for ever" and at times
we have thought of trying to work out how to retrofit something akin to
either the Common Lisp package system or the C++ namespace one, but
certainly neither of those would be at all a trivial exercise.
So at least it is good that you can check the status of a symbol.
However even that is still not perfect. Many Reduce packages autoload when
you first invoke one of the key operations that are their entrypoint.
Loading a fresh package can introduce all the syntax and functions of that
particular package. So to be really safe sometimes "grep" through the
Reduce sources can be a fallback. for function definitions I go
grep "procedure fname" packages//.red packages///*.red
and sometimes for "operator fname". Possibly via emacs a tags file would
index nicely?
Arthur
On Wed, 6 Feb 2019, arpi wrote:
Dear All,
Is there a way in reduce to query if a name is already defined, e.g., as an operator?
Why I am asking is that I tried to run an old reduce file written by a late colleague, and it did not run. I localised the error to be a definition of an operator de, e.g.,
operator de;
for all f let de(f)=df(f,r);
and I get the rather cryptic error message
+++ Error attempt to take car of an atom: nil
I am using the jan 20 snapshot on Linux.
Thank you: Arpad
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you, now it is clear. I just had no idea what a "car" is.
I learned about reduce from my diploma supervisor, and his convention was using two letter abbreviations for symbols, e.g., delta was de, and that's where I ran into this. Interestingly, the file used to work with older versions (3.5). Also it seems to me that the ordering of terms in factorize() changed. Is is possible to see the changes between reduce versions somewhere?
I do not know if it was possible to come up with a warning message when I enter "operator de;" that de is already defined. Or another idea might be to use names for teduce internals (stuff that is not meant to be used by normal users) that are not that easily used by accident, e.g, intead of de, something like reduceinternal-de, or packagename-internal-....
Best regards: Arpad
Last edit: arpi 2019-02-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you, now it is clear. I just had no idea what a "car" is.
I learned about reduce from my diploma supervisor, and his convention
was using two letter abbreviations for symbols, e.g., delta was de, and
that's where I ran into this. Interestingly, the file used to work with
older versions (3.5). Also it seems to me that the ordering of terms in
factorize() changed. Is is possible to see the changes between reduce
versions somewhere?
Version 3.5 is now seriously ancient history, dating from 1993. A list of
all the changes since then would be sufficiently large that it would
overwhelm you, and we do not have that sort of change log anywhere!
As from the end of 2008 onwards the sources of Reduce have been in the
subversion repository at Sourceforge and for each update since then
(4770 of them!) there will be a checkin message that you can read via
"svn log" - some of those are more cryptic than others and most are
aimed at developers not users. Serious work has gone into the manual. That
is a succes story as regards how complete it is and how carefully it
describes things, but that makes it rather large for most people to read!
Snapshot sources of some older releases of Reduce are also stored on
sourceforge for those interested in software archaeology.
So changes as against historical versions are not collected anywhere
neatly. Changes to the current system that we believe might impact users
get announced on the mailing list. I hope we are generally cautious before
making upwards-incompatible changes, but accidents can happen.
I do not know if it was possible to come up with a warning message when
I enter "operator de;" that de is already defined.
There is quite a lot of that done in the "mkop" function in alg/simp.red
and putting an extra line in that checks if a 'formfn is present for the
thing that somebody is trying to make an operator will be easy. In part
this comment is to see if other developers can think of better tests to
make or other cases to watch for...
Or another idea might
be to use names for teduce internals (stuff that is not meant to be used
by normal users) that are not that easily used by accident, e.g, intead
of de, something like reduceinternal-de, or <packagename>-internal-....</packagename>
While an attractive though that would not be feasible! But I believe that
in my previous response I had mentioned the THOUGH of a scheme to give
Reduce namespaces. Designing such a scheme is not trivial and then
implementing it ditto and more so - so it is at present one of the many
ideal ideas not a current active project. Sorry.
Best regards: Arpad
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oh, sorry, I did not mean a detailed changelog, including all changes to the Reduce source, just something like that is at the end of some software manuals, e.g,
in version x.y, we changed the behaviour of function z() to return...
i.e., important changes an average user has to be warned about.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One is the behaviour of "de" when used as an operator. This used to work is earlier releases, but was changed sometime in 2011. We need to check why it was changed and what to do about it.
The larger issue concerns the point you raised in your first post: how can one find out whether a name is already defined or has some special property?
I think something could be implemented to look up the properties of a name. E.g, a new operator
properties(de);
to return information about the name de.
I put this on our ToDo list.
Rainer
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear All,
Is there a way in reduce to query if a name is already defined, e.g., as an operator?
Why I am asking is that I tried to run an old reduce file written by a late colleague, and it did not run. I localised the error to be a definition of an operator de, e.g.,
operator de;
for all f let de(f)=df(f,r);
and I get the rather cryptic error message
+++ Error attempt to take car of an atom: nil
Changing the name de to, e.g., den everywhere solves the problem.
I am using the jan 20 snapshot on Linux.
Thank you: Arpad
Last edit: arpi 2019-02-06
At least if you use low-level facilities it is possible to see all sorts
of things.
Eg you can go
lisp getd 'de;
which may say (fexpr . de), where you vam contrast that with the output
from lisp getd 'nothing_in_particular;. And
lisp prop 'de;
where the presence of the "number-of-arguments" property tends to be a
signature of something that has been defined.
The way I would check yet further would be to start by loading up
bootstrapreduce rather than the main (production) version.
bootstrapreduce is slower but has extra information saved within it.
Then I would go
lisp;
load!-source();
plist 'de;
and that would reveal to me a suggestion that someting might be defined
on line 628 of the file [.../packages/]misc/rcref.red and while in this
case that is not actually very interesting in other case it might be and
could point you are the location in the Reduce sources to investigate
further.
The cryptic error message is not as it should be - obviously. One can sort
out a bit more by setting "on backtrace;" before attempting the
systatement that fails. Here I see
4: for all f let de(d) = df(f, r);
+++ Error attempt to take car of an atom: nil
Inside: formde
Arg1: (de d)
Arg2: nil
Arg3: algebraic
Inside: form1
Arg1: (de d)
Arg2: nil
Arg3: algebraic
Inside: formlet1
Arg1: ((equal (de d) (df f r)))
...
where the formfn you saw mentioned on the property list of 'de is
expectiing the system-style use of "de" that has a form like
"(de increment (x) (plus x 1))" or some such - and when it gets just "(de
d)" it gets upset. It is easy to find the code concerned - it is in
packages/rlisp/proc.red and formde does not validate the form of the
expression it is given at all - it just assumes it is a list of length 4
or more. I think this case is not one that makes me rush to update the
code for formde.. perhaps becuse name clashes between things the user uses
and deeply internal parts of the Reduce will have similar bad behaviour -
eg try using the word "prog" where you have used "de".
This issue of namespaces has been part of Reduce "for ever" and at times
we have thought of trying to work out how to retrofit something akin to
either the Common Lisp package system or the C++ namespace one, but
certainly neither of those would be at all a trivial exercise.
So at least it is good that you can check the status of a symbol.
However even that is still not perfect. Many Reduce packages autoload when
you first invoke one of the key operations that are their entrypoint.
Loading a fresh package can introduce all the syntax and functions of that
particular package. So to be really safe sometimes "grep" through the
Reduce sources can be a fallback. for function definitions I go
grep "procedure fname" packages//.red packages///*.red
and sometimes for "operator fname". Possibly via emacs a tags file would
index nicely?
On Wed, 6 Feb 2019, arpi wrote:
Thank you, now it is clear. I just had no idea what a "car" is.
I learned about reduce from my diploma supervisor, and his convention was using two letter abbreviations for symbols, e.g., delta was de, and that's where I ran into this. Interestingly, the file used to work with older versions (3.5). Also it seems to me that the ordering of terms in factorize() changed. Is is possible to see the changes between reduce versions somewhere?
I do not know if it was possible to come up with a warning message when I enter "operator de;" that de is already defined. Or another idea might be to use names for teduce internals (stuff that is not meant to be used by normal users) that are not that easily used by accident, e.g, intead of de, something like reduceinternal-de, or packagename-internal-....
Best regards: Arpad
Last edit: arpi 2019-02-08
On Fri, 8 Feb 2019, arpi wrote:
Version 3.5 is now seriously ancient history, dating from 1993. A list of
all the changes since then would be sufficiently large that it would
overwhelm you, and we do not have that sort of change log anywhere!
As from the end of 2008 onwards the sources of Reduce have been in the
subversion repository at Sourceforge and for each update since then
(4770 of them!) there will be a checkin message that you can read via
"svn log" - some of those are more cryptic than others and most are
aimed at developers not users. Serious work has gone into the manual. That
is a succes story as regards how complete it is and how carefully it
describes things, but that makes it rather large for most people to read!
Snapshot sources of some older releases of Reduce are also stored on
sourceforge for those interested in software archaeology.
So changes as against historical versions are not collected anywhere
neatly. Changes to the current system that we believe might impact users
get announced on the mailing list. I hope we are generally cautious before
making upwards-incompatible changes, but accidents can happen.
There is quite a lot of that done in the "mkop" function in alg/simp.red
and putting an extra line in that checks if a 'formfn is present for the
thing that somebody is trying to make an operator will be easy. In part
this comment is to see if other developers can think of better tests to
make or other cases to watch for...
While an attractive though that would not be feasible! But I believe that
in my previous response I had mentioned the THOUGH of a scheme to give
Reduce namespaces. Designing such a scheme is not trivial and then
implementing it ditto and more so - so it is at present one of the many
ideal ideas not a current active project. Sorry.
Oh, sorry, I did not mean a detailed changelog, including all changes to the Reduce source, just something like that is at the end of some software manuals, e.g,
in version x.y, we changed the behaviour of function z() to return...
i.e., important changes an average user has to be warned about.
There is a (very terse) list of changes in Appendix C of the manual.
I think we have two different issues here.
One is the behaviour of "de" when used as an operator. This used to work is earlier releases, but was changed sometime in 2011. We need to check why it was changed and what to do about it.
The larger issue concerns the point you raised in your first post: how can one find out whether a name is already defined or has some special property?
I think something could be implemented to look up the properties of a name. E.g, a new operator
properties(de);
to return information about the name de.
I put this on our ToDo list.
Rainer