login  home  contents  what's new  discussion  bug reports     help  links  subscribe  changes  refresh  edit

Edit detail for LanguageDifferences revision 15 of 15

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Editor: hemmecke
Time: 2019/12/04 10:33:06 GMT+0
Note:

changed:
-    is the same as
    is the same as::

As mentioned on FriCASProgramming, there are a number of languages connected to PanAxiom. Since for actual users only 3 of them are relevant, namely, "Spad":FriCASCompiler, the "FriCAS interpreter":FriCASInterpreter language, and "Aldor":AldorForAxiom?, we are going to list here a number of differences.

The main difference between Aldor/Spad and the interpreter language is that the interpreter language is more relaxed with respect to types. As a first iteration one could say that the interpreter language is identical with Spad plus a mechanism that throws in coercion functions in places where they make sense. This mechanism is, however, a heuristics. It sometimes does a coercion at the wrong moment so that eventually the computation will not succeed for seemingly non-obvious reasons.

In fact, these coercions are helpful for people that come from typeless computer algebra systems. Neither Spad nor Aldor do such automated coercions. For serious library writing it is a good thing to be explicit about type coercions. The flow of computation should be predictable.

There are other small differences. For example, you can use the keyword rule in the interpreter like:

rule log(x) + log(y) == log(x * y)

but that form is not available in Spad or Aldor. You would have to call the corresponding library functions more explicitly.

Currenly in FriCAS interpreter and Spad compiler share the first stage. Conseqently Spad and intepreter keyword are almost the same, the difference is that the Spad compiler treats words rule and default as ordinary identifiers. Also, the Spad compiler does not form piles in some cases where intepreter would make them. For exmaple:

my_list : List Integer := [ 1,  2,  3,  4,  5,
                            6,  7,  8,  9, 10,
                           11, 12, 13, 14, 15]

works producing a list in Spad, but leads to parse error due to unwanted piles in the interpreter.

Differences between Aldor and Spad

  • Aldor has the type Generator, Spad has not.
  • delay is a (unused and reserved) keyword in Aldor but not in Spad. Rather it is a function name in the Axiom library.
  • In Spad anonymous functions can omit types when the type is determined by context, like x +-> x^2. Aldor requires explicit types, like (x : Integer) : Integer +-> x^2.
  • In Spad if a function is declared, then definition can omit types. Aldor requires to repeat the types.
  • Spad has singleton types: string is treated as a name of type with single element. This does not work in Aldor.
  • Aldor programs can be written in ordinary mode with braces and semicolons or in pile mode (which must be introduced via the compiler directive #pile) Spad is written by default in pile mode, but allows to introduce a (not always equivalent to Aldor) brace-mode by introducing it with
)nopile.
  • Compiler directives start with # in Aldor and with ) in Spad.

  • Each domain/package/category has to be abbreviated via the )abbrev directive in Spad. In Aldor that is not necessary.

  • In Aldor the representation Rep is defined as a constant, i.e., one writes something like:

    Rep == Record(re: Integer, im: Integer)
    

    whereas in Spad one has to write:

    Rep := Record(re: Integer, im: Integer)
    

    i.e., like a variable assignment or:

    Rep ==> Record(re: Integer, im: Integer)
    

    i.e. as a macro definition.

  • The meaning of == in Aldor is: assignment of a constant. In Spad == means delayed assignment.

  • In Aldor, one must properly use rep and per to convert between the types % and Rep. In Spad, this is not always necessary. This is one of the places where Spad throws in some mild form of automated coercion.

  • Spad uses an apostroph to introduce a symbol:

    op := operator 'X
    

    In Aldor, the apostroph is reserved, and used for the Enumeration type, i.e.,:

    Foo == Enumeration(f1: Type, f2: Type, f3: Type)
    

    is the same as:

    Foo == 'f1, f2, f3'
    
  • Aldor allows to extend a domain D by a category C like this:

    extend D: C == add {...}
    
  • (syntactic sugar) Aldor uses bracket whereas Spad uses construct, i.e., [a,b,c]? is translated to bracket(a,b,c) and construct(a,b,c), respectively.

  • The category defaults are given in Aldor like this:

    C: Category == with {
       ...
       default { ... }
    

    whereas in Spad they are written with the add keyword:

    C: Category == with
      ...
      add
        ....
    
  • Aldor has exception handling. In Spad there is no way to specify exceptions. However, in FriCAS it is possible to catch all exceptions (errors) via try finally pair:

    try
        do_something()
    finally
        cleanup()
    

    ensures that cleanup is run regardless of errors.

  • Aldor knows the builtin types Cross, TrailingArray?, Literal, which are not in Spad.

  • In Spad and Aldor one can use multiple assignment like this:

    (a, b) := (b, a)
    

    But only Aldor allows to write a function that returns a multi-value, i.e.,:

    foo(x: Integer): (Integer, Integer) == (x, 2*x);
    
  • Spad and Aldor behave differently with respect to syntactic sugar. While in Spad one can define (for example for a data structure:

    elt(x: %, i: Integer, s: String): SOMETYPE == ...
    setelt!(x: %, sy: Symbol, val: VALUETYPE): VALUETYPE == ...
    

    and then use it like:

    struct: STRUCTURE := ...
    t: SOMETYPE := struct(3, "blah")
    sym: Symbol := "y" :: Symbol
    struct.sym := v
    

    one must define the respective equivalents in Aldor by the names apply and set!, i.e.,:

    apply(x: %, i: Integer, s: String): SOMETYPE == ...
    set!(x: %, sy: Symbol, val: VALUETYPE): VALUETYPE == ...