Reasonable people can disagree, even about history. I believe it was a mistake to implement the Aldor compiler in C.
Implementing a new compiler inside Scratchpad would have cleaned up the Spad language, the Spad compiler, and made the interpreter/compiler semantic difference disappear. It would also have been a much smaller effort as most of the machinery already existed. Dick Jenks thought the same thing but Stephen argued that we could re-implement the algebra in the C version (which was eventually my PhD task). Is there any Aldor algebra in the build process? I taught a compiler course at Vassar and used some examples from Aldor. It is a very pretty piece of software written by brilliant programmers. However, there are more people that "speak boot" than "speak Aldor" and that is already a vanishingly small number. > it was good change for Spad. The huge effort would have been better spent developing more algebra or, as I argued then and now, developing specification/proof technology inside Scratchpad. Reasonable people disagree with me :-) The point is moot. Aldor exists. On Sunday, April 23, 2023 at 5:15:04 PM UTC-4 Waldek Hebisch wrote: > On Sat, Apr 22, 2023 at 09:00:23PM -0700, Tim Daly wrote: > > Historically this change was introduced because of the Aldor compiler. > > Well, this was desirable change to Spad language. Aldor was a new > start, so it was easier to make change in Aldor first. But > it was good change for Spad. > > > There was a clash of the use of the symbols. I had to rewrite code to > > get Scratchpad (Axiom) and Asharp (Aldor) to work together. > > Yes. Around 1990 using symbol renaming was right thing to do, otherwise > change would require too much effort. But we want to move forward... > > > > > On Saturday, April 22, 2023 at 3:19:32 PM UTC-4 Waldek Hebisch wrote: > > > > > For many years internally Spad compiler and interpreter renamed > > > '%' to '$' and internally used '$'. I have now commited a patch > > > that disables this renaming so that '%' from source is internally > > > represented by itself, without renaming. This should slightly > > > simplify structure of Spad compiler and interpreter, but main > > > gain should be in debugging: Lisp data structures should be > > > more similar to Spad source, so easier to interpret. > > > > > > There is also related cost: patch touches a lot of places in > > > interp subdirectory and potentially may introduce bugs. > > > > > > -- > > > Waldek Hebisch > > > > > > > -- > > You received this message because you are subscribed to the Google > Groups "FriCAS - computer algebra system" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/fricas-devel/783e527c-5071-40b8-90f6-020623b4b07fn%40googlegroups.com > . > > > -- > Waldek Hebisch > -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/be189d74-999b-429e-8429-8c77942862a3n%40googlegroups.com.
