Pith. sign in

REVIEW 3 major objections 4 minor 56 references

Software Portability for Computer Algebra

T0 review · 3 major / 4 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read A six-decade survey of computer algebra portability concludes that low-level portability is mature and the open problems are mathematical definitions and algorithm encoding.

desk verdict A candid first-hand retrospective on CAS portability; the four-era frame is useful but the 'mathematical consolidation' claim overreaches the authors' own evidence. read the letter →

arxiv 2506.01864 v4 pith:OGFUB5B2 submitted 2025-06-02 cs.SC

Arthur C. Norman , Stephen M. Watt This is my paper
classification cs.SC MSC 68W3068-02
keywords computeralgebrasoftwareportabilitylayerReduceMapleAxiomAldormathematicaldefinitions
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This article argues that the meaning of software portability for computer algebra systems has shifted over six decades. Where early systems had to chase a dozen incompatible hardware and software platforms, the field has now reached a platform consolidation point: a stack of 64-bit words, 8-bit bytes, byte addressability, POSIX, Unicode, IEEE 754, and gcc/clang covers almost every relevant environment. The paper's central claim is that we are now in a "mathematical consolidation period" in which the main remaining portability problems are not machine-level but semantic: differing mathematical definitions and incompatible encodings of algorithms keep one system's results from being used in another. A sympathetic reader would take this as a call to treat mathematical-definition interoperability and preservation of algorithm code as the real portability agenda. The claim matters because valuable mathematical code, such as two major symbolic integration efforts, is stranded in systems whose languages and semantics are hard to port.

What carries the argument

The paper's central mechanism is the portability layer: a deliberately thin, low-level abstraction (Aldor's Layer 0, about 3% of that codebase) that isolates the rest of a system from platform quirks, combined with the modern convergent baseline platform of 64-bit words, 8-bit bytes, byte addressability, POSIX, Unicode, IEEE 754, and gcc/clang. The portability layer absorbs compiler, operating system, and architecture differences behind named properties and macros, while the converged baseline makes most of those differences academic. Together they carry the argument that low-level portability is a mature engineering problem and push the remaining difficulties to the mathematical layer above.

What would settle it

Introduce a genuinely new common computing environment, say capability-based memory with 128-bit tagged pointers and no flat address space, or a hardened operating system that forbids executable writable memory and arbitrary checkpoint reload, and port the four case-study systems to it. If a substantial fraction of the porting effort goes to low-level memory representation, garbage collection, or code generation rather than to mathematical definitions and algorithm encoding, then low-level portability is not yet mature and the periodization is wrong.

Watch

Extended reading notes

Core claim

The central discovery, presented from the authors' first-hand experience building Reduce, Maple, Axiom, and Aldor, is a periodization of portability: an early platform period (before roughly 1970), a platform diversification period (roughly 1970 to 2000), a platform consolidation period (roughly 2000 to 2015), and a mathematical consolidation period (roughly 2015 onward). In the current period, low-level portability is largely mature because the surviving common platform resolves the old issues of word size, floating-point representation, byte order, character sets, and pointer shapes. What remains is portability of mathematics itself: conventions such as branch cuts, the presence of a multiplicative identity in a ring, the sign of a Lie bracket, or the choice of foundational logic differ between systems, and algorithms encoded in one system's language cannot be moved elsewhere automatically.

Load-bearing premise

The whole periodization rests on the assumption that the systems the authors worked on, Reduce, Maple, Axiom, and Aldor, represent computer algebra as a whole, and that today's convergent platform stack of 64-bit words, 8-bit bytes, byte addressability, POSIX, Unicode, IEEE 754, and gcc/clang will remain stable long enough for low-level portability to count as mature.

Editorial extensions

If this is right

  • New computer algebra systems can be built against the convergent platform stack with confidence that low-level porting will not dominate their costs.
  • A carefully constructed portability layer of roughly 3% of the codebase is enough to support even a very wide range of platforms, so portability need not come at the price of a mess of #ifdefs.
  • Sharing mathematical computations between systems now hinges on resolving definitional differences such as branch cuts, ring conventions, normalization, and logic, rather than on data representation.
  • Substantial algorithm code, such as major symbolic integration packages, will become unportable and potentially lost if it is not translated out of its original host language, and the paper identifies this as a critical portability problem.
  • The next portability frontier involves time and expectations as much as machines: graphical, web, generative AI, and cloud concurrency each require deep rework of existing systems.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Beyond the paper: if the periodization holds, interoperability projects should invest primarily in semantic content dictionaries and formal proof library integration, not in new low-level compatibility layers.
  • Beyond the paper: the two integration examples suggest a testable programme: measure how much of a rule-based system like Rubi can be automatically translated to another host by replacing the original host's pattern-matching semantics with explicitly encoded guards; the paper mentions AI transformation only in passing.
  • Beyond the paper: pointer-tagging and NAN-boxing tricks that rely on 48-bit virtual addresses may become less portable as 5-level page tables and capability architectures spread; the paper notes 5-level tables in a footnote but does not develop the consequence for its "solved low-level portability" claim.
  • Beyond the paper: the convergence stack is defined by today's dominant compilers and operating systems, and a future security-hardening change that breaks checkpoint/restart or just-in-time compilation would reopen low-level portability, so the periodization should be read as contingent on platform stability.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 4 minor

Summary. This paper is a first-hand retrospective on software portability for computer algebra systems, based on the authors' experience building Reduce, Maple, Axiom, and Aldor. It distinguishes portability across platforms, across time on the same platform, and of intellectual content (e.g., moving an algorithm from one system to another). After historical accounts of Lisp-based and C-based portability strategies, the paper proposes a four-period periodization (Section 9): early platform (<1970), platform diversification (1970–2000), platform consolidation (2000–2015), and mathematical consolidation (2015 onward). The central thesis is that since about 2015 low-level platform portability is largely mature and the main remaining portability issues are at the levels of mathematical definitions and algorithm encoding.

Significance. The manuscript is a valuable primary source on the engineering practices of influential CAS projects. The Aldor case study is particularly strong: it quantifies the portability layer (a few thousand lines out of ~200,000, ~370 #ifdefs, ~50 named platform properties, ~80 macros) and explains the design rationale in detail. The discussion in Section 8 of divergent mathematical conventions (e.g., branch cuts, ring identity, Lie bracket normalization) is a useful catalog of semantic interoperability problems. However, the paper's main thesis—the Section 9 periodization—is supported mainly by the authors' own systems and a small set of anecdotes, and the paper's own narrative provides counterexamples to the maturity of low-level portability. The manuscript is therefore a compelling testimony, but not yet a fully established field-level conclusion.

major comments (3)
  1. [Section 9, first paragraph; Section 2, paragraph beginning "A more serious porting challenge"] The central periodization claim—that we are now in a 'mathematical consolidation period' where the main remaining portability issues are at the levels of mathematical definitions and algorithm encoding—is not supported by the evidence the paper itself provides. Section 2 describes OS security hardening that undermines dynamic code generation, checkpoint/reload, code signing, and license management; conclusion 2 concedes that aggressive compilers can invalidate previously reasonable assumptions and that 'things are sometimes tough again.' These are low-level platform portability problems, not mathematical-semantic ones. The paper gives no measure of where portability effort goes after 2015, so the assertion that mathematical consolidation now dominates is an unsupported empirical claim. I recommend either softening the claim to a statement about the authors' experience with their own systems, or adding evidence of the relative volume and severity of low-level versus semantic portability issues.
  2. [Section 7, "The Role of Standards"] The claim that '64-bit words + 8-bit bytes + byte addressability + POSIX + Unicode + IEEE 754 + gcc/clang covers almost all relevant modern environments' is asserted without a survey. It may be accurate for x86-64 Linux and macOS workstations, but the paper does not establish coverage for the range of environments in which CAS are actually deployed (HPC clusters, web servers, GPUs, mobile, embedded). The paper itself notes that Apple's PowerPC-to-Intel-to-ARM transitions required substantial rework, and the NAN-boxing discussion acknowledges that 5-level page tables complicate pointer tagging. Since the maturity of low-level portability is the hinge of the Section 9 periodization, this claim needs either a defined scope or supporting evidence.
  3. [Sections 5, 6, and 9] The generalization from Reduce and Aldor (plus brief Maple, Axiom, and Mathematica anecdotes) to the whole field of computer algebra is a leap. These are systems the authors built or helped build, so the evidence is first-hand and potentially subject to selection bias. No evidence is offered from systems with different implementation strategies (e.g., Java-based, Python-based, or systems that rely on separate runtime ecosystems such as web browsers). If the conclusion is meant to apply to 'mainstream computer algebra environments' broadly, this sample is too small; if it is meant only for the authors' systems, the conclusion should be scoped accordingly. I would ask the authors to either broaden the evidence base or restrict the periodization to the systems under discussion.
minor comments (4)
  1. [Section 6, "Case Study: Aldor"] The size of the Aldor portability layer is given as 6829 lines in one paragraph and about 8000 lines in a later paragraph. These figures should be reconciled or explicitly described as different metrics.
  2. [Sections 3.1, 3.3, and reference [32]] Dennis Ritchie's surname is consistently misspelled as 'Richie.' Please correct this in the text and in the reference.
  3. [Section 4, "Issues Encountered in Lisp Evolution"] The phrase 'CSL(Standard Lisp was coded inC)' appears to have a missing closing parenthesis; it should probably read 'CSL (Standard Lisp) was coded in C.' Similarly, 'forced further case regarding' should be 'forced further care regarding.'
  4. [Section 7, bullet list] The word 'Pathalogical' should be 'Pathological.' Also, the definition of 'gcc/clang' as a standard is imprecise; if these compilers are meant as de facto standards, that should be stated explicitly.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper is a first-hand retrospective and position argument, with no equation-level derivation or fitted-parameter 'prediction' that could reduce to its inputs.

full rationale

This paper does not claim to derive a new mathematical or algorithmic result, so the usual circularity patterns do not apply. Its central periodization (early platform period, platform diversification, platform consolidation, mathematical consolidation) is presented as an interpretive summary of the authors' direct experience with Reduce, Maple, Axiom and Aldor, supported by external standards and independently observable examples. The standards list in Section 7 (IEEE 754, Unicode, POSIX, C/C++, XML/MathML/OpenMath) comes from outside the authors' own work, and the Rubi/Mathematica integration examples are public and checkable. Self-citations do appear, notably for Aldor ([51-53]), CSL ([40]), and the claim that porting Rubi out of Mathematica is non-trivial ([41]), but these document the authors' own systems rather than serving as an external authority for a contested premise; the Section 9 conclusion that mathematical definitions and algorithm encoding are the main remaining portability issues is not made to follow from those citations by construction. In-scope admissions such as Apple CPU transitions, OS security hardening, and aggressive compilers making "things are sometimes tough again" (Section 9, second conclusion) weaken the empirical strength of the maturity claim, but that is an issue of evidence and representativeness, not circularity: there is no equation, fitted parameter, or imported uniqueness theorem whose output equals its input by definition. The paper is self-contained as an essay; no circular step was identified.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

The paper has no mathematical derivation, so there are no fitted constants. Its thesis rests on two domain assumptions: that the authors' first-hand systems are a representative sample, and that the mainstream platform convergence is durable. No invented entities are introduced.

assumptions (3)
  • domain assumption First-hand systems (Reduce, Maple, Axiom, Aldor) are representative of the wider computer algebra field for drawing portability conclusions.
    Sections 5 and 6 present these as case studies, and Section 9 generalizes from them to four field-wide periods; Macsyma, Mathematica, and SageMath receive only brief mentions.
  • domain assumption The platform convergence set (64-bit words, 8-bit bytes, byte addressability, POSIX, Unicode, IEEE 754, gcc/clang) covers almost all relevant modern environments and is durable.
    Section 7 lists this set and says it covers almost all relevant modern environments; the thesis that low-level portability is mature depends on this continuing.
  • domain assumption Low-level portability issues have reached a stage of mature solution.
    This conclusion in Section 9 is the premise that pushes the remaining portability burden onto mathematics, but it is supported only by the authors' selected sample of systems.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Software Portability for Computer Algebra." pith.science (2026). https://pith.science/paper/OGFUB5B2

@misc{pith2026250601864,
  author       = {Pith},
  title        = {Pith review of: Software Portability for Computer Algebra},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/OGFUB5B2}},
  note         = {Machine review of arXiv:2506.01864}
}
read the original abstract

We have been involved in the creation of multiple software systems for computer algebra, including Reduce, Maple, Axiom and Aldor as well as a number of smaller specialised programs. We relate observations on how the meaning of software portability has changed over time and how it continues to evolve. We describe how the systems with which we have first-hand experience have achieved portability, how the central issues have changed over time and the challenges that remain.

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

56 extracted references · 53 canonical work pages

  1. [1]

    In: AFIPS ’66 (Fall): Proceedings of the November 7-10, 1966, fall joint computer conference

    Abrahams, P.W., Barnett, J.A., Book, E., Firth, D., Kameny, S.L., Weissman, C., Hawkinson, L., Levin, M.I., Saunders, R.A.: The LISP 2 programming language and system. In: AFIPS ’66 (Fall): Proceedings of the November 7-10, 1966, fall joint computer conference. pp. 661–67 (1966)

    work page 1966

  2. [3]

    org/projects/LISP/ibm/Blair-StructureOfLispCompiler.pdf

    Blair, F.: Structure of the Lisp compiler.https://www.softwarepreservation. org/projects/LISP/ibm/Blair-StructureOfLispCompiler.pdf

    work page

  3. [4]

    In: Calmet, J., Limongelli, C

    Bronstein, M.:Σ IT — a strongly-typed embeddable computer algebra library. In: Calmet, J., Limongelli, C. (eds.) Design and Implementation of Symbolic Compu- tation Systems. pp. 22–33. Springer Berlin Heidelberg, Berlin, Heidelberg (1996)

    work page 1996

  4. [5]

    Springer (1997)

    Bronstein, M.: Symbolic Integration I – transcendental functions. Springer (1997)

    work page 1997

  5. [6]

    Brown,W.S.:Alanguageandsystemforsymbolicalgebraonadigitalcomputer.In: SYMSAC ’66: Proceedings of the first ACM symposium on symbolic and algebraic manipulation. pp. 501–540 (January 1966),https://doi.org/10.1145/800005. 807955

    doi:10.1145/800005 1966

  6. [7]

    In: van Hulzen, J

    Char, B., Geddes, K., Gentleman, W., Gonnet, G.: The design of Maple: A com- pact, portable, and powerful computer algebra system. In: van Hulzen, J. (ed.) Computer Algebra. EUROCAL 1983. LNCS 162, Springer, Berlin, Heidelberg (1983)

    work page 1983

  7. [8]

    Communications of the ACM9(8), 578–589 (August 1966)

    Collins, G.E.: PM, a system for polynomial manipulation. Communications of the ACM9(8), 578–589 (August 1966)

    work page 1966

  8. [9]

    In: Proc

    Dalmas, S., Gaëtano, M., Watt, S.M.: An OpenMath 1.0 implementation. In: Proc. International Symposium on Symbolic and Algebraic Computation (ISSAC). pp. 241–248. ACM, New York (1997)

    work page 1997

Show all 56 references
  1. [10]

    NIST Digital Library of Mathematical Functions.https://dlmf.nist.gov/, Re- lease 1.2.4 of 2025-03-15, f. W. J. Olver, A. B. Olde Daalhuis, D. W. Lozier, B. I. Schneider, R. F. Boisvert, C. W. Clark, B. R. Miller, B. V. Saunders, H. S. Cohl, and M. A. McClain, eds

    2025

  2. [11]

    In: Proc

    Dragan, L., Watt, S.M.: Performance analysis of generics for scientific computing. In: Proc. 7th Internatioanl Symposium on Symbolic and Numeric Algorithms in Scientific Computing, (SYNASC 2005), September 25-29 2005, Timişoara Roma- nia. pp. 93–100. IEEE Press (2005)

    2005

  3. [12]

    Software: Practice and Experience7(6), 713–725 (1977),https://onlinelibrary.wiley

    Fitch, J.P., Norman, A.C.: Implementing LISP in a high-level language. Software: Practice and Experience7(6), 713–725 (1977),https://onlinelibrary.wiley. com/doi/abs/10.1002/spe.4380070606

    1977 doi

  4. [13]

    (eds.) Intelligent Computer Mathematics (CICM 2009)

    Fitch, J.: CAMAL 40 years on — is small still beautiful? In: Carette, J., Dixon, L., Cohen, C.S., Watt, S.M. (eds.) Intelligent Computer Mathematics (CICM 2009). pp. 32–44. LNAI 5625, Springer (2009)

    2009

  5. [14]

    In: Proc

    Griss, M.L., Benson, E., Magruire Jr, G.Q.: PSL: A portable Lisp system. In: Proc. ACM Symposium on Lisp and Functional Programming. pp. 88–97 (1982)

    1982

  6. [15]

    Software - Practice and Expe- rience11(6), 541–605 (June 1979)

    Griss, M.L., Hearn, A.C.: Portable LISP compiler. Software - Practice and Expe- rience11(6), 541–605 (June 1979)

    1979

  7. [16]

    Hall, A.D.: The M6 Macros Processor. Tech. rep., Bell Laboratories|: Computing Science Technical Report #2 (April 1972)

    1972

  8. [17]

    In: Petrick, S

    Hall Jr, A.D.: The ALTRAN system for rational function manipulation - a survey. In: Petrick, S. (ed.) SYMSAC ’71: Proceedings of the second ACM symposium on Symbolic and algebraic manipulation. pp. 153–157. ACM, New York (1971)

    1971

  9. [18]

    ACM SIGSAM Bulletin pp

    Hearn, A.C.: Standard Lisp. ACM SIGSAM Bulletin pp. 28–49 (December 1969)

    1969

  10. [19]

    IEEE (1996)

    IEEE: 1996 (ISO/IEC) [IEEE/ANSI Std 1003.1, 1996 Edition] Information Tech- nology — Portable Operating System Interface (POSIX®) — Part 1: System Application: Program Interface (API) [C Language]. IEEE (1996)

    1996

  11. [20]

    IEEE Std 754-2019 (Revision of IEEE 754-2008) pp

    IEEE: IEEE standard for floating-point arithmetic. IEEE Std 754-2019 (Revision of IEEE 754-2008) pp. 1–84 (2019)

    2019

  12. [21]

    United States of America Standards Institute (1966) 26 Arthur C

    Institute, A.N.S.: ANSI X 3.9 1966 Fortran 66. United States of America Standards Institute (1966) 26 Arthur C. Norman and Stephen M. Watt

    1966

  13. [22]

    In: Wang, P.S

    Ion, P.D., Bouche, T., Misra, G., Onshuus, A.A., Watt, S.M., Zheng, L.: Inter- national mathematical knowledge trust (IMKT): An update on the global digital mathematics library. In: Wang, P.S. (ed.) Proc. International Congress of Math- ematicians 2018, (ICM 2018), Rio de Jane...

    2018

  14. [23]

    International Organiza- tion for Standardization, Geneva, Switzerland (1990),http://www.iso.ch/cate/ d17782.html

    ISO: ISO/IEC 9899:1990: Programming languages — C. International Organiza- tion for Standardization, Geneva, Switzerland (1990),http://www.iso.ch/cate/ d17782.html

    1990

  15. [24]

    International Organization for Standardization, Geneva, Switzerland, fifth edn

    ISO: ISO/IEC 14882:2017 Information technology — Programming languages — C++. International Organization for Standardization, Geneva, Switzerland, fifth edn. (Dec 2017),https://www.iso.org/standard/68564.html

    2017

  16. [25]

    International Organization for Standardization, Geneva, Switzerland, sixth edn

    ISO: ISO/IEC 14882:2020 Information technology — Programming languages — C++. International Organization for Standardization, Geneva, Switzerland, sixth edn. (Dec 2020)

    2020

  17. [26]

    International Organization for Standardization, Geneva, Switzerland, seventh edn

    ISO: ISO/IEC 14882:2024 IEC 14882:2020 Information technology — Program- ming languages — C++. International Organization for Standardization, Geneva, Switzerland, seventh edn. (Oct 2024)

    2024

  18. [27]

    International Organization for Standardization, Geneva, Switzerland, fifth edn

    ISO: ISO/IEC 9899:2024 Information technology — Programming languages — C. International Organization for Standardization, Geneva, Switzerland, fifth edn. (Oct 2024),https://www.iso.org/standard/82075.html

    2024

  19. [28]

    ACM Com- munications in Computer Algebra49, 34–34 (04 2015)

    Jeffrey, D., Rich, A., Hu, J.: RUBI and integration as term re-writing. ACM Com- munications in Computer Algebra49, 34–34 (04 2015)

    2015

  20. [29]

    Springer- Verlag (1992),http://link.springer.com/10.1007/978-1-4612-2940-7

    Jenks, R.D., Sutor, R.S.: AXIOM: The Scientific Computation System. Springer- Verlag (1992),http://link.springer.com/10.1007/978-1-4612-2940-7

    1992 doi

  21. [30]

    In: Janßen, R

    Jenks, R.D., Sutor, R.S., Watt, S.M.: Scratchpad II: An abstract datatype system for mathematical computation. In: Janßen, R. (ed.) Trends in Computer Algebra. pp. 12–37. Springer Berlin Heidelberg, Berlin, Heidelberg (1988)

    1988

  22. [31]

    In: Wang, P.S

    Jenks, R.D., Trager, B.M.: A language for computational algebra. In: Wang, P.S. (ed.) Proceedings of the Symposium on Symbolic and Algebraic Manipulation, SYMSAC 1981, Snowbird, Utah, USA, August 5-7, 1981. pp. 6–13. ACM (1981)

    1981

  23. [32]

    Johnson, S.C., Richie, D.M.: Unix portability.https://www.landley.net/ history/mirror/unix/dmr/firstport.html

  24. [33]

    Prentice-Hall (2006)

    Kernighan, B.W., Ritchie, D.M.: The C programming language. Prentice-Hall (2006)

    2006

  25. [34]

    The Computer Journal27(2), 97–111 (1984)

    Knuth, D.E.: Literate programming. The Computer Journal27(2), 97–111 (1984)

    1984

  26. [35]

    LMFDB Collaboration, T.: The L-functions and modular forms database.https: //www.lmfdb.org(2025), [Online; accessed 1 June 2025]

    2025

  27. [36]

    ac.uk/courses/moved.OldFortran/paper_2.pdf

    Maclaren, N.: Converting old to modern fortran.https://www-uxsup.csx.cam. ac.uk/courses/moved.OldFortran/paper_2.pdf

  28. [37]

    Maplesoft, Waterloo, Ontario Canada: Maple 2025.http://www.maplesoft.com

    2025

  29. [38]

    SIGSAM Bulletin14(1), 23–41 (February 1980),https://doi.acm.org/10.1145/1089212

    Marti, J., Hearn, A.C., Griss, M.L., Griss, C.: Standard Lisp report. SIGSAM Bulletin14(1), 23–41 (February 1980),https://doi.acm.org/10.1145/1089212. 1089218

    1980 doi

  30. [39]

    Moses, J.: Quotes about Lisp.https://en.wikiquote.org/wiki/Lisp_ (programming_language)

  31. [40]

    In: Miola, A

    Norman, A.C.: Compact delivery support for REDUCE. In: Miola, A. (ed.) De- sign and Implementation of Symbolic Computation Systems. pp. 331–340. Springer Berlin Heidelberg, Berlin, Heidelberg (1993)

    1993

  32. [41]

    In: Proc

    Norman, A.C., Jeffrey, D.J.: Software for indefinite integration. In: Proc. SCSS 2024: 10th International Symposium on Symbolic Computation in Software Sci- ence, Tokyo, Japan (2024) Software Portability for Computer Algebra 27

    2024

  33. [42]

    MIT/LCS/TR, Massachusetts Institute of Technology (1983),https://books.google.co.uk/books?id=s6UaGQAACAAJ

    Pitman, K.: The Revised Maclisp Manual. MIT/LCS/TR, Massachusetts Institute of Technology (1983),https://books.google.co.uk/books?id=s6UaGQAACAAJ

    1983

  34. [43]

    In: AFIPS ’69 (Spring): Proceedings of the May 14-16, 1969, spring joint computer conference.pp.557–566(May1969),https://doi.org/10.1145/1476793.1476880

    Richards, M.: BCPL: a tool for compiler writing and system programming. In: AFIPS ’69 (Spring): Proceedings of the May 14-16, 1969, spring joint computer conference.pp.557–566(May1969),https://doi.org/10.1145/1476793.1476880

    1969

  35. [44]

    Risch, R.H.: The solution of the problem of integration in finite terms. Bull. Amer. Math. Soc76(3), 605–608 (May 1970)

    1970

  36. [45]

    Sloane, N.: The on-line encyclopedia of integer sequences.https://oeis.org

  37. [46]

    Elsevier (1990)

    Steele, G.: Common LISP: the language. Elsevier (1990)

    1990

  38. [47]

    ACM SIGPLAN Notices pp

    Steele Jr, G.L., Gabriel, R.: The evolution of Lisp. ACM SIGPLAN Notices pp. 231–270 (March 1993)

    1993

  39. [48]

    BBN and Xerox PARC (1974)

    Teitelman, W.: Interlisp reference manual. BBN and Xerox PARC (1974)

    1974

  40. [49]

    The OpenMath Society: OpenMath version 2.0r2.https://openmath.org/ standard/om20-2019-07-01/omstd20.html(2019), [Online; accessed 1 June 2025]

    2019

  41. [50]

    The Unicode Consortium: The Unicode Standard, version 16.0.0. Tech. rep., Uni- code Consortium, South San Francisco, CA (2024)

    2024

  42. [51]

    In: International Symposium on Symbolic and Algebraic Computation (ISSAC 1994)

    Watt, S., Broadbery, P., Dooley, S., Iglio, P., Steinbach, J., Sutor, R.: A first report on theA♯ compiler. In: International Symposium on Symbolic and Algebraic Computation (ISSAC 1994). pp. 25–31. ACM Press (1994)

    1994

  43. [52]

    Watt,S.M.:Aldor.In:HandbookofComputerAlgebra,p.265–270.SpringerVerlag (2003)

    2003

  44. [53]

    Watt, S.M., Moreno Maza, M.: Aldor User Guide.http://www.aldor.org/docs/ aldorug.pdf(2003)

    2003

  45. [54]

    Wolfram Research Inc.: Mathematica.https://www.wolfram.com/mathematica, Champaign, IL, 2024

    2024

  46. [55]

    w3.org/TR/xml/(2025), [Online; accessed 1 June 2025]

    World Wide Web Consortium: Extensible markup language (xml).https://www. w3.org/TR/xml/(2025), [Online; accessed 1 June 2025]

    2025

  47. [56]

    World Wide Web Consortium: Mathematical markup language (MathML).https: //www.w3.org/TR/mathml3/(2025), [Online; accessed 1 June 2025]

    2025

  48. [57]

    github.com/shafik/848ae25ee209f698763cffee272a58f8

    Yaghmour, S.: What is the strict aliasing rule and why do we care?https://gist. github.com/shafik/848ae25ee209f698763cffee272a58f8

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.