Re: LISPPA
From: Alexander Baranovsky (ab_at_cable.netlux.org)
Date: 04/19/04
- Next message: Christopher C. Stacy: "Re: Delaunay Triangulation in Lisp"
- Previous message: Wade Humeniuk: "delete and adjustable arrays"
- In reply to: Gareth McCaughan: "Re: LISPPA"
- Next in thread: William Bland: "Re: LISPPA"
- Reply: William Bland: "Re: LISPPA"
- Reply: Gareth McCaughan: "Re: LISPPA"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 19 Apr 2004 12:04:06 -0700
First of all, thank you for your answer as it turns the discussion
into serious direction, at least.
> I'm sure it's very nice, but the only thing it has in common
> with Lisp is (1) the first four letters of its name and
> (2) the fact that it provides a way of working with sequences
> of arbitrary objects in a programming language. So I'm not
> sure why you've posted it to comp.lang.lisp.
(1) Both Lisp and LISPPA have relation to the list processing. LISPPA
uses a "classic" data structure in the imperative programming, namely
the array, for the representation of linked lists. Both directions try
to "reconcile" the functional and imperative approaches of the
programming: Pure functional Lisp introduces "imperative" concepts via
side effects, LISPPA tries to provide uniform and concise data
representation and algorithmes for the recursive data structures what
is peculiar to the functional approach. It explains the name.
(2) I hoped that the comparison of both approaches can be interesting.
> so perhaps the answer is that you think your LISPPA thing
> is going to make Lisp obsolete by providing ways to solve
> the problems Lisp is good at, while remaining palatable to
> the "majority of programmers".
No, I did not think that. However, I suppose that mentioned imperative
languages are more claimed at present time. You cannot avoid to see
it. At the same time, they have many drawbacks. I have tried to remove
one such defect.
> But there are already languages that do what your LISPPA
> does. Have a look at Python, for instance; it has "polymorphic
> arrays"
This is the second mention about Python (the first I've received in a
private email). Not only Python uses polymorphic arrays. JavaScript,
PHP and many other languages use it. In particular, there are a lot
languages which support Variant types and COM technology. I never
stated that the polymorphic array is a new concept. But, it seems, the
using arrays for the representation and processing of linked lists is
quite new idea. Indeed, in terms of the arrays we can give the simple
recursive definition of lists and binary trees. For example:
1. NULL (undefined variable) is empty list.
2. If L is a list, the one-dimensional array A with two elements A(0)
and A(1) = L is a list too.
We cannot produce such concise definition of the linked list using
standard approach based on pointers. This is the start point, further
LISPPA offers a uniform ways to process lists and other dynamic data
structures.
Please note, that the presence of polymorphic arrays in an imperative
programming language not yet provides
effective programming. A few extra conditions are required. LISPPA
uncovers a minimal set of such conditions. (In this relation, you can
take a look at the discussion about LISPPA in comp.lang.php).
> (which it calls lists, but never mind) among its
> data structures, and it doesn't require you to keep writing
> "AddressOf(...)" whenever you want to do anything non-trivial
> with them. --
Oh, I do not like AddressOf too :-) This denotation has been borrowed
from VB.NET (AddressOf denotes delegate of a function there). I'm
using AddressOf in paxBasic to denote a delegate of variable (alias).
> And yet, despite the existence of Python, Lisp
> programmers don't seem to have given up. Why might that be?
> Answer: the advantages of Lisp are *not* all about the "data
> domains" it can handle, but about the facilities it provides
> for writing powerful software efficiently and concisely.
I think the real advantages of LISPPA can be discovered after its
implementation in a compiler such as Visual Basic or Delphi. (It is
quite easy to extend well known Variant types to take into
consideration LISPPA requirements). Benefits of it are obvious, I
hope.
> LISPPA, so far as I can see, offers none of this.
Sorry, I cannot agree with it. See, for example:
http://www.virtlabs.com.ua/paxscript/demo_basic_lists.htm
http://www.virtlabs.com.ua/paxscript/demo_basic_trees.htm
http://www.virtlabs.com.ua/paxscript/demo_pascal_lists.htm
http://www.virtlabs.com.ua/paxscript/demo_pascal_trees.htm
http://www.virtlabs.com.ua/paxscript/demo_c_lists.htm
http://www.virtlabs.com.ua/paxscript/demo_c_trees.htm
http://www.virtlabs.com.ua/paxscript/demo_js_lists.htm
http://www.virtlabs.com.ua/paxscript/demo_js_trees.htm
> Random example: your symbolid differentiation program has
> a function called "InOrder" that produces an infix
> representation of an expression. It's 30 lines long.
> In Lisp it would say [danger: untested code!] ............
The function is written bad, I can accept it. But it is not a typical
example. I think more interesting example is Compress procedure which
allows you to compress a sub-tree of a tree without having to relocate
the whole tree in each act of the compression. The body of the
procedure is not short, but quite uniform and clear for understanding.
I do not think that you will use less number of lines to express the
same in Lisp.
Besides you might take a look at the source code of the theoprem
proving program in paxBasic
http://www.virtlabs.com.ua/paxscript/demo_basic_theorem.htm
or in paxPascal
http://www.virtlabs.com.ua/paxscript/demo_pascal_theorem.htm
and compare this code with source code presented in book Chang C.L and
Lee R.C. "Symbolic Logic and Mechanical Theorem Proving". Then you can
conclude what of codes is more suitable for understanding.
I do not discuss representation of algorithmes of linear algebra :-)
Finally, the ancients spoke: "If two man do the same thing, it already
is not same thing". I think that alternative approaches are always
useful for the consideration. Not?
A.
Gareth McCaughan <gareth.mccaughan@pobox.com> wrote in message news:<8765bw46m4.fsf@g.mccaughan.ntlworld.com>...
> ab@cable.netlux.org (Alexander Baranovsky) writes:
>
> > LISPPA (List Processing based on the Polymorphic Arrays) technology
> > provides a way to process dynamic data structures (lists, trees and
> > more) without using pointers. LISPPA uses polymorphic arrays as a base
> > of the data representation.
> ...
> > http://www.virtlabs.com.ua/paxscript/lisppa.htm
>
> I'm sure it's very nice, but the only thing it has in common
> with Lisp is (1) the first four letters of its name and
> (2) the fact that it provides a way of working with sequences
> of arbitrary objects in a programming language. So I'm not
> sure why you've posted it to comp.lang.lisp.
>
> Now, you've said
>
> | I know only one answer: the imperative approach and such languages as
> | Pascal, Basic C or Java are more attractive for majority of
> | programmers.
> |
> | You will answer me: "The success is not a good reason. There are a lot
> | data domains where the imperative approach is not applicable". My
> | answer is: LISPPA.
>
> so perhaps the answer is that you think your LISPPA thing
> is going to make Lisp obsolete by providing ways to solve
> the problems Lisp is good at, while remaining palatable to
> the "majority of programmers".
>
> But there are already languages that do what your LISPPA
> does. Have a look at Python, for instance; it has "polymorphic
> arrays" (which it calls lists, but never mind) among its
> data structures, and it doesn't require you to keep writing
> "AddressOf(...)" whenever you want to do anything non-trivial
> with them. -- And yet, despite the existence of Python, Lisp
> programmers don't seem to have given up. Why might that be?
> Answer: the advantages of Lisp are *not* all about the "data
> domains" it can handle, but about the facilities it provides
> for writing powerful software efficiently and concisely.
> LISPPA, so far as I can see, offers none of this.
>
> Random example: your symbolid differentiation program has
> a function called "InOrder" that produces an infix
> representation of an expression. It's 30 lines long.
> In Lisp it would say [danger: untested code!]
>
> (defun prefix->infix (x &optional (lparen "(") (rparen ")"))
> (cond
> ((atom x) (write-to-string x))
> ((= (length x) 2)
> (case (car x)
> ((-) (format nil "~A-~A~A" lparen (prefix->infix (second x)) rparen))
> ((log) (format nil "log(~A)" (prefix->infix (second x) t)))))
> (t (format nil "~A~A~A~A~A" lparen
> (prefix->infix (second x))
> (first x)
> (prefix->infix (third x))
> rparen))))
>
> That's 40% the length of yours. (Actually, in Lisp we'd
> take advantage of the fact that this stuff is so much less
> painful and write it differently so that it didn't have
> to do so much copying of strings.) Your "InOrder" function
> has some code in it that's meant to turn "A+-B" into "A-B",
> but it doesn't actually work (there's no way what you've
> called RR can ever begin with "-") so I haven't felt it
> necessary to copy it.
>
> Another random example: all those functions like IsPower, which
> (1) occupy 6 lines each in your code and would be 2 lines each
> in Lisp and (2) wouldn't actually be needed in a Lisp implementation,
> for reasons related to the fact that Lisp isn't stuck with purely
> "procedural" code. You talked about "data domains"; procedural
> programming is unsuitable for this application because of the
> nature of the *algorithms*, not the *data*.
- Next message: Christopher C. Stacy: "Re: Delaunay Triangulation in Lisp"
- Previous message: Wade Humeniuk: "delete and adjustable arrays"
- In reply to: Gareth McCaughan: "Re: LISPPA"
- Next in thread: William Bland: "Re: LISPPA"
- Reply: William Bland: "Re: LISPPA"
- Reply: Gareth McCaughan: "Re: LISPPA"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
