Re: [Axiom-developer] RE: Mathaction edit/preview/save problem

[William Sit]

William Sit wrote:
> 
> Sorry, it was the Firewall setting. I set the Internet Zone to High and it
> blocked sending data from my computer. Setting it to Medium works. (However,
> that is only for the Mathaction site. I have no trouble sending data, 
> uploading
> etc to other sites with setting on High. So it is probably some special java
> applet that was blocked.)
> 
> I am using the EZ Firewall Lite from Computer Associates (it is like 
> ZoneAlarm).
> 
> Thanks for helping to diagnose the problem.

Well, not quite. it only worked on the Sandbox page, where I was able to submit
an edit for the MainPage (I entered "What is this?"). In fact that page worked
(Preview/Save) even with the security setting on High.

But when I tried to edit the DynamicFunctionDomains, it still says "This page
cannot be displayed".  

This is not intermittent. Every time. It's not a DNS problem because I can click
on to any link on the page and it displays. I just added Hello to the Sandbox
MainPage. I went right to the DynamicFunctionDomains and change (4,7) to (4,8)
and click preview. Then it stalls and same problem.

It seems to be a write privilege denied type of problem to me.

William
---
Bill, here is new page to replace the current one.

On Wednesday, January 12, 2005 12:00 PM you wrote:
Ralf Hemmecke wrote:
 
Well, I haven't checked whether it should really work, but
shouldn't:
 
 Foo: with {
    g: (n: PositiveInteger, k: PositiveInteger) ->
       (P: PrimeFieldCategory, x: P)
 } == add {
    g(n: PositiveInteger, k: PositiveInteger ):
     (P: PrimeFieldCategory, x:P) == {
     (PrimeField(n), k::Integer::PrimeField(n)
    }
 }

be even better? 

Later William Sit wrote:
 
In fact you just pointed out a way to solve the problem! Notice 
that you are in effect constructing a domain! So first create
this domain (call this anything else you like)

\begin{axiom}
)abbrev domain PPF PointedPrimeField
--%PointedPrimeField
PointedPrimeField(n:PositiveInteger):Cat==Dog where
  Cat == FiniteFieldCategory with
    foo:PositiveInteger->PrimeField(n)
  Dog == PrimeField(n) add
    foo(k)==k::Integer::PrimeField(n)
\end{axiom}

After compiling, define in the interpreter

\begin{axiom} 
g(n,k)==foo(k)$PPF(n)
g(7,4)
\end{axiom}
 
and it works (in Axiom)! (Do not declare the types
for g because n is not defined).

Compiling g is still a problem in Axiom due to
signature limitation. At least this way, inlining
a complicated function is almost like a function call.

The idea is: Since in creating domains (or any other
types of constructors), we are in effect creating a
function(the domain constructor PPF is a function of
sort, or functor) and the compiler can take dependent
types in its signature,structurally::

  PPF(n:PositiveInteger)==PrimeField(n) with foo

so it should be able to compile something like g by
lifting it to the package level.

So here is another way using package.

\begin{axiom}
)abbrev package FOO Foo
--%Foo
Foo(n:PositiveInteger, k:PositiveInteger):T==C where
  T == with
       point:()->PrimeField(n)
  C == add
       point()==k::Integer::PrimeField(n)
\end{axiom}

After compiling, we can use::

  point()$Foo(n,k)

in any computation in compiler code (and in interpreter). 
\begin{axiom}
)abbrev package BARTEST Bartest
Bartest: T==C where
   T == with
        barrun: () -> Void
   C == add
        import FOO
        barrun() ==
          for k in 4..5 repeat
            for n in [1,2,4,6]::List PositiveInteger repeat
              print(point()$Foo(n+1,k)::OutputForm)$PrintPackage
\end{axiom}

\begin{axiom}
barrun()
\end{axiom}

Still can't call this bar(n,k) even if you use a macro expansion:

\begin{axiom}
bar ==>point()$Foo
bar(4,7)
\end{axiom}

In compiler version (as probably the same in the interpreter version), 
the macro is expanded and parsed before attaching (4,7). bar(n,k)
would be parsed in lisp code as

   ((|elt| |Foo| |point|)) |n| |k|

but should be

   ((|elt| (|Foo| |n| |k|) |point|))

for the macro to work.

The package version does not sacrifice the mathematical type structure of the
original example that Martin proposed:

   g(n:PositiveInteger, k:PositiveInteger):PrimeField(n)

It reflects exactly the same structure with the exception that there is no
signature used and g(n,k) is replaced by the longer name
point()$Foo(n,k) as illustrated in the Bartest package. Aldor is
nicer because it allows that, so that such a wrapper is not necessary. But the
wrapper is straightforward and general and can even be automated.


Can someone give an example where the *signature* of bar::

  bar: (n: PositiveInteger, k: PositiveInteger) -> PrimeField(n)

is actually needed?