Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It's 2023, so of course I'm learning Common Lisp

log.schemescape.com

Post reply on HN
Print view View original

151–160 of 346 posts

Re: It's 2023, so of course I'm learning Common Lisp

#151

Post by CraigJPerry »

mathisfun123 wrote: post #82
xbpx wrote: post #75

Earlier quoted context omitted.

A REPL isn't just a REPL. You are comparing modern day Toyota Corollas to a Spaceship sent from the future to the 80s. One is just different level radical. At least when it's baked by SLY or SLIME

here is the list of slime features on the slime webpage >Code evaluation, compilation, and macroexpansion. >Online documentation (describe, apropos, hyperspec). >Definition finding (aka Meta-Point aka M-.). >Symbol and package name completion. >Automatic macro indentation based on &body. >Cross-reference interface (WHO-CALLS, etc). https://slime.common-lisp.dev/ and i'm still wondering which of these things i can't d…

>Code evaluation, compilation

I couldn’t debug the following in pycharm and add the missing function at runtime, or could i?

    def interactively_writing_code():
        this_doesnt_exist_yet()

    interactively_writing_code()
I don’t think i can patch a function at runtime without losing state either in python - the act of redefining the function causes the variables to be reset but in lisp the bindings are untouched.

Re: It's 2023, so of course I'm learning Common Lisp

#152

Post by lispm »

mathisfun123 wrote: post #142
lispm wrote: post #140

Earlier quoted context omitted.

> 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 See "Details and Options"

>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.

> 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.

Re: It's 2023, so of course I'm learning Common Lisp

#153

Post by [deleted] »

mathisfun123 wrote: post #86
LispSporks22 wrote: post #85

Earlier quoted context omitted.

In TFA, go to the “Try this in your favorite repl”, try that in your “repl” and that would be the fine distinction you’re missing.

>The answer to that question is the differentiating point of repl-driven programming. In an old-fashioned Lisp or Smalltalk environment, the break in foo drops you into a breakloop. do you want me to show you how to do this in a python repl? it's literally just breaking on exception...

[deleted]

Re: It's 2023, so of course I'm learning Common Lisp

#154

Post by mathisfun123 »

CraigJPerry wrote: post #151
mathisfun123 wrote: post #82

Earlier quoted context omitted.

here is the list of slime features on the slime webpage >Code evaluation, compilation, and macroexpansion. >Online documentation (describe, apropos, hyperspec). >Definition finding (aka Meta-Point aka M-.). >Symbol and package name completion. >Automatic macro indentation based on &body. >Cross-reference interface (WHO-CALLS, etc). https://slime.common-lisp.dev/ and i'm still wondering which of these things i can't d…

>Code evaluation, compilation I couldn’t debug the following in pycharm and add the missing function at runtime, or could i? def interactively_writing_code(): this_doesnt_exist_yet() interactively_writing_code() I don’t think i can patch a function at runtime without losing state either in python - the act of redefining the function causes the variables to be reset but in lisp the bindings are untouched.

I just did it - it works perfectly fine. Debug-run your code, an exception will be thrown at the call site, step up one frame from the exception (ie module level), define the missing function, call again and it succeeds - all without leaving the same repl instance. Don't believe me? Try it.

I'll say it again: you guys are in plain denial not about python or lisp as languages but about how interpreters work. There's just nothing more to be said about this dimension of it.

Re: It's 2023, so of course I'm learning Common Lisp

#155

Post by mathisfun123 »

lispm wrote: post #152
mathisfun123 wrote: post #142

Earlier quoted context omitted.

>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.

> 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. Th…

> 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.

Re: It's 2023, so of course I'm learning Common Lisp

#156

Post by lispm »

mathisfun123 wrote: post #80
memefrog wrote: post #72

Earlier quoted context omitted.

Of course people "realise" this. But those REPLs are not actually REPLs. They are interactive language prompts. They aren't actually REPLs. As the joke goes, Python doesn't have a REPL: it lacks READ, EVAL, PRINT and LOOP. Being able to type in code and have it evaluated one line at a time isn't a REPL.

i have no idea what subtle or nuanced distinction you're trying to strike so what exactly do you imagine is the difference between a lisp repl and a python repl? Edit: people that aren't familiar with python (or how interpreters work in general) don't seem to understand that being able to poke and prod the runtime is entirely a function of the runtime, not the language. In cpython you can absolutely do anything you w…

How does it look like in Python? In Lisp:

  CL-USER 43 > (+ 1 (foo 20))

  Error: Undefined operator FOO in form (FOO 20).
    1 (continue) Try invoking FOO again.
    2 Return some values from the form (FOO 20).
    3 Try invoking something other than FOO with the same arguments.
    4 Set the symbol-function of FOO to another function.
    5 Set the macro-function of FOO to another function.
    6 (abort) Return to top loop level 0.

  Type :b for backtrace or :c  to proceed.
  Type :bug-form "" for a bug report template or :? for other options.

  CL-USER 44 : 1 > (defun foo (a) (+ a 21))
  FOO

  CL-USER 45 : 1 > :c 1
  42
Note that we are not in some debug mode, to get this functionality. It also works for compiled code.

Lisp detects that FOO is undefined. We get a clear error message.

Lisp then offers me a list of restarts, how to continue.

It then displays a REPL one level deep in an error.

I then define the missing function.

Then I tell Lisp to use the first restart, to try to invoke FOO again. We don't want to start from scratch, we want to continue the computation.

Lisp then is able to complete the computation, since FOO is available now.

Re: It's 2023, so of course I'm learning Common Lisp

#157

Post by mathisfun123 »

lispm wrote: post #156
mathisfun123 wrote: post #80

Earlier quoted context omitted.

i have no idea what subtle or nuanced distinction you're trying to strike so what exactly do you imagine is the difference between a lisp repl and a python repl? Edit: people that aren't familiar with python (or how interpreters work in general) don't seem to understand that being able to poke and prod the runtime is entirely a function of the runtime, not the language. In cpython you can absolutely do anything you w…

How does it look like in Python? In Lisp: CL-USER 43 > (+ 1 (foo 20)) Error: Undefined operator FOO in form (FOO 20). 1 (continue) Try invoking FOO again. 2 Return some values from the form (FOO 20). 3 Try invoking something other than FOO with the same arguments. 4 Set the symbol-function of FOO to another function. 5 Set the macro-function of FOO to another function. 6 (abort) Return to top loop level 0. Type :b fo…

>Note that we are not in some debug mode, to get this functionality.

Jesus Christ I swear it's like you ascribe mysterious powers to the parens. Do you think the parens give you the ability to travel through time or reverse the pc or what? Okay it's not in a debug mode but it's in a "debug mode". Like seriously tell me how you think this works if it's not effectively catching/trapping some sigkill or something that's the equivalent thereof?

I have never in my life met this kind of intransigence on just manifestly obvious things.

Re: It's 2023, so of course I'm learning Common Lisp

#158

Post by kazinator »

mathisfun123 wrote: post #142
lispm wrote: post #140

Earlier quoted context omitted.

> 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 See "Details and Options"

>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.

> 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".

Re: It's 2023, so of course I'm learning Common Lisp

#159

Post by sireat »

lispm wrote: post #156
mathisfun123 wrote: post #80

Earlier quoted context omitted.

i have no idea what subtle or nuanced distinction you're trying to strike so what exactly do you imagine is the difference between a lisp repl and a python repl? Edit: people that aren't familiar with python (or how interpreters work in general) don't seem to understand that being able to poke and prod the runtime is entirely a function of the runtime, not the language. In cpython you can absolutely do anything you w…

How does it look like in Python? In Lisp: CL-USER 43 > (+ 1 (foo 20)) Error: Undefined operator FOO in form (FOO 20). 1 (continue) Try invoking FOO again. 2 Return some values from the form (FOO 20). 3 Try invoking something other than FOO with the same arguments. 4 Set the symbol-function of FOO to another function. 5 Set the macro-function of FOO to another function. 6 (abort) Return to top loop level 0. Type :b fo…

Hmm, what advantage does Lisp offer here over Python?

  >>> 1 + foo(20)
  Traceback (most recent call last):
    File "", line 1, in 
  NameError: name 'foo' is not defined
  >>> def foo(a):
  ... return a + 21
    File "", line 2
      return a + 21
           ^
  IndentationError: expected an indented block
  >>> def foo(a):
  ...   return a + 21
  ...
  >>> 1 + foo(20)
  42
  >>>
Mind the hilarious indentation error, as I had not touched the old-school REPL in ages.

In normal day to day operations, I do the same thing daily with Jupyter Notebooks. I get access to as much state as I need.

With notebooks workflow it is normal to forget to define something and then redefine in the next cell. You could redefine function signatures etc. Ideally then you move cells in the correct order so that code can be used as Run All.

I "feel" ridiculously productive in VS Code with full Notebook support + copilot. I can work across multiple knowledge domains with ease (ETL across multiple database technologies, NLP-ML, visualization, web scraping, etc)

Underneath it is same as working in old school Python REPL just with more scaffolding.

Re: It's 2023, so of course I'm learning Common Lisp

#160

Post by kazinator »

mathisfun123 wrote: post #155
lispm wrote: post #152

Earlier quoted context omitted.

> 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. Th…

> 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.

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?
Post reply on HN