4 ms·

Technically what Mathematica calls "lists" are one-dimensional arrays (aka vectors in Lisp), but not Lisp-like singly-linked lists. This is an example of an M-

by lispm 2y ago

Technically what Mathematica calls "lists" are one-dimensional arrays (aka vectors in Lisp), but not Lisp-like singly-linked lists. This is an example of an M-Expression in the original definition of Lisp: [eq[third[(A B C (D . E))];C]→cons[D;cdr[((A 1 2 3) B C)]; T→car[x]] which is roughly equivalent to the Lisp S-Expression (COND ((EQ (THIRD (QUOTE (A B C (D . E)))) (QUOTE C)) (CONS (QUOTE D) (CDR (QUOTE ((A 1 2 3) B C))))) (T (CAR X))) Which evaluates to (D B C)

Y_Y 2y ago
Is the underlying implementation a necessary condition? Mathematica is a heap of shit, but it was deliberately based on lisp by sensible people and has astonishingly similar semantics. Afaik the language spec doesn't define anything incompatible with OG lisp and you can treat it like one without inconsistencies.
- lispm 2y ago
  It was more influenced by computer algebra systems written in Lisp, like Macsyma (-> Maxima), REDUCE, and others. > astonishingly similar semantics The "Wolfram language" has at its core a rewrite rule systems. Expressions are being rewritten by applying transformations to it. Lisp does not use anything like that. Lisp has an evaluator mechanism, based on fixed evaluation rules (+ macro transformations, which are again Lisp functions). As a result, code in the Wolfram language is difficult to (fully) compile. Good and extensive Lisp compilers exist since the early 60s. Current examples of complete compilers are SBCL for Lisp and Chez Scheme for Scheme. The Wolfram language also has no formal spec (compare to something like Scheme) and the language itself is not open sourced, including its main implementation. It's basically defined by its main implementation, while its proprietary language documentation looks like written in a such way to prevent implementations of the language.
  - Y_Y 2y ago
    I guess I consider term-rewriting to be just a fancy lambda calculus. See, e.g. https://cstheory.stackexchange.com/questions/36090/how-is-lambda-calculus-a-specific-type-of-term-writing-system https://cstheory.stackexchange.com/questions/36090/how-is-la... I can't argue with any of your points, but I'd like to mention that Mathematica's internal compiler is pretty capable and if you do something like Plot[f, xs] it will automatically try to compile f before evaluating it at all the points.
    - lispm 2y ago
      Lisp is not an implementation of "lambda calculus". > internal compiler is pretty capable Depends, when reading the documentation, one gets the impression that their compiler is very limited.
      - Y_Y 2y ago
        > Lisp is not an implementation of "lambda calculus". Maybe you could explain that one for the benefit of myself and the other mortals.
        lispm 2y ago
        See the following excerpt of a longer paper. Generally the lambda calculus is a specific mathematical formalism, LISP is quite a bit more and an actual programming language (it has more than just functions) and implementations don't follow the rules of lambda calculus for evaluation. We also need to see differences between formal models for some of Lisp and actual implementations of a "real" Lisp with numbers, etc. We don't need to model numbers with functions, like with "church numerals". Here follows an excerpt from a paper "Some History of Functional Programming Languages" by D. A. Turner. It talks about LISP, as invent/discovered by John McCarthy: https://www.cs.kent.ac.uk/people/staff/dat/tfp12/tfp12.pdf https://www.cs.kent.ac.uk/people/staff/dat/tfp12/tfp12.pdf ----- Some Myths about LISP Something called “Pure LISP” never existed — McCarthy (1978) records that LISP had assignment and goto before it had conditional expressions and recursion — it started as a version of FORTRAN I to which these latter were added. LISP 1.5 programmers made frequent use of setq which updates a variable and rplaca, rplacd which update the fields of a CONS cell. LISP was not based on the lambda calculus, despite using the word “LAMBDA” to denote functions. At the time he invented LISP, McCarthy was aware of (Church 1941) but had not studied it. The theoretical model behind LISP was Kleene’s theory of first order recursive functions. The M-language was first order, as already noted, but you could pass a function as a parameter by quotation, i.e. as the S-expression which encodes it. Unfortunately, this gives the wrong binding rules for free variables (dynamic instead of lexicographic). If a function has a free variable, e.g y in f = λx.x + y y should be bound to the value in scope for y where f is defined, not where f is called. McCarthy (1978) reports that this problem (wrong binding for free variables) showed up very early in a program of James Slagle. At first McCarthy assumed it was a bug and expected it to be fixed, but it actually springs from something fundamental — that meta-programming is not the same as higher order programming. Various devices were invented to get round this FUNARG problem, as it became known. Not until SCHEME (Sussman 1975) did versions of LISP with default static binding appear. Today all versions of LISP are lambda calculus based. ----- A remark from me: "Today all versions of LISP are lambda calculus based.", except where they are not, like evaluation rules, dynamic binding, data types, etc. What we have now in most Lisps since the mid 80s is lexical binding and closures, but not exclusively. Scheme earlier called dynamic bound variables "fluids". CL has it, for example by default for global variables.

by lispm 2y ago

Y_Y 2y ago

Is the underlying implementation a necessary condition? Mathematica is a heap of shit, but it was deliberately based on lisp by sensible people and has astonishingly similar semantics. Afaik the language spec doesn't define anything incompatible with OG lisp and you can treat it like one without inconsistencies.

lispm 2y ago
It was more influenced by computer algebra systems written in Lisp, like Macsyma (-> Maxima), REDUCE, and others. > astonishingly similar semantics The "Wolfram language" has at its core a rewrite rule systems. Expressions are being rewritten by applying transformations to it. Lisp does not use anything like that. Lisp has an evaluator mechanism, based on fixed evaluation rules (+ macro transformations, which are again Lisp functions). As a result, code in the Wolfram language is difficult to (fully) compile. Good and extensive Lisp compilers exist since the early 60s. Current examples of complete compilers are SBCL for Lisp and Chez Scheme for Scheme. The Wolfram language also has no formal spec (compare to something like Scheme) and the language itself is not open sourced, including its main implementation. It's basically defined by its main implementation, while its proprietary language documentation looks like written in a such way to prevent implementations of the language.
- Y_Y 2y ago
  I guess I consider term-rewriting to be just a fancy lambda calculus. See, e.g. https://cstheory.stackexchange.com/questions/36090/how-is-lambda-calculus-a-specific-type-of-term-writing-system https://cstheory.stackexchange.com/questions/36090/how-is-la... I can't argue with any of your points, but I'd like to mention that Mathematica's internal compiler is pretty capable and if you do something like Plot[f, xs] it will automatically try to compile f before evaluating it at all the points.
  - lispm 2y ago
    Lisp is not an implementation of "lambda calculus". > internal compiler is pretty capable Depends, when reading the documentation, one gets the impression that their compiler is very limited.
    - Y_Y 2y ago
      > Lisp is not an implementation of "lambda calculus". Maybe you could explain that one for the benefit of myself and the other mortals.
      - lispm 2y ago
        See the following excerpt of a longer paper. Generally the lambda calculus is a specific mathematical formalism, LISP is quite a bit more and an actual programming language (it has more than just functions) and implementations don't follow the rules of lambda calculus for evaluation. We also need to see differences between formal models for some of Lisp and actual implementations of a "real" Lisp with numbers, etc. We don't need to model numbers with functions, like with "church numerals". Here follows an excerpt from a paper "Some History of Functional Programming Languages" by D. A. Turner. It talks about LISP, as invent/discovered by John McCarthy: https://www.cs.kent.ac.uk/people/staff/dat/tfp12/tfp12.pdf https://www.cs.kent.ac.uk/people/staff/dat/tfp12/tfp12.pdf ----- Some Myths about LISP Something called “Pure LISP” never existed — McCarthy (1978) records that LISP had assignment and goto before it had conditional expressions and recursion — it started as a version of FORTRAN I to which these latter were added. LISP 1.5 programmers made frequent use of setq which updates a variable and rplaca, rplacd which update the fields of a CONS cell. LISP was not based on the lambda calculus, despite using the word “LAMBDA” to denote functions. At the time he invented LISP, McCarthy was aware of (Church 1941) but had not studied it. The theoretical model behind LISP was Kleene’s theory of first order recursive functions. The M-language was first order, as already noted, but you could pass a function as a parameter by quotation, i.e. as the S-expression which encodes it. Unfortunately, this gives the wrong binding rules for free variables (dynamic instead of lexicographic). If a function has a free variable, e.g y in f = λx.x + y y should be bound to the value in scope for y where f is defined, not where f is called. McCarthy (1978) reports that this problem (wrong binding for free variables) showed up very early in a program of James Slagle. At first McCarthy assumed it was a bug and expected it to be fixed, but it actually springs from something fundamental — that meta-programming is not the same as higher order programming. Various devices were invented to get round this FUNARG problem, as it became known. Not until SCHEME (Sussman 1975) did versions of LISP with default static binding appear. Today all versions of LISP are lambda calculus based. ----- A remark from me: "Today all versions of LISP are lambda calculus based.", except where they are not, like evaluation rules, dynamic binding, data types, etc. What we have now in most Lisps since the mid 80s is lexical binding and closures, but not exclusively. Scheme earlier called dynamic bound variables "fluids". CL has it, for example by default for global variables.