\documentclass{book}
%\newcommand{\VolumeName}{Volume 2: Axiom Users Guide}
%\input{bookheader.tex}
\pagenumbering{arabic}
\mainmatter
\setcounter{chapter}{0} % Chapter 1

\usepackage{makeidx}
\makeindex
\begin{document}
\begin{verbatim}
\start
Date: Tue, 9 Jul 2019 22:57:45 -0400
From: Tim Daly <axiomcas@gmail.com>
To: axiom-dev <axiom-developer@nongnu.org>
Subject: [Axiom-developer] Fwd: [EXTERNAL] Re: Axiom's Sane redesign musings

---------- Forwarded message ----------
From: Tim Daly <axiomcas@gmail.com>
Date: Tue, 9 Jul 2019 22:56:24 -0400
Subject: Re: [EXTERNAL] Re: [Axiom-developer] Axiom's Sane redesign musings
To: Martin Baker <ax87438@martinb.com>

Progress is being made. Axiom was written long before Common
Lisp existed. A lot of the code is due to translations from Maclisp
and LispVM.

I'm moving the Axiom hierarchy to Common Lisp CLOS code.
This has several advantages.

It eliminates the databases. They were created because there
was not enough memory (at 16 megabytes).

It uses native code to do dispatch.

CLOS defclass creates Common Lisp types so all of the code
is well-typed at the lisp level.

CLOS is lisp so ordinary lisp code can use Axiom functions
directly. This makes Axiom into an "embeddable library".

CLOS is the target language for the Axiom compiler. The
compiler is being re-architected to use nano passes [0] for
compiling. This will make it much easier to maintain in
the long term and much easier to extend.

This technique allows building the compiler in stages from
running code to running code at every step.

The new interpreter is much simpler as it just runs the CLOS
code directly.

The choice of logic and specification languages are still unclear.
These will also be created first at the lisp level and then covered
by the compiler with additional nano-passes.

Anyway, coding has begun.

Tim

[0]  Sarker, Dipanwita and Waddell, Oscar and Kybvig, R. Kent
"A Nanopass Framework for Compiler Education" (2004)


On 6/30/19, Tim Daly <axiomcas@gmail.com> wrote:
> There are thousands of hours of expertise and thousands of
> functions embedded in Spad code. An important design goal
> is to ensure that code continues to function. The Sane compiler
> will output code that runs in the interpreter. It is important that
> "nothing breaks".
>
> That said, the Sane compiler is "layered". The core of the design
> is that Axiom categories, domains, and packages are represnted
> as lisp classes and instances. This "core" is essentially what the
> compiler people call an Abstract Syntax Tree (AST). But in this
> case it is much more than syntax.
>
> Given this "core" there are several tasks.
>
> 1) compile spad code to the core. The "front end" should
> accept and understand current Spad code, unwinding it
> into the core class structure.
>
> 2) compile core classes to Axiom data structures. Thi
> "back end" generates current Axiom data structures from
> the core data structures.
>
> Now the compiler generates working code yet is in a state
> to accept enhancements, essentially by extending the core
> class objects.
>
> 3) In the interpreter, modify the getdatabase function to
> extract data from the core rather than the databases. So
> the databases go away but the interpreter continues to work.
>
> So now the interpreter has been "lifted" onto the core classes
> but continues to function.
>
> 4) enhance the core to support the axioms / specifications /
> proofs /etc. This involves adding fields to the lisp classes.
> This core work gives additional fields to hold information.
>
> 5) extend the Spad language (Spad 2.0?) to handle the
> additional axioms / specifications / proofs / etc. This
> involves adding syntax to the Spad language to support
> the new fields.
>
> 6) build back-end targets to proof systems, spec systems,
> etc. Compilers like GCC have multiple back ends. The Sane
> compiler targets the interpreter, a specification checker, a
> proof system, etc. as separate back ends, all from the same
> core structures.
>
> The Compiler Design
>
> A separate but parallel design goal is to build the compiler so
> it can be type-checked. Each function has typed input and
> typed output and is, for the most part, purely functional. So,
> for example, a "Filename" is an instance of a "File" object.
> A "Line" is an instance of "String". The "FileReader" is
>
> FileReader : Filename -> List Line
>
> Careful design of the language used to construct hte compiler
> (as opposed to the Spad language it accepts) makes it easier
> to type check the compiler itself.
>
> By REALLY careful design, the types are build on a layered
> subset of lisp, like Milawa
> https://www.cl.cam.ac.uk/~mom22/soundness.pdf
> which is sound all the way down to the metal.
>
> It all goes in stages. Build the new core class structure in a
> strongly typed fashion. Accept the Spad language. Generate
> Interpreter code. Enhance the core to support proofs / specs.
> Enhance the language to support proofs / specs. Accept the
> new language. Generate back ends to target the interpreter
> and a proof / spec system. Build it all on a sound base so
> the compiler can be checked.
>
> To the initial end user, the Sane version is the same as the
> current system. But in the long term all of the Axiom code
> could be called from any Lisp function. The Sane version
> can also be used as an "Oracle" for proof systems, since
> the code has been proven correct.
>
> This is a huge project but it can be done in small steps.
> In particular, the goal is to build a "thin thread" all the way
> through the system to handle only the GCD algorithms.
> Once that proof happens "the real work begins".
>
> Tim
>
>
>
>
> On 6/30/19, Martin Baker <ax87438@martinb.com> wrote:
>> Tim,
>>
>> This all seems to be about the lisp layer, obviously thats what
>> interests you.
>>
>> It seems to me that if SPAD code is complicated and not aligned to type
>> theory then, when SPAD is complied to Lisp, the List code will be
>> complicated and hard to work with. Your previous remarks, about not
>> seeing the whole elephant, suggest to me that you are drowning in
>> complexity. Most languages, in their lifetime, acquire some messiness
>> that needs to be cleared out occasionally.
>>
>> Don't you think its time for SPAD 2.0 ?
>>
>> Martin
>>
>> On 30/06/2019 02:17, Tim Daly wrote:
>>> One major Sane design decision is the use of CLOS,
>>> the Common Lisp Object System.
>>>
>>> First, since each CLOS object is a type it is possible to
>>> create strong types everywhere. This helps with the ultimate
>>> need to typecheck the compiler and the generated code.
>>>
>>> Second, CLOS is an integral part of common lisp. One of
>>> the Sane design goals is to make it possible to use Axiom's
>>> domains in ordinary lisp programs. Since Axiom is nothing
>>> more than a domain specific language on common lisp it
>>> makes sense to construct it so users can freely intermix
>>> polynomials with non-algebraic code.
>>>
>>> Third, CLOS is designed for large program development,
>>> hiding most of the implementation details and exposing
>>> a well-defined API. This will make future maintenance and
>>> documentation of Axiom easier, contributing to its longer
>>> intended life.
>>>
>>> So for a traditional Axiom user nothing seems to have
>>> changed. But for future users it will be easy to compute
>>> an integral in the middle of regular programs.
>>>
>>> Tim
>>>
>>> On 6/27/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>> Another thought....
>>>>
>>>> There has been a "step change" in computer science in the last few
>>>> years.
>>>>
>>>> Guy Steele did a survey of the use of logic notation in conference
>>>> papers.
>>>> More than 50% of the papers in some conferences use logic notation
>>>> (from one of the many logics).
>>>>
>>>> CMU teaches their CS courses all based on and requiring the use of
>>>> logic and the associated notation. My college mathematics covered
>>>> the use of truth tables. The graduate course covered the use of
>>>> Karnaugh maps.
>>>>
>>>> Reading current papers, I have found several papers with multiple
>>>> pages containing nothing but "judgements", pages of greek notation.
>>>> If you think Axiom's learning curve is steep, you should look at
>>>> Homotopy Type Theory (HoTT).
>>>>
>>>> I taught a compiler course at Vassar in the previous century but
>>>> the Dragon book didn't cover CIC in any detail and I would not
>>>> have understood it if it did.
>>>>
>>>> The original Axiom software predates most of the published logic
>>>> papers, at least as they applied to software. Haskell Curry wrote
>>>> from the logic side in 1934 and William Howard published in 1969
>>>> but I only heard of the Curry-Howard correspondence in 1998.
>>>>
>>>> Writing a compiler these days requires the use of this approach.
>>>> In all, that's a good thing as it makes it clear how to handle types
>>>> and how to construct software that is marginally more correct.
>>>>
>>>> The new Sane compiler is building on these logic foundations,
>>>> based on the Calculus of Inductive Construction and Dependent
>>>> Type theory. The compiler itself is strongly typed as is the
>>>> language it supports.
>>>>
>>>> Since dependent types are not decidable there will always be
>>>> heuristics at runtime to try to disambiguate types, only now we
>>>> will have to write the code in greek :-)
>>>>
>>>> Tim

\start
Date: Fri, 12 Jul 2019 05:11:40 -0400
From: Tim Daly <axiomcas@gmail.com>
To: axiom-dev <axiom-developer@nongnu.org>
Subject: Re: [Axiom-developer] [EXTERNAL] Re: Axiom's Sane redesign musings

Temptation...

I would like to remain faithful to Axiom's syntax for signatures

foo: (%,%) -> %

but the world seems to have converged on

foo: % -> % -> %

This shows up everywhere in logic, in haskell, etc.
It allows for a primitive kind of currying, the "right curry"
(Some form of scheme allows currying anywhere in the
argument list, including multiple currying)

I need to logic-style signatures for the axioms so the
tempation is to rewrite the Axiom signatures using the
logic notation.

I can do both but it might be clearer to follow the world
rather than follow our own, given the user base.

Tim


On 7/9/19, Tim Daly <axiomcas@gmail.com> wrote:
> ---------- Forwarded message ----------
> From: Tim Daly <axiomcas@gmail.com>
> Date: Tue, 9 Jul 2019 22:56:24 -0400
> Subject: Re: [EXTERNAL] Re: [Axiom-developer] Axiom's Sane redesign musings
> To: Martin Baker <ax87438@martinb.com>
>
> Progress is being made. Axiom was written long before Common
> Lisp existed. A lot of the code is due to translations from Maclisp
> and LispVM.
>
> I'm moving the Axiom hierarchy to Common Lisp CLOS code.
> This has several advantages.
>
> It eliminates the databases. They were created because there
> was not enough memory (at 16 megabytes).
>
> It uses native code to do dispatch.
>
> CLOS defclass creates Common Lisp types so all of the code
> is well-typed at the lisp level.
>
> CLOS is lisp so ordinary lisp code can use Axiom functions
> directly. This makes Axiom into an "embeddable library".
>
> CLOS is the target language for the Axiom compiler. The
> compiler is being re-architected to use nano passes [0] for
> compiling. This will make it much easier to maintain in
> the long term and much easier to extend.
>
> This technique allows building the compiler in stages from
> running code to running code at every step.
>
> The new interpreter is much simpler as it just runs the CLOS
> code directly.
>
> The choice of logic and specification languages are still unclear.
> These will also be created first at the lisp level and then covered
> by the compiler with additional nano-passes.
>
> Anyway, coding has begun.
>
> Tim
>
> [0]  Sarker, Dipanwita and Waddell, Oscar and Kybvig, R. Kent
> "A Nanopass Framework for Compiler Education" (2004)
>
>
> On 6/30/19, Tim Daly <axiomcas@gmail.com> wrote:
>> There are thousands of hours of expertise and thousands of
>> functions embedded in Spad code. An important design goal
>> is to ensure that code continues to function. The Sane compiler
>> will output code that runs in the interpreter. It is important that
>> "nothing breaks".
>>
>> That said, the Sane compiler is "layered". The core of the design
>> is that Axiom categories, domains, and packages are represnted
>> as lisp classes and instances. This "core" is essentially what the
>> compiler people call an Abstract Syntax Tree (AST). But in this
>> case it is much more than syntax.
>>
>> Given this "core" there are several tasks.
>>
>> 1) compile spad code to the core. The "front end" should
>> accept and understand current Spad code, unwinding it
>> into the core class structure.
>>
>> 2) compile core classes to Axiom data structures. Thi
>> "back end" generates current Axiom data structures from
>> the core data structures.
>>
>> Now the compiler generates working code yet is in a state
>> to accept enhancements, essentially by extending the core
>> class objects.
>>
>> 3) In the interpreter, modify the getdatabase function to
>> extract data from the core rather than the databases. So
>> the databases go away but the interpreter continues to work.
>>
>> So now the interpreter has been "lifted" onto the core classes
>> but continues to function.
>>
>> 4) enhance the core to support the axioms / specifications /
>> proofs /etc. This involves adding fields to the lisp classes.
>> This core work gives additional fields to hold information.
>>
>> 5) extend the Spad language (Spad 2.0?) to handle the
>> additional axioms / specifications / proofs / etc. This
>> involves adding syntax to the Spad language to support
>> the new fields.
>>
>> 6) build back-end targets to proof systems, spec systems,
>> etc. Compilers like GCC have multiple back ends. The Sane
>> compiler targets the interpreter, a specification checker, a
>> proof system, etc. as separate back ends, all from the same
>> core structures.
>>
>> The Compiler Design
>>
>> A separate but parallel design goal is to build the compiler so
>> it can be type-checked. Each function has typed input and
>> typed output and is, for the most part, purely functional. So,
>> for example, a "Filename" is an instance of a "File" object.
>> A "Line" is an instance of "String". The "FileReader" is
>>
>> FileReader : Filename -> List Line
>>
>> Careful design of the language used to construct hte compiler
>> (as opposed to the Spad language it accepts) makes it easier
>> to type check the compiler itself.
>>
>> By REALLY careful design, the types are build on a layered
>> subset of lisp, like Milawa
>> https://www.cl.cam.ac.uk/~mom22/soundness.pdf
>> which is sound all the way down to the metal.
>>
>> It all goes in stages. Build the new core class structure in a
>> strongly typed fashion. Accept the Spad language. Generate
>> Interpreter code. Enhance the core to support proofs / specs.
>> Enhance the language to support proofs / specs. Accept the
>> new language. Generate back ends to target the interpreter
>> and a proof / spec system. Build it all on a sound base so
>> the compiler can be checked.
>>
>> To the initial end user, the Sane version is the same as the
>> current system. But in the long term all of the Axiom code
>> could be called from any Lisp function. The Sane version
>> can also be used as an "Oracle" for proof systems, since
>> the code has been proven correct.
>>
>> This is a huge project but it can be done in small steps.
>> In particular, the goal is to build a "thin thread" all the way
>> through the system to handle only the GCD algorithms.
>> Once that proof happens "the real work begins".
>>
>> Tim
>>
>>
>>
>>
>> On 6/30/19, Martin Baker <ax87438@martinb.com> wrote:
>>> Tim,
>>>
>>> This all seems to be about the lisp layer, obviously thats what
>>> interests you.
>>>
>>> It seems to me that if SPAD code is complicated and not aligned to type
>>> theory then, when SPAD is complied to Lisp, the List code will be
>>> complicated and hard to work with. Your previous remarks, about not
>>> seeing the whole elephant, suggest to me that you are drowning in
>>> complexity. Most languages, in their lifetime, acquire some messiness
>>> that needs to be cleared out occasionally.
>>>
>>> Don't you think its time for SPAD 2.0 ?
>>>
>>> Martin
>>>
>>> On 30/06/2019 02:17, Tim Daly wrote:
>>>> One major Sane design decision is the use of CLOS,
>>>> the Common Lisp Object System.
>>>>
>>>> First, since each CLOS object is a type it is possible to
>>>> create strong types everywhere. This helps with the ultimate
>>>> need to typecheck the compiler and the generated code.
>>>>
>>>> Second, CLOS is an integral part of common lisp. One of
>>>> the Sane design goals is to make it possible to use Axiom's
>>>> domains in ordinary lisp programs. Since Axiom is nothing
>>>> more than a domain specific language on common lisp it
>>>> makes sense to construct it so users can freely intermix
>>>> polynomials with non-algebraic code.
>>>>
>>>> Third, CLOS is designed for large program development,
>>>> hiding most of the implementation details and exposing
>>>> a well-defined API. This will make future maintenance and
>>>> documentation of Axiom easier, contributing to its longer
>>>> intended life.
>>>>
>>>> So for a traditional Axiom user nothing seems to have
>>>> changed. But for future users it will be easy to compute
>>>> an integral in the middle of regular programs.
>>>>
>>>> Tim
>>>>
>>>> On 6/27/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>> Another thought....
>>>>>
>>>>> There has been a "step change" in computer science in the last few
>>>>> years.
>>>>>
>>>>> Guy Steele did a survey of the use of logic notation in conference
>>>>> papers.
>>>>> More than 50% of the papers in some conferences use logic notation
>>>>> (from one of the many logics).
>>>>>
>>>>> CMU teaches their CS courses all based on and requiring the use of
>>>>> logic and the associated notation. My college mathematics covered
>>>>> the use of truth tables. The graduate course covered the use of
>>>>> Karnaugh maps.
>>>>>
>>>>> Reading current papers, I have found several papers with multiple
>>>>> pages containing nothing but "judgements", pages of greek notation.
>>>>> If you think Axiom's learning curve is steep, you should look at
>>>>> Homotopy Type Theory (HoTT).
>>>>>
>>>>> I taught a compiler course at Vassar in the previous century but
>>>>> the Dragon book didn't cover CIC in any detail and I would not
>>>>> have understood it if it did.
>>>>>
>>>>> The original Axiom software predates most of the published logic
>>>>> papers, at least as they applied to software. Haskell Curry wrote
>>>>> from the logic side in 1934 and William Howard published in 1969
>>>>> but I only heard of the Curry-Howard correspondence in 1998.
>>>>>
>>>>> Writing a compiler these days requires the use of this approach.
>>>>> In all, that's a good thing as it makes it clear how to handle types
>>>>> and how to construct software that is marginally more correct.
>>>>>
>>>>> The new Sane compiler is building on these logic foundations,
>>>>> based on the Calculus of Inductive Construction and Dependent
>>>>> Type theory. The compiler itself is strongly typed as is the
>>>>> language it supports.
>>>>>
>>>>> Since dependent types are not decidable there will always be
>>>>> heuristics at runtime to try to disambiguate types, only now we
>>>>> will have to write the code in greek :-)
>>>>>
>>>>> Tim

\start
Date: Fri, 12 Jul 2019 21:45:56 +0000
From: William Sit <wsit@ccny.cuny.edu>
To: Tim Daly <axiomcas@gmail.com>
Subject: Re: [Axiom-developer] [EXTERNAL] Re: Axiom's Sane redesign musings

Dear Tim:=0A=
=0A=
According to Wiki on currying (https://en.wikipedia.org/wiki/Currying, para=
graph on lambda calculi):=0A=
=0A=
"Curried functions may be used in any programming language that supports cl=
osures; however, uncurried functions are generally preferred for efficiency=
 reasons, since the overhead of partial application and closure creation ca=
n then be avoided for most function calls."=0A=
See also the paragraph on "Contrast with partial function application."=0A=
=0A=
Moreover, under the paragraph on "Category theory,"=0A=
=0A=
"Currying can break down in one of two ways. One is if a category is not cl=
osed, and thus lacks an internal hom functor (possibly because there is mor=
e than one choice for such a functor). Another ways is if it is not monoida=
l, and thus lacks a product (that is, lacks a way of writing down pairs of =
objects). Categories that do have both products and internal homs are exact=
ly the closed monoidal categories."=0A=
=0A=
The rest of that paragraph is also worth reading and by examples, it shows =
perhaps why the logic notation is preferred because closed monoidal categor=
ies are very common. In particular:=0A=
=0A=
"By contrast, the product for monoidal categories (such as Hilbert space an=
d the vector spaces of functional analysis) is the tensor product. The inte=
rnal language of such categories is linear logic, a form of quantum logic; =
the corresponding type system is the linear type system. Such categories ar=
e suitable for describing entangled quantum states, and, more generally, al=
low a vast generalization of the Curry=96Howard correspondence to quantum m=
echanics, to cobordisms in algebraic topology, and to string theory.[1] The=
 linear type system, and linear logic are useful for describing synchroniza=
tion primitives, such as mutual exclusion locks, and the operation of vendi=
ng machines."=0A=
=0A=
Even if the goal is to have compatibility with other systems that uses curr=
ying or logic convention, it may not make sense to change the Axiom signatu=
re syntax for multi-input functions (which requires changes to the compiler=
 and other components). Perhaps a compromise would be to create a bidirecti=
onal translation Axiom package to facilitate the interfaces (that is, an im=
plementation of currying and uncurrying in Axiom to the targeted CAS using =
the currying convention). This should not be too hard in Lisp (for you :-))=
. This has the advantage that if the computation is from a currying system =
but to be done in Axiom, there is only one overhead call (uncurrying) for i=
nput, and perhaps another for output (currying, if the output is a function=
 type); and if the computation is from Axiom but to be done in a currying s=
ystem, there is also just one overhead call (currying) for input (here, I a=
ssume the currying system has optimized its implementation), and perhaps an=
other (decurrying, if the output is a function).=0A=
=0A=
There is no need to reinvent the wheel for either system.=0A=
=0A=
William=0A=
=0A=
William Sit=0A=
Professor Emeritus=0A=
Department of Mathematics=0A=
The City College of The City University of New York=0A=
New York, NY 10031=0A=
homepage: wsit.ccny.cuny.edu=0A=
=0A=
________________________________________=0A=
From: Axiom-developer <axiom-developer-bounces+wyscc=3Dsci.ccny.cuny.edu@no=
ngnu.org> on behalf of Tim Daly <axiomcas@gmail.com>=0A=
Sent: Friday, July 12, 2019 5:11 AM=0A=
To: axiom-dev=0A=
Subject: Re: [Axiom-developer] [EXTERNAL] Re: Axiom's Sane redesign musings=
=0A=
=0A=
Temptation...=0A=
=0A=
I would like to remain faithful to Axiom's syntax for signatures=0A=
=0A=
foo: (%,%) -> %=0A=
=0A=
but the world seems to have converged on=0A=
=0A=
foo: % -> % -> %=0A=
=0A=
This shows up everywhere in logic, in haskell, etc.=0A=
It allows for a primitive kind of currying, the "right curry"=0A=
(Some form of scheme allows currying anywhere in the=0A=
argument list, including multiple currying)=0A=
=0A=
I need to logic-style signatures for the axioms so the=0A=
tempation is to rewrite the Axiom signatures using the=0A=
logic notation.=0A=
=0A=
I can do both but it might be clearer to follow the world=0A=
rather than follow our own, given the user base.=0A=
=0A=
Tim=0A=
=0A=
=0A=
On 7/9/19, Tim Daly <axiomcas@gmail.com> wrote:=0A=
> ---------- Forwarded message ----------=0A=
> From: Tim Daly <axiomcas@gmail.com>=0A=
> Date: Tue, 9 Jul 2019 22:56:24 -0400=0A=
> Subject: Re: [EXTERNAL] Re: [Axiom-developer] Axiom's Sane redesign musin=
gs=0A=
> To: Martin Baker <ax87438@martinb.com>=0A=
>=0A=
> Progress is being made. Axiom was written long before Common=0A=
> Lisp existed. A lot of the code is due to translations from Maclisp=0A=
> and LispVM.=0A=
>=0A=
> I'm moving the Axiom hierarchy to Common Lisp CLOS code.=0A=
> This has several advantages.=0A=
>=0A=
> It eliminates the databases. They were created because there=0A=
> was not enough memory (at 16 megabytes).=0A=
>=0A=
> It uses native code to do dispatch.=0A=
>=0A=
> CLOS defclass creates Common Lisp types so all of the code=0A=
> is well-typed at the lisp level.=0A=
>=0A=
> CLOS is lisp so ordinary lisp code can use Axiom functions=0A=
> directly. This makes Axiom into an "embeddable library".=0A=
>=0A=
> CLOS is the target language for the Axiom compiler. The=0A=
> compiler is being re-architected to use nano passes [0] for=0A=
> compiling. This will make it much easier to maintain in=0A=
> the long term and much easier to extend.=0A=
>=0A=
> This technique allows building the compiler in stages from=0A=
> running code to running code at every step.=0A=
>=0A=
> The new interpreter is much simpler as it just runs the CLOS=0A=
> code directly.=0A=
>=0A=
> The choice of logic and specification languages are still unclear.=0A=
> These will also be created first at the lisp level and then covered=0A=
> by the compiler with additional nano-passes.=0A=
>=0A=
> Anyway, coding has begun.=0A=
>=0A=
> Tim=0A=
>=0A=
> [0]  Sarker, Dipanwita and Waddell, Oscar and Kybvig, R. Kent=0A=
> "A Nanopass Framework for Compiler Education" (2004)=0A=
>=0A=
>=0A=
> On 6/30/19, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>> There are thousands of hours of expertise and thousands of=0A=
>> functions embedded in Spad code. An important design goal=0A=
>> is to ensure that code continues to function. The Sane compiler=0A=
>> will output code that runs in the interpreter. It is important that=0A=
>> "nothing breaks".=0A=
>>=0A=
>> That said, the Sane compiler is "layered". The core of the design=0A=
>> is that Axiom categories, domains, and packages are represnted=0A=
>> as lisp classes and instances. This "core" is essentially what the=0A=
>> compiler people call an Abstract Syntax Tree (AST). But in this=0A=
>> case it is much more than syntax.=0A=
>>=0A=
>> Given this "core" there are several tasks.=0A=
>>=0A=
>> 1) compile spad code to the core. The "front end" should=0A=
>> accept and understand current Spad code, unwinding it=0A=
>> into the core class structure.=0A=
>>=0A=
>> 2) compile core classes to Axiom data structures. Thi=0A=
>> "back end" generates current Axiom data structures from=0A=
>> the core data structures.=0A=
>>=0A=
>> Now the compiler generates working code yet is in a state=0A=
>> to accept enhancements, essentially by extending the core=0A=
>> class objects.=0A=
>>=0A=
>> 3) In the interpreter, modify the getdatabase function to=0A=
>> extract data from the core rather than the databases. So=0A=
>> the databases go away but the interpreter continues to work.=0A=
>>=0A=
>> So now the interpreter has been "lifted" onto the core classes=0A=
>> but continues to function.=0A=
>>=0A=
>> 4) enhance the core to support the axioms / specifications /=0A=
>> proofs /etc. This involves adding fields to the lisp classes.=0A=
>> This core work gives additional fields to hold information.=0A=
>>=0A=
>> 5) extend the Spad language (Spad 2.0?) to handle the=0A=
>> additional axioms / specifications / proofs / etc. This=0A=
>> involves adding syntax to the Spad language to support=0A=
>> the new fields.=0A=
>>=0A=
>> 6) build back-end targets to proof systems, spec systems,=0A=
>> etc. Compilers like GCC have multiple back ends. The Sane=0A=
>> compiler targets the interpreter, a specification checker, a=0A=
>> proof system, etc. as separate back ends, all from the same=0A=
>> core structures.=0A=
>>=0A=
>> The Compiler Design=0A=
>>=0A=
>> A separate but parallel design goal is to build the compiler so=0A=
>> it can be type-checked. Each function has typed input and=0A=
>> typed output and is, for the most part, purely functional. So,=0A=
>> for example, a "Filename" is an instance of a "File" object.=0A=
>> A "Line" is an instance of "String". The "FileReader" is=0A=
>>=0A=
>> FileReader : Filename -> List Line=0A=
>>=0A=
>> Careful design of the language used to construct hte compiler=0A=
>> (as opposed to the Spad language it accepts) makes it easier=0A=
>> to type check the compiler itself.=0A=
>>=0A=
>> By REALLY careful design, the types are build on a layered=0A=
>> subset of lisp, like Milawa=0A=
>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.cl.cam.ac.uk_=
-7Emom22_soundness.pdf&d=3DDwIGaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRw=
tIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3DvSWzY44D3q0Zbuii=
WC71z-d0735kVc-z56JhhJvTxWk&s=3DhlB5Qn3wSwx2kqsIJIM6yL63N8pGP_FZJQWPvOz_Anw=
&e=3D=0A=
>> which is sound all the way down to the metal.=0A=
>>=0A=
>> It all goes in stages. Build the new core class structure in a=0A=
>> strongly typed fashion. Accept the Spad language. Generate=0A=
>> Interpreter code. Enhance the core to support proofs / specs.=0A=
>> Enhance the language to support proofs / specs. Accept the=0A=
>> new language. Generate back ends to target the interpreter=0A=
>> and a proof / spec system. Build it all on a sound base so=0A=
>> the compiler can be checked.=0A=
>>=0A=
>> To the initial end user, the Sane version is the same as the=0A=
>> current system. But in the long term all of the Axiom code=0A=
>> could be called from any Lisp function. The Sane version=0A=
>> can also be used as an "Oracle" for proof systems, since=0A=
>> the code has been proven correct.=0A=
>>=0A=
>> This is a huge project but it can be done in small steps.=0A=
>> In particular, the goal is to build a "thin thread" all the way=0A=
>> through the system to handle only the GCD algorithms.=0A=
>> Once that proof happens "the real work begins".=0A=
>>=0A=
>> Tim=0A=
>>=0A=
>>=0A=
>>=0A=
>>=0A=
>> On 6/30/19, Martin Baker <ax87438@martinb.com> wrote:=0A=
>>> Tim,=0A=
>>>=0A=
>>> This all seems to be about the lisp layer, obviously thats what=0A=
>>> interests you.=0A=
>>>=0A=
>>> It seems to me that if SPAD code is complicated and not aligned to type=
=0A=
>>> theory then, when SPAD is complied to Lisp, the List code will be=0A=
>>> complicated and hard to work with. Your previous remarks, about not=0A=
>>> seeing the whole elephant, suggest to me that you are drowning in=0A=
>>> complexity. Most languages, in their lifetime, acquire some messiness=
=0A=
>>> that needs to be cleared out occasionally.=0A=
>>>=0A=
>>> Don't you think its time for SPAD 2.0 ?=0A=
>>>=0A=
>>> Martin=0A=
>>>=0A=
>>> On 30/06/2019 02:17, Tim Daly wrote:=0A=
>>>> One major Sane design decision is the use of CLOS,=0A=
>>>> the Common Lisp Object System.=0A=
>>>>=0A=
>>>> First, since each CLOS object is a type it is possible to=0A=
>>>> create strong types everywhere. This helps with the ultimate=0A=
>>>> need to typecheck the compiler and the generated code.=0A=
>>>>=0A=
>>>> Second, CLOS is an integral part of common lisp. One of=0A=
>>>> the Sane design goals is to make it possible to use Axiom's=0A=
>>>> domains in ordinary lisp programs. Since Axiom is nothing=0A=
>>>> more than a domain specific language on common lisp it=0A=
>>>> makes sense to construct it so users can freely intermix=0A=
>>>> polynomials with non-algebraic code.=0A=
>>>>=0A=
>>>> Third, CLOS is designed for large program development,=0A=
>>>> hiding most of the implementation details and exposing=0A=
>>>> a well-defined API. This will make future maintenance and=0A=
>>>> documentation of Axiom easier, contributing to its longer=0A=
>>>> intended life.=0A=
>>>>=0A=
>>>> So for a traditional Axiom user nothing seems to have=0A=
>>>> changed. But for future users it will be easy to compute=0A=
>>>> an integral in the middle of regular programs.=0A=
>>>>=0A=
>>>> Tim=0A=
>>>>=0A=
>>>> On 6/27/19, Tim Daly <axiomcas@gmail.com> wrote:=0A=
>>>>> Another thought....=0A=
>>>>>=0A=
>>>>> There has been a "step change" in computer science in the last few=0A=
>>>>> years.=0A=
>>>>>=0A=
>>>>> Guy Steele did a survey of the use of logic notation in conference=0A=
>>>>> papers.=0A=
>>>>> More than 50% of the papers in some conferences use logic notation=0A=
>>>>> (from one of the many logics).=0A=
>>>>>=0A=
>>>>> CMU teaches their CS courses all based on and requiring the use of=0A=
>>>>> logic and the associated notation. My college mathematics covered=0A=
>>>>> the use of truth tables. The graduate course covered the use of=0A=
>>>>> Karnaugh maps.=0A=
>>>>>=0A=
>>>>> Reading current papers, I have found several papers with multiple=0A=
>>>>> pages containing nothing but "judgements", pages of greek notation.=
=0A=
>>>>> If you think Axiom's learning curve is steep, you should look at=0A=
>>>>> Homotopy Type Theory (HoTT).=0A=
>>>>>=0A=
>>>>> I taught a compiler course at Vassar in the previous century but=0A=
>>>>> the Dragon book didn't cover CIC in any detail and I would not=0A=
>>>>> have understood it if it did.=0A=
>>>>>=0A=
>>>>> The original Axiom software predates most of the published logic=0A=
>>>>> papers, at least as they applied to software. Haskell Curry wrote=0A=
>>>>> from the logic side in 1934 and William Howard published in 1969=0A=
>>>>> but I only heard of the Curry-Howard correspondence in 1998.=0A=
>>>>>=0A=
>>>>> Writing a compiler these days requires the use of this approach.=0A=
>>>>> In all, that's a good thing as it makes it clear how to handle types=
=0A=
>>>>> and how to construct software that is marginally more correct.=0A=
>>>>>=0A=
>>>>> The new Sane compiler is building on these logic foundations,=0A=
>>>>> based on the Calculus of Inductive Construction and Dependent=0A=
>>>>> Type theory. The compiler itself is strongly typed as is the=0A=
>>>>> language it supports.=0A=
>>>>>=0A=
>>>>> Since dependent types are not decidable there will always be=0A=
>>>>> heuristics at runtime to try to disambiguate types, only now we=0A=
>>>>> will have to write the code in greek :-)=0A=
>>>>>=0A=
>>>>> Tim=0A=

\start
Date: Fri, 12 Jul 2019 23:57:13 -0400
From: Tim Daly <axiomcas@gmail.com>
To: William Sit <wsit@ccny.cuny.edu>
Subject: Re: [Axiom-developer] [EXTERNAL] Re: Axiom's Sane redesign musings

>"Curried functions may be used in any programming language that supports c=
losures;
>however, uncurried functions are generally preferred for efficiency reason=
s, since the
>overhead of partial application and closure creation can then be avoided f=
or most function
>calls."See also the paragraph on "Contrast with partial function applicati=
on."

Overhead of creating a curried lisp function is almost nothing. Lisp
handles closures
and function creation all the time. A macro to create a curried lisp
function is a small
classroom exercise.

>Moreover, under the paragraph on "Category theory,"

>"Currying can break down in one of two ways. One is if a category is not c=
losed, and
>thus lacks an internal hom functor (possibly because there is more than on=
e choice
>for such a functor). Another ways is if it is not monoidal, and thus lacks=
 a product
>(that is, lacks a way of writing down pairs of objects). Categories that d=
o have both
>products and internal homs are exactly the closed monoidal categories."

Indeed. I suspect, though I don't know, that most of the Axiom functions ba=
sed
on group theory are closed monoidial. The same is likely true tor the data
structure manipulating code.

>The rest of that paragraph is also worth reading and by examples, it shows
>perhaps why the logic notation is preferred because closed monoidal catego=
ries
>are very common.

>"By contrast, the product for monoidal categories (such as Hilbert space a=
nd the
>vector spaces of functional analysis) is the tensor product. The internal =
language
>of such categories is linear logic, a form of quantum logic; the correspon=
ding type
>system is the linear type system.

Frank Pfenning http://www.cs.cmu.edu/~fp/
taught me everything I know about linear logic. He has pointed
me at papers and talks (especially his Oregon lectures,
https://www.cs.uoregon.edu/research/summerschool/summer18/topics.php
as well as Stephanie Balzer's lectures). I admit I do not yet have a handle
on where I can use linear logic. It applies really well in communication bu=
t
I'm not sure how to apply it in the Axiom context, except in the conext of
parallel computation. However, I'm still climbing the (near-vertically) ste=
ep
hill of logic and proofs. The amount I don't know currently fills 3
shelves of my
bookcase.

>Even if the goal is to have compatibility with other systems that uses cur=
rying
>or logic convention, it may not make sense to change the Axiom signature
>syntax for multi-input functions (which requires changes to the compiler a=
nd
>other components).

I am rewriting the compiler / interpreter in Common Lisp CLOS. CLOS can
handle most of Axiom's inheritance automatically. I have most of the catego=
ries
built so far. For non-standard lookups it provides an override.

Since the new (Sane) compiler is going to handle logic syntax for axioms,
theorems, and specification it seems reasonable to use a syntax and semanti=
cs
from the existing proof systems (Coq, Lean, etc..). I will have to export p=
roofs
to those systems both because they need to trust Axiom (I hope Axiom can be
the "Oracle" for proof systems doing computation) and because I'm not
smart enough to do otherwise.

>Perhaps a compromise would be to create a bidirectional
>translation Axiom package to facilitate the interfaces (that is, an implem=
entation
>of currying and uncurrying in Axiom to the targeted CAS using the currying
>convention). This should not be too hard in Lisp (for you :-)). This has t=
he
>advantage that if the computation is from a currying system but to be done
>in Axiom, there is only one overhead call (uncurrying) for input, and perh=
aps
>another for output (currying, if the output is a function type); and if th=
e
>computation is from Axiom but to be done in a currying system, there is
>also just one overhead call (currying) for input (here, I assume the curry=
ing
>system has optimized its implementation), and perhaps another (decurrying,
>if the output is a function).

Currying isn't really that much of a motivation for adopting logic syntax.

The main reason is that most people in computer science these days are
generating papers using rules and judgements (witness the talk given at
CCNY by Andre Platzer combining logic and differential equations).
https://www.youtube.com/watch?v=3D4QDeZnw7_m0

Guy Steele gave a talk where he counted the use of logical notation trends
in published research papers. It is now well above 50 percent.
https://www.youtube.com/watch?v=3DdCuZkaaou0Q

I could easily accept both Axiom's input forms and Logic input forms
but the world seems to use the logic forms, even in code (e.g. Haskell).
Given that about a dozen people use the Axiom notation why would it
make sense to use it for Spad and a different notation for the axioms?

Axiom's syntax is really showing its age.

The more interesting (and not in a good way) change is my current
struggle over using unicode in the input/output syntax. Should the 'sum'
function be 'sum' or '\sum' (i.e. a sigma)? Is subscript I/O unicode?
Can you write an integral sign in a signature as a function name?

The unicode issue is further highlighted by the fact that X11 support
is going into "maintenance mode". That means I have to move the
documentation and graphics to a browser or jupiter front-end. I have
previously worked out the Axiom browser notebook (Volume 11) but
not the graphics.
https://en.wikipedia.org/wiki/Axiom_(computer_algebra_system)

More interesting is the issue of moving from the 1960s CHARYBDIS
I/O to in-browser latex I/O. The output equations are much prettier.
And the current trend for input seems to be a form of in-browser
literate programs, witness:
https://leanprover.github.io/tutorial/
and
https://x80.org/rhino-coq/

>There is no need to reinvent the wheel for either system

Axiom is an amazing collection of algorithms but it is not keeping
up with current trends. Nobody wants to work in a system that will
die of old age so we need to adapt and grow. "More of the same"
is not enough. By combining computer algebra and proof systems
with a more current front end and better literate documentation
we are breaking new ground, which should keep us relevant for at
least a few weeks at the current world speed.

I thought "The 30 Year Horizon" was further away...

Tim


On 7/12/19, William Sit <wsit@ccny.cuny.edu> wrote:
> Dear Tim:
>
> According to Wiki on currying (https://en.wikipedia.org/wiki/Currying,
> paragraph on lambda calculi):
>
> "Curried functions may be used in any programming language that supports
> closures; however, uncurried functions are generally preferred for
> efficiency reasons, since the overhead of partial application and closure
> creation can then be avoided for most function calls."
> See also the paragraph on "Contrast with partial function application."
>
> Moreover, under the paragraph on "Category theory,"
>
> "Currying can break down in one of two ways. One is if a category is not
> closed, and thus lacks an internal hom functor (possibly because there is
> more than one choice for such a functor). Another ways is if it is not
> monoidal, and thus lacks a product (that is, lacks a way of writing down
> pairs of objects). Categories that do have both products and internal hom=
s
> are exactly the closed monoidal categories."
>
> The rest of that paragraph is also worth reading and by examples, it show=
s
> perhaps why the logic notation is preferred because closed monoidal
> categories are very common. In particular:
>
> "By contrast, the product for monoidal categories (such as Hilbert space =
and
> the vector spaces of functional analysis) is the tensor product. The
> internal language of such categories is linear logic, a form of quantum
> logic; the corresponding type system is the linear type system. Such
> categories are suitable for describing entangled quantum states, and, mor=
e
> generally, allow a vast generalization of the Curry=E2=80=93Howard corres=
pondence to
> quantum mechanics, to cobordisms in algebraic topology, and to string
> theory.[1] The linear type system, and linear logic are useful for
> describing synchronization primitives, such as mutual exclusion locks, an=
d
> the operation of vending machines."
>
> Even if the goal is to have compatibility with other systems that uses
> currying or logic convention, it may not make sense to change the Axiom
> signature syntax for multi-input functions (which requires changes to the
> compiler and other components). Perhaps a compromise would be to create a
> bidirectional translation Axiom package to facilitate the interfaces (tha=
t
> is, an implementation of currying and uncurrying in Axiom to the targeted
> CAS using the currying convention). This should not be too hard in Lisp (=
for
> you :-)). This has the advantage that if the computation is from a curryi=
ng
> system but to be done in Axiom, there is only one overhead call (uncurryi=
ng)
> for input, and perhaps another for output (currying, if the output is a
> function type); and if the computation is from Axiom but to be done in a
> currying system, there is also just one overhead call (currying) for inpu=
t
> (here, I assume the currying system has optimized its implementation), an=
d
> perhaps another (decurrying, if the output is a function).
>
> There is no need to reinvent the wheel for either system.
>
> William
>
> William Sit
> Professor Emeritus
> Department of Mathematics
> The City College of The City University of New York
> New York, NY 10031
> homepage: wsit.ccny.cuny.edu
>
> ________________________________________
> From: Axiom-developer
> <axiom-developer-bounces+wyscc=3Dsci.ccny.cuny.edu@nongnu.org> on behalf =
of
> Tim Daly <axiomcas@gmail.com>
> Sent: Friday, July 12, 2019 5:11 AM
> To: axiom-dev
> Subject: Re: [Axiom-developer] [EXTERNAL] Re: Axiom's Sane redesign musin=
gs
>
> Temptation...
>
> I would like to remain faithful to Axiom's syntax for signatures
>
> foo: (%,%) -> %
>
> but the world seems to have converged on
>
> foo: % -> % -> %
>
> This shows up everywhere in logic, in haskell, etc.
> It allows for a primitive kind of currying, the "right curry"
> (Some form of scheme allows currying anywhere in the
> argument list, including multiple currying)
>
> I need to logic-style signatures for the axioms so the
> tempation is to rewrite the Axiom signatures using the
> logic notation.
>
> I can do both but it might be clearer to follow the world
> rather than follow our own, given the user base.
>
> Tim
>
>
> On 7/9/19, Tim Daly <axiomcas@gmail.com> wrote:
>> ---------- Forwarded message ----------
>> From: Tim Daly <axiomcas@gmail.com>
>> Date: Tue, 9 Jul 2019 22:56:24 -0400
>> Subject: Re: [EXTERNAL] Re: [Axiom-developer] Axiom's Sane redesign
>> musings
>> To: Martin Baker <ax87438@martinb.com>
>>
>> Progress is being made. Axiom was written long before Common
>> Lisp existed. A lot of the code is due to translations from Maclisp
>> and LispVM.
>>
>> I'm moving the Axiom hierarchy to Common Lisp CLOS code.
>> This has several advantages.
>>
>> It eliminates the databases. They were created because there
>> was not enough memory (at 16 megabytes).
>>
>> It uses native code to do dispatch.
>>
>> CLOS defclass creates Common Lisp types so all of the code
>> is well-typed at the lisp level.
>>
>> CLOS is lisp so ordinary lisp code can use Axiom functions
>> directly. This makes Axiom into an "embeddable library".
>>
>> CLOS is the target language for the Axiom compiler. The
>> compiler is being re-architected to use nano passes [0] for
>> compiling. This will make it much easier to maintain in
>> the long term and much easier to extend.
>>
>> This technique allows building the compiler in stages from
>> running code to running code at every step.
>>
>> The new interpreter is much simpler as it just runs the CLOS
>> code directly.
>>
>> The choice of logic and specification languages are still unclear.
>> These will also be created first at the lisp level and then covered
>> by the compiler with additional nano-passes.
>>
>> Anyway, coding has begun.
>>
>> Tim
>>
>> [0]  Sarker, Dipanwita and Waddell, Oscar and Kybvig, R. Kent
>> "A Nanopass Framework for Compiler Education" (2004)
>>
>>
>> On 6/30/19, Tim Daly <axiomcas@gmail.com> wrote:
>>> There are thousands of hours of expertise and thousands of
>>> functions embedded in Spad code. An important design goal
>>> is to ensure that code continues to function. The Sane compiler
>>> will output code that runs in the interpreter. It is important that
>>> "nothing breaks".
>>>
>>> That said, the Sane compiler is "layered". The core of the design
>>> is that Axiom categories, domains, and packages are represnted
>>> as lisp classes and instances. This "core" is essentially what the
>>> compiler people call an Abstract Syntax Tree (AST). But in this
>>> case it is much more than syntax.
>>>
>>> Given this "core" there are several tasks.
>>>
>>> 1) compile spad code to the core. The "front end" should
>>> accept and understand current Spad code, unwinding it
>>> into the core class structure.
>>>
>>> 2) compile core classes to Axiom data structures. Thi
>>> "back end" generates current Axiom data structures from
>>> the core data structures.
>>>
>>> Now the compiler generates working code yet is in a state
>>> to accept enhancements, essentially by extending the core
>>> class objects.
>>>
>>> 3) In the interpreter, modify the getdatabase function to
>>> extract data from the core rather than the databases. So
>>> the databases go away but the interpreter continues to work.
>>>
>>> So now the interpreter has been "lifted" onto the core classes
>>> but continues to function.
>>>
>>> 4) enhance the core to support the axioms / specifications /
>>> proofs /etc. This involves adding fields to the lisp classes.
>>> This core work gives additional fields to hold information.
>>>
>>> 5) extend the Spad language (Spad 2.0?) to handle the
>>> additional axioms / specifications / proofs / etc. This
>>> involves adding syntax to the Spad language to support
>>> the new fields.
>>>
>>> 6) build back-end targets to proof systems, spec systems,
>>> etc. Compilers like GCC have multiple back ends. The Sane
>>> compiler targets the interpreter, a specification checker, a
>>> proof system, etc. as separate back ends, all from the same
>>> core structures.
>>>
>>> The Compiler Design
>>>
>>> A separate but parallel design goal is to build the compiler so
>>> it can be type-checked. Each function has typed input and
>>> typed output and is, for the most part, purely functional. So,
>>> for example, a "Filename" is an instance of a "File" object.
>>> A "Line" is an instance of "String". The "FileReader" is
>>>
>>> FileReader : Filename -> List Line
>>>
>>> Careful design of the language used to construct hte compiler
>>> (as opposed to the Spad language it accepts) makes it easier
>>> to type check the compiler itself.
>>>
>>> By REALLY careful design, the types are build on a layered
>>> subset of lisp, like Milawa
>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.cl.cam.ac.uk=
_-7Emom22_soundness.pdf&d=3DDwIGaQ&c=3D4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHR=
wtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3DvSWzY44D3q0Zbui=
iWC71z-d0735kVc-z56JhhJvTxWk&s=3DhlB5Qn3wSwx2kqsIJIM6yL63N8pGP_FZJQWPvOz_An=
w&e=3D
>>> which is sound all the way down to the metal.
>>>
>>> It all goes in stages. Build the new core class structure in a
>>> strongly typed fashion. Accept the Spad language. Generate
>>> Interpreter code. Enhance the core to support proofs / specs.
>>> Enhance the language to support proofs / specs. Accept the
>>> new language. Generate back ends to target the interpreter
>>> and a proof / spec system. Build it all on a sound base so
>>> the compiler can be checked.
>>>
>>> To the initial end user, the Sane version is the same as the
>>> current system. But in the long term all of the Axiom code
>>> could be called from any Lisp function. The Sane version
>>> can also be used as an "Oracle" for proof systems, since
>>> the code has been proven correct.
>>>
>>> This is a huge project but it can be done in small steps.
>>> In particular, the goal is to build a "thin thread" all the way
>>> through the system to handle only the GCD algorithms.
>>> Once that proof happens "the real work begins".
>>>
>>> Tim
>>>
>>>
>>>
>>>
>>> On 6/30/19, Martin Baker <ax87438@martinb.com> wrote:
>>>> Tim,
>>>>
>>>> This all seems to be about the lisp layer, obviously thats what
>>>> interests you.
>>>>
>>>> It seems to me that if SPAD code is complicated and not aligned to typ=
e
>>>> theory then, when SPAD is complied to Lisp, the List code will be
>>>> complicated and hard to work with. Your previous remarks, about not
>>>> seeing the whole elephant, suggest to me that you are drowning in
>>>> complexity. Most languages, in their lifetime, acquire some messiness
>>>> that needs to be cleared out occasionally.
>>>>
>>>> Don't you think its time for SPAD 2.0 ?
>>>>
>>>> Martin
>>>>
>>>> On 30/06/2019 02:17, Tim Daly wrote:
>>>>> One major Sane design decision is the use of CLOS,
>>>>> the Common Lisp Object System.
>>>>>
>>>>> First, since each CLOS object is a type it is possible to
>>>>> create strong types everywhere. This helps with the ultimate
>>>>> need to typecheck the compiler and the generated code.
>>>>>
>>>>> Second, CLOS is an integral part of common lisp. One of
>>>>> the Sane design goals is to make it possible to use Axiom's
>>>>> domains in ordinary lisp programs. Since Axiom is nothing
>>>>> more than a domain specific language on common lisp it
>>>>> makes sense to construct it so users can freely intermix
>>>>> polynomials with non-algebraic code.
>>>>>
>>>>> Third, CLOS is designed for large program development,
>>>>> hiding most of the implementation details and exposing
>>>>> a well-defined API. This will make future maintenance and
>>>>> documentation of Axiom easier, contributing to its longer
>>>>> intended life.
>>>>>
>>>>> So for a traditional Axiom user nothing seems to have
>>>>> changed. But for future users it will be easy to compute
>>>>> an integral in the middle of regular programs.
>>>>>
>>>>> Tim
>>>>>
>>>>> On 6/27/19, Tim Daly <axiomcas@gmail.com> wrote:
>>>>>> Another thought....
>>>>>>
>>>>>> There has been a "step change" in computer science in the last few
>>>>>> years.
>>>>>>
>>>>>> Guy Steele did a survey of the use of logic notation in conference
>>>>>> papers.
>>>>>> More than 50% of the papers in some conferences use logic notation
>>>>>> (from one of the many logics).
>>>>>>
>>>>>> CMU teaches their CS courses all based on and requiring the use of
>>>>>> logic and the associated notation. My college mathematics covered
>>>>>> the use of truth tables. The graduate course covered the use of
>>>>>> Karnaugh maps.
>>>>>>
>>>>>> Reading current papers, I have found several papers with multiple
>>>>>> pages containing nothing but "judgements", pages of greek notation.
>>>>>> If you think Axiom's learning curve is steep, you should look at
>>>>>> Homotopy Type Theory (HoTT).
>>>>>>
>>>>>> I taught a compiler course at Vassar in the previous century but
>>>>>> the Dragon book didn't cover CIC in any detail and I would not
>>>>>> have understood it if it did.
>>>>>>
>>>>>> The original Axiom software predates most of the published logic
>>>>>> papers, at least as they applied to software. Haskell Curry wrote
>>>>>> from the logic side in 1934 and William Howard published in 1969
>>>>>> but I only heard of the Curry-Howard correspondence in 1998.
>>>>>>
>>>>>> Writing a compiler these days requires the use of this approach.
>>>>>> In all, that's a good thing as it makes it clear how to handle types
>>>>>> and how to construct software that is marginally more correct.
>>>>>>
>>>>>> The new Sane compiler is building on these logic foundations,
>>>>>> based on the Calculus of Inductive Construction and Dependent
>>>>>> Type theory. The compiler itself is strongly typed as is the
>>>>>> language it supports.
>>>>>>
>>>>>> Since dependent types are not decidable there will always be
>>>>>> heuristics at runtime to try to disambiguate types, only now we
>>>>>> will have to write the code in greek :-)
>>>>>>
>>>>>> Tim

\start
Date: Mon, 15 Jul 2019 23:51:23 -0400
From: Tim Daly <axiomcas@gmail.com>
To: axiom-dev <axiom-developer@nongnu.org>
Subject: [Axiom-developer] Fwd: A Philosophy of Software Design

---------- Forwarded message ----------
From: Tim Daly <axiomcas@gmail.com>
Date: Mon, 15 Jul 2019 08:29:05 -0400
Subject: A Philosophy of Software Design
To: software-design-book@googlegroups.com, axiomcas@gmail.com

I'm watching your Google talk on youtube.

I've been programming for 50 years. I've done free software development
since 1996. I've written a LOT of code in over 60 languages. I have co-authored
4 commercial products. So I feel like I need to comment.

BORN or LEARN?

First, you ask if programming is something you are born with or something
you can learn. I think I could teach anyone who can follow a cooking recipe
to program. Learning to program is easy.

But programming is hard. It requires an inborn talent which is the ability to
cope with very high levels of frustration and ambiguity. I have spent a whole
week chasing a bug only to find that it is a compiler bug (4 times so far).
If you can't handle the ground-pounding frustration of failing software which
leads you to scream "WHY DOESN"T THIS WORK" and still continue then
you will never be a programmer.

I whole-heartedly agree with the value of code reviews for learning.

DEEP CLASSES

I tend to both agree and disagree with your deep class idea. I agree
that it is a useful idea for design. But I think it is a bad idea for coding.
Deep classes have a lot of complexity and are extremely specific to
the problem to be solved. Unfortunately, most of the lifetime of code
is post-development. Maintaining deep-class code is nearly impossible
because it is so task specific.

I prefer deeply layered code. See, for example, Sarker [0] where the
development is incremental and deeply layered. But the intellectual
steps are small and easily adapted. I find this form of development
easier to do, easier to teach, and easier to maintain. The most
productive programmers I know write small but working pieces of
code that makes incremental steps of improvement. Note that this
is NOT a tactical approach with ad hoc decisions, but small steps
toward the ultimate goals.

I took a course (at UCONN) where the prof gave us the spec of a
multitasking operating system. He gave us 10 weeks (in teams) to
develop it. It had to run on bare hardware (these days, an Arduino).
We had to process 100 "batch programs" to be run in minumum
time, assuming they block for I/O, etc. We developed a minimal
Read-Schedule-Process-Print loop and then enhanced it bit by bit.
You might consider that as an example project.

So while I agree that a Deep Class DESIGN is seems like a good
short term idea, I think it costs much more in the long term due to
the high maintain / modify costs.

Designers need to consider the full software lifecycle, not just the
initial implementation. You would not like an automobile that was
glued together and could not be fixed.

LOGIC and PROOF

In my later years I have watched the growth of proving
programs correct. I think designers need to write specifications
that can be proven. There is a HUGE growth in this field. See
Guy Steele [3] invited talk.

Designers need to be deeply educated in program proof and
typing. At UCONN I took a course that just gave us a pile of
research papers. We each were assigned 3 papers from the
pile. Each paper had to be presented to the class in a 20
minute talk. You were graded on your 3 presentations. We
not only learned the theory, we learned to read (and write)
research literature.

FOSS CONTRIBUTION

There is an alternative to wasting class time developing new
code to review.

You could structure a class for designers that took an
open source codebase from github for analysis. The whole
codebase would be reviewed throughout the semester and
each person who led the section could post fixes from the
code reviews to the open source site. Not only would they
see real design issues, they would learn to participate in
open source (and, incidently, how to maintain with source
code control).

LITERATE PROGRAMMING

On another track, I think you should teach literate programming.
All it takes is a simple latex macro and a trivial C[1] or Lisp[2]
program to extract code from a latex document. Future designers
out to follow the wisdom of Knuth and learn to write for humans
and, incidently, for computers.

Tim Daly
http://daly.axiom-developer.org
Carnegie Mellon University

[0] Sarker, Dipanwita and Waddell, Oscar and Dybvig, R. Kent
"A Nonpass Infrastructure for Compiler Education" (2004)
9th ACM SIGPLAN, pp 201-212

[1] http://daly.axiom-developer.org/tanglec.c

[2] http://daly.axiom-developer.org/tangle.lisp

[3] https://www.youtube.com/watch?v=dCuZkaaou0Q

\start
Date: Mon, 15 Jul 2019 23:51:48 -0400
From: Tim Daly <axiomcas@gmail.com>
To: axiom-dev <axiom-developer@nongnu.org>
Subject: [Axiom-developer] Fwd: [software-design-book] A Philosophy of
 Software Design

---------- Forwarded message ----------
From: John Ousterhout <ouster@cs.stanford.edu>
Date: Mon, 15 Jul 2019 10:52:23 -0700
Subject: Re: [software-design-book] A Philosophy of Software Design
To: Tim Daly <axiomcas@gmail.com>
Cc: software-design-book <software-design-book@googlegroups.com>

Hi Tim,

Thanks for the comments. Here are a few overall followups.

* You expressed a concern that deep classes might be harder to maintain and
modify. If this were the case, then deep classes would be a bad idea.
However, my experience is that deep classes make it *easier* to maintain
and modify software. Deep classes don't have to be more complicated than
shallow ones, and well-designed deep code is mostly non-task-specific (see
Chapter 6 of APOSD).

* You argued for proving correctness. I'm not opposed to this, but as of
today I believe it is too difficult and time-intensive to be practical in
most environments. In other words, if you're looking for the lowest-cost
way to achieve a given level of functionality, reliability, etc., you can
probably get there more cheaply using the more intuitive design approaches
I advocate than using formal verification. It feels like verification is
making gradual progress, so perhaps this situation will change in the
future. Also, for systems that require extremely high levels of
reliability, it may be that formal verification is the only way to get
there today.

* You suggested analyzing existing open source projects rather than writing
new code. There is certainly value in analyzing existing code, but in terms
of students learning how to design, it's crucial that they write code
themselves and get feedback on it. I would draw an analogy with writing.
Reading great books can be helpful in learning to write, but it is nowhere
near sufficient: you have to write stuff yourself, make mistakes, get
feedback, and fix the mistakes.

-John-

On Mon, Jul 15, 2019 at 5:29 AM Tim Daly <axiomcas@gmail.com> wrote:

> I'm watching your Google talk on youtube.
>
> I've been programming for 50 years. I've done free software development
> since 1996. I've written a LOT of code in over 60 languages. I have
> co-authored
> 4 commercial products. So I feel like I need to comment.
>
> BORN or LEARN?
>
> First, you ask if programming is something you are born with or something
> you can learn. I think I could teach anyone who can follow a cooking recipe
> to program. Learning to program is easy.
>
> But programming is hard. It requires an inborn talent which is the ability
> to
> cope with very high levels of frustration and ambiguity. I have spent a
> whole
> week chasing a bug only to find that it is a compiler bug (4 times so far).
> If you can't handle the ground-pounding frustration of failing software
> which
> leads you to scream "WHY DOESN"T THIS WORK" and still continue then
> you will never be a programmer.
>
> I whole-heartedly agree with the value of code reviews for learning.
>
> DEEP CLASSES
>
> I tend to both agree and disagree with your deep class idea. I agree
> that it is a useful idea for design. But I think it is a bad idea for
> coding.
> Deep classes have a lot of complexity and are extremely specific to
> the problem to be solved. Unfortunately, most of the lifetime of code
> is post-development. Maintaining deep-class code is nearly impossible
> because it is so task specific.
>
> I prefer deeply layered code. See, for example, Sarker [0] where the
> development is incremental and deeply layered. But the intellectual
> steps are small and easily adapted. I find this form of development
> easier to do, easier to teach, and easier to maintain. The most
> productive programmers I know write small but working pieces of
> code that makes incremental steps of improvement. Note that this
> is NOT a tactical approach with ad hoc decisions, but small steps
> toward the ultimate goals.
>
> I took a course (at UCONN) where the prof gave us the spec of a
> multitasking operating system. He gave us 10 weeks (in teams) to
> develop it. It had to run on bare hardware (these days, an Arduino).
> We had to process 100 "batch programs" to be run in minumum
> time, assuming they block for I/O, etc. We developed a minimal
> Read-Schedule-Process-Print loop and then enhanced it bit by bit.
> You might consider that as an example project.
>
> So while I agree that a Deep Class DESIGN is seems like a good
> short term idea, I think it costs much more in the long term due to
> the high maintain / modify costs.
>
> Designers need to consider the full software lifecycle, not just the
> initial implementation. You would not like an automobile that was
> glued together and could not be fixed.
>
> LOGIC and PROOF
>
> In my later years I have watched the growth of proving
> programs correct. I think designers need to write specifications
> that can be proven. There is a HUGE growth in this field. See
> Guy Steele [3] invited talk.
>
> Designers need to be deeply educated in program proof and
> typing. At UCONN I took a course that just gave us a pile of
> research papers. We each were assigned 3 papers from the
> pile. Each paper had to be presented to the class in a 20
> minute talk. You were graded on your 3 presentations. We
> not only learned the theory, we learned to read (and write)
> research literature.
>
> FOSS CONTRIBUTION
>
> There is an alternative to wasting class time developing new
> code to review.
>
> You could structure a class for designers that took an
> open source codebase from github for analysis. The whole
> codebase would be reviewed throughout the semester and
> each person who led the section could post fixes from the
> code reviews to the open source site. Not only would they
> see real design issues, they would learn to participate in
> open source (and, incidently, how to maintain with source
> code control).
>
> LITERATE PROGRAMMING
>
> On another track, I think you should teach literate programming.
> All it takes is a simple latex macro and a trivial C[1] or Lisp[2]
> program to extract code from a latex document. Future designers
> out to follow the wisdom of Knuth and learn to write for humans
> and, incidently, for computers.
>
> Tim Daly
> http://daly.axiom-developer.org
> Carnegie Mellon University
>
> [0] Sarker, Dipanwita and Waddell, Oscar and Dybvig, R. Kent
> "A Nonpass Infrastructure for Compiler Education" (2004)
> 9th ACM SIGPLAN, pp 201-212
>
> [1] http://daly.axiom-developer.org/tanglec.c
>
> [2] http://daly.axiom-developer.org/tangle.lisp
>
> [3] https://www.youtube.com/watch?v=dCuZkaaou0Q
>
> --
> You received this message because you are subscribed to the Google Groups
> "software-design-book" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to software-design-book+unsubscribe@googlegroups.com.
> To post to this group, send email to software-design-book@googlegroups.com
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/software-design-book/CAJn5L%3DKzPb4vHKfJFCfJjmNbtSjEJmnmFNUHB_JLx2iPKGxgUQ%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

\start
Date: Mon, 15 Jul 2019 23:52:09 -0400
From: Tim Daly <axiomcas@gmail.com>
To: axiom-dev <axiom-developer@nongnu.org>
Subject: [Axiom-developer] Fwd: [software-design-book] A Philosophy of
 Software Design

---------- Forwarded message ----------
From: Brooks Moses <brooks.moses@dpdx.net>
Date: Mon, 15 Jul 2019 16:33:29 -0700
Subject: Re: [software-design-book] A Philosophy of Software Design
To: John Ousterhout <ouster@cs.stanford.edu>
Cc: Tim Daly <axiomcas@gmail.com>, software-design-book
<software-design-book@googlegroups.com>

Tim,

In my opinion, one of the interesting things about both literate
programming and proving correctness is that explicitly doing them is less
useful today than it was when they were invented, because a lot of the
useful parts have been incorporated into programming languages and "normal"
toolchains.  So here's a counterpoint argument to your points:

I've been a fan of literate programming since I discovered it, to the point
where I wrote my own tool to process the Fortran 95 code from my thesis
work (Mech. Eng., not C.S.) as literate programs.  However, now that I've
been programming professionally for a decade, I don't really miss it.

>From what I remember, there were three significant pieces to the "literate
programming" toolchain as Knuth invented it.  The piece that I consider the
major innovation was that Knuth's literate-programming tool allowed one to
organize the code in an order that made sense to humans, rather than what
the programming language he was using (Pascal, IIRC) required.  Second, the
tool allowed one to produce cross-references somewhat automatically.
Third, the text around the program was written in LaTeX rather than plain
text, allowing formatting and mathematics.

The first of these is fundamentally obsolete as a separate tool.  Modern
programming languages and programming style do not require code to be
written in the same computer-centric linear fashion as the Pascal of
Knuth's day required.  We write code in tree structures (directories and
files), which are much easier to navigate than a single linear document.
The files are roughly the same size as the sections that Knuth wrote for
his literate programs, and within them there's a lot more freedom to
organize things in ways that are meaningful to the human readers.  So,
basically, this functionality is just an inherent part of the language and
compiler.

The second of these is also obsolete in its literate-programming form.
Knuth's cross-references were designed for what was fundamentally a
paper-centric style of reading code; they point to numbered sections in a
linear document, with the expectation that one will turn pages to get to
the relevant section.  Today, we have IDEs where we can click on a symbol
and it will automatically pull up a list of places this symbol is
referenced, and with a click it will open the relevant file at the location
of the relevant reference -- and this happens without any need for
annotations on the part of the programmer.

The third of these is the one piece that I think is sometimes still
useful.  The ability to write equations in the comments was pretty critical
for the computational-fluid-dynamics code in my dissertation.  On the other
hand, outside of deeply mathematical regimes, the ability to embed
equations is not a "killer feature".  And the fact that the text around the
program requires a "formatting" step is a problem -- it means that the tool
in which I read the program is not the tool in which I edit the program,
and so I have to have both forms open on my screen and mentally map between
them in order to get any value from the formatted text in understanding the
context around my edits.  The existence of two forms of the document also
makes it hard (at least for me) to have mental landmarks of "where things
are in the file", so I'm having to think about finding things at least
twice as often.  I always found that to be a serious enough drawback that I
pretty much only used the formatted form of the document for rare
only-reading cases.

Beyond the tooling, Knuth's literate programming was also of course a
radically different way of actually writing programs.  It involved writing
large high-level comments explaining the purpose and implementation of the
section of code first, before writing the low-level implementation -- that
is, addressing why the code does what it does in an essay-like way.  For
the "why" part, this is pretty much what the modern programming-style
guidelines I'm familiar with say that comments should be.  We have large
comment blocks at the top of files explaining the purpose of the code in
the file, and similar comment blocks at the top of classes and functions.
The header files for the heavily-used APIs I work with tend to be written
similarly, with functions grouped in human-significant ways with generally
more comment than code explaining the intended use.

For the "what" part, this again is something strongly influenced by the
programming languages Knuth was working with.  Pascal of the day was fairly
low-level, and it could be difficult to "see the forests for the trees".
The computer science community has basically considered this to be a bug in
the programming languages, and so there is far less need for this sort of
comment.  The machine code is now human-readable at a reasonably high
level, so disadvantages of having duplicate definitions of things (once in
the code, once in the comments) now much more commonly outweigh the
advantages of having "what this code does" comments.

So, IMO, a large part of the innovations of literate programming have been
incorporated into standard programming languages and tools, and much of the
rest is reasonably well-accepted as the "right way" to write comments, and
so "literate programming" as a distinct thing is no longer especially
relevant.

I'd make much the same argument for proving correctness, although it's a
much weaker argument.  In my experience, proving correctness has always had
the issue that we have to first define the correct behavior -- and that
definition can also be buggy.  There are some aspects of correct behavior
that are easy because they reasonably universal: Programs should not do
out-of-bounds accesses to arrays, they should not leak memory, they should
not have threading deadlocks, call sites and function definitions should
agree on what arguments are being passed, and so on.  However, many bugs in
practice are cases where something occurred that we didn't expect to happen
when we wrote the specification, and so a proof of correctness would fail
to find the bug.  So I find it hard to talk usefully about "proving
correctness" without some information about what sort of correctness we're
talking about.

For the reasonably-universal things, there have been a lot of advances on
this in programming-language design.  A strong type system is,
fundamentally, a compiler-provided proof of certain kinds of correctness.
Languages such as Rust take this much farther; if the compiler cannot prove
the correctness of the program in a number of ways, it is considered an
invalid program and you get a compile error.  (And, because of this, we
have a fair bit of data about the inherent costs of this -- enough to
support many debates and arguments about the tradeoffs!  But it's
absolutely clear that there are some tradeoffs.)  I think what's happening
is that the idea of a "specification that can be proven" is slowly being
subsumed into the programming language itself, rather than being something
separate -- see, for instance, type annotations in Python, and
static_assert in C++, although those are both fairly small steps.

I'm sure there still remain some cases where manual proofs of correctness
are worthwhile, and some cases where one wouldn't want to consider a
machine-checkable specification to be part of the program, but I think
they're both becoming fairly rare.

In general, I don't disagree with the idea that literate programming and
explicitly proving programming correctness are valuable.  But I think
what's fundamentally valuable there is the underlying ideas, and teaching
these using the same methods as one would have used thirty-odd years ago is
much like going from the idea that structured programming is valuable to
teaching RATFOR.

- Brooks




On Mon, Jul 15, 2019 at 10:52 AM John Ousterhout <ouster@cs.stanford.edu>
wrote:

> Hi Tim,
>
> Thanks for the comments. Here are a few overall followups.
>
> * You expressed a concern that deep classes might be harder to maintain
> and modify. If this were the case, then deep classes would be a bad idea.
> However, my experience is that deep classes make it *easier* to maintain
> and modify software. Deep classes don't have to be more complicated than
> shallow ones, and well-designed deep code is mostly non-task-specific (see
> Chapter 6 of APOSD).
>
> * You argued for proving correctness. I'm not opposed to this, but as of
> today I believe it is too difficult and time-intensive to be practical in
> most environments. In other words, if you're looking for the lowest-cost
> way to achieve a given level of functionality, reliability, etc., you can
> probably get there more cheaply using the more intuitive design approaches
> I advocate than using formal verification. It feels like verification is
> making gradual progress, so perhaps this situation will change in the
> future. Also, for systems that require extremely high levels of
> reliability, it may be that formal verification is the only way to get
> there today.
>
> * You suggested analyzing existing open source projects rather than
> writing new code. There is certainly value in analyzing existing code, but
> in terms of students learning how to design, it's crucial that they write
> code themselves and get feedback on it. I would draw an analogy with
> writing. Reading great books can be helpful in learning to write, but it is
> nowhere near sufficient: you have to write stuff yourself, make mistakes,
> get feedback, and fix the mistakes.
>
> -John-
>
> On Mon, Jul 15, 2019 at 5:29 AM Tim Daly <axiomcas@gmail.com> wrote:
>
>> I'm watching your Google talk on youtube.
>>
>> I've been programming for 50 years. I've done free software development
>> since 1996. I've written a LOT of code in over 60 languages. I have
>> co-authored
>> 4 commercial products. So I feel like I need to comment.
>>
>> BORN or LEARN?
>>
>> First, you ask if programming is something you are born with or something
>> you can learn. I think I could teach anyone who can follow a cooking
>> recipe
>> to program. Learning to program is easy.
>>
>> But programming is hard. It requires an inborn talent which is the
>> ability to
>> cope with very high levels of frustration and ambiguity. I have spent a
>> whole
>> week chasing a bug only to find that it is a compiler bug (4 times so
>> far).
>> If you can't handle the ground-pounding frustration of failing software
>> which
>> leads you to scream "WHY DOESN"T THIS WORK" and still continue then
>> you will never be a programmer.
>>
>> I whole-heartedly agree with the value of code reviews for learning.
>>
>> DEEP CLASSES
>>
>> I tend to both agree and disagree with your deep class idea. I agree
>> that it is a useful idea for design. But I think it is a bad idea for
>> coding.
>> Deep classes have a lot of complexity and are extremely specific to
>> the problem to be solved. Unfortunately, most of the lifetime of code
>> is post-development. Maintaining deep-class code is nearly impossible
>> because it is so task specific.
>>
>> I prefer deeply layered code. See, for example, Sarker [0] where the
>> development is incremental and deeply layered. But the intellectual
>> steps are small and easily adapted. I find this form of development
>> easier to do, easier to teach, and easier to maintain. The most
>> productive programmers I know write small but working pieces of
>> code that makes incremental steps of improvement. Note that this
>> is NOT a tactical approach with ad hoc decisions, but small steps
>> toward the ultimate goals.
>>
>> I took a course (at UCONN) where the prof gave us the spec of a
>> multitasking operating system. He gave us 10 weeks (in teams) to
>> develop it. It had to run on bare hardware (these days, an Arduino).
>> We had to process 100 "batch programs" to be run in minumum
>> time, assuming they block for I/O, etc. We developed a minimal
>> Read-Schedule-Process-Print loop and then enhanced it bit by bit.
>> You might consider that as an example project.
>>
>> So while I agree that a Deep Class DESIGN is seems like a good
>> short term idea, I think it costs much more in the long term due to
>> the high maintain / modify costs.
>>
>> Designers need to consider the full software lifecycle, not just the
>> initial implementation. You would not like an automobile that was
>> glued together and could not be fixed.
>>
>> LOGIC and PROOF
>>
>> In my later years I have watched the growth of proving
>> programs correct. I think designers need to write specifications
>> that can be proven. There is a HUGE growth in this field. See
>> Guy Steele [3] invited talk.
>>
>> Designers need to be deeply educated in program proof and
>> typing. At UCONN I took a course that just gave us a pile of
>> research papers. We each were assigned 3 papers from the
>> pile. Each paper had to be presented to the class in a 20
>> minute talk. You were graded on your 3 presentations. We
>> not only learned the theory, we learned to read (and write)
>> research literature.
>>
>> FOSS CONTRIBUTION
>>
>> There is an alternative to wasting class time developing new
>> code to review.
>>
>> You could structure a class for designers that took an
>> open source codebase from github for analysis. The whole
>> codebase would be reviewed throughout the semester and
>> each person who led the section could post fixes from the
>> code reviews to the open source site. Not only would they
>> see real design issues, they would learn to participate in
>> open source (and, incidently, how to maintain with source
>> code control).
>>
>> LITERATE PROGRAMMING
>>
>> On another track, I think you should teach literate programming.
>> All it takes is a simple latex macro and a trivial C[1] or Lisp[2]
>> program to extract code from a latex document. Future designers
>> out to follow the wisdom of Knuth and learn to write for humans
>> and, incidently, for computers.
>>
>> Tim Daly
>> http://daly.axiom-developer.org
>> Carnegie Mellon University
>>
>> [0] Sarker, Dipanwita and Waddell, Oscar and Dybvig, R. Kent
>> "A Nonpass Infrastructure for Compiler Education" (2004)
>> 9th ACM SIGPLAN, pp 201-212
>>
>> [1] http://daly.axiom-developer.org/tanglec.c
>>
>> [2] http://daly.axiom-developer.org/tangle.lisp
>>
>> [3] https://www.youtube.com/watch?v=dCuZkaaou0Q
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "software-design-book" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to software-design-book+unsubscribe@googlegroups.com.
>> To post to this group, send email to
>> software-design-book@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/software-design-book/CAJn5L%3DKzPb4vHKfJFCfJjmNbtSjEJmnmFNUHB_JLx2iPKGxgUQ%40mail.gmail.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "software-design-book" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to software-design-book+unsubscribe@googlegroups.com.
> To post to this group, send email to software-design-book@googlegroups.com
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/software-design-book/CAGXJAmzxj8wsVk9Ei9HQopWiLZCA7HXEL%2Bijxb7JnXfV4AMmqA%40mail.gmail.com
> <https://groups.google.com/d/msgid/software-design-book/CAGXJAmzxj8wsVk9Ei9HQopWiLZCA7HXEL%2Bijxb7JnXfV4AMmqA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

\start
Date: Mon, 15 Jul 2019 23:52:30 -0400
From: Tim Daly <axiomcas@gmail.com>
To: axiom-dev <axiom-developer@nongnu.org>
Subject: [Axiom-developer] Fwd: [software-design-book] A Philosophy of
 Software Design

---------- Forwarded message ----------
From: Tim Daly <axiomcas@gmail.com>
Date: Mon, 15 Jul 2019 22:57:30 -0400
Subject: Re: [software-design-book] A Philosophy of Software Design
To: Brooks Moses <brooks.moses@dpdx.net>
Cc: John Ousterhout <ouster@cs.stanford.edu>, software-design-book
<software-design-book@googlegroups.com>

RE: LITERATE PROGRAMMING

CODE ORGANIZATION AND IDEs

"The first of these is fundamentally obsolete as a separate tool"...

I wrote code before directories were invented. Code had to be
broken in less than 4k bytes as the operating system and editor
lived in the other 4k. So code had to be written in what I call
Piles-of-Sand (POS). Directories came along and people built
tools (make) to handle POS code. Clever naming of directories
carry all the "semantics" (e.g. src, doc, lib, test, build, etc)

You now have 16 gig of memory but you program in POS.
You have "layered" an IDE on the POS but still write in sand.

Can you navigate a code base if your IDE doesn't work?
Axiom is 1.2 million lines of code, considered "small" these days.

IDEs, like all code, tend to die. I used to work in Visual Basic
with an IDE from Microsoft. The IDE is dead (as is the VB code).

I used an old IDE from Microsoft that used to generate all of the
"glue code" to the visual front end (don't remember its name).
All I had to do was fill in various code blocks. The IDE died,
as has the code I wrote in it.


THE LONG TERM

Why is this a problem? Well, the REAL problem doesn't show
up until the code is older. Ten years from now your IDE won't
run on anything. So your "sematic directory names" (the
"chapters / sections" organization), and your navigation is
gone (your "index"). The flow of your comments is scattered
(the "paragraph organization"). Your "automatic comment
extractor / formatter" is gone.

Your spiffy new IDE has NO idea how to format
"Forth / Smalltalk / Pascal / Swift / Visual Basic /
SNOBOL / WATFIV / PL/I / MASM / or ... Rust.

So you're busy writing "dead" code.

Almost everything I've written over the last 50 years in
over 60 languages no longer runs. But all of my Common
Lisp code still runs. As does my Lisp/VM code and
MACLISP code due to macros.

To understand the long term view of your code find a calculus,
physics, or chemistry text. Cut it up so all you keep are the
equations on little index cards. Throw the rest away. THAT
is your code in 10 years. Can you learn calculus from a box
of randomly arranged index cards containing equations?

Sure, the equations are "right" and "type correct" but the
shiny-new programming language you're using (Rust?) has
no standard. Even if it did (e.g. C++) you'll find that there
are a dozen "standards" (C99, C11, C14, C17, etc), some
of which are no longer supported (e.g. C99, C11) because
the libraries have died.

The 10-year result is that your code is dead the day YOU
stop typing. Look at github / sourceforge / savannah. There
are thousand of programs that died the day the lead
developer stopped.

CONCLUSION

LIterate programming is trivial to use. I have use my editor
(emacs) to write latex with embedded code.

I type 'make' every 10 lines of changes (code or text) to:
(1) extracts the code
(2) compile it
(3) test it
(4) recreated the book with chapters/sections/paragraphs/
     index/tables/graphics all hyperlinked.
(5) displays it as a PDF (usually just updates the already
     displayed PDF with new changes)

The day *I* stop coding you have a book that explains the
whole state of my code (the calculus equations) as well as
the whole state of my organization (the chapters/etc) and
the whole state of my thinking.

I work in tools (Latex, Emacs, Common Lisp) that have
survived for decades with the same functionality. They will
likely survive in the future unchanged. My "literate
programming" tool chain is trivial (a 172 line C program) to
extract code and 'make' to build it.

Literate programs are only useful if you want your code
to live.

I HIGHLY recommend:

Lisp in Small Pieces, a complete lisp compiler / interpreter /
debugger in literate form.

https://www.amazon.com/Lisp-Small-Pieces-Christian-Queinnec-ebook/dp/B00AKE1U6O/ref=sr_1_1?keywords=lisp+in+small+pieces&qid=1563245147&s=gateway&sr=8-1

Physically Based Rendering, a graphics rendering engine
in literate form

https://www.amazon.com/Physically-Based-Rendering-Theory-Implementation/dp/0128006455/ref=sr_1_2?crid=1RKWRJMHFO2NX&keywords=physically+based+rendering&qid=1563245225&s=gateway&sprefix=Physically+Based%2Caps%2C187&sr=8-2

Tim

On 7/15/19, Brooks Moses <brooks.moses@dpdx.net> wrote:
> Tim,
>
> In my opinion, one of the interesting things about both literate
> programming and proving correctness is that explicitly doing them is less
> useful today than it was when they were invented, because a lot of the
> useful parts have been incorporated into programming languages and "normal"
> toolchains.  So here's a counterpoint argument to your points:
>
> I've been a fan of literate programming since I discovered it, to the point
> where I wrote my own tool to process the Fortran 95 code from my thesis
> work (Mech. Eng., not C.S.) as literate programs.  However, now that I've
> been programming professionally for a decade, I don't really miss it.
>
> From what I remember, there were three significant pieces to the "literate
> programming" toolchain as Knuth invented it.  The piece that I consider the
> major innovation was that Knuth's literate-programming tool allowed one to
> organize the code in an order that made sense to humans, rather than what
> the programming language he was using (Pascal, IIRC) required.  Second, the
> tool allowed one to produce cross-references somewhat automatically.
> Third, the text around the program was written in LaTeX rather than plain
> text, allowing formatting and mathematics.
>
> The first of these is fundamentally obsolete as a separate tool.  Modern
> programming languages and programming style do not require code to be
> written in the same computer-centric linear fashion as the Pascal of
> Knuth's day required.  We write code in tree structures (directories and
> files), which are much easier to navigate than a single linear document.
> The files are roughly the same size as the sections that Knuth wrote for
> his literate programs, and within them there's a lot more freedom to
> organize things in ways that are meaningful to the human readers.  So,
> basically, this functionality is just an inherent part of the language and
> compiler.
>
> The second of these is also obsolete in its literate-programming form.
> Knuth's cross-references were designed for what was fundamentally a
> paper-centric style of reading code; they point to numbered sections in a
> linear document, with the expectation that one will turn pages to get to
> the relevant section.  Today, we have IDEs where we can click on a symbol
> and it will automatically pull up a list of places this symbol is
> referenced, and with a click it will open the relevant file at the location
> of the relevant reference -- and this happens without any need for
> annotations on the part of the programmer.
>
> The third of these is the one piece that I think is sometimes still
> useful.  The ability to write equations in the comments was pretty critical
> for the computational-fluid-dynamics code in my dissertation.  On the other
> hand, outside of deeply mathematical regimes, the ability to embed
> equations is not a "killer feature".  And the fact that the text around the
> program requires a "formatting" step is a problem -- it means that the tool
> in which I read the program is not the tool in which I edit the program,
> and so I have to have both forms open on my screen and mentally map between
> them in order to get any value from the formatted text in understanding the
> context around my edits.  The existence of two forms of the document also
> makes it hard (at least for me) to have mental landmarks of "where things
> are in the file", so I'm having to think about finding things at least
> twice as often.  I always found that to be a serious enough drawback that I
> pretty much only used the formatted form of the document for rare
> only-reading cases.
>
> Beyond the tooling, Knuth's literate programming was also of course a
> radically different way of actually writing programs.  It involved writing
> large high-level comments explaining the purpose and implementation of the
> section of code first, before writing the low-level implementation -- that
> is, addressing why the code does what it does in an essay-like way.  For
> the "why" part, this is pretty much what the modern programming-style
> guidelines I'm familiar with say that comments should be.  We have large
> comment blocks at the top of files explaining the purpose of the code in
> the file, and similar comment blocks at the top of classes and functions.
> The header files for the heavily-used APIs I work with tend to be written
> similarly, with functions grouped in human-significant ways with generally
> more comment than code explaining the intended use.
>
> For the "what" part, this again is something strongly influenced by the
> programming languages Knuth was working with.  Pascal of the day was fairly
> low-level, and it could be difficult to "see the forests for the trees".
> The computer science community has basically considered this to be a bug in
> the programming languages, and so there is far less need for this sort of
> comment.  The machine code is now human-readable at a reasonably high
> level, so disadvantages of having duplicate definitions of things (once in
> the code, once in the comments) now much more commonly outweigh the
> advantages of having "what this code does" comments.
>
> So, IMO, a large part of the innovations of literate programming have been
> incorporated into standard programming languages and tools, and much of the
> rest is reasonably well-accepted as the "right way" to write comments, and
> so "literate programming" as a distinct thing is no longer especially
> relevant.
>
> I'd make much the same argument for proving correctness, although it's a
> much weaker argument.  In my experience, proving correctness has always had
> the issue that we have to first define the correct behavior -- and that
> definition can also be buggy.  There are some aspects of correct behavior
> that are easy because they reasonably universal: Programs should not do
> out-of-bounds accesses to arrays, they should not leak memory, they should
> not have threading deadlocks, call sites and function definitions should
> agree on what arguments are being passed, and so on.  However, many bugs in
> practice are cases where something occurred that we didn't expect to happen
> when we wrote the specification, and so a proof of correctness would fail
> to find the bug.  So I find it hard to talk usefully about "proving
> correctness" without some information about what sort of correctness we're
> talking about.
>
> For the reasonably-universal things, there have been a lot of advances on
> this in programming-language design.  A strong type system is,
> fundamentally, a compiler-provided proof of certain kinds of correctness.
> Languages such as Rust take this much farther; if the compiler cannot prove
> the correctness of the program in a number of ways, it is considered an
> invalid program and you get a compile error.  (And, because of this, we
> have a fair bit of data about the inherent costs of this -- enough to
> support many debates and arguments about the tradeoffs!  But it's
> absolutely clear that there are some tradeoffs.)  I think what's happening
> is that the idea of a "specification that can be proven" is slowly being
> subsumed into the programming language itself, rather than being something
> separate -- see, for instance, type annotations in Python, and
> static_assert in C++, although those are both fairly small steps.
>
> I'm sure there still remain some cases where manual proofs of correctness
> are worthwhile, and some cases where one wouldn't want to consider a
> machine-checkable specification to be part of the program, but I think
> they're both becoming fairly rare.
>
> In general, I don't disagree with the idea that literate programming and
> explicitly proving programming correctness are valuable.  But I think
> what's fundamentally valuable there is the underlying ideas, and teaching
> these using the same methods as one would have used thirty-odd years ago is
> much like going from the idea that structured programming is valuable to
> teaching RATFOR.
>
> - Brooks
>
>
>
>
> On Mon, Jul 15, 2019 at 10:52 AM John Ousterhout <ouster@cs.stanford.edu>
> wrote:
>
>> Hi Tim,
>>
>> Thanks for the comments. Here are a few overall followups.
>>
>> * You expressed a concern that deep classes might be harder to maintain
>> and modify. If this were the case, then deep classes would be a bad idea.
>> However, my experience is that deep classes make it *easier* to maintain
>> and modify software. Deep classes don't have to be more complicated than
>> shallow ones, and well-designed deep code is mostly non-task-specific
>> (see
>> Chapter 6 of APOSD).
>>
>> * You argued for proving correctness. I'm not opposed to this, but as of
>> today I believe it is too difficult and time-intensive to be practical in
>> most environments. In other words, if you're looking for the lowest-cost
>> way to achieve a given level of functionality, reliability, etc., you can
>> probably get there more cheaply using the more intuitive design
>> approaches
>> I advocate than using formal verification. It feels like verification is
>> making gradual progress, so perhaps this situation will change in the
>> future. Also, for systems that require extremely high levels of
>> reliability, it may be that formal verification is the only way to get
>> there today.
>>
>> * You suggested analyzing existing open source projects rather than
>> writing new code. There is certainly value in analyzing existing code,
>> but
>> in terms of students learning how to design, it's crucial that they write
>> code themselves and get feedback on it. I would draw an analogy with
>> writing. Reading great books can be helpful in learning to write, but it
>> is
>> nowhere near sufficient: you have to write stuff yourself, make mistakes,
>> get feedback, and fix the mistakes.
>>
>> -John-
>>
>> On Mon, Jul 15, 2019 at 5:29 AM Tim Daly <axiomcas@gmail.com> wrote:
>>
>>> I'm watching your Google talk on youtube.
>>>
>>> I've been programming for 50 years. I've done free software development
>>> since 1996. I've written a LOT of code in over 60 languages. I have
>>> co-authored
>>> 4 commercial products. So I feel like I need to comment.
>>>
>>> BORN or LEARN?
>>>
>>> First, you ask if programming is something you are born with or
>>> something
>>> you can learn. I think I could teach anyone who can follow a cooking
>>> recipe
>>> to program. Learning to program is easy.
>>>
>>> But programming is hard. It requires an inborn talent which is the
>>> ability to
>>> cope with very high levels of frustration and ambiguity. I have spent a
>>> whole
>>> week chasing a bug only to find that it is a compiler bug (4 times so
>>> far).
>>> If you can't handle the ground-pounding frustration of failing software
>>> which
>>> leads you to scream "WHY DOESN"T THIS WORK" and still continue then
>>> you will never be a programmer.
>>>
>>> I whole-heartedly agree with the value of code reviews for learning.
>>>
>>> DEEP CLASSES
>>>
>>> I tend to both agree and disagree with your deep class idea. I agree
>>> that it is a useful idea for design. But I think it is a bad idea for
>>> coding.
>>> Deep classes have a lot of complexity and are extremely specific to
>>> the problem to be solved. Unfortunately, most of the lifetime of code
>>> is post-development. Maintaining deep-class code is nearly impossible
>>> because it is so task specific.
>>>
>>> I prefer deeply layered code. See, for example, Sarker [0] where the
>>> development is incremental and deeply layered. But the intellectual
>>> steps are small and easily adapted. I find this form of development
>>> easier to do, easier to teach, and easier to maintain. The most
>>> productive programmers I know write small but working pieces of
>>> code that makes incremental steps of improvement. Note that this
>>> is NOT a tactical approach with ad hoc decisions, but small steps
>>> toward the ultimate goals.
>>>
>>> I took a course (at UCONN) where the prof gave us the spec of a
>>> multitasking operating system. He gave us 10 weeks (in teams) to
>>> develop it. It had to run on bare hardware (these days, an Arduino).
>>> We had to process 100 "batch programs" to be run in minumum
>>> time, assuming they block for I/O, etc. We developed a minimal
>>> Read-Schedule-Process-Print loop and then enhanced it bit by bit.
>>> You might consider that as an example project.
>>>
>>> So while I agree that a Deep Class DESIGN is seems like a good
>>> short term idea, I think it costs much more in the long term due to
>>> the high maintain / modify costs.
>>>
>>> Designers need to consider the full software lifecycle, not just the
>>> initial implementation. You would not like an automobile that was
>>> glued together and could not be fixed.
>>>
>>> LOGIC and PROOF
>>>
>>> In my later years I have watched the growth of proving
>>> programs correct. I think designers need to write specifications
>>> that can be proven. There is a HUGE growth in this field. See
>>> Guy Steele [3] invited talk.
>>>
>>> Designers need to be deeply educated in program proof and
>>> typing. At UCONN I took a course that just gave us a pile of
>>> research papers. We each were assigned 3 papers from the
>>> pile. Each paper had to be presented to the class in a 20
>>> minute talk. You were graded on your 3 presentations. We
>>> not only learned the theory, we learned to read (and write)
>>> research literature.
>>>
>>> FOSS CONTRIBUTION
>>>
>>> There is an alternative to wasting class time developing new
>>> code to review.
>>>
>>> You could structure a class for designers that took an
>>> open source codebase from github for analysis. The whole
>>> codebase would be reviewed throughout the semester and
>>> each person who led the section could post fixes from the
>>> code reviews to the open source site. Not only would they
>>> see real design issues, they would learn to participate in
>>> open source (and, incidently, how to maintain with source
>>> code control).
>>>
>>> LITERATE PROGRAMMING
>>>
>>> On another track, I think you should teach literate programming.
>>> All it takes is a simple latex macro and a trivial C[1] or Lisp[2]
>>> program to extract code from a latex document. Future designers
>>> out to follow the wisdom of Knuth and learn to write for humans
>>> and, incidently, for computers.
>>>
>>> Tim Daly
>>> http://daly.axiom-developer.org
>>> Carnegie Mellon University
>>>
>>> [0] Sarker, Dipanwita and Waddell, Oscar and Dybvig, R. Kent
>>> "A Nonpass Infrastructure for Compiler Education" (2004)
>>> 9th ACM SIGPLAN, pp 201-212
>>>
>>> [1] http://daly.axiom-developer.org/tanglec.c
>>>
>>> [2] http://daly.axiom-developer.org/tangle.lisp
>>>
>>> [3] https://www.youtube.com/watch?v=dCuZkaaou0Q
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups
>>> "software-design-book" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an
>>> email to software-design-book+unsubscribe@googlegroups.com.
>>> To post to this group, send email to
>>> software-design-book@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/software-design-book/CAJn5L%3DKzPb4vHKfJFCfJjmNbtSjEJmnmFNUHB_JLx2iPKGxgUQ%40mail.gmail.com
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "software-design-book" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to software-design-book+unsubscribe@googlegroups.com.
>> To post to this group, send email to
>> software-design-book@googlegroups.com
>> .
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/software-design-book/CAGXJAmzxj8wsVk9Ei9HQopWiLZCA7HXEL%2Bijxb7JnXfV4AMmqA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/software-design-book/CAGXJAmzxj8wsVk9Ei9HQopWiLZCA7HXEL%2Bijxb7JnXfV4AMmqA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.

\start
Date: Mon, 15 Jul 2019 23:52:52 -0400
From: Tim Daly <axiomcas@gmail.com>
To: axiom-dev <axiom-developer@nongnu.org>
Subject: [Axiom-developer] Fwd: [software-design-book] A Philosophy of
 Software Design

---------- Forwarded message ----------
From: Tim Daly <axiomcas@gmail.com>
Date: Mon, 15 Jul 2019 23:41:33 -0400
Subject: Re: [software-design-book] A Philosophy of Software Design
To: Brooks Moses <brooks.moses@dpdx.net>
Cc: John Ousterhout <ouster@cs.stanford.edu>, software-design-book
<software-design-book@googlegroups.com>

RE: PROVING PROGRAMS CORRECT

First, I should point out that the "next generation" of students
are being taught to prove programs. I spent 3 years taking
classes at CMU and its all proof-related teaching. I'm now
taking an MIT course and each lecture is nothing but a proof
or two. See [0] and [1] which are from CMU courses this year.

>I'd make much the same argument for proving correctness,
>although it's a much weaker argument.  In my experience,
>proving correctness has always had the issue that we have
>to first define the correct behavior -- and that definition can
>also be buggy.

"Software Designers" SHOULD specify programs in some
sort of machine-checkable way. Tell me what you want and
I will prove my program does that. Show me the machine
checked spec and I will construct a proven program.

I'm not talking about "programmer tools", like bounds checks
and compile-time type checks. Those are programmer-level
tool quality issues. They are useful but irrelevant. Anything
Rust does is irrelevant.



>I'm sure there still remain some cases where manual proofs
>of correctness are worthwhile, and some cases where one
>wouldn't want to consider a machine-checkable specification
>to be part of the program, but I think they're both becoming
>fairly rare.

I think you didn't watch Guy Steele's talk. The number of papers
using logic notation (and logical development) is increasing at
a furious rate. CMU and MIT are teaching this stuff TODAY to
the next generation. Rather than "becoming fairly rare", it is "the
coming wave".

The software DESIGNER needs to tell me what the spec is
that my program needs to fulfill. If you don't know what you want,
you're sure to get something but...

>teaching these using the same methods as one would
>have used thirty-odd years ago is much like going from the idea
>that structured programming is valuable to teaching RATFOR.

They aren't teaching these like structured programming. They
are teaching these with formal methods. The classes are
teaching the "Calculus of Inductive Construction" (CIC) which
your compiler can't check. These are not "special classes" but
are spread across every class they teach.

[0] Look at "Programming in Martin-Lof's Type Theory"
http://www.cse.chalmers.se/research/group/logic/book/book.pdf

or, to see a "non-programming course", such as self-driving
car software, see:

[1] "Logical Foundations of Cyber-Physical Systems"
https://www.springer.com/gp/book/9783319635873

This was published late in 2018 and is the "state of the art" in
things like robots. If you can't read the proof on page 236
"Sequent Calculus proof shape for a bouncing ball" then you
are not "keeping your saw sharp" and the kids won't hire you.

Is your login software secure? Prove it.
Is your websocket recoverable? Prove it.
Is your JSON reader correct? Prove it.
Is your phone banking app robust? Prove it.
Is your home camera private? Prove it.

If someone calls themselves a software DESIGNER then
I want a DESIGN that specifies what my program must do.
And I want a DESIGN that I can prove my program fulfills.

The days of "mm, yeah, we sorta need a banking thing
in the browser" are dying.

Tim


On 7/15/19, Tim Daly <axiomcas@gmail.com> wrote:
> RE: LITERATE PROGRAMMING
>
> CODE ORGANIZATION AND IDEs
>
> "The first of these is fundamentally obsolete as a separate tool"...
>
> I wrote code before directories were invented. Code had to be
> broken in less than 4k bytes as the operating system and editor
> lived in the other 4k. So code had to be written in what I call
> Piles-of-Sand (POS). Directories came along and people built
> tools (make) to handle POS code. Clever naming of directories
> carry all the "semantics" (e.g. src, doc, lib, test, build, etc)
>
> You now have 16 gig of memory but you program in POS.
> You have "layered" an IDE on the POS but still write in sand.
>
> Can you navigate a code base if your IDE doesn't work?
> Axiom is 1.2 million lines of code, considered "small" these days.
>
> IDEs, like all code, tend to die. I used to work in Visual Basic
> with an IDE from Microsoft. The IDE is dead (as is the VB code).
>
> I used an old IDE from Microsoft that used to generate all of the
> "glue code" to the visual front end (don't remember its name).
> All I had to do was fill in various code blocks. The IDE died,
> as has the code I wrote in it.
>
>
> THE LONG TERM
>
> Why is this a problem? Well, the REAL problem doesn't show
> up until the code is older. Ten years from now your IDE won't
> run on anything. So your "sematic directory names" (the
> "chapters / sections" organization), and your navigation is
> gone (your "index"). The flow of your comments is scattered
> (the "paragraph organization"). Your "automatic comment
> extractor / formatter" is gone.
>
> Your spiffy new IDE has NO idea how to format
> "Forth / Smalltalk / Pascal / Swift / Visual Basic /
> SNOBOL / WATFIV / PL/I / MASM / or ... Rust.
>
> So you're busy writing "dead" code.
>
> Almost everything I've written over the last 50 years in
> over 60 languages no longer runs. But all of my Common
> Lisp code still runs. As does my Lisp/VM code and
> MACLISP code due to macros.
>
> To understand the long term view of your code find a calculus,
> physics, or chemistry text. Cut it up so all you keep are the
> equations on little index cards. Throw the rest away. THAT
> is your code in 10 years. Can you learn calculus from a box
> of randomly arranged index cards containing equations?
>
> Sure, the equations are "right" and "type correct" but the
> shiny-new programming language you're using (Rust?) has
> no standard. Even if it did (e.g. C++) you'll find that there
> are a dozen "standards" (C99, C11, C14, C17, etc), some
> of which are no longer supported (e.g. C99, C11) because
> the libraries have died.
>
> The 10-year result is that your code is dead the day YOU
> stop typing. Look at github / sourceforge / savannah. There
> are thousand of programs that died the day the lead
> developer stopped.
>
> CONCLUSION
>
> LIterate programming is trivial to use. I have use my editor
> (emacs) to write latex with embedded code.
>
> I type 'make' every 10 lines of changes (code or text) to:
> (1) extracts the code
> (2) compile it
> (3) test it
> (4) recreated the book with chapters/sections/paragraphs/
>      index/tables/graphics all hyperlinked.
> (5) displays it as a PDF (usually just updates the already
>      displayed PDF with new changes)
>
> The day *I* stop coding you have a book that explains the
> whole state of my code (the calculus equations) as well as
> the whole state of my organization (the chapters/etc) and
> the whole state of my thinking.
>
> I work in tools (Latex, Emacs, Common Lisp) that have
> survived for decades with the same functionality. They will
> likely survive in the future unchanged. My "literate
> programming" tool chain is trivial (a 172 line C program) to
> extract code and 'make' to build it.
>
> Literate programs are only useful if you want your code
> to live.
>
> I HIGHLY recommend:
>
> Lisp in Small Pieces, a complete lisp compiler / interpreter /
> debugger in literate form.
>
> https://www.amazon.com/Lisp-Small-Pieces-Christian-Queinnec-ebook/dp/B00AKE1U6O/ref=sr_1_1?keywords=lisp+in+small+pieces&qid=1563245147&s=gateway&sr=8-1
>
> Physically Based Rendering, a graphics rendering engine
> in literate form
>
> https://www.amazon.com/Physically-Based-Rendering-Theory-Implementation/dp/0128006455/ref=sr_1_2?crid=1RKWRJMHFO2NX&keywords=physically+based+rendering&qid=1563245225&s=gateway&sprefix=Physically+Based%2Caps%2C187&sr=8-2
>
> Tim
>
> On 7/15/19, Brooks Moses <brooks.moses@dpdx.net> wrote:
>> Tim,
>>
>> In my opinion, one of the interesting things about both literate
>> programming and proving correctness is that explicitly doing them is less
>> useful today than it was when they were invented, because a lot of the
>> useful parts have been incorporated into programming languages and
>> "normal"
>> toolchains.  So here's a counterpoint argument to your points:
>>
>> I've been a fan of literate programming since I discovered it, to the
>> point
>> where I wrote my own tool to process the Fortran 95 code from my thesis
>> work (Mech. Eng., not C.S.) as literate programs.  However, now that I've
>> been programming professionally for a decade, I don't really miss it.
>>
>> From what I remember, there were three significant pieces to the
>> "literate
>> programming" toolchain as Knuth invented it.  The piece that I consider
>> the
>> major innovation was that Knuth's literate-programming tool allowed one
>> to
>> organize the code in an order that made sense to humans, rather than what
>> the programming language he was using (Pascal, IIRC) required.  Second,
>> the
>> tool allowed one to produce cross-references somewhat automatically.
>> Third, the text around the program was written in LaTeX rather than plain
>> text, allowing formatting and mathematics.
>>
>> The first of these is fundamentally obsolete as a separate tool.  Modern
>> programming languages and programming style do not require code to be
>> written in the same computer-centric linear fashion as the Pascal of
>> Knuth's day required.  We write code in tree structures (directories and
>> files), which are much easier to navigate than a single linear document.
>> The files are roughly the same size as the sections that Knuth wrote for
>> his literate programs, and within them there's a lot more freedom to
>> organize things in ways that are meaningful to the human readers.  So,
>> basically, this functionality is just an inherent part of the language
>> and
>> compiler.
>>
>> The second of these is also obsolete in its literate-programming form.
>> Knuth's cross-references were designed for what was fundamentally a
>> paper-centric style of reading code; they point to numbered sections in a
>> linear document, with the expectation that one will turn pages to get to
>> the relevant section.  Today, we have IDEs where we can click on a symbol
>> and it will automatically pull up a list of places this symbol is
>> referenced, and with a click it will open the relevant file at the
>> location
>> of the relevant reference -- and this happens without any need for
>> annotations on the part of the programmer.
>>
>> The third of these is the one piece that I think is sometimes still
>> useful.  The ability to write equations in the comments was pretty
>> critical
>> for the computational-fluid-dynamics code in my dissertation.  On the
>> other
>> hand, outside of deeply mathematical regimes, the ability to embed
>> equations is not a "killer feature".  And the fact that the text around
>> the
>> program requires a "formatting" step is a problem -- it means that the
>> tool
>> in which I read the program is not the tool in which I edit the program,
>> and so I have to have both forms open on my screen and mentally map
>> between
>> them in order to get any value from the formatted text in understanding
>> the
>> context around my edits.  The existence of two forms of the document also
>> makes it hard (at least for me) to have mental landmarks of "where things
>> are in the file", so I'm having to think about finding things at least
>> twice as often.  I always found that to be a serious enough drawback that
>> I
>> pretty much only used the formatted form of the document for rare
>> only-reading cases.
>>
>> Beyond the tooling, Knuth's literate programming was also of course a
>> radically different way of actually writing programs.  It involved
>> writing
>> large high-level comments explaining the purpose and implementation of
>> the
>> section of code first, before writing the low-level implementation --
>> that
>> is, addressing why the code does what it does in an essay-like way.  For
>> the "why" part, this is pretty much what the modern programming-style
>> guidelines I'm familiar with say that comments should be.  We have large
>> comment blocks at the top of files explaining the purpose of the code in
>> the file, and similar comment blocks at the top of classes and functions.
>> The header files for the heavily-used APIs I work with tend to be written
>> similarly, with functions grouped in human-significant ways with
>> generally
>> more comment than code explaining the intended use.
>>
>> For the "what" part, this again is something strongly influenced by the
>> programming languages Knuth was working with.  Pascal of the day was
>> fairly
>> low-level, and it could be difficult to "see the forests for the trees".
>> The computer science community has basically considered this to be a bug
>> in
>> the programming languages, and so there is far less need for this sort of
>> comment.  The machine code is now human-readable at a reasonably high
>> level, so disadvantages of having duplicate definitions of things (once
>> in
>> the code, once in the comments) now much more commonly outweigh the
>> advantages of having "what this code does" comments.
>>
>> So, IMO, a large part of the innovations of literate programming have
>> been
>> incorporated into standard programming languages and tools, and much of
>> the
>> rest is reasonably well-accepted as the "right way" to write comments,
>> and
>> so "literate programming" as a distinct thing is no longer especially
>> relevant.
>>
>> I'd make much the same argument for proving correctness, although it's a
>> much weaker argument.  In my experience, proving correctness has always
>> had
>> the issue that we have to first define the correct behavior -- and that
>> definition can also be buggy.  There are some aspects of correct behavior
>> that are easy because they reasonably universal: Programs should not do
>> out-of-bounds accesses to arrays, they should not leak memory, they
>> should
>> not have threading deadlocks, call sites and function definitions should
>> agree on what arguments are being passed, and so on.  However, many bugs
>> in
>> practice are cases where something occurred that we didn't expect to
>> happen
>> when we wrote the specification, and so a proof of correctness would fail
>> to find the bug.  So I find it hard to talk usefully about "proving
>> correctness" without some information about what sort of correctness
>> we're
>> talking about.
>>
>> For the reasonably-universal things, there have been a lot of advances on
>> this in programming-language design.  A strong type system is,
>> fundamentally, a compiler-provided proof of certain kinds of correctness.
>> Languages such as Rust take this much farther; if the compiler cannot
>> prove
>> the correctness of the program in a number of ways, it is considered an
>> invalid program and you get a compile error.  (And, because of this, we
>> have a fair bit of data about the inherent costs of this -- enough to
>> support many debates and arguments about the tradeoffs!  But it's
>> absolutely clear that there are some tradeoffs.)  I think what's
>> happening
>> is that the idea of a "specification that can be proven" is slowly being
>> subsumed into the programming language itself, rather than being
>> something
>> separate -- see, for instance, type annotations in Python, and
>> static_assert in C++, although those are both fairly small steps.
>>
>> I'm sure there still remain some cases where manual proofs of correctness
>> are worthwhile, and some cases where one wouldn't want to consider a
>> machine-checkable specification to be part of the program, but I think
>> they're both becoming fairly rare.
>>
>> In general, I don't disagree with the idea that literate programming and
>> explicitly proving programming correctness are valuable.  But I think
>> what's fundamentally valuable there is the underlying ideas, and teaching
>> these using the same methods as one would have used thirty-odd years ago
>> is
>> much like going from the idea that structured programming is valuable to
>> teaching RATFOR.
>>
>> - Brooks
>>
>>
>>
>>
>> On Mon, Jul 15, 2019 at 10:52 AM John Ousterhout <ouster@cs.stanford.edu>
>> wrote:
>>
>>> Hi Tim,
>>>
>>> Thanks for the comments. Here are a few overall followups.
>>>
>>> * You expressed a concern that deep classes might be harder to maintain
>>> and modify. If this were the case, then deep classes would be a bad
>>> idea.
>>> However, my experience is that deep classes make it *easier* to maintain
>>> and modify software. Deep classes don't have to be more complicated than
>>> shallow ones, and well-designed deep code is mostly non-task-specific
>>> (see
>>> Chapter 6 of APOSD).
>>>
>>> * You argued for proving correctness. I'm not opposed to this, but as of
>>> today I believe it is too difficult and time-intensive to be practical
>>> in
>>> most environments. In other words, if you're looking for the lowest-cost
>>> way to achieve a given level of functionality, reliability, etc., you
>>> can
>>> probably get there more cheaply using the more intuitive design
>>> approaches
>>> I advocate than using formal verification. It feels like verification is
>>> making gradual progress, so perhaps this situation will change in the
>>> future. Also, for systems that require extremely high levels of
>>> reliability, it may be that formal verification is the only way to get
>>> there today.
>>>
>>> * You suggested analyzing existing open source projects rather than
>>> writing new code. There is certainly value in analyzing existing code,
>>> but
>>> in terms of students learning how to design, it's crucial that they
>>> write
>>> code themselves and get feedback on it. I would draw an analogy with
>>> writing. Reading great books can be helpful in learning to write, but it
>>> is
>>> nowhere near sufficient: you have to write stuff yourself, make
>>> mistakes,
>>> get feedback, and fix the mistakes.
>>>
>>> -John-
>>>
>>> On Mon, Jul 15, 2019 at 5:29 AM Tim Daly <axiomcas@gmail.com> wrote:
>>>
>>>> I'm watching your Google talk on youtube.
>>>>
>>>> I've been programming for 50 years. I've done free software development
>>>> since 1996. I've written a LOT of code in over 60 languages. I have
>>>> co-authored
>>>> 4 commercial products. So I feel like I need to comment.
>>>>
>>>> BORN or LEARN?
>>>>
>>>> First, you ask if programming is something you are born with or
>>>> something
>>>> you can learn. I think I could teach anyone who can follow a cooking
>>>> recipe
>>>> to program. Learning to program is easy.
>>>>
>>>> But programming is hard. It requires an inborn talent which is the
>>>> ability to
>>>> cope with very high levels of frustration and ambiguity. I have spent a
>>>> whole
>>>> week chasing a bug only to find that it is a compiler bug (4 times so
>>>> far).
>>>> If you can't handle the ground-pounding frustration of failing software
>>>> which
>>>> leads you to scream "WHY DOESN"T THIS WORK" and still continue then
>>>> you will never be a programmer.
>>>>
>>>> I whole-heartedly agree with the value of code reviews for learning.
>>>>
>>>> DEEP CLASSES
>>>>
>>>> I tend to both agree and disagree with your deep class idea. I agree
>>>> that it is a useful idea for design. But I think it is a bad idea for
>>>> coding.
>>>> Deep classes have a lot of complexity and are extremely specific to
>>>> the problem to be solved. Unfortunately, most of the lifetime of code
>>>> is post-development. Maintaining deep-class code is nearly impossible
>>>> because it is so task specific.
>>>>
>>>> I prefer deeply layered code. See, for example, Sarker [0] where the
>>>> development is incremental and deeply layered. But the intellectual
>>>> steps are small and easily adapted. I find this form of development
>>>> easier to do, easier to teach, and easier to maintain. The most
>>>> productive programmers I know write small but working pieces of
>>>> code that makes incremental steps of improvement. Note that this
>>>> is NOT a tactical approach with ad hoc decisions, but small steps
>>>> toward the ultimate goals.
>>>>
>>>> I took a course (at UCONN) where the prof gave us the spec of a
>>>> multitasking operating system. He gave us 10 weeks (in teams) to
>>>> develop it. It had to run on bare hardware (these days, an Arduino).
>>>> We had to process 100 "batch programs" to be run in minumum
>>>> time, assuming they block for I/O, etc. We developed a minimal
>>>> Read-Schedule-Process-Print loop and then enhanced it bit by bit.
>>>> You might consider that as an example project.
>>>>
>>>> So while I agree that a Deep Class DESIGN is seems like a good
>>>> short term idea, I think it costs much more in the long term due to
>>>> the high maintain / modify costs.
>>>>
>>>> Designers need to consider the full software lifecycle, not just the
>>>> initial implementation. You would not like an automobile that was
>>>> glued together and could not be fixed.
>>>>
>>>> LOGIC and PROOF
>>>>
>>>> In my later years I have watched the growth of proving
>>>> programs correct. I think designers need to write specifications
>>>> that can be proven. There is a HUGE growth in this field. See
>>>> Guy Steele [3] invited talk.
>>>>
>>>> Designers need to be deeply educated in program proof and
>>>> typing. At UCONN I took a course that just gave us a pile of
>>>> research papers. We each were assigned 3 papers from the
>>>> pile. Each paper had to be presented to the class in a 20
>>>> minute talk. You were graded on your 3 presentations. We
>>>> not only learned the theory, we learned to read (and write)
>>>> research literature.
>>>>
>>>> FOSS CONTRIBUTION
>>>>
>>>> There is an alternative to wasting class time developing new
>>>> code to review.
>>>>
>>>> You could structure a class for designers that took an
>>>> open source codebase from github for analysis. The whole
>>>> codebase would be reviewed throughout the semester and
>>>> each person who led the section could post fixes from the
>>>> code reviews to the open source site. Not only would they
>>>> see real design issues, they would learn to participate in
>>>> open source (and, incidently, how to maintain with source
>>>> code control).
>>>>
>>>> LITERATE PROGRAMMING
>>>>
>>>> On another track, I think you should teach literate programming.
>>>> All it takes is a simple latex macro and a trivial C[1] or Lisp[2]
>>>> program to extract code from a latex document. Future designers
>>>> out to follow the wisdom of Knuth and learn to write for humans
>>>> and, incidently, for computers.
>>>>
>>>> Tim Daly
>>>> http://daly.axiom-developer.org
>>>> Carnegie Mellon University
>>>>
>>>> [0] Sarker, Dipanwita and Waddell, Oscar and Dybvig, R. Kent
>>>> "A Nonpass Infrastructure for Compiler Education" (2004)
>>>> 9th ACM SIGPLAN, pp 201-212
>>>>
>>>> [1] http://daly.axiom-developer.org/tanglec.c
>>>>
>>>> [2] http://daly.axiom-developer.org/tangle.lisp
>>>>
>>>> [3] https://www.youtube.com/watch?v=dCuZkaaou0Q
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups
>>>> "software-design-book" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an
>>>> email to software-design-book+unsubscribe@googlegroups.com.
>>>> To post to this group, send email to
>>>> software-design-book@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/software-design-book/CAJn5L%3DKzPb4vHKfJFCfJjmNbtSjEJmnmFNUHB_JLx2iPKGxgUQ%40mail.gmail.com
>>>> .
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups
>>> "software-design-book" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an
>>> email to software-design-book+unsubscribe@googlegroups.com.
>>> To post to this group, send email to
>>> software-design-book@googlegroups.com
>>> .
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/software-design-book/CAGXJAmzxj8wsVk9Ei9HQopWiLZCA7HXEL%2Bijxb7JnXfV4AMmqA%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/software-design-book/CAGXJAmzxj8wsVk9Ei9HQopWiLZCA7HXEL%2Bijxb7JnXfV4AMmqA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.

\start
Date: Sat, 20 Jul 2019 03:27:53 -0400
From: Tim Daly <axiomcas@gmail.com>
To: axiom-developer@nongnu.org, axiomcas@gmail.com
Subject: [Axiom-developer] Axiom's Sane redesign musings
Cc: "Scott E. Fahlman" <sef@cs.cmu.edu>

When injured, I often use the phrase "Well, learning occurred".

I just spent the last day chasing a circular reference problem
in the meta-object protocol (MOP) which is the basis of the
Common Lisp Object System (CLOS). It turns out that the
"circular reference" is a REALLY bad error message. It won't
bore you with the deails but it the usual "Wow, I found a bug
in the system" thing.

But I'm too experienced ("old") to believe that. After a day of
creating ever-smaller versions of the input I finally cornered it.

That's when I found a one-line paragraph in the MOP that
tells me when "finalize-inheritance" will be called. After much
Omphaloskepsis I translated that to "that's obvious, so it must
be my bug"... (spoiler alert) ... which it was.

Well, learning occurred.

So I'm going to concentrate REALLY hard on making Sane
give, not only an error message, but a likely thing to check.
The error message should also include references into the
literate documentation for a deeper explanation.

Tim

\start
Date: Sat, 20 Jul 2019 22:55:21 -0400
From: Tim Daly <axiomcas@gmail.com>
To: axiom-developer@nongnu.org, axiomcas@gmail.com
Subject: Re: [Axiom-developer] Axiom's Sane redesign musings

I've discovered something pleasant about CLOS development.

Normal compiler development is top=down, from the syntax to
the intermediate representation to the target machine. By its
nature the intermediate representation is usually a hairy data
structure.

However, CLOS is both a surface syntax and an intermediate
representation. I can write the categories in CLOS directly
compile them, and execute them. The surface syntax is just
a "cover" over the CLOS.

Working from the "middle out" like this makes it easy to
construct the categories in the REPL. And since CLOS is
dynamic I can experiement and fix issues "on the fly" and
port the solution back to the file.

Since printing (print-object) can completely control the way an
object is printed it turns out to be nearly trivial to construct the
spad source file from the CLOS representation.

No databases are necessary. Generating Spad vs Logic syntax
is a simple parameter. Comment syntax can be changed by a
single parameter (hyperdoc, latex, user-level, etc).

I taught compilers years before CLOS was created. I wish I knew
then what I know now. It is so much easier "middle-out" with the
right tools.

Tim


On 7/20/19, Tim Daly <axiomcas@gmail.com> wrote:
> When injured, I often use the phrase "Well, learning occurred".
>
> I just spent the last day chasing a circular reference problem
> in the meta-object protocol (MOP) which is the basis of the
> Common Lisp Object System (CLOS). It turns out that the
> "circular reference" is a REALLY bad error message. It won't
> bore you with the deails but it the usual "Wow, I found a bug
> in the system" thing.
>
> But I'm too experienced ("old") to believe that. After a day of
> creating ever-smaller versions of the input I finally cornered it.
>
> That's when I found a one-line paragraph in the MOP that
> tells me when "finalize-inheritance" will be called. After much
> Omphaloskepsis I translated that to "that's obvious, so it must
> be my bug"... (spoiler alert) ... which it was.
>
> Well, learning occurred.
>
> So I'm going to concentrate REALLY hard on making Sane
> give, not only an error message, but a likely thing to check.
> The error message should also include references into the
> literate documentation for a deeper explanation.
>
> Tim
>

\start
Date: Sun, 21 Jul 2019 08:29:03 -0400
From: Tim Daly <axiomcas@gmail.com>
To: Jeremy Avigad <avigad@cmu.edu>, Frank Pfenning <fp@cs.cmu.edu>,
 axiom-developer@nongnu.org, 
 axiomcas@gmail.com, Stephanie Balzer <balzers@cs.cmu.edu>
Subject: [Axiom-developer] AI is coming for my job!

Generating Correctness Proof with Neural Networks
https://arxiv.org/pdf/1907.07794.pdf

Apparently they managed to prove 15.77% of the proofs in
the CompCert verified compiler effort.

"Now, here, you see, it takes all the running you can do to
keep in the same place. If you want to get somewhere else,
you must run at least twice as fast as that."
   -- Alvin Toffler "Future Shock" :-)

Tim

\start
Date: Sun, 21 Jul 2019 10:35:56 -0400
From: Frank Pfenning <fp@cs.cmu.edu>
To: Tim Daly <axiomcas@gmail.com>
Subject: Re: [Axiom-developer] AI is coming for my job!
Cc: Jeremy Avigad <avigad@cmu.edu>, axiom-dev <axiom-developer@nongnu.org>, 
 Stephanie Balzer <balzers@cs.cmu.edu>

I would venture the proofs are not the real effort in CompCert.
The real effort is to formulate the various systems such that the
proofs become as simple as possible.  So 15.77% is minuscule
compared to the total intellectual effort of this project.  Your job
is not yet in danger (even in your retirement :-)

But, seriously, sometimes I am worried that too much automation
is a bad thing, because it can mask the flaws in what one is doing.
There are many examples in the study of logics, but let me use
programming instead.  Start with your favorite terrible programming language
(Python happens to be a convenient target, or C++).  Now, sure, you can
reduce the number of bugs with automatic program analysis, the smarter
the better.  But you would nevertheless still be better off in a statically
typed
functional language with a decent module system.  You prop up something
that would be better left to wither and die.

  - Frank

On Sun, Jul 21, 2019 at 8:29 AM Tim Daly <axiomcas@gmail.com> wrote:

> Generating Correctness Proof with Neural Networks
> https://arxiv.org/pdf/1907.07794.pdf
>
> Apparently they managed to prove 15.77% of the proofs in
> the CompCert verified compiler effort.
>
> "Now, here, you see, it takes all the running you can do to
> keep in the same place. If you want to get somewhere else,
> you must run at least twice as fast as that."
>    -- Alvin Toffler "Future Shock" :-)
>
> Tim
>


-- 
Frank Pfenning, Professor
Computer Science Department
Carnegie Mellon University
Pittsburgh, PA 15213-3891

http://www.cs.cmu.edu/~fp
+1 412 268-6343
GHC 6017

\start
Date: Sat, 27 Jul 2019 22:36:02 -0400
From: Tim Daly <axiomcas@gmail.com>
To: axiom-dev <axiom-developer@nongnu.org>
Subject: [Axiom-developer] Axiom runs on the new Raspberry Pi 4

I just received a new Raspberry Pi 4, installed Axiom, and it runs.

Tim


\end{verbatim}
\eject
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Bibliography}
\bibliographystyle{axiom}
\bibliography{axiom}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Index}
\printindex
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{document}
