RE: [Axiom-developer] RE: Cast = pretend in Spad/Aldor?

[Bill Page]

On November 21, 2005 4:48 PM I wrote:

> 
> It is pretty clear in the following example that the Axiom
> interpreter does something odd:
> 
> (1) -> I:Integer
>                                                 Type: Void
> (2) -> F:Float:=1.0
> 
>    (2)  1.0
>                                                 Type: Float
> (3) -> I := F pretend Integer
> 
>    (3)  1()
>                                                 Type: Integer
> ... 
> In the mean time we can certainly apply these same ideas to
> Spad and to the Spad-like programming language embedded in
> Axiom's interpreter.
>
> Gaby wrote:
> > Bill Page wrote:
> > | Yet the ability to use 'pretend' is critical to the concept
> > | of representation in the construction of Axiom domains.
> > 
> > Indeed.
> > 
> > | For a perhaps overly abstract discussion of this see:
> > | 
> > | http://wiki.axiom-developer.org/RepAndPer
> > | 
> > | So my question is: Does this feature of the Spad and Aldor
> > | languages actually make them "weakly typed"?
> > 
> 
> > In my mind "pretend" by itself does not make the language "weak
> > typed".  It would make it so only if it "actively support" type
> > unsafe operations to be carried on with minimal effort -- in that
> > sense I would claim C is weakly typed.  Notice here that my used
> > of "type safety" is not in a universal sense, but relatively to
> > Aldor's own semantics.
>
> Ok, so my example above from the Axiom interpreter (this is not
> what happens in Spad and Aldor) would be such an example of
> failure of type safety, right?

Here is the unhappy result of using 'pretend' this same way in
Spad:

(1) -> )sys cat cast.spad

)abbrev package CAST cast
cast(): exports == implementation where

  exports == with

    cast1: Integer -> Float

  implementation == add

    cast1(i:Integer):Float ==
      j:Float := (i pretend Float)

(1) -> )compile cast.spad
   Compiling AXIOM source code from file
      /home/page/cast.spad
      using old system compiler.
   CAST abbreviates package cast
...
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
Finished compiling /home/page/axiom/CAST.NRLIB/code.lsp.
------------------------------------------------------------------------
   cast is already explicitly exposed in frame initial
   cast will be automatically loaded when needed from
      /home/page/CAST.NRLIB/code

(1) -> cast1(1)$CAST

   >> System error:
   Caught fatal error [memory may be damaged]

(1) ->

-----------

The same thing happens with Aldor:

(1) -> )sys cat casta.as
#include "axiom"
cast2(i: Integer): Float == {
      j:Float := (i pretend Float)
}

(1) -> )compile casta.as
   Compiling AXIOM source code from file /home/page/casta.as using
      AXIOM-XL compiler and options
-O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom -Y
$AXIOM/algebra
      Use the system command )set compiler args to change these
      options.
#1 (Warning) Deprecated message prefix: use `ALDOR_' instead of `_AXL'
   Compiling Lisp source code from file ./casta.lsp
   Issuing )library command for casta
   Reading /home/page/casta.asy

(1) -> cast2(1)

   >> System error:
   Caught fatal error [memory may be damaged]

---------

As you can see we do not get a compile time errors, but we
do get a run-time errors.

By your criteria above then, would you agree that this
example proves that both Spad and Aldor are in fact weakly
typed or type unsafe?

Or do I have to be more careful to define clearly what are
the Spad and Aldor semantics for the example code before I
can make such a claim?

Regards,
Bill Page.