> From: Jon Harrop <use...@[EMAIL PROTECTED]
>
> I think you're explaining why CL has things from Xah's list of
> things that he does not value, e.g. Mathematica lacks many of the
> features that Xah enumerated.
As I said, his wording was clear as to why he said "... jargons,
really have _little_ significance to daily practice", since he
included some really essential features I use all the time. Was he
saying daily practice fails to use these wonderful features because
people treat those features with undue disrespect, or because he
(Xah) disrespects them himself and is saying they aren't needed (in
his opinion)? Is he a total idiot who can't understand why closures
and a few other things are generally useful in programming? I was
giving him the benefit of doubt that he was saying that normal
Programming Dummies aren't using those good features, rather than
that those features aren't good in the first place.
By the way, one of the most common uses for closures is to curry
(freeze) one or more of the parameters to a function so that it can
be passed to map the one remaining parameter down a list:
For example: constant c, and list l, lexically visible here:
(mapcar #'(lambda (x) (+ x c)) l)
> It is interesting to me, but probably not to Xah.
Closures *should* be interesting/useful to just about *anyone*
wanting to write serious software.
> > ... in recent years I have been advocating a system for
> > drawing a dataflow diagram for interval arithmetic where lazy
> > evaluation is used to compute approximate intervals narrower and
> > narrower as needed to produce a meaningful decision/output. The
> > general idea is to use a mathematical identity to yield a directed
> > computation which forms a stable feedback loop. For example, given
> > N known non-negative, you compute the square root of N via Newton's
> > method expressed as a feedback loop. Whenever you need to narrow
> > the interval, you track the dataflow backwards until you reach a
> > place where you can get more accuracy, then you compute forwards
> > again to see how narrow your output interval is now. ...
> Ironically, Mathematica already does that (and it is a good idea, yes).
:-)
Double irony that they don't even sup****t recursion. It must take
some presence of mind to make sure you never do recursion when
backtracking dataflow around a loop during lazy evaluation!
Do you know what this is *called* there, so that I can do a Google
search to find a description of their methodology to compare with
my own ideas? Trying Google anyway: Mathematica interval arithmetic
dataflow
Did you mean: Mathematica interval arithmetic data flow
CONDOR: Constraint-Based Dataflow
Is that it?
Processor with reconfigurable arithmetic data path - Patent 6247036
Beware of dog!!
That Google search didn't turn up anything vaguely like what we're
talking about. What keyword to search for??
> I assume Xah is referring to pattern matching over algebraic datatypes.
I don't even know what that means!
> Note that Mathematica doesn't implement tail calls and (probably)
> doesn't even implement mutual tail recursion.
Did you miss the note that it doesn't sup****t recursion at all?
> >> call-with-continuation
> > I'm not familiar with that jargon, but it sounds like something to
> > do with co-routines. I'll do a Google search ...
> Callcc can be useful and is missing in all of the languages I use
> (and Common Lisp).
Google search for: Callcc
<http://en.wikipedia.org/wiki/Continuation>
The remarks about continuation-style programming possibly being
useful for the Web (to avoid needing to explicitly write algorithms
as state machines to achieve inverted control) is interesting.
http://en.wikipedia.org/wiki/Call-with-current-continuation>
Taking a function f as its only argument, call/cc reifies the current
continuation (i.e. control context or control state of the program) as
an object and applies f to it. ...
Let's see if I understand that: The only kind of function that can
be passed to call/cc is one that takes exactly one parameter, and
that one parameter is the passed state-of-computation object, right?
So if you want to pass a function with actual parameters other than
the state-of-computation, you need to curry all those other
parameters first, then pass the resultant zero-parameter (except
state-of-computation parameter) function as f, right?
So Scheme (the pragramming environment we're talking about) doesn't
keep the program-state as a first-class citizen all the time it
runs, rather call/cc does an introspection of the (efficient)
program state to *construct* the first-class-object representation
of it to pass? But how does that representation of a program state
ever get converted back to an actual (efficient) program state to
allow continued running from there? Is it essentially an emulation
of threads, where sometime later somebody says "hey, let's pick up
that process where it left off" and converts the object back to the
actual machine state? If so, why not just use threads, which are
well sup****ted in several modern programming languages?
> In the context of general-purpose programming, Mathematica's
> standard library is grossly deficient. For example, you cannot
> create efficient implementations of any tree-based data structures
> (RB, AVL, finger trees etc.).
Ah, this is why I chose your article for a response!
What primitives are missing from Mathematica that cause this
deficiency? Is it that ordered pairs (like CONS cells, or Java's
arrays of class Object *1*) are entirely missing? Or that you *can*
make ordered pairs if you want, but the storage and processing
overhead per pair is much larger than in Lisp, perhaps as bad as if
you had to use a Java instance of class Vector for *each* ordered
pair, and go through the entire object-oriented dispatch every time
you did the equivalent of CAR or CDR or SETF thereof?
*1* Something like this perhaps:
public static Object[] CONS(Object car, Object cdr) {
Object[] newCell = new Object[2];
newCell[0] = car;
newCell[1] = cdr;
return newCell;
}
public static Object CAR(Object cell) { return cell[0]; }
public static Object CDR(Object cell) { return cell[1]; }
|
