4 ms·

> I have already addressed this: FullForm No you haven't addressed it. The "Wolfram Language" user typically does not write code in FullForm. It's used as an i

by lispm 3y ago

> I have already addressed this: FullForm No you haven't addressed it. The "Wolfram Language" user typically does not write code in FullForm. It's used as an internal representation. > it's just that it's very good at beta reduction and not so good at compiling code... https://reference.wolfram.com/language/ref/Compile.html https://reference.wolfram.com/language/ref/Compile.html See "Details and Options"

mathisfun123 3y ago
>The "Wolfram Language" user typically does not write code in FullForm. It's used as an internal representation. I have no clue what you're talking about - it's an available primitive and I use it all the time. >and not so good at compiling code... Lol I am 100% sure that the majority of lisps cannot be aot compiled.
- lispm 3y ago
  > I have no clue what you're talking about That's not good. Try again. In Lisp adding two numbers looks like this is source code: (+ 1 2) CL-USER 41 > (+ 1 2) 3 If I quote the expression and evaluate it, the result is (+ 1 2) CL-USER 42 > (quote (+ 1 2)) (+ 1 2) Thus in Lisp the textual representation of code and code as data are the same. Not so in "Wolfram Language": a + b has a FullForm which looks differently. The user does not write ALL of the code in FullForm notation. Source notation a + b FullForm Plus[a, b] Lisp: Source notation (+ a b) FullForm (+ a b) Can you see the difference? > Lol I am 100% sure that the majority of lisps cannot be aot compiled. I'd expect that they can. That's a feature since 1962. SBCL for example does AOT compilation by default, always. * (disassemble (lambda (a) (+ a 42))) ; disassembly for (LAMBDA (A)) ; Size: 36 bytes. Origin: #x7006DC83B4 ; (LAMBDA (A)) ; B4: AA0A40F9 LDR R0, [THREAD, #16] ; binding-stack-pointer ; B8: 4A0B00F9 STR R0, [CFP, #16] ; BC: EA030CAA MOV R0, R2 ; C0: 8B0A80D2 MOVZ R1, #84 ; C4: 3CAA80D2 MOVZ TMP, #1361 ; C8: BE6B7CF8 LDR LR, [NULL, TMP] ; SB-KERNEL:TWO-ARG-+ ; CC: DE130091 ADD LR, LR, #4 ; D0: C0031FD6 BR LR ; D4: E00120D4 BRK #15 ; Invalid argument count trap NIL Looks like native ARM64 code to me.
  - mathisfun123 3y ago
    > FullForm Plus[a, b] How can I make this any more clear? You are able, in Mathematica, to write Plus[a, b] with your own fingers on your own keyboard and it will be interpreted as the same thing as a+b > I'd expect that they can. Clisp is not the only lisp - I can name 10 others that cannot be compiled.
    - kazinator 3y ago
      If we count everyone's one-weekend project that evaluates (+ 1 2) into 3, then there are probably thousands of Lisps that cannot be compiled. So what?
      - lispm 3y ago
        Then the person should spend another weekend and implement a compiler for it.
    - lispm 3y ago
      > You are able, in Mathematica, to write Plus[a, b] with your own fingers on your own keyboard and it will be interpreted as the same thing as a+b Sure, but it is not Mathematica's InputForm: https://reference.wolfram.com/language/ref/InputForm.html https://reference.wolfram.com/language/ref/InputForm.html The majority of code is written not in FullForm. In Lisp 100% of the code is written in s-expressions. > Clisp is not the only lisp - I can name 10 others that cannot be compiled. Typical Lisp and Lisp dialects all can be compiled: Common Lisp, Emacs Lisp, ISLisp, Scheme, Racket, ... Which Lisps can not be compiled?
      - mathisfun123 3y ago
        >Racket Do you really know what you're talking about here? https://docs.racket-lang.org/raco/make.html https://docs.racket-lang.org/raco/make.html >The raco make command accept filenames for Racket modules to be compiled to bytecode format. That's not a compiler... I don't claim to be an expert on lisp, so further googling I find https://racket.discourse.group/t/chez-for-architectures-without-native-backends/950/2 https://racket.discourse.group/t/chez-for-architectures-with... which has some discussion about this and that native backend. Suffice it to say I am not any more confident that being compilable is somehow intrinsic to lisp.
- kazinator 3y ago
  > Lol I am 100% sure that the majority of lisps cannot be aot compiled. Ahead-of-time compiling has been the principal method in mainstream Lisps going back to the 1960's. The Lisp 1.5 Programmer's Manual from 1962 describes ahead-of-time compiling. The curious thing is how can you be "100% sure" in making a completely wrong statement, rather than some lower number, like "12% sure".
  - mathisfun123 3y ago
    >The curious thing is how can you be "100% sure" in making a completely wrong statement, rather than some lower number, like "12% sure". The reason is very simple and surprisingly straightforward (but requires some understanding of compilers): dynamically typed languages that are amenable to interpreter implementations are very hard to compile AOT. Now note I have since the beginning emphasized AOT - ahead of time - but this does not preclude JITs. But in reality I don't really care about this aspect - it was the other guy who for whatever reason decided to flaunt that clisp can be compiled when comparing it with Mathematica.
    - kazinator 3y ago
      For someone playing with Mathematica, you have a curious intellectual process. To be clear, I'd rather have you doing that than hocking loogies at cars from an overpass.
- eadmund 3y ago
  > Lol I am 100% sure that the majority of lisps cannot be aot compiled. CL-USER> (defun foobar (x) (1+ x)) FOOBAR CL-USER> (disassemble #'foobar) ; disassembly for FOOBAR ; Size: 35 bytes. Origin: #x5365BF44 ; FOOBAR ; 44: 498B4510 MOV RAX, [R13+16] ; thread.binding-stack-pointer ; 48: 488945F8 MOV [RBP-8], RAX ; 4C: BF02000000 MOV EDI, 2 ; 51: 488BD3 MOV RDX, RBX ; 54: FF14251001A052 CALL QWORD PTR [#x52A00110] ; SB-VM::GENERIC-+ ; 5B: 488B5DF0 MOV RBX, [RBP-16] ; 5F: 488BE5 MOV RSP, RBP ; 62: F8 CLC ; 63: 5D POP RBP ; 64: C3 RET ; 65: CC10 INT3 16 ; Invalid argument count trap NIL CL-USER> There you go: #'FOOBAR is AOT-compiled down to four MOVs, a CALL, two MOVs, a CLC, a POP and a RET.

by lispm 3y ago

mathisfun123 3y ago

>The "Wolfram Language" user typically does not write code in FullForm. It's used as an internal representation. I have no clue what you're talking about - it's an available primitive and I use it all the time. >and not so good at compiling code... Lol I am 100% sure that the majority of lisps cannot be aot compiled.

lispm 3y ago
> I have no clue what you're talking about That's not good. Try again. In Lisp adding two numbers looks like this is source code: (+ 1 2) CL-USER 41 > (+ 1 2) 3 If I quote the expression and evaluate it, the result is (+ 1 2) CL-USER 42 > (quote (+ 1 2)) (+ 1 2) Thus in Lisp the textual representation of code and code as data are the same. Not so in "Wolfram Language": a + b has a FullForm which looks differently. The user does not write ALL of the code in FullForm notation. Source notation a + b FullForm Plus[a, b] Lisp: Source notation (+ a b) FullForm (+ a b) Can you see the difference? > Lol I am 100% sure that the majority of lisps cannot be aot compiled. I'd expect that they can. That's a feature since 1962. SBCL for example does AOT compilation by default, always. * (disassemble (lambda (a) (+ a 42))) ; disassembly for (LAMBDA (A)) ; Size: 36 bytes. Origin: #x7006DC83B4 ; (LAMBDA (A)) ; B4: AA0A40F9 LDR R0, [THREAD, #16] ; binding-stack-pointer ; B8: 4A0B00F9 STR R0, [CFP, #16] ; BC: EA030CAA MOV R0, R2 ; C0: 8B0A80D2 MOVZ R1, #84 ; C4: 3CAA80D2 MOVZ TMP, #1361 ; C8: BE6B7CF8 LDR LR, [NULL, TMP] ; SB-KERNEL:TWO-ARG-+ ; CC: DE130091 ADD LR, LR, #4 ; D0: C0031FD6 BR LR ; D4: E00120D4 BRK #15 ; Invalid argument count trap NIL Looks like native ARM64 code to me.
- mathisfun123 3y ago
  > FullForm Plus[a, b] How can I make this any more clear? You are able, in Mathematica, to write Plus[a, b] with your own fingers on your own keyboard and it will be interpreted as the same thing as a+b > I'd expect that they can. Clisp is not the only lisp - I can name 10 others that cannot be compiled.
  - kazinator 3y ago
    If we count everyone's one-weekend project that evaluates (+ 1 2) into 3, then there are probably thousands of Lisps that cannot be compiled. So what?
    - lispm 3y ago
      Then the person should spend another weekend and implement a compiler for it.
  - lispm 3y ago
    > You are able, in Mathematica, to write Plus[a, b] with your own fingers on your own keyboard and it will be interpreted as the same thing as a+b Sure, but it is not Mathematica's InputForm: https://reference.wolfram.com/language/ref/InputForm.html https://reference.wolfram.com/language/ref/InputForm.html The majority of code is written not in FullForm. In Lisp 100% of the code is written in s-expressions. > Clisp is not the only lisp - I can name 10 others that cannot be compiled. Typical Lisp and Lisp dialects all can be compiled: Common Lisp, Emacs Lisp, ISLisp, Scheme, Racket, ... Which Lisps can not be compiled?
    - mathisfun123 3y ago
      >Racket Do you really know what you're talking about here? https://docs.racket-lang.org/raco/make.html https://docs.racket-lang.org/raco/make.html >The raco make command accept filenames for Racket modules to be compiled to bytecode format. That's not a compiler... I don't claim to be an expert on lisp, so further googling I find https://racket.discourse.group/t/chez-for-architectures-without-native-backends/950/2 https://racket.discourse.group/t/chez-for-architectures-with... which has some discussion about this and that native backend. Suffice it to say I am not any more confident that being compilable is somehow intrinsic to lisp.
kazinator 3y ago
> Lol I am 100% sure that the majority of lisps cannot be aot compiled. Ahead-of-time compiling has been the principal method in mainstream Lisps going back to the 1960's. The Lisp 1.5 Programmer's Manual from 1962 describes ahead-of-time compiling. The curious thing is how can you be "100% sure" in making a completely wrong statement, rather than some lower number, like "12% sure".
- mathisfun123 3y ago
  >The curious thing is how can you be "100% sure" in making a completely wrong statement, rather than some lower number, like "12% sure". The reason is very simple and surprisingly straightforward (but requires some understanding of compilers): dynamically typed languages that are amenable to interpreter implementations are very hard to compile AOT. Now note I have since the beginning emphasized AOT - ahead of time - but this does not preclude JITs. But in reality I don't really care about this aspect - it was the other guy who for whatever reason decided to flaunt that clisp can be compiled when comparing it with Mathematica.
  - kazinator 3y ago
    For someone playing with Mathematica, you have a curious intellectual process. To be clear, I'd rather have you doing that than hocking loogies at cars from an overpass.
eadmund 3y ago
> Lol I am 100% sure that the majority of lisps cannot be aot compiled. CL-USER> (defun foobar (x) (1+ x)) FOOBAR CL-USER> (disassemble #'foobar) ; disassembly for FOOBAR ; Size: 35 bytes. Origin: #x5365BF44 ; FOOBAR ; 44: 498B4510 MOV RAX, [R13+16] ; thread.binding-stack-pointer ; 48: 488945F8 MOV [RBP-8], RAX ; 4C: BF02000000 MOV EDI, 2 ; 51: 488BD3 MOV RDX, RBX ; 54: FF14251001A052 CALL QWORD PTR [#x52A00110] ; SB-VM::GENERIC-+ ; 5B: 488B5DF0 MOV RBX, [RBP-16] ; 5F: 488BE5 MOV RSP, RBP ; 62: F8 CLC ; 63: 5D POP RBP ; 64: C3 RET ; 65: CC10 INT3 16 ; Invalid argument count trap NIL CL-USER> There you go: #'FOOBAR is AOT-compiled down to four MOVs, a CALL, two MOVs, a CLC, a POP and a RET.