\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: Sat, 6 May 2017 16:31:01 -0400
From: Tim Daly <axiomcas@gmail.com>
To: Jacques Carette <carette@mcmaster.ca>, Jeremy Avigad <avigad@cmu.edu>, 
	axiom-dev <axiom-developer@nongnu.org>,
	Laurent Thery <Laurent.Thery@inria.fr>
Cc: William Farmer <wmfarmer@mcmaster.ca>, Tim Daly <daly@axiom-developer.org>
Subject: Re: [Axiom-developer] MathScheme project

Jacques,

I'm reading your paper "The MathScheme Library: Some Preliminary
Experiments".  https://arxiv.org/pdf/1106.1862.pdf

The LeftNearSemiring description on page 4 is essentially
what I'm aiming to implement in Axiom.

We differ on the choice of 'axiom' vs 'proposition'. I see what you label
as 'axiom' as a continuation of the type signatures. You have

   * : (U, U) -> U

which in Type Theory is basically

   U : Type
   F : ( Type x Type ) -> Type

Similarly what you label as 'axiom' is really just another type signature
(per Curry-Howard) and I'd label it as a 'proposition'

So where '*' needs to be implemented in any Domain that inherits from
LeftNearSemiring the 'proposition'

associative_* := forall x,y,z:U  (x * y) * z = x * (y * z)

means any Domain which inherits from LeftNearSemiring would have to prove
those propositions using operations from the Domain being constructed.

Comments?

Tim


On Sat, May 6, 2017 at 11:32 AM, Jacques Carette <carette@mcmaster.ca>
wrote:

> Hello Tim.
>
> I believe we've met -- but 10+ years ago, at either an ISSAC or an ECCAD.
>
> In any case, Bill and I are quite familiar with Axiom.  We've had many
> conversations about it with James Davenport, Stephen Watt and Gabriel Dos
> Reis.
>
> Yes, MathScheme is a current project.  Its main web site is available at
> http://mathscheme.cas.mcmaster.ca.  [The list of papers is out of date,
> we're working on that; and we are also open-sourcing various bits of it as
> we clean the implementation].
>
> Personally, I would encourage you to build a proof-of-concept using Axiom
> and Agda (rather than Coq); or even Idris.  I believe the approach to
> proofs there is much closer to Axiom than what you will get with Coq.  Or,
> since you are at CMU, Lean ?
>
> What you will undoubtedly encounter is that Axiom's current "batteries
> included" approach to library building where, for example, the Category
> AbelianGroup [Book Volume 10.2, Category Layer 6, AbelianGroup.input on
> p.667 of the pdf at www.axiom-developer.org/axiom-website/bookvol10.2.pdf
> ] really builds abelian group as a Z-module.  While this is mathematically
> correct, it is not very modular.  At [1] we show how we have made this
> quite a bit more modular, using the combinators of [2].  To recover the
> "batteries included" version (which we believe in [3]), we have 'invented'
> Realms [4].  To us, Axioms' AbelianGroup Category is closer the
> AbelianGroup Realm than the fundamental 'theory' of AbelianGroup as found
> in textbooks.
>
> We are also actively working on what you'd understand as rep/per. PL and
> logic people refer to this as reflection/reification (or quote and eval if
> you come from LISP).  In Coq, you have likely encountered ssreflect.  These
> are all instances of the same idea. Extremely powerful but also very
> dangerous.
>
> Lastly, and perhaps most importantly, we have spent years thinking about
> how to have a properly typed Expr type.  In Axiom, this really has root in
> the 'eval' operation of InnerEvalable (and then Evalable and
> ExpressionSpace).  Expr is both absolutely essential, but extremely
> problematic as it 1) internalizes semantics, and 2) generally involves
> partiality (undefinedness) in deep ways.  If this interests you, we can
> forward a number of papers where we start to deal with that.
>
> Sincerely,
> Jacques
>
> [1] https://arxiv.org/abs/1106.1862
> [2] https://arxiv.org/abs/1204.0053
> [3] http://imps.mcmaster.ca/doc/hlt.pdf
> [4] https://arxiv.org/abs/1405.5956
>
> On 2017-05-05 1:22 AM, Tim Daly wrote:
>
>> I'm Tim Daly, Lead Developer on Axiom.
>>
>> I just came across this posting:
>> http://www.cas.mcmaster.ca/~carette/IR-MathScheme-Standard.pdf <
>> http://www.cas.mcmaster.ca/%7Ecarette/IR-MathScheme-Standard.pdf>
>>
>> Is this a current project?
>>
>> I'm currently at Carnegie-Mellon doing research on proving Axiom
>> correct. As you're certainly aware, Axiom's category structure is
>> based on group theory.
>>
>> In Type Theory you find the concept of typeclasses which have
>> three distinct parts:
>>   1) the "carrier" (aka the representation)
>>   2) the signatures of functions for the typeclass
>>   3) the propositions (aka types) that these fulfill.
>>
>> Axiom has a domain called NonNegativeInteger (NNI) which is very
>> close to the usual 'nat' type in COQ. Lean, and other systems.
>>
>> Currently in Axiom the Category supplies the signatures (2 above)
>> which a Domain (e.g. NNI) which inherits from the Category must
>> implement (e.g. =)
>>
>> In Axiom the carrier (1 above) is a property of the Domain, which
>> allows Domains (aka Types) to have different representation. That
>> enables Axiom to have a sparse poly representation, a dense
>> poly representation, a recursive poly rep, etc., all of which inherit
>> from the same category structure, each in its own Domain.
>>
>> Axiom is currently missing the propositions (3 above). Since Types
>> are Propostiion (Curry-Howard) there is a way to integrate the
>> propositions into the Category hierarchy.
>>
>> A Category that requires a signature such as
>>   = : (x, y) -> Boolean
>> needs to also provide propositions for symmetry, reflexivity, and
>> associativity.
>>
>> Any Domain that inherits from the Category would have to provide
>> proofs for the symmetry, reflexivity, and associativity propositions
>> using operations from the newly defined domain.
>>
>> My current goal is to construct a proof-of-concept example using
>> Axiom and COQ.
>>
>> I'd be interested in more information on your MathScheme project.
>>
>> Tim Daly
>>
>>
>

\start
Date: Mon, 8 May 2017 20:00:11 -0400
From: Jacques Carette <carette@mcmaster.ca>
To: Tim Daly <axiomcas@gmail.com>, Jeremy Avigad <avigad@cmu.edu>, axiom-dev
	<axiom-developer@nongnu.org>, Laurent Thery <Laurent.Thery@inria.fr>
Subject: Re: [Axiom-developer] MathScheme project
CC: William Farmer <wmfarmer@mcmaster.ca>, Tim Daly <daly@axiom-developer.org>

Comments inline below.

On 2017-05-06 16:31 , Tim Daly wrote:
> Jacques,
>
> I'm reading your paper "The MathScheme Library: Some Preliminary
> Experiments". https://arxiv.org/pdf/1106.1862.pdf
>
> The LeftNearSemiring description on page 4 is essentially
> what I'm aiming to implement in Axiom.

Are you trying to do it as we are, by carefully building up the 
'signature' via combinators?  I know Axiom has most of the needed 
infrastructure, except for 1) renaming, and 2) a notion of 'join' that 
properly solves the "diamond problem".  That's the big difference 
between MathScheme and Axiom.  See paper [2] below.

> We differ on the choice of 'axiom' vs 'proposition'. I see what you label
> as 'axiom' as a continuation of the type signatures. You have
>
>    * : (U, U) -> U
>
> which in Type Theory is basically
>
>    U : Type
>    F : ( Type x Type ) -> Type
>
> Similarly what you label as 'axiom' is really just another type signature
> (per Curry-Howard) and I'd label it as a 'proposition'

Actually, we agree.  This is just a label - we use 'axiom' to mean 
'signature of type prop'.  It's meant to be surface syntax closer to 
traditional mathematics.  As our internal core is dependently typed, 
there is no real difference.

>
> So where '*' needs to be implemented in any Domain that inherits from
> LeftNearSemiring the 'proposition'
>
> associative_* := forall x,y,z:U  (x * y) * z = x * (y * z)
>
> means any Domain which inherits from LeftNearSemiring would have to prove
> those propositions using operations from the Domain being constructed.

Agreed.  That is exactly what we mean.

Jacques

>
> Comments?
>
> Tim
>
>
> On Sat, May 6, 2017 at 11:32 AM, Jacques Carette <carette@mcmaster.ca 
> <mailto:carette@mcmaster.ca>> wrote:
>
>     Hello Tim.
>
>     I believe we've met -- but 10+ years ago, at either an ISSAC or an
>     ECCAD.
>
>     In any case, Bill and I are quite familiar with Axiom. We've had
>     many conversations about it with James Davenport, Stephen Watt and
>     Gabriel Dos Reis.
>
>     Yes, MathScheme is a current project.  Its main web site is
>     available at http://mathscheme.cas.mcmaster.ca
>     <http://mathscheme.cas.mcmaster.ca>. [The list of papers is out of
>     date, we're working on that; and we are also open-sourcing various
>     bits of it as we clean the implementation].
>
>     Personally, I would encourage you to build a proof-of-concept
>     using Axiom and Agda (rather than Coq); or even Idris.  I believe
>     the approach to proofs there is much closer to Axiom than what you
>     will get with Coq.  Or, since you are at CMU, Lean ?
>
>     What you will undoubtedly encounter is that Axiom's current
>     "batteries included" approach to library building where, for
>     example, the Category AbelianGroup [Book Volume 10.2, Category
>     Layer 6, AbelianGroup.input on p.667 of the pdf at
>     www.axiom-developer.org/axiom-website/bookvol10.2.pdf
>     <http://www.axiom-developer.org/axiom-website/bookvol10.2.pdf> ]
>     really builds abelian group as a Z-module.  While this is
>     mathematically correct, it is not very modular.  At [1] we show
>     how we have made this quite a bit more modular, using the
>     combinators of [2].  To recover the "batteries included" version
>     (which we believe in [3]), we have 'invented' Realms [4].  To us,
>     Axioms' AbelianGroup Category is closer the AbelianGroup Realm
>     than the fundamental 'theory' of AbelianGroup as found in textbooks.
>
>     We are also actively working on what you'd understand as rep/per.
>     PL and logic people refer to this as reflection/reification (or
>     quote and eval if you come from LISP).  In Coq, you have likely
>     encountered ssreflect. These are all instances of the same idea.
>     Extremely powerful but also very dangerous.
>
>     Lastly, and perhaps most importantly, we have spent years thinking
>     about how to have a properly typed Expr type.  In Axiom, this
>     really has root in the 'eval' operation of InnerEvalable (and then
>     Evalable and ExpressionSpace).  Expr is both absolutely essential,
>     but extremely problematic as it 1) internalizes semantics, and 2)
>     generally involves partiality (undefinedness) in deep ways.  If
>     this interests you, we can forward a number of papers where we
>     start to deal with that.
>
>     Sincerely,
>     Jacques
>
>     [1] https://arxiv.org/abs/1106.1862 <https://arxiv.org/abs/1106.1862>
>     [2] https://arxiv.org/abs/1204.0053 <https://arxiv.org/abs/1204.0053>
>     [3] http://imps.mcmaster.ca/doc/hlt.pdf
>     <http://imps.mcmaster.ca/doc/hlt.pdf>
>     [4] https://arxiv.org/abs/1405.5956 <https://arxiv.org/abs/1405.5956>
>
>     On 2017-05-05 1:22 AM, Tim Daly wrote:
>
>         I'm Tim Daly, Lead Developer on Axiom.
>
>         I just came across this posting:
>         http://www.cas.mcmaster.ca/~carette/IR-MathScheme-Standard.pdf
>         <http://www.cas.mcmaster.ca/%7Ecarette/IR-MathScheme-Standard.pdf>
>         <http://www.cas.mcmaster.ca/%7Ecarette/IR-MathScheme-Standard.pdf
>         <http://www.cas.mcmaster.ca/%7Ecarette/IR-MathScheme-Standard.pdf>>
>
>
>         Is this a current project?
>
>         I'm currently at Carnegie-Mellon doing research on proving Axiom
>         correct. As you're certainly aware, Axiom's category structure is
>         based on group theory.
>
>         In Type Theory you find the concept of typeclasses which have
>         three distinct parts:
>           1) the "carrier" (aka the representation)
>           2) the signatures of functions for the typeclass
>           3) the propositions (aka types) that these fulfill.
>
>         Axiom has a domain called NonNegativeInteger (NNI) which is very
>         close to the usual 'nat' type in COQ. Lean, and other systems.
>
>         Currently in Axiom the Category supplies the signatures (2 above)
>         which a Domain (e.g. NNI) which inherits from the Category must
>         implement (e.g. =)
>
>         In Axiom the carrier (1 above) is a property of the Domain, which
>         allows Domains (aka Types) to have different representation. That
>         enables Axiom to have a sparse poly representation, a dense
>         poly representation, a recursive poly rep, etc., all of which
>         inherit
>         from the same category structure, each in its own Domain.
>
>         Axiom is currently missing the propositions (3 above). Since Types
>         are Propostiion (Curry-Howard) there is a way to integrate the
>         propositions into the Category hierarchy.
>
>         A Category that requires a signature such as
>           = : (x, y) -> Boolean
>         needs to also provide propositions for symmetry, reflexivity, and
>         associativity.
>
>         Any Domain that inherits from the Category would have to provide
>         proofs for the symmetry, reflexivity, and associativity
>         propositions
>         using operations from the newly defined domain.
>
>         My current goal is to construct a proof-of-concept example using
>         Axiom and COQ.
>
>         I'd be interested in more information on your MathScheme project.
>
>         Tim Daly

\start
Date: Tue, 9 May 2017 17:39:48 -0400
From: Tim Daly <axiomcas@gmail.com>
To: Kyriakos Kalorkoti <kk@inf.ed.ac.uk>, Tim Daly <daly@axiom-developer.org>, 
	axiom-dev <axiom-developer@nongnu.org>
Subject: Re: [Axiom-developer] Axiom course

No need to apologize. I know this is a busy time.

The ultimate goal is to replace the hyperdoc/graphics with a browser front
end using HTML canvas for the graphics. I have made a start on this but
have been busy with other things.
(See http://axiom-developer.org/axiom-website/bookvol11.pdf)

A possible alternative is to use the Jupyter notebook. (http://jupyter.org/)
I have not looked into this in detail. The student is free to talk to me
about any ideas.

I'm working on a syllabus for a CMU course which seems to differ from the
current
courses taught elsewhere. Almost every course spends all of its time on the
algorithms. That's fine but it leave the topic "ungrounded". The student
does
not know how the algorithms are actually implemented and does not know how
to build/test/modify an existing system with new work. It's a bit like
teaching
art by looking at paintings but never mentioning 90% of the subject that a
real
artist knows, like brushes, medium, art shows, etc. It's all nice in theory
but
is ultimately pointless as the student can't use the information.

In the ideal case the students would be part of a group that does real work
on a real system, just as art students end up painting and entering their
work
in art shows. I'm hoping to start a "reading group" that covers papers from
the
past as well as the latest conferences. I have a set of papers on CAD
starting
with the Collins 1975 paper onward which I'm starting to organize.

Tim

\start
Date: Thu, 11 May 2017 13:06:21 -0400
From: Tim Daly <axiomcas@gmail.com>
To: Camm Maguire <camm@maguirefamily.org>
Subject: Re: [Axiom-developer] 20170401 sources

Oh. Sigh.

I will look into fixing this. This breaks the function <-> filename
correspondence so it is a slightly deeper issue.

Btw, do you have a version of GCL that will build on Ubuntu 16.04?
It appears they changed the default 'standard' for C so 'inline' no
longer works properly. I'm unable to get Axiom to build on any system
later than Ubuntu 14.04.

Tim


On Thu, May 11, 2017 at 12:53 PM, Camm Maguire <camm@maguirefamily.org>
wrote:

> Hi Tim!  Congratulations on releasing a new set of sources!
>
> There is an issue with your '.help files from lisp' mechanism in
> tangle.lisp.  You end up trying to open files like
> "..../retractable?.help" which is not ansi, as the pathname is wild.
> I'm building a patched version with '?' -> 'q' on help file writing,
> but I do not immediately see where to update the help system on
> reading.
>
> Perhaps you have a suggestion?
>
> Take care, and thanks again for all your axiom work!
> --
> Camm Maguire                                        camm@maguirefamily.org
> ==========================================================================
> "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
>
>

\start
Date: Thu, 11 May 2017 12:53:54 -0400
From: Camm Maguire <camm@maguirefamily.org>
To: Tim Daly <axiomcas@gmail.com>
Subject: [Axiom-developer] 20170401 sources

Hi Tim!  Congratulations on releasing a new set of sources!

There is an issue with your '.help files from lisp' mechanism in
tangle.lisp.  You end up trying to open files like
"..../retractable?.help" which is not ansi, as the pathname is wild.
I'm building a patched version with '?' -> 'q' on help file writing,
but I do not immediately see where to update the help system on
reading. 

Perhaps you have a suggestion?

Take care, and thanks again for all your axiom work!
-- 
Camm Maguire			     		    camm@maguirefamily.org

\start
Date: Fri, 12 May 2017 08:21:40 -0400
From: Camm Maguire <camm@maguirefamily.org>
To: Tim Daly <axiomcas@gmail.com>
Subject: Re: [Axiom-developer] 20170401 sources

Greetings!

Tim Daly <axiomcas@gmail.com> writes:

> Oh. Sigh.
>
> I will look into fixing this. This breaks the function <-> filename
> correspondence so it is a slightly deeper issue.
>

Great!  Please keep me posted as I'd like to see how this builds in
Debian before releasing a new GCL.

> Btw, do you have a version of GCL that will build on Ubuntu 16.04?
> It appears they changed the default 'standard' for C so 'inline' no
> longer works properly. I'm unable to get Axiom to build on any system
> later than Ubuntu 14.04.
>

One can fix this with a CFLAGS setting if I recall, but the issue is
fixed in git.

git clone git://git.sv.gnu.org/gcl.git
cd gcl/gcl
git checkout Version_2_6_13pre

Please let me know if problems persist.

Take care,

> Tim
>
> On Thu, May 11, 2017 at 12:53 PM, Camm Maguire <camm@maguirefamily.org> w=
rote:
>
>     Hi Tim!=A0 Congratulations on releasing a new set of sources!

>     There is an issue with your '.help files from lisp' mechanism in
>     tangle.lisp.=A0 You end up trying to open files like
>     "..../retractable?.help" which is not ansi, as the pathname is wild.
>     I'm building a patched version with '?' -> 'q' on help file writing,
>     but I do not immediately see where to update the help system on
>     reading.

>     Perhaps you have a suggestion?

>     Take care, and thanks again for all your axiom work!
>     --
>     Camm Maguire=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
>     "The earth is but one country, and mankind its citizens."=A0 --=A0 Ba=
ha'u'llah
>

--=20
Camm Maguire			     		    camm@maguirefamily.org

\start
Date: Fri, 12 May 2017 15:41:07 -0400
From: Tim Daly <axiomcas@gmail.com>
To: Camm Maguire <camm@maguirefamily.org>
Subject: Re: [Axiom-developer] 20170401 sources

Camm,

13pre builds. Thanks.
I'll work on getting Axiom built on it and let you know when that works.

Tim


On Fri, May 12, 2017 at 8:21 AM, Camm Maguire <camm@maguirefamily.org>
wrote:

> Greetings!
>
> Tim Daly <axiomcas@gmail.com> writes:
>
> > Oh. Sigh.
> >
> > I will look into fixing this. This breaks the function <-> filename
> > correspondence so it is a slightly deeper issue.
> >
>
> Great!  Please keep me posted as I'd like to see how this builds in
> Debian before releasing a new GCL.
>
> > Btw, do you have a version of GCL that will build on Ubuntu 16.04?
> > It appears they changed the default 'standard' for C so 'inline' no
> > longer works properly. I'm unable to get Axiom to build on any system
> > later than Ubuntu 14.04.
> >
>
> One can fix this with a CFLAGS setting if I recall, but the issue is
> fixed in git.
>
> git clone git://git.sv.gnu.org/gcl.git
> cd gcl/gcl
> git checkout Version_2_6_13pre
>
> Please let me know if problems persist.
>
> Take care,
>
> > Tim
> >
> > On Thu, May 11, 2017 at 12:53 PM, Camm Maguire <camm@maguirefamily.org>
> wrote:
> >
> >     Hi Tim!  Congratulations on releasing a new set of sources!
> >
> >     There is an issue with your '.help files from lisp' mechanism in
> >     tangle.lisp.  You end up trying to open files like
> >     "..../retractable?.help" which is not ansi, as the pathname is wild.
> >     I'm building a patched version with '?' -> 'q' on help file writing,
> >     but I do not immediately see where to update the help system on
> >     reading.
> >
> >     Perhaps you have a suggestion?
> >
> >     Take care, and thanks again for all your axiom work!
> >     --
> >     Camm Maguire

\start
Date: Sat, 13 May 2017 00:40:07 -0400
From: Tim Daly <axiomcas@gmail.com>
To: Camm Maguire <camm@maguirefamily.org>
Subject: Re: [Axiom-developer] 20170401 sources

Camm,

Axiom builds on Ubuntu 16 and on the MAC using 2.6.13pre.

I have yet to look into the ? wildcard issue but everything else works.

Thanks,
Tim


On Fri, May 12, 2017 at 3:41 PM, Tim Daly <axiomcas@gmail.com> wrote:

> Camm,
>
> 13pre builds. Thanks.
> I'll work on getting Axiom built on it and let you know when that works.
>
> Tim
>
>
> On Fri, May 12, 2017 at 8:21 AM, Camm Maguire <camm@maguirefamily.org>
> wrote:
>
>> Greetings!
>>
>> Tim Daly <axiomcas@gmail.com> writes:
>>
>> > Oh. Sigh.
>> >
>> > I will look into fixing this. This breaks the function <-> filename
>> > correspondence so it is a slightly deeper issue.
>> >
>>
>> Great!  Please keep me posted as I'd like to see how this builds in
>> Debian before releasing a new GCL.
>>
>> > Btw, do you have a version of GCL that will build on Ubuntu 16.04?
>> > It appears they changed the default 'standard' for C so 'inline' no
>> > longer works properly. I'm unable to get Axiom to build on any system
>> > later than Ubuntu 14.04.
>> >
>>
>> One can fix this with a CFLAGS setting if I recall, but the issue is
>> fixed in git.
>>
>> git clone git://git.sv.gnu.org/gcl.git
>> cd gcl/gcl
>> git checkout Version_2_6_13pre
>>
>> Please let me know if problems persist.
>>
>> Take care,
>>
>> > Tim
>> >
>> > On Thu, May 11, 2017 at 12:53 PM, Camm Maguire <camm@maguirefamily.org>
>> wrote:
>> >
>> >     Hi Tim!  Congratulations on releasing a new set of sources!
>> >
>> >     There is an issue with your '.help files from lisp' mechanism in
>> >     tangle.lisp.  You end up trying to open files like
>> >     "..../retractable?.help" which is not ansi, as the pathname is wild.
>> >     I'm building a patched version with '?' -> 'q' on help file writing,
>> >     but I do not immediately see where to update the help system on
>> >     reading.
>> >
>> >     Perhaps you have a suggestion?
>> >
>> >     Take care, and thanks again for all your axiom work!
>> >     --
>> >     Camm Maguire

\start
Date: Sun, 14 May 2017 01:26:53 -0400
From: Tim Daly <axiomcas@gmail.com>
To: William Sit <wsit@ccny.cuny.edu>, axiom-dev <axiom-developer@nongnu.org>, 
	Tim Daly <daly@axiom-developer.org>
Subject: Re: [Axiom-developer] 20170401 sources
Cc: Camm Maguire <camm@maguirefamily.org>

Camm,

Axiom uses a program called 'tanglec' (in books/tanglec.c) to extract
'chunks' from the source pamphlet files. The tanglec program will look for

   \begin{chunk}{somename}
        source code goes here
   \end{chunk}

so given a filename and a chunk name it will extract the chunk to stdout
which are, by default, extracted to the equivalent filename, e.g.

   tanglec bookvol10.3.pamphlet retractable?.help >retractable?.help

so the solution for output is to rename the chunk names not to use
wildcards.
Thus I need to change it to read:

   \begin{chunk}{retractableq.help}

When the lisp code is trying to find the help file named 'retractable?.help
I need to quietly mangle it to 'retractableq' and look for retractableq.help

This seems a simple but, as we both know, there is no such thing as a
simple job. Nevertheless, I'm working on the fix.

Tim




On Sun, May 14, 2017 at 1:11 AM, William Sit <wsit@ccny.cuny.edu> wrote:

> Camm, thanks for the explanation, which is way beyond my understanding. I
> get it that pathnames are more complicated than I realized.
>
> 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: Camm Maguire <camm@maguirefamily.org>
> Sent: Friday, May 12, 2017 9:24 AM
> To: William Sit
> Subject: Re: [Axiom-developer] 20170401 sources
>
> Greetings!
>
> William Sit <wsit@ccny.cuny.edu> writes:
>
> > Hi, Camm:
> >
> > Isn't it true to use %3F for "?" on path and url names for html? (other
> punctuations like space %20 are commonly used as well)? If true then there
> is no need to change function names ending with "?".
> >
>
> Exactly what freedom a lisp implementation has in defining wild
> pathnames is an interesting question.  #'open must fail on a
> wild-pathname.  clisp and sbcl (and gcl) both recognize '*' and '?' as
> pathname wildcards.  If '?' is defined as non-wild, then of course
> #'directory will not expand it in producing its output.
>
> Take care,
>

> ---------------------------
> Function WILD-PATHNAME-P
>
> Syntax:
>
> wild-pathname-p pathname &optional field-key => generalized-boolean
>
> Arguments and Values:
>
> pathname---a pathname designator.
>
> Field-key---one of :host, :device :directory, :name, :type, :version, or
> nil.
>
> generalized-boolean---a generalized boolean.
>
> Description:
>
> wild-pathname-p tests pathname for the presence of wildcard components.
>
> If pathname is a pathname (as returned by pathname) it represents the name
> used to open the file. This may be, but is not required to be, the
> actual name of the file.
>
> If field-key is not supplied or nil, wild-pathname-p returns true if
> pathname has any wildcard components, nil if pathname has none. If field-key
> is non-nil, wild-pathname-p returns true if the indicated component of
> pathname is a wildcard, nil if the component is not a wildcard.
>
> Examples:
>
>  ;;;The following examples are not portable.  They are written to run
>  ;;;with particular file systems and particular wildcard conventions.
>  ;;;Other implementations will behave differently.  These examples are
>  ;;;intended to be illustrative, not to be prescriptive.
>
>  (wild-pathname-p (make-pathname :name :wild)) =>  true
>  (wild-pathname-p (make-pathname :name :wild) :name) =>  true
>  (wild-pathname-p (make-pathname :name :wild) :type) =>  false
>  (wild-pathname-p (pathname "s:>foo>**>")) =>  true ;Lispm
>  (wild-pathname-p (pathname :name "F*O")) =>  true ;Most places
>
> Affected By: None.
>
> Exceptional Situations:
>
> If pathname is not a pathname, a string, or a stream associated with a
> file an error of type type-error is signaled.
>
> See Also:
>
> pathname, logical-pathname, Section 20.1 (File System Concepts), Section
> 19.1.2 (Pathnames as Filenames)
>
> Notes:
>
> Not all implementations support wildcards in all fields. See Section
> 19.2.2.2.2 (:WILD as a Component Value) and Section 19.2.2.3 (Restrictions
> on
> Wildcard Pathnames).
>
> ------------------------------------------------------------
> ------------------------------------------------------------
> ---------------------------
> ============================================================
> =================
>
> > 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=sci.ccny.cuny.edu@
> nongnu.org> on behalf of Camm Maguire <camm@maguirefamily.org>
> > Sent: Thursday, May 11, 2017 12:53 PM
> > To: Tim Daly
> > Cc: axiom-dev
> > Subject: [Axiom-developer] 20170401 sources
> >
> > Hi Tim!  Congratulations on releasing a new set of sources!
> >
> > There is an issue with your '.help files from lisp' mechanism in
> > tangle.lisp.  You end up trying to open files like
> > "..../retractable?.help" which is not ansi, as the pathname is wild.
> > I'm building a patched version with '?' -> 'q' on help file writing,
> > but I do not immediately see where to update the help system on
> > reading.
> >
> > Perhaps you have a suggestion?
> >
> > Take care, and thanks again for all your axiom work!
> > --
> > Camm Maguire
> camm@maguirefamily.org
> > ============================================================
> ==============
> > "The earth is but one country, and mankind its citizens."  --
> Baha'u'llah
> >
> >
> > _______________________________________________
> > Axiom-developer mailing list
> > Axiom-developer@nongnu.org
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.
> nongnu.org_mailman_listinfo_axiom-2Ddeveloper&d=DgICAg&c=
> 4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=
> qW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=jKPZYt0l9-
> Gq2G7mULUdnuY7RoMtJlBrPjLRzBCHak4&s=VVky8lyaGHS4YDqNXQA_
> aa4RLxHkI6-ZKuJRFQihfSw&e=
> >
> >
> >
> >
>
> --
> Camm Maguire                                        camm@maguirefamily.org
> ==========================================================================
> "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
>
>

\start
Date: Sun, 14 May 2017 19:55:05 -0400
From: Camm Maguire <camm@maguirefamily.org>
To: Tim Daly <axiomcas@gmail.com>
Subject: Re: [Axiom-developer] 20170401 sources

Greetings!  Thanks so much for looking at this!

Take care,

Tim Daly <axiomcas@gmail.com> writes:

> Camm,
>
> Axiom uses a program called 'tanglec' (in books/tanglec.c) to extract
> 'chunks' from the source pamphlet files. The tanglec program will look for
>
> =C2=A0=C2=A0 \begin{chunk}{somename}
> =C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0 source code goes here
> =C2=A0=C2=A0 \end{chunk}
>
> so given a filename and a chunk name it will extract the chunk to stdout
> which are, by default, extracted to the equivalent filename, e.g.
>
> =C2=A0=C2=A0 tanglec bookvol10.3.pamphlet retractable?.help >retractable?=
.help
>
> so the solution for output is to rename the chunk names not to use wildca=
rds.
> Thus I need to change it to read:
>
> =C2=A0=C2=A0 \begin{chunk}{retractableq.help}
>
> When the lisp code is trying to find the help file named 'retractable?.he=
lp
> I need to quietly mangle it to 'retractableq' and look for retractableq.h=
elp
>
> This seems a simple but, as we both know, there is no such thing as a
> simple job. Nevertheless, I'm working on the fix.
>
> Tim
>
> On Sun, May 14, 2017 at 1:11 AM, William Sit <wsit@ccny.cuny.edu> wrote:
>
>     Camm, thanks for the explanation, which is way beyond my understandin=
g. I get it that pathnames are more complicated than I realized.

>     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: Camm Maguire <camm@maguirefamily.org>
>     Sent: Friday, May 12, 2017 9:24 AM
>     To: William Sit
>     Subject: Re: [Axiom-developer] 20170401 sources

>     Greetings!

>     William Sit <wsit@ccny.cuny.edu> writes:

>     > Hi, Camm:
>     >
>     > Isn't it true to use %3F for "?" on path and url names for html? (o=
ther punctuations like space %20 are commonly used as well)? If true then
>     there is no need to change function names ending with "?".
>     >

>     Exactly what freedom a lisp implementation has in defining wild
>     pathnames is an interesting question.=C2=A0 #'open must fail on a
>     wild-pathname.=C2=A0 clisp and sbcl (and gcl) both recognize '*' and =
'?' as
>     pathname wildcards.=C2=A0 If '?' is defined as non-wild, then of cour=
se
>     #'directory will not expand it in producing its output.

>     Take care,

>     ---------------------------------------------------------------------=
---------------------------------------------------
>     ---------------------------
>     Function WILD-PATHNAME-P

>     Syntax:

>     wild-pathname-p pathname &optional field-key =3D> generalized-boolean

>     Arguments and Values:

>     pathname---a pathname designator.

>     Field-key---one of :host, :device :directory, :name, :type, :version,=
 or nil.

>     generalized-boolean---a generalized boolean.

>     Description:

>     wild-pathname-p tests pathname for the presence of wildcard component=
s.

>     If pathname is a pathname (as returned by pathname) it represents the=
 name used to open the file. This may be, but is not required to be, the
>     actual name of the file.

>     If field-key is not supplied or nil, wild-pathname-p returns true if =
pathname has any wildcard components, nil if pathname has none. If
>     field-key
>     is non-nil, wild-pathname-p returns true if the indicated component o=
f pathname is a wildcard, nil if the component is not a wildcard.

>     Examples:

>     =C2=A0;;;The following examples are not portable.=C2=A0 They are writ=
ten to run
>     =C2=A0;;;with particular file systems and particular wildcard convent=
ions.
>     =C2=A0;;;Other implementations will behave differently.=C2=A0 These e=
xamples are
>     =C2=A0;;;intended to be illustrative, not to be prescriptive.

>     =C2=A0(wild-pathname-p (make-pathname :name :wild)) =3D>=C2=A0 true
>     =C2=A0(wild-pathname-p (make-pathname :name :wild) :name) =3D>=C2=A0 =
true
>     =C2=A0(wild-pathname-p (make-pathname :name :wild) :type) =3D>=C2=A0 =
false
>     =C2=A0(wild-pathname-p (pathname "s:>foo>**>")) =3D>=C2=A0 true ;Lispm
>     =C2=A0(wild-pathname-p (pathname :name "F*O")) =3D>=C2=A0 true ;Most =
places

>     Affected By: None.

>     Exceptional Situations:

>     If pathname is not a pathname, a string, or a stream associated with =
a file an error of type type-error is signaled.

>     See Also:

>     pathname, logical-pathname, Section 20.1 (File System Concepts), Sect=
ion 19.1.2 (Pathnames as Filenames)

>     Notes:

>     Not all implementations support wildcards in all fields. See Section =
19.2.2.2.2 (:WILD as a Component Value) and Section 19.2.2.3 (Restrictions
>     on
>     Wildcard Pathnames).
>=20=20=20=20
>     ---------------------------------------------------------------------=
---------------------------------------------------
>     ---------------------------

>     > 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.cun=
y.edu@nongnu.org> on behalf of Camm Maguire <camm@maguirefamily.org>
>     > Sent: Thursday, May 11, 2017 12:53 PM
>     > To: Tim Daly
>     > Cc: axiom-dev
>     > Subject: [Axiom-developer] 20170401 sources
>     >
>     > Hi Tim!=C2=A0 Congratulations on releasing a new set of sources!
>     >
>     > There is an issue with your '.help files from lisp' mechanism in
>     > tangle.lisp.=C2=A0 You end up trying to open files like
>     > "..../retractable?.help" which is not ansi, as the pathname is wild.
>     > I'm building a patched version with '?' -> 'q' on help file writing,
>     > but I do not immediately see where to update the help system on
>     > reading.
>     >
>     > Perhaps you have a suggestion?
>     >
>     > Take care, and thanks again for all your axiom work!
>     > --
>     > Camm Maguire=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 camm@maguirefamily.org

>     > "The earth is but one country, and mankind its citizens."=C2=A0 --=
=C2=A0 Baha'u'llah
>     >
>     >
>     > _______________________________________________
>     > Axiom-developer mailing list
>     > Axiom-developer@nongnu.org
>     > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__lists.nongnu=
.org_mailman_listinfo_axiom-2Ddeveloper&d=3DDgICAg&c=3D
>     4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo6sWEVPpx7wwW=
YZ79PdSWMRxNZvTih0Bkxc&m=3DjKPZYt0l9-Gq2G7mULUdnuY7RoMtJlBrPjLRzBCHak4&s=3D
>     VVky8lyaGHS4YDqNXQA_aa4RLxHkI6-ZKuJRFQihfSw&e=3D
>     >
>     >
>     >
>     >
>=20=20=20=20
>     --
>     Camm Maguire=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =

\start
Date: Sun, 14 May 2017 23:40:44 -0400
From: Tim Daly <axiomcas@gmail.com>
To: Camm Maguire <camm@maguirefamily.org>
Subject: Re: [Axiom-developer] 20170401 sources

The latest push (1cb0661) contains the wildcard name fix.
)help member? works but is stored as memberq.help

Tim



On Sun, May 14, 2017 at 7:55 PM, Camm Maguire <camm@maguirefamily.org>
wrote:

> Greetings!  Thanks so much for looking at this!
>
> Take care,
>
> Tim Daly <axiomcas@gmail.com> writes:
>
> > Camm,
> >
> > Axiom uses a program called 'tanglec' (in books/tanglec.c) to extract
> > 'chunks' from the source pamphlet files. The tanglec program will look
> for
> >
> >    \begin{chunk}{somename}
> >         source code goes here
> >    \end{chunk}
> >
> > so given a filename and a chunk name it will extract the chunk to stdout
> > which are, by default, extracted to the equivalent filename, e.g.
> >
> >    tanglec bookvol10.3.pamphlet retractable?.help >retractable?.help
> >
> > so the solution for output is to rename the chunk names not to use
> wildcards.
> > Thus I need to change it to read:
> >
> >    \begin{chunk}{retractableq.help}
> >
> > When the lisp code is trying to find the help file named
> 'retractable?.help
> > I need to quietly mangle it to 'retractableq' and look for
> retractableq.help
> >
> > This seems a simple but, as we both know, there is no such thing as a
> > simple job. Nevertheless, I'm working on the fix.
> >
> > Tim
> >
> > On Sun, May 14, 2017 at 1:11 AM, William Sit <wsit@ccny.cuny.edu> wrote:
> >
> >     Camm, thanks for the explanation, which is way beyond my
> understanding. I get it that pathnames are more complicated than I realized.
> >
> >     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: Camm Maguire <camm@maguirefamily.org>
> >     Sent: Friday, May 12, 2017 9:24 AM
> >     To: William Sit
> >     Subject: Re: [Axiom-developer] 20170401 sources
> >
> >     Greetings!
> >
> >     William Sit <wsit@ccny.cuny.edu> writes:
> >
> >     > Hi, Camm:
> >     >
> >     > Isn't it true to use %3F for "?" on path and url names for html?
> (other punctuations like space %20 are commonly used as well)? If true then
> >     there is no need to change function names ending with "?".
> >     >
> >
> >     Exactly what freedom a lisp implementation has in defining wild
> >     pathnames is an interesting question.  #'open must fail on a
> >     wild-pathname.  clisp and sbcl (and gcl) both recognize '*' and '?'
> as
> >     pathname wildcards.  If '?' is defined as non-wild, then of course
> >     #'directory will not expand it in producing its output.
> >
> >     Take care,
> >
> >     ============================================================
> =================
> >     ------------------------------------------------------------
> ------------------------------------------------------------
> >     ---------------------------
> >     Function WILD-PATHNAME-P
> >
> >     Syntax:
> >
> >     wild-pathname-p pathname &optional field-key => generalized-boolean
> >
> >     Arguments and Values:
> >
> >     pathname---a pathname designator.
> >
> >     Field-key---one of :host, :device :directory, :name, :type,
> :version, or nil.
> >
> >     generalized-boolean---a generalized boolean.
> >
> >     Description:
> >
> >     wild-pathname-p tests pathname for the presence of wildcard
> components.
> >
> >     If pathname is a pathname (as returned by pathname) it represents
> the name used to open the file. This may be, but is not required to be, the
> >     actual name of the file.
> >
> >     If field-key is not supplied or nil, wild-pathname-p returns true if
> pathname has any wildcard components, nil if pathname has none. If
> >     field-key
> >     is non-nil, wild-pathname-p returns true if the indicated component
> of pathname is a wildcard, nil if the component is not a wildcard.
> >
> >     Examples:
> >
> >      ;;;The following examples are not portable.  They are written to run
> >      ;;;with particular file systems and particular wildcard conventions.
> >      ;;;Other implementations will behave differently.  These examples
> are
> >      ;;;intended to be illustrative, not to be prescriptive.
> >
> >      (wild-pathname-p (make-pathname :name :wild)) =>  true
> >      (wild-pathname-p (make-pathname :name :wild) :name) =>  true
> >      (wild-pathname-p (make-pathname :name :wild) :type) =>  false
> >      (wild-pathname-p (pathname "s:>foo>**>")) =>  true ;Lispm
> >      (wild-pathname-p (pathname :name "F*O")) =>  true ;Most places
> >
> >     Affected By: None.
> >
> >     Exceptional Situations:
> >
> >     If pathname is not a pathname, a string, or a stream associated with
> a file an error of type type-error is signaled.
> >
> >     See Also:
> >
> >     pathname, logical-pathname, Section 20.1 (File System Concepts),
> Section 19.1.2 (Pathnames as Filenames)
> >
> >     Notes:
> >
> >     Not all implementations support wildcards in all fields. See Section
> 19.2.2.2.2 (:WILD as a Component Value) and Section 19.2.2.3 (Restrictions
> >     on
> >     Wildcard Pathnames).
> >
> >     ------------------------------------------------------------
> ------------------------------------------------------------
> >     ---------------------------
> >     ============================================================
> =================
> >
> >     > 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=
> sci.ccny.cuny.edu@nongnu.org> on behalf of Camm Maguire <
> camm@maguirefamily.org>
> >     > Sent: Thursday, May 11, 2017 12:53 PM
> >     > To: Tim Daly
> >     > Cc: axiom-dev
> >     > Subject: [Axiom-developer] 20170401 sources
> >     >
> >     > Hi Tim!  Congratulations on releasing a new set of sources!
> >     >
> >     > There is an issue with your '.help files from lisp' mechanism in
> >     > tangle.lisp.  You end up trying to open files like
> >     > "..../retractable?.help" which is not ansi, as the pathname is
> wild.
> >     > I'm building a patched version with '?' -> 'q' on help file
> writing,
> >     > but I do not immediately see where to update the help system on
> >     > reading.
> >     >
> >     > Perhaps you have a suggestion?
> >     >
> >     > Take care, and thanks again for all your axiom work!
> >     > --
> >     > Camm Maguire
> camm@maguirefamily.org
> >     > ============================================================
> ==============
> >     > "The earth is but one country, and mankind its citizens."  --
> Baha'u'llah
> >     >
> >     >
> >     > _______________________________________________
> >     > Axiom-developer mailing list
> >     > Axiom-developer@nongnu.org
> >     > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.
> nongnu.org_mailman_listinfo_axiom-2Ddeveloper&d=DgICAg&c=
> >     4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=
> qW9SUYRDo6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=jKPZYt0l9-
> Gq2G7mULUdnuY7RoMtJlBrPjLRzBCHak4&s=
> >     VVky8lyaGHS4YDqNXQA_aa4RLxHkI6-ZKuJRFQihfSw&e=
> >     >
> >     >
> >     >
> >     >
> >
> >     --
> >     Camm Maguire

\start
Date: Mon, 15 May 2017 07:45:09 -0400
From: Tim Daly <axiomcas@gmail.com>
To: Kyriakos Kalorkoti <kk@inf.ed.ac.uk>, Tim Daly <daly@axiom-developer.org>, 
	axiom-dev <axiom-developer@nongnu.org>
Subject: Re: [Axiom-developer] Axiom course

Speaking of "real work on a real system" there could be several projects
that would be useful.

view2d / vew3d

For the browser-based version the graphics goal is to replace the view2d and
view3d programs with HTML5 canvas-based versions. The first step would
be to document the message patterns from axiom to view2d and back. Once
that is done and documented there would be an effort to use something like
websockets to display the messages in browser text and automate the replies.

Now that you know the messages they need to be turned into HTML5 canvas
drawing commands. Once the drawing happens there is another layer of
control because clicking on a view2d/3d image will bring up a control panel.
This could be done with menus or buttons in the web page rather than as a
separate window.

If a student wants to do this they should look at the book
"Physically Based Rendering". This book won an Academy Award.
It is the canonical example of where Axiom needs to go.

Deconstructing Hyperdoc

Hyperdoc was our pre-internet version of a browser. Some portions of it are
pre-canned scripts (some of which I've already written, as you can see from
the sources). Some portions interact with the running Axiom to send an
input line and open a DIV section with the response. I have also written
some
prototype code for that in the sources.

Some page output is generated dynamically by Axiom. This needs to be
written so it creates browser-based text rather than hyperdoc text.

Removing Makefiles

We currently use 'make' to build the system. But Axiom is trying to remove
as many tools and external dependencies as possible. Each thing we remove
is one less thing users need to pre-install and one less thing to maintain.

The task would be to trace the 'make' scripts to find out the exact sequence
of commands to build Axiom. These would then be written as lisp functions.
So instead of using 'make', we start lisp and use it to build Axiom, which
is
a large lisp program.

Some of this tracing is already done in anticipation that this rewrite will
happen. The Makefile files are documented (and generated from) the
Makefile.pamphlet files.

Knuth, Literate Programming, and Axiom

The 'pamphlet' files are raw latex files. You can just run latex on them.
Knuth's original vision of literate programming had 2 tools, 'weave' and
'tangle'. The 'weave' program takes the literate sources and generates
tex-compatible output. Axiom uses latex directly so there is no need for
a 'weave' program.

The 'tangle' program exists, called 'tanglec' in the books subdirectory.
It takes 2 arguments, the source latex file and the name of a 'chunk'.
It writes the chunk contents to stdout.

    tanglec bookvol10.3.pamphlet "domain INT Integer" >integer.spad

This will look for a chunk with the given name, e.g.

   \begin{chunk}{domain INT Integer}
        the integer.spad source code is here
   \end{chunk}

There is no real magic in the 'tanglec' program. It just reads the source
file, makes a hash table of every chunk name (concatenating repeated
names into a single block) and then writes out the requested chunk to
stdout.

The ultimate goal is to make every file a latex document. Most
programs use the "pile of sand" (POS) method to organize sources.
They try to provide "semantics" by clever directory names such as 'doc'.

What they don't realize is that this is left-over technology from the past.
I used to work on a machine with 8k, 4k of which was the operating system.
If you created a file larger than 4k you crashed the system. So we invented
"include" for files and "overlay linkers" (which are now virtual memory
hardware). Comments cost bytes and were frowned upon.

People STILL write 4k files and POS directories with include files despite
having 16G of memory. They still think comments are expensive and that
'documentation' is worthless. We need to think of 'explanations', not
documentation or comments. POS programming needs to die.

Explanations

If you cover a topic in class (e.g. CAD, Groebner, Berlekamp factoring, etc)
the task would be to find the code that implements the algorithms and
document them. This is rather more difficult than it sounds as there are
a lot of implementation details which classes never cover but are vital.

A good starting point would be polynomial algorithms. Axiom supports a
lot of different poly representations, such as sparse/dense, recursive,
distributed, and various multivariate versions of the same. Pick one of
the Domains, e.g. SparseUnivariatePolynomial (SUP), discuss its
representation in Axiom, and explain operations like 'variables',
'resultant',
'primitivePart', 'squareFree', etc.

Contributions

You should stress to any student that Axiom is literate. That means that
any contribution NEEDS to focus on explanation. For a system like Axiom
to live, it needs to be possible for people to maintain, modify, and extend
it.

The prior authors (me included) failed to explain anything. Axiom was
originally a research project not a product so nobody cared. Unfortunately,
now we have to re-discover how existing code works. New code can't be
allowed to make the same mistake.

I'd be happy to work with students who want to contribute.

Tim


On Tue, May 9, 2017 at 5:39 PM, Tim Daly <axiomcas@gmail.com> wrote:

> No need to apologize. I know this is a busy time.
>
> The ultimate goal is to replace the hyperdoc/graphics with a browser front
> end using HTML canvas for the graphics. I have made a start on this but
> have been busy with other things.
> (See http://axiom-developer.org/axiom-website/bookvol11.pdf)
>
> A possible alternative is to use the Jupyter notebook. (
> http://jupyter.org/)
> I have not looked into this in detail. The student is free to talk to me
> about any ideas.
>
> I'm working on a syllabus for a CMU course which seems to differ from the
> current
> courses taught elsewhere. Almost every course spends all of its time on the
> algorithms. That's fine but it leave the topic "ungrounded". The student
> does
> not know how the algorithms are actually implemented and does not know how
> to build/test/modify an existing system with new work. It's a bit like
> teaching
> art by looking at paintings but never mentioning 90% of the subject that a
> real
> artist knows, like brushes, medium, art shows, etc. It's all nice in
> theory but
> is ultimately pointless as the student can't use the information.
>
> In the ideal case the students would be part of a group that does real work
> on a real system, just as art students end up painting and entering their
> work
> in art shows. I'm hoping to start a "reading group" that covers papers
> from the
> past as well as the latest conferences. I have a set of papers on CAD
> starting
> with the Collins 1975 paper onward which I'm starting to organize.
>
> Tim
>

\start
From: Camm Maguire <camm@maguirefamily.org>
To: Tim Daly <axiomcas@gmail.com>
Date: Mon, 15 May 2017 14:11:41 -0400
Subject: Re: [Axiom-developer] 20170401 sources

Greetings, and thanks!  Looks like we have a winner!  You can check here
if desired for the autobuilder results as they come in:

https://buildd.debian.org/status/package.php?p=3Daxiom

Tim Daly <axiomcas@gmail.com> writes:

> The latest push (1cb0661) contains the wildcard name fix.
> )help member? works but is stored as memberq.help
>
> Tim
>
> On Sun, May 14, 2017 at 7:55 PM, Camm Maguire <camm@maguirefamily.org> wr=
ote:
>
>     Greetings!=A0 Thanks so much for looking at this!
>
>     Take care,
>
>     Tim Daly <axiomcas@gmail.com> writes:
>
>     > Camm,
>     >
>     > Axiom uses a program called 'tanglec' (in books/tanglec.c) to extra=
ct
>     > 'chunks' from the source pamphlet files. The tanglec program will l=
ook for
>     >
>     >  \begin{chunk}{somename}
>     >    source code goes here
>     >  \end{chunk}
>     >
>     > so given a filename and a chunk name it will extract the chunk to s=
tdout
>     > which are, by default, extracted to the equivalent filename, e.g.
>     >
>     >  tanglec bookvol10.3.pamphlet retractable?.help >retractable?=
.help
>     >
>     > so the solution for output is to rename the chunk names not to use =
wildcards.
>     > Thus I need to change it to read:
>     >
>     >  \begin{chunk}{retractableq.help}
>     >
>     > When the lisp code is trying to find the help file named 'retractab=
le?.help
>     > I need to quietly mangle it to 'retractableq' and look for retracta=
bleq.help
>     >
>     > This seems a simple but, as we both know, there is no such thing as=
 a
>     > simple job. Nevertheless, I'm working on the fix.
>     >
>     > Tim
>     >
>     > On Sun, May 14, 2017 at 1:11 AM, William Sit <wsit@ccny.cuny.edu> w=
rote:
>     >
>     >  Camm, thanks for the explanation, which is way beyond my =
understanding. I get it that pathnames are more complicated than I realized.
>     >
>     >  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: Camm Maguire <camm@maguirefamily.org>
>     >  Sent: Friday, May 12, 2017 9:24 AM
>     >  To: William Sit
>     >  Subject: Re: [Axiom-developer] 20170401 sources
>     >
>     >  Greetings!
>     >
>     >  William Sit <wsit@ccny.cuny.edu> writes:
>     >
>     >  > Hi, Camm:
>     >  >
>     >  > Isn't it true to use %3F for "?" on path and url names =
for html? (other punctuations like space %20 are commonly used as well)? If=
 true
>     then
>     >  there is no need to change function names ending with "?".
>     >  >
>     >
>     >  Exactly what freedom a lisp implementation has in definin=
g wild
>     >  pathnames is an interesting question. #'open must fail=
 on a
>     >  wild-pathname. clisp and sbcl (and gcl) both recognize=
 '*' and '?' as
>     >  pathname wildcards. If '?' is defined as non-wild, the=
n of course
>     >  #'directory will not expand it in producing its output.
>     >
>     >  Take care,
>     >

>     >  ---------------------------------------------------------=
---------------------------------------------------------------
>     >  ---------------------------
>     >  Function WILD-PATHNAME-P
>     >
>     >  Syntax:
>     >
>     >  wild-pathname-p pathname &optional field-key =3D> general=
ized-boolean
>     >
>     >  Arguments and Values:
>     >
>     >  pathname---a pathname designator.
>     >
>     >  Field-key---one of :host, :device :directory, :name, :typ=
e, :version, or nil.
>     >
>     >  generalized-boolean---a generalized boolean.
>     >
>     >  Description:
>     >
>     >  wild-pathname-p tests pathname for the presence of wildca=
rd components.
>     >
>     >  If pathname is a pathname (as returned by pathname) it re=
presents the name used to open the file. This may be, but is not required t=
o be,
>     the
>     >  actual name of the file.
>     >
>     >  If field-key is not supplied or nil, wild-pathname-p retu=
rns true if pathname has any wildcard components, nil if pathname has none.=
 If
>     >  field-key
>     >  is non-nil, wild-pathname-p returns true if the indicated=
 component of pathname is a wildcard, nil if the component is not a wildcar=
d.
>     >
>     >  Examples:
>     >
>     >  ;;;The following examples are not portable. They ar=
e written to run
>     >  ;;;with particular file systems and particular wildcar=
d conventions.
>     >  ;;;Other implementations will behave differently. T=
hese examples are
>     >  ;;;intended to be illustrative, not to be prescriptive.
>     >
>     >  (wild-pathname-p (make-pathname :name :wild)) =3D> =
true
>     >  (wild-pathname-p (make-pathname :name :wild) :name) =
=3D> true
>     >  (wild-pathname-p (make-pathname :name :wild) :type) =
=3D> false
>     >  (wild-pathname-p (pathname "s:>foo>**>")) =3D> true=
 ;Lispm
>     >  (wild-pathname-p (pathname :name "F*O")) =3D> true =
;Most places
>     >
>     >  Affected By: None.
>     >
>     >  Exceptional Situations:
>     >
>     >  If pathname is not a pathname, a string, or a stream asso=
ciated with a file an error of type type-error is signaled.
>     >
>     >  See Also:
>     >
>     >  pathname, logical-pathname, Section 20.1 (File System Con=
cepts), Section 19.1.2 (Pathnames as Filenames)
>     >
>     >  Notes:
>     >
>     >  Not all implementations support wildcards in all fields. =
See Section 19.2.2.2.2 (:WILD as a Component Value) and Section 19.2.2.3
>     (Restrictions
>     >  on
>     >  Wildcard Pathnames).
>     >
>     >  ---------------------------------------------------------=
---------------------------------------------------------------
>     >  ---------------------------

>     >
>     >  > 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=3D=
sci.ccny.cuny.edu@nongnu.org> on behalf of Camm Maguire <camm@maguirefamily=
.org>
>     >  > Sent: Thursday, May 11, 2017 12:53 PM
>     >  > To: Tim Daly
>     >  > Cc: axiom-dev
>     >  > Subject: [Axiom-developer] 20170401 sources
>     >  >
>     >  > Hi Tim! Congratulations on releasing a new set of so=
urces!
>     >  >
>     >  > There is an issue with your '.help files from lisp' mec=
hanism in
>     >  > tangle.lisp. You end up trying to open files like
>     >  > "..../retractable?.help" which is not ansi, as the path=
name is wild.
>     >  > I'm building a patched version with '?' -> 'q' on help =
file writing,
>     >  > but I do not immediately see where to update the help s=
ystem on
>     >  > reading.
>     >  >
>     >  > Perhaps you have a suggestion?
>     >  >
>     >  > Take care, and thanks again for all your axiom work!
>     >  > --
>     >  > Camm Maguire          =
          camm@maguirefamily.org

lists.nongnu.org_mailman_listinfo_axiom-2Ddeveloper&d=3DDgICAg&c=3D
>     >  4NmamNZG3KTnUCoC6InoLJ6KV1tbVKrkZXHRwtIMGmo&r=3DqW9SUYRDo=
6sWEVPpx7wwWYZ79PdSWMRxNZvTih0Bkxc&m=3DjKPZYt0l9-Gq2G7mULUdnuY7RoMtJlBrPjLR=
zBCHak4&s
>     =3D
>     >  VVky8lyaGHS4YDqNXQA_aa4RLxHkI6-ZKuJRFQihfSw&e=3D
>     >  >
>     >  >
>     >  >
>     >  >
>     >
>     >  --
>     >  Camm Maguire           =
         camm@maguirefamily.org

\start
Date: Mon, 15 May 2017 14:18:58 -0400
From: Tim Daly <axiomcas@gmail.com>
To: Kyriakos Kalorkoti <kk@inf.ed.ac.uk>, Tim Daly <daly@axiom-developer.org>, 
	axiom-dev <axiom-developer@nongnu.org>, Klaus Sutner <sutner@cs.cmu.edu>
Subject: Re: [Axiom-developer] Axiom course

Web Assembly / Web Sockets

On my list of things to think about for the Axiom browser interface is using
Web Assembly (http://webassembly.org/docs/mvp/) and Web Sockets
(https://tools.ietf.org/html/rfc6455)

The current implementation uses older technology.

Gnu Common Lisp compiles to C code. LLVM supports compiling C
code to wasm (web assembly). This raises the interesting possibility of
sending a compiled user function for a graph (or other user-interface
function) directly to the browser front end for local execution.

This is "current research", meaning that nobody knows how to do this yet
so it really is research. It might be more appropriate for an advanced
student's project with a poster/publication effort.

I have played with websockets for a bit, unsuccessfully. But my efforts were
at their first introduction a while ago so browser "support" was quite new
and
buggy. Socket support is probably better now but web assembly is at the MVP
(minimum viable product) stage which means somebody, somewhere got it
to work once on hand-crafted code in an undocumented custom tool chain.

The 'canonical' case I'm trying to construct is to send a set of functions,
graph them on a common (2D) canvas, have the user provide vertical lines
that are the Cylindrical Algebraic Decomposition "cells" which show where
the separations are, and send these vertical line equations back to Axiom.
This is an example of the user providing part of the actual computation
interactively. Again, I'll mention that this is real research as nobody does
interactive CAD computations yet as far as I know.

Approaching this canonical case requires a lot of tiny demonstration steps.
Any student willing to take tiny steps should be encouraged.

Tim



On Mon, May 15, 2017 at 7:45 AM, Tim Daly <axiomcas@gmail.com> wrote:

> Speaking of "real work on a real system" there could be several projects
> that would be useful.
>
> view2d / vew3d
>
> For the browser-based version the graphics goal is to replace the view2d
> and
> view3d programs with HTML5 canvas-based versions. The first step would
> be to document the message patterns from axiom to view2d and back. Once
> that is done and documented there would be an effort to use something like
> websockets to display the messages in browser text and automate the
> replies.
>
> Now that you know the messages they need to be turned into HTML5 canvas
> drawing commands. Once the drawing happens there is another layer of
> control because clicking on a view2d/3d image will bring up a control
> panel.
> This could be done with menus or buttons in the web page rather than as a
> separate window.
>
> If a student wants to do this they should look at the book
> "Physically Based Rendering". This book won an Academy Award.
> It is the canonical example of where Axiom needs to go.
>
> Deconstructing Hyperdoc
>
> Hyperdoc was our pre-internet version of a browser. Some portions of it are
> pre-canned scripts (some of which I've already written, as you can see from
> the sources). Some portions interact with the running Axiom to send an
> input line and open a DIV section with the response. I have also written
> some
> prototype code for that in the sources.
>
> Some page output is generated dynamically by Axiom. This needs to be
> written so it creates browser-based text rather than hyperdoc text.
>
> Removing Makefiles
>
> We currently use 'make' to build the system. But Axiom is trying to remove
> as many tools and external dependencies as possible. Each thing we remove
> is one less thing users need to pre-install and one less thing to maintain.
>
> The task would be to trace the 'make' scripts to find out the exact
> sequence
> of commands to build Axiom. These would then be written as lisp functions.
> So instead of using 'make', we start lisp and use it to build Axiom, which
> is
> a large lisp program.
>
> Some of this tracing is already done in anticipation that this rewrite will
> happen. The Makefile files are documented (and generated from) the
> Makefile.pamphlet files.
>
> Knuth, Literate Programming, and Axiom
>
> The 'pamphlet' files are raw latex files. You can just run latex on them.
> Knuth's original vision of literate programming had 2 tools, 'weave' and
> 'tangle'. The 'weave' program takes the literate sources and generates
> tex-compatible output. Axiom uses latex directly so there is no need for
> a 'weave' program.
>
> The 'tangle' program exists, called 'tanglec' in the books subdirectory.
> It takes 2 arguments, the source latex file and the name of a 'chunk'.
> It writes the chunk contents to stdout.
>
>     tanglec bookvol10.3.pamphlet "domain INT Integer" >integer.spad
>
> This will look for a chunk with the given name, e.g.
>
>    \begin{chunk}{domain INT Integer}
>         the integer.spad source code is here
>    \end{chunk}
>
> There is no real magic in the 'tanglec' program. It just reads the source
> file, makes a hash table of every chunk name (concatenating repeated
> names into a single block) and then writes out the requested chunk to
> stdout.
>
> The ultimate goal is to make every file a latex document. Most
> programs use the "pile of sand" (POS) method to organize sources.
> They try to provide "semantics" by clever directory names such as 'doc'.
>
> What they don't realize is that this is left-over technology from the past.
> I used to work on a machine with 8k, 4k of which was the operating system.
> If you created a file larger than 4k you crashed the system. So we invented
> "include" for files and "overlay linkers" (which are now virtual memory
> hardware). Comments cost bytes and were frowned upon.
>
> People STILL write 4k files and POS directories with include files despite
> having 16G of memory. They still think comments are expensive and that
> 'documentation' is worthless. We need to think of 'explanations', not
> documentation or comments. POS programming needs to die.
>
> Explanations
>
> If you cover a topic in class (e.g. CAD, Groebner, Berlekamp factoring,
> etc)
> the task would be to find the code that implements the algorithms and
> document them. This is rather more difficult than it sounds as there are
> a lot of implementation details which classes never cover but are vital.
>
> A good starting point would be polynomial algorithms. Axiom supports a
> lot of different poly representations, such as sparse/dense, recursive,
> distributed, and various multivariate versions of the same. Pick one of
> the Domains, e.g. SparseUnivariatePolynomial (SUP), discuss its
> representation in Axiom, and explain operations like 'variables',
> 'resultant',
> 'primitivePart', 'squareFree', etc.
>
> Contributions
>
> You should stress to any student that Axiom is literate. That means that
> any contribution NEEDS to focus on explanation. For a system like Axiom
> to live, it needs to be possible for people to maintain, modify, and
> extend it.
>
> The prior authors (me included) failed to explain anything. Axiom was
> originally a research project not a product so nobody cared. Unfortunately,
> now we have to re-discover how existing code works. New code can't be
> allowed to make the same mistake.
>
> I'd be happy to work with students who want to contribute.
>
> Tim
>
>
> On Tue, May 9, 2017 at 5:39 PM, Tim Daly <axiomcas@gmail.com> wrote:
>
>> No need to apologize. I know this is a busy time.
>>
>> The ultimate goal is to replace the hyperdoc/graphics with a browser front
>> end using HTML canvas for the graphics. I have made a start on this but
>> have been busy with other things.
>> (See http://axiom-developer.org/axiom-website/bookvol11.pdf)
>>
>> A possible alternative is to use the Jupyter notebook. (
>> http://jupyter.org/)
>> I have not looked into this in detail. The student is free to talk to me
>> about any ideas.
>>
>> I'm working on a syllabus for a CMU course which seems to differ from the
>> current
>> courses taught elsewhere. Almost every course spends all of its time on
>> the
>> algorithms. That's fine but it leave the topic "ungrounded". The student
>> does
>> not know how the algorithms are actually implemented and does not know how
>> to build/test/modify an existing system with new work. It's a bit like
>> teaching
>> art by looking at paintings but never mentioning 90% of the subject that
>> a real
>> artist knows, like brushes, medium, art shows, etc. It's all nice in
>> theory but
>> is ultimately pointless as the student can't use the information.
>>
>> In the ideal case the students would be part of a group that does real
>> work
>> on a real system, just as art students end up painting and entering their
>> work
>> in art shows. I'm hoping to start a "reading group" that covers papers
>> from the
>> past as well as the latest conferences. I have a set of papers on CAD
>> starting
>> with the Collins 1975 paper onward which I'm starting to organize.
>>
>> Tim
>>
>
>



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