[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: root
Subject: Re: [Axiom-developer] RE: Cast = pretend in Spad/Aldor?
Date: Tue, 22 Nov 2005 16:47:01 -0500

ultimately i think the issue comes down to this: i'm a primitivist
by nature and expect programmers, like myself, to know EXACTLY what
the machine will execute when i use high level languages like spad,
lisp, or haskell. (and to send email by tapping on the correct wire pair
in an ethernet cable with a battery.) i "understand clearly what is
involved in the abstraction of types in high level languages" as i've
implemented several languages, 4 of which were sold commercially and
i've been involved in endless language "feature" discussions.

your approach to programming "from the other end of the telescope"
tends to view the machine as a distant abstraction and expect
programming languages to properly support their abstractions in all
their various nuances. thus, you expect that

   type-thing :=               other-type-thing
   type-thing := (cast)        other-type-thing
   type-thing := (coerce)      other-type-thing
   type-thing := thing pretend other-type-thing

to "do the right thing" and i tend to run (disassemble) to figure
out what it ACTUALLY does on the machine. i'd have to be smoking
guano in a batcave before i'd even think to code

    int-i := (cast int) float-f

as this is fundamentally "lying" to the machine. (cast a 747 to
an "airplane" and you can land it on any runway). 

if you approach a language with the expectation of "closed semantics"
(that is, everything you write is well defined) you'd expect the
previous statement to mean something. by nature i tend to expect
languages to have "open semantics" where not everything you can
write has meaning and a native speaker of the language will only
write meaningful statements.

so when you write:

> Axiom is supposed to support strong static typing. This would not
> be true of it where necessary to know exact internal representations
> in order to use fundamental simple constructs in the language.
> When I write 'F pretend Integer' it should mean something that
> can be expressed in the Axiom programming language without
> reference to the internal representation.

we're never going to see eye-to-eye because there is a telescope
between us. your view is clearly correct but only if you start with
your programming assumptions. Axiom DOES support strong static typing
but (at least in my view) it isn't a closed semantics language so
sometimes you have to know the internals. in your view the primitive
domains would export operations that hide the implementation,
fully support the abstractions and have closed semantics.

i can build facade patterned structures using agent-based communication
among network distributed backends in a functional programming language 
specified with full denotational semantics but i still need to know what's 
on the call stack.

ultimately you want to appeal to the documentation to see what a language
construct means. i kneel before the altar of the machine and see what it

   A pretend B

is "knowledge-based lying" in my view and strong static typing in yours.

our axioms of what it means to program differ and thus our views differ.


ps. i liked programming in high school. the wang mini with the
hand-punched "toaster" card reader kicked ass. :-)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]