something to chat about, lisp and Mathematica for list processing.
Nasser Abbasi
language-war topic :) (dont you love these topics?)
Lisp was one of the earliest programming languages I fell in love with, I
guess because I was fascinated with studying AI then (the language before it
was Fortran, and after lisp I fell in love with Pascal, then ...etc.)
But I have not used lisp for many many years now.
From http://en.wikipedia.org/wiki/Lisp_programming_language it says : The
name Lisp derives from "List Processing".
And now I am using Mathematica more (for school work), and saw this in
Mathematica docs:
"Widely recognized as the world's most powerful list manipulation language,
Mathematica ..."
Topic for discussion: From only the list processing/manipulation point of
view, and nothing else, what would you consider the advantages/disadvantages
of one over the other?
I am sure by now, any kind of list processing task that can be done by one
language, most likely can just as well be done in the other.
So the question is not really asking about syntax or how many extra key
strokes needed to do the same list 'manipulation', but more along the lines
if there exist something inheritably more advantages of one language over
the other *when it comes to list processing*. I think one can argue than too
many [[[[[ ]]]]]] are harder to read than ((((( )))))) and I would probably
agree, but I remember also when I programmed in lisp I had problems making
sure the closing )))) matched the starting (((((, any way...I am thinking
more along the lines of a language design issues related to list processing
which might make one more suited for list processing than another.
May be someone here has more insight into both and educate us.
Nasser
dimitris
What was so boring this weekend?
Forgive me but I can't find a specific boring
issue in this forum the current week.
Of course I speake on behalf of myself.
Which you don't do in your message.
So If you are bored, it's ok!
But do not make generalizations.
If you are not interested in one thread, simply
do not participate in.
Otherwise, make your own forum, where you could be
the moderator of it and "cut" what posts...make you bored!
With kind regards
Dimitris
/ Nasser Abbasi :
Nasser Abbasi
"dimitris" <dimm...@yahoo.com> wrote in message
news:1182019018.3...@m36g2000hse.googlegroups.com...
> >I thought everyone was bored this weekend...
>
> But do not make generalizations.
> If you are not interested in one thread, simply
> do not participate in.
> Otherwise, make your own forum, where you could be
> the moderator of it and "cut" what posts...make you bored!
wow!
For someone who seems smart in math, you did not even see the sense of humor
in that statement that "every one seems to be bored"?
Amazing.
Sorry you feel I insulted you by even suggesting you might be bored.
It was tongue in cheek statement, you do not get it? what is the big deal
any way?
You skipped the whole topic only to take time for this silly childish reply?
You must be really bored then :)
Nasser
Vladimir Bondarenko
NA> I thought everyone was bored this weekend...
Me, especially...
Some Bondarenko throws new and new bug data about Mathematica,
Maple... why he couldn't write something else... something
different... say about bugs in some other systems?
Bondarenko, what a crashing bore you are... I am upset and
much bored with your topics... or better say *the* topic.
My only hope that you could go straight... if not soon but
maybe one fine day...
> "dimitris" <dimmec...@yahoo.com> wrote in message
Daniel Lichtblau
> I thought everyone was bored this weekend, so I am strating a new
> language-war topic :) (dont you love these topics?)
>
> Lisp was one of the earliest programming languages I fell in love with, I
> guess because I was fascinated with studying AI then (the language before it
> was Fortran, and after lisp I fell in love with Pascal, then ...etc.)
>
> But I have not used lisp for many many years now.
>
> name Lisp derives from "List Processing".
>
> And now I am using Mathematica more (for school work), and saw this in
> Mathematica docs:
>
> "Widely recognized as the world's most powerful list manipulation language,
> Mathematica ..."
>
> Topic for discussion: From only the list processing/manipulation point of
> view, and nothing else, what would you consider the advantages/disadvantages
> of one over the other?
>
> I am sure by now, any kind of list processing task that can be done by one
> language, most likely can just as well be done in the other.
>
> So the question is not really asking about syntax or how many extra key
> strokes needed to do the same list 'manipulation', but more along the lines
> if there exist something inheritably more advantages of one language over
> the other *when it comes to list processing*. I think one can argue than too
> many [[[[[ ]]]]]] are harder to read than ((((( )))))) and I would probably
> agree, but I remember also when I programmed in lisp I had problems making
> sure the closing )))) matched the starting (((((, any way...I am thinking
> more along the lines of a language design issues related to list processing
> which might make one more suited for list processing than another.
>
> May be someone here has more insight into both and educate us.
>
> Nasser
I'm not going to address the main question but rather discuss some
underlying issues. I'll state in advance that this is my opinion only,
not necessarily shared by my employer.
Mathematica "lists" are akin to what might be called, arrays, vectors,
or tables elsewhere. Lisp lists are linked lists. These are very
different from the point of view of data structures and algorithms
thereon. Certainly I think Mathematica does wonderful things with its
List expression (and pretty much all other expressions). But a linked
list is, in my view, something that relies on the notion of a
"pointer" in order to be implemented and behave in a reasonable way.
This is something that one can emulate in various ways in Mathematica,
but the behavior is not always as good as might be desired.
Compounding this, I think, is the Mathematica notion of "infinite
evaluation". Some methods of linked list emulation might have
asymptotic complexity misbehavior due to reevaluation attempts that
might not be forestalled in all cases where they ought.
To an extent this might address the actual question. Mathematica is
good at working with its List structure. It is less proficient, though
by no means unable, to handle emulation of the sort of linked list
structure of Lisp.
Caveat: I last used Lisp more than 30 years ago. If I got it all
wrong, in the words of Ruth Buzzy, "Never mind".
Daniel Lichtblau
Wolfram Research
Jon Harrop
> "Widely recognized as the world's most powerful list manipulation
> language, Mathematica ..."
LOL. :-)
> Topic for discussion: From only the list processing/manipulation point of
> view, and nothing else, what would you consider the
> advantages/disadvantages of one over the other?
There are several useful/essential features for list processing:
1. Performance.
2. Well-defined performance.
3. Pattern matching.
4. Tail recursion.
1. Mathematica is very slow.
2. Mathematica doesn't define the performance of most of its operators. Lisp
is slow due to dynamic typing.
3. Lisp doesn't bundle pattern matching and most Lisp implementations of
pattern matchers suck.
4. Neither Lisp nor Mathematica make sufficient assurances about tail
recursion.
So I'd say both languages were quite poor for list processing. I'd recommend
Scheme, Haskell, OCaml or Standard ML.
--
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
rjf
......
>
> And now I am using Mathematica more (for school work), and saw this in
> Mathematica docs:
>
> "Widely recognized as the world's most powerful list manipulation language,
> Mathematica ..."
This is marketing fluff. It would be foolish to put any credence
into this statement.
>
> Topic for discussion: From only the list processing/manipulation point of
> view, and nothing else, what would you consider the advantages/disadvantages
> of one over the other?
Lisp lists are linked lists. The List object in Mathematica appears
to be a fixed-length array or string.
Thus Mathematica is an array-based manipulation language and not even
in the same category.
Adding an element to the front of a list in Lisp is a constant-time
operation. Adding an element to
the front of a list in Mathematica takes time proportional to the
length of the "list" because it has
to be copied.
Advantages of Lisp involving list processing include several good
implementations (several free),
and excellent compilers. Mathematica is not free, and the "compiler"
last I looked worked only on
arithmetic, not lists.
Advantages of Mathematica include peculiar syntax which allows a
person skilled in its arcana to write compact,
yet unreadable code. Um, maybe not an advantage..
>
> I am sure by now, any kind of list processing task that can be done by one
> language, most likely can just as well be done in the other.
Actually, false. The data structure that corresponds to Mathematica
List would be
an array in lisp. So you could compare them. If you want to have a
lisp-like list
for (a b c d) in Mathematica, you could encode it as a[b[c[d[]]]]
and then they would
be similar. But none of the List operations or syntax built-in to
Mathematica would
work. And if you rewrote them, they probably be something like
10-1000 times slower than Lisp.
Anyone programming in lisp or mathematica should not have to count
matching parentheses
or square brackets, simply by using a text editor that flashes the
matching ( or [. Are there
any such programmers?
>
..I am thinking
> more along the lines of a language design issues related to list processing
> which might make one more suited for list processing than another.
To reiterate, Mathematica does not use a List data structure in the
computer science sense.
Many things that are said to be true about lists are false for
Mathematica Lists because
it is using arrays.
Lisp has macro expansion capabilities and there are advantages, for
the skilled programmer,
to make use of the fact that Lisp programs are lists and can be
constructed (e.g. by macro expansion)
and then compiled and run. Manipulating Mathematica programs is
presumably possible, but
I do not know of anyone doing so. As an indication that Mathematica
is relatively defective, note
that extensions to the system continue to be written, at least in
large part, in languages like C or C++.
While Lisp programs can be set up to call pre-existing libraries in C
or Fortran etc, it would be quite
unusual for a Lisp programmer to find an advantage to writing a large
new piece of code in C.
(I have used an occasional fragment of C to access a peculiar API ,
but the overall efficiency and
expressiveness of Lisp is not an issue the way it seems to be for
Mathematica).
>May be someone here has more insight into both and educate us.
>
> Nasser
PS. I just read the comments from DanL and he said some of the same
things.
RJF
Jon Harrop
All good points but...
rjf wrote:
> Manipulating Mathematica programs is presumably possible, but I do not
> know of anyone doing so.
If Lisp macros count then Mathematica replacement rules should count. These
are ubiquitous, of course.
rjf
No, I don't see that mathematica rules are similar to macros in lisp.
Mathematica rules are part of a rewriting system at the center of
mathematica, kind of a read-applyrules-print loop. In lisp there is
a read-eval-print loop.
The eval step sometimes requires "expand macros, then eval".
A macro system as usually used in Lisp is via a function that defines
functions. A macro system for mathematica would, I suppose, enable a
programmer to do something like produce and install in the system a
whole bunch of distinct rules by using a single rule repeatedly with
different arguments.
I agree that mathematica rules are ubiquitous. they are usually
confused by the casual user with programs, e.g. f[x_]:=x+1 seems to
act like (defun f(x)(+ x 1)) in lisp. But the mathematica notion
is rather different in general. but this specific example works almost
the same.
A rule-driven system written in Lisp is easy to define, and is done in
any number of books on Lisp, e.g. where prolog is defined in Lisp.
Macros are, however, something else. And they are not like rules in
mathematica.
RJF
Jon Harrop
> Macros are, however, something else. And they are not like rules in
> mathematica.
They both rewrite ASTs.
--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet
rjf
So? Elephants and fruit flies eat vegetable matter..
That does not provide much insight into their (significant)
differences.
In Lisp, programs are viewable as (nested) lists, and can be [and
sometimes are] rewritten by macros.
In Mma, programs are viewed as fixed entities defined solely by
explicit text (or notebooks) in files.
In computer algebra systems written in Lisp, as well as the CAS
Mathematica, the data objects are typically an abstraction for
algebraic trees. These can (and are) manipulated by explicit
commands, substitutions, and "evaluations". These manipulations can
be directed by rules or some other mechanisms.
While it is undoubtedly possible to simulate in Mma any computational
regime, including a version of the Lisp evaluator, including macros,
there is no explicit macro-expansion phase in the usual explanations
of Mma programming paradigms.
RJF
Jon Harrop
> In Lisp, programs are viewable as (nested) lists, and can be [and
> sometimes are] rewritten by macros.
> In Mma, programs are viewed as fixed entities defined solely by
> explicit text (or notebooks) in files.
Your statement about Lisp is correct but your statement about Mathematica is
completely wrong. You can get a correct statement about Mathematica by
replacing "Lisp" in the first statement with "Mathematica" and "macro"
with "rules". Indeed, this similarity was my original point.
rjf
> rjf wrote:
> > In Lisp, programs are viewable as (nested) lists, and can be [and
> > sometimes are] rewritten by macros.
> > In Mma, programs are viewed as fixed entities defined solely by
> > explicit text (or notebooks) in files.
>
> Your statement about Lisp is correct but your statement about Mathematica is
> completely wrong. You can get a correct statement about Mathematica by
> replacing "Lisp" in the first statement with "Mathematica" and "macro"
> with "rules". Indeed, this similarity was my original point.
>
Search for mathematica and macro and you'll find discussions of how
to generate excel or postscript macros.
If you believe mathematica rules are in some significant way used like
macros, you are pretty much alone.
RJF
Jon Harrop
> On Jun 21, 2:42 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
>> Your statement about Lisp is correct but your statement about Mathematica
>> is completely wrong. You can get a correct statement about Mathematica by
>> replacing "Lisp" in the first statement with "Mathematica" and "macro"
>> with "rules". Indeed, this similarity was my original point.
>
Like I said, you mean "rule" and not "macro".
rjf
>
> > Search for mathematica and macro...
>
> Like I said, you mean "rule" and not "macro".
As I said, you are pretty much alone.
Jon Harrop
Google indicates 835,000 results. I think "alone" might be wrong as well...
rjf
> rjf wrote:
> >> > Search for mathematica and macro...
>
> >> Like I said, you mean "rule" and not "macro".
>
> > As I said, you are pretty much alone.
>
> Google indicates 835,000 results. I think "alone" might be wrong as well...
>
557,000 hits.
But if you exclude excel etc. macros, by a search for
mathematica macro -keyboard -basic -excel -solid -matlab -tex
then you get about 50,000 hits.
If you look at the first page or so you find that the hits STILL
describe other languages using macros to invoke mathematica.
Searching on mathematica rule gets about 847,000
hits.
Searching on mathematica rule macro gets 270,000 hits, of which the
first is about tex, the second is about a solid modeling program that
uses macros to call mathematica, and the third is THIS DISCUSSION.
So this thread is apparently a primary reference to mathematica+macros
+rules. In this thread you say that rules and macros are somehow
equivalent, and I say you are apparently alone in believing this. I
think the Google search is supportive of my view, though not
definitive.
In that search, an interview with Wolfram came up...
http://www.stephenwolfram.com/interviews/93-dobbs/
in which SW talks about programming languages, and the interviewer
(from Doctor Dobbs) uses the word macro -- in relation to Lotus123.
SW never uses the word.
I apologize to other readers for taking Jon's troll too seriously.
RJF
Jon Harrop
> I found that searching with google on mathematica macro got
Thinking about it some more, this is never going to work reliably because
macro is a homonym even in this specific context (e.g. C macro, Lisp macro
and OCaml macro all mean significantly different things).
> I apologize to other readers for taking Jon's troll too seriously.
My objection was primarily to your statement that Lisp manipulates ASTs
whereas Mathematica manipulates text. I still don't think that statement
had any merit, although perhaps you were referring to Lisp's unconventional
lack of pretty printing and parsing of ASTs?
If so, you can rewrite programs using only FullForm in Mathematica, of
course...
rjf
Sorry, again, Jon, (and readers too). I never said "Mathematica
manipulates text".
I said " In Mma, programs are viewed as fixed entities defined
solely by
explicit text (or notebooks) in files. "
In the most common situation, Mathematica's represents programs, once
they are read in from text files, as trees.
So does Lisp. Mathematica trees are built up of nodes of various
sizes, each of which is an array, mostly populated with pointers to
other arrays, symbols, constants. Lisp trees are built up of nodes of
fixed size, and atoms.
The fact is that Lisp macros are important tools for intermediate and
advanced Lisp programmers who use macros to facilitate the alteration
of the programs qua trees into other programs. It is used, for
example, to aid in abstraction, information hiding, building or
extending languages on top of Lisp, and other purposes, some not so
great (e.g. premature optimizations). I have not seen this done in
Mathematica. I can imagine people trying to do such things, by
defining programs by f[x_]= .... rather than f[x_]:= ..... But I
have not seen this. And even if it were done, it would not mean rules
are like macros.
You say
" although perhaps you were referring to Lisp's unconventional
> lack of pretty printing and parsing of ASTs?"
I think you meant Lisp->Mathematica in that statement.
I have found Mathematica's on-line reformatting of program texts to
be less readable than my own formatting, which is too bad. In Lisp I
can depend on Lisp (or emacs) to reveal certain kinds of errors by
noticing anomalies in the automatic indentation. It seems to me that
Mathematica's support for the programmer, including debugging, has
been unsatisfactory for a long time. Rules make this hard, I suspect.
There is no reason to believe that a good "prettyprinter" cannot be
created for Mathematica. Maybe there is one already. It would not be
difficult to write one in Lisp, where there are packages to help do
this. The language is still overly complex both syntactically and
semantically, regardless of its formatting.
Jon Harrop
> The fact is that Lisp macros are important tools for intermediate and
> advanced Lisp programmers who use macros to facilitate the alteration
> of the programs qua trees into other programs. It is used, for
> example, to aid in abstraction, information hiding, building or
> extending languages on top of Lisp, and other purposes, some not so
> great (e.g. premature optimizations). I have not seen this done in
> Mathematica. I can imagine people trying to do such things, by
> defining programs by f[x_]= .... rather than f[x_]:= ..... But I
> have not seen this.
Have a look at some of the DSLs available for Mathematica, such as the ones
for Feynman diagrams, combinatorics and graph theory. Many of these go
beyond macro-capabilities to provide customised typesetting and editing.
rjf
...
>
> Have a look at some of the DSLs available for Mathematica, such as the ones
> for Feynman diagrams, combinatorics and graph theory. Many of these go
> beyond macro-capabilities to provide customised typesetting and editing.
>
Sorry, no can do. Searching for DSL and feynman gets no hits on
wolfram.com.
Except for DSL modems, I'm unfamiliar with the use of that acronym.
If whatever you are talking about provides customised typsetting and
editing, I don't see why that would go "beyond" macro-capabilities.
Maybe Nasser should get the troll credit for this thread.
Jon Harrop
> If whatever you are talking about provides customised typsetting and
> editing, I don't see why that would go "beyond" macro-capabilities.
Typesetting.
Jon Harrop
> Searching for DSL...
Domain Specific Language:
http://en.wikipedia.org/wiki/Domain-specific_programming_language
http://msdn2.microsoft.com/en-us/vstudio/aa718368.aspx
e.g. XSLT.