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

161–170 of 346 posts

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

#161

Post by mathisfun123 »

kazinator wrote: post #158
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.

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

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

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

#162

Post by lispm »

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.

> 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

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?

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

#163

Post by lispm »

kazinator wrote: post #160
mathisfun123 wrote: post #155

Earlier quoted context omitted.

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

Then the person should spend another weekend and implement a compiler for it.

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

#164

Post by lispm »

sireat wrote: post #159
lispm wrote: post #156

Earlier quoted context omitted.

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 ag…

From what I see in your example, you invoke the form again. In Common Lisp you don't need that. You can stay in a computation and fix&resume from within.

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

#165

Post by yaantc »

mathisfun123 wrote: post #154
CraigJPerry wrote: post #151

Earlier quoted context omitted.

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

Calling again and continuing are not the same thing. Sure, with the above trivial example it is. But if the parent function has non idempotent code before calling the missing function (like doing some global change / side effects), then calling again will give a different result than just continuing from the current state.

So is it possible to define the missing function and continue from the same state in Python? I don't think so, but I'm not a heavy Python user (just for small/medium scripts).

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

#166

Post by mathisfun123 »

lispm wrote: post #162
mathisfun123 wrote: post #155

Earlier quoted context omitted.

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

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

>Racket

Do you really know what you're talking about here?

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

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

#167

Post by kubb »

opportune wrote: post #92

I see a lot of “coding” talk in the blog and comments from the author here, but few mentions as to what kind of software they’re building or what use cases they’re targeting. My hot take is that the reason functional programming never took off is that, while it certainly is fine for writing programs, most software these days is not “program running locally on my pc/server from the command line until it completes” and…

Functional programming took off big time. Just look at the JavaScript ecosystem.

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

#168

Post by _19qg »

mathisfun123 wrote: post #157
lispm wrote: post #156

Earlier quoted context omitted.

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…

Common Lisp programs run by default in a way that calls to undefined functions are detected.

Here the Lisp simply tries to look up the function object from the symbol. There is no function, so it signals a condition (aka exception). The default exception handler gets called (without unwinding the stack). This handler prints the restarts and calls another REPL. I define the function -> the symbol now has a function definition. We then resume and Lisp tries again to get the function definition. The computation continues where we were.

That's the DEFAULT behavior you'll find in Common Lisp implementations.

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

#169

Post by massimosgrelli »

Always been fascinated by Lisp, but I never spent enough time to enjoy its elegance and applications. I went through Lurk, a Lisp dialect, a Turing-complete programming language for recursive zk-SNARKs in the last year. I started to grasp a bit of its potential in solving real-world problems, but still too little to understand why it's so right for solving some problems. I'm curious about what other projects you guys are successfully and better solving because of Lisp today.

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

#170

Post by kgwgk »

sireat wrote: post #159
lispm wrote: post #156

Earlier quoted context omitted.

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 ag…

> Hmm, what advantage does Lisp offer here over Python?

It does have a clear advantage if instead of

    (+ 1 (foo 20))
we were doing

    (+ (long-computation-answering-the-ultimate-question-of-life-the-universe-and-everything)
       (foo 20))
(Reminder: we're dicussing Common Lisp here.)
Post reply on HN