> From: Xah Lee <x...@[EMAIL PROTECTED]
>
(second part of reply:)
> Jargons And High Level Languages
> http://xahlee.org/emacs/jargons_high_level_lang.html
> ... a ideal high level language. ...
"a" should read "an". Please correct your Web page.
> my wishes are:
> The language will be absolutely high-level, meaning in particular:
o The language's do***entation, will not need to have mentioning any
of the following words: pointer, reference, memory allocation, stacks,
hash, cons cells, linked list, circular list.
Although "pointer" and "reference" with the specific meaning used
in C++ should be avoided, I see no reason to deny the application
programmer knowledge of the difference between linked records and
embedded/sequential records. When writing an algorithm to deal with
a very large amount of data that won't all fit in RAM at the same
time, forcing the programmer to deal with page faults and/or
explicitly-coded disk access to load data as-needed, it's essential
that the programmer have control over making sure that groups of
records are in contiguous memory (so that at most two page faults
are needed) rather than strung out over many pages (requiring as
many page faults as there are pages occupied by the different
blocks of data in the linked list).
It's considered implicit that when an object is instantiated, some
memory is allocated, and when it's either disposed (C++ style) or
garbage collected (LIsp/Java style) that memory is freed for other
subsequent use. It's not acceptable that programmers haven't the
slightest concept of how memory allocation is used by their
application, hence there's nothing the programmer can do to
alleviate memory leaks/bloat and other problems that might cause
extremely slow operation or an outright crash of the application.
Stacks are an essential part of many algorithms. Denying an
application programmer the use of built-in stack features forces
the programmer to emulate stacks via his own arrays, which is a
step backward toward coding in assembly language. I find that to be
unacceptable.
Consider for example the task of writing a recursive descent parser
without the ability to manipulate any stack whatsoever.
Hashs are one of several ways to implement an associative array
(lookup table, mapping key to value). Sorted arrays (using binary
search to find a key), and balanced binary trees (using traversal
down left-or-right sub-tree to find a key), are two other ways.
Each technique has its own advantages and disadvantages. IMO any
application programmer should be allowed to choose the appropriate
technique for his particular application, which requires "hash"
etc. to be mentionned somewhere in the do***etation.
Instead of "cons cells", would you accept the term "linked-list
cells", or perhaps "standard pairs", or "binary cells", or some
other term which avoids the Lisp jargon yet still indicates the
existance of such a cell with exactly two pointers to other objects??
Why not mention linked list? That is an essential ADT for many
applications. Do you plan to deny every application programmer that
built-in feature, or confuse the programmer by calling it something
else?
Circular lists are not common enough that they absolutely need to
be included in the do***entation for the language. But occasionally
they are useful. So do you propose to make it clear what primitives
are available that might be used for building circular lists, or
deny any ability whatsoever to create any circular list?
o The language will not have concept of binary bits, bit operator,
bytes, etc. (see the optimization section below) (However, the
language can (and should) sup****t computing with arbitrary number
basis, and when the basis is 2, the compiler should of course
automatically map it to bits on a chip as its method to achieve speed)
What do you mean by "number basis". Are you having trouble with
English, and you really meant to say "number base" i.e. "radix"?
I believe you're confusing two concepts:
- Number base used to represent arbitrary integers, whereby each
position to the left is weighted base times the old weight.
- Arrays of enumeration objects, whereby each element in the array
can hold just a fixed finite number of different objects but the
elements all have the same weight.
For example, '49' represents fourty-nine (seven times seven)
under the first concept (if base is ten), but merely represents the
vector (list) [Yellow, White] under the second concept (if the
enumeration is
{Black|Brown|Red|Orange|Yellow|Green|Blue|Purple|Gray|White}).
o The language's computational model should be simple, high-level,
mathematics based as possible, as opposed to being a model of some
abstract machine, implementation, or computational model ...
In mathematics, everything is constant, only our meta-knowledge
*about* mathematical fact changes over time as we
discover/learn/prove additional facts. Such a mathematical model is
totally inappropriate for most data/processing tasks, where things
actually change over time, such as the number of refrigerators in
the warehouse decreases whenever one is purchased and increases
whenever a delivery from the wholesaler happens. It is completely
unacceptable to model this as a mathematical function of time,
where everything that is ever going to happen in the future is
already encompassed in a pre-established **FATE** function that we
can incrementally learn about but do nothing to affect.
The language's syntax and semantics should be as much as consistent
and regular as possible.
Agreed. Lisp is better than most languages. The basic structure of
the language is:
<list> ::= <atom>
<openParens> <list>* <closeParens>
About the only use of special characters is for commonly used types
of literal constants (such as strings/numbers/characters) and shorthand
to avoid repetitive typing (such as #' to denote wrapping FUNCTION
around something).
> For example lisp's syntax would be considered not acceptable
> here. (it has "' # ;" and various ad hoc irregularities)
' is shorthand for wrapping QUOTE around something.
Nobody is forcing you to use that!! It's a *convenience* for people
who would rather type fewer characters than (QUOTE (RED GREEN BLUE)).
# is a multi-purpose way to generate character constants and shorthand
for wrapping FUNCTION around something etc.
For example, nobody is stopping you from saying:
(defconstant charComma (code-char 44))
and then using charComma instead of #\, throughout your program.
(I avoided the $ around the name of the global because you don't
like special characters?)
Except for read-time or load-time execution (#. and #,
respectively), is there any other use of # that you feel is
absolutely needed the way Common Lisp is currently defined?
Surely feature conditionals (#+) can be replaced by simply
distributing different source files for each target environment.
> As another example, Common Lisp's multi-meaning names would be
> considered ah hoc irregular semantics here. (i.e. a symbol can be a
> variable as well as a function).
IMO this is an absord complaint. An ordinary (not keyword) sumbol
in Common LIsp has more than just two purposes:
- Can be bound to a function.
- Can be bound to a value.
- Can have a property list.
- Always has a print name, by which it can be read and printed.
Do you honestly feel that each of those four purposes should
require a different type of object?? If not, why should value and
function be split apart, whereby the same symbol can't have both??
Or do you propose even further that each symbol be allowed to have
exactly one of those first three purposes, never two?
Or do you propose that there are different kinds of symbols, with
each having a distinct syntax, for example if the first character
of the symbol's name is F then it can be used only as the name of a
function, and if the first character of the symbol's name is V then
it can be used only as something with a value, and if the first
character of the symbal's name is P then it can have only a
property list?
o The language's variables must not have types. Its values can have
types.
So you'd forbid all compiler declarations that optimize code that
deals with variables that never have any but a single type of
value? So you'd force all Lisp code to run as slow as necessary to
be capable of handling all possible data types even where only a
single data type will ever be used?
o The numbers in the language can have the following types: integer,
rational, real, complex number. (and possibly extension from these,
such as algebraic number, etc.)
That's not possible. It requires an infinite amount of data to
specify a single arbitrary real number, and it's impossible for
anything in the physical world to store even one such value.
You really need to re-think your essay.
Will you accept as an alternative a number representation which
gives an interval (upper and lower bound) on a real number, thereby
specifying an uncountably infinite set of possible reals within
that interval? Each endpoint of that interval could then be a
rational?
|
