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

Common Lisp Implementations in 2023

n16f.net

Post reply on HN
Print view View original

231–240 of 243 posts

Re: Common Lisp Implementations in 2023

#231

Post by taeric »

runevault wrote: post #230
taeric wrote: post #213

Earlier quoted context omitted.

For machine learning, it makes a lot of sense. Effectively, training is a function that returns a function, after all.

Oh yeah not disagreeing with that, just interesting because I'd never seen anyone rig up curried functions in scheme/lisp before as it obviously isn't default behavior in a traditional lisp. I'm assuming using some sort of wrapper function or macro.

https://mitpress.ublish.com/ebook/the-little-learner-a-strai... has the first two chapters. The forward plants the seed for the fact that it will be currying. When the chapters start, they don't use the term and just show functions returning functions. Immediately.

Re: Common Lisp Implementations in 2023

#232

Post by kazinator »

runevault wrote: post #230
taeric wrote: post #213

Earlier quoted context omitted.

For machine learning, it makes a lot of sense. Effectively, training is a function that returns a function, after all.

Oh yeah not disagreeing with that, just interesting because I'd never seen anyone rig up curried functions in scheme/lisp before as it obviously isn't default behavior in a traditional lisp. I'm assuming using some sort of wrapper function or macro.

The examples look like normal Scheme to me. There is nothing odd going on with custom macros.

They have broken some argument lists into currying, that's all.

  (define line (lambda (x)
                 (lambda (w b)
                   (+ (* w x) b))))
Firstly, it's not full currying; the w and b parameters are not separated from each other into different lambdas.

These kinds of nested lambdas are not unheard of in Lisp and Scheme programming.

Lisps do not have automatic partial application. If you have a (f x y z) function, you cannot just call it (f 42) to partially apply it, to obtain a function which takes the y and z arguments. You have to do a clumsy thing with an explicit lambda like this: (lambda (y z) (f 42 y z)). There are macros for that, which can make it look like (op f 42) or what have you.

If you need partial application regularly over some functions, it may behave you to write the function in the curried style. Passing all the parameters becomes a bit less convenient:

   ((line 1) 2 3)  ;; versus just (line 1 2 3)
but the partial application you want is a lot less verbose:

   (line 1)    ;; versus (lambda (w b) (line 1 w b)).
So basically it looks like the authors may be after low-verbosity partial application without macro assistance.

Re: Common Lisp Implementations in 2023

#233

Post by runevault »

kazinator wrote: post #232
runevault wrote: post #230

Earlier quoted context omitted.

Oh yeah not disagreeing with that, just interesting because I'd never seen anyone rig up curried functions in scheme/lisp before as it obviously isn't default behavior in a traditional lisp. I'm assuming using some sort of wrapper function or macro.

The examples look like normal Scheme to me. There is nothing odd going on with custom macros. They have broken some argument lists into currying, that's all. (define line (lambda (x) (lambda (w b) (+ (* w x) b)))) Firstly, it's not full currying; the w and b parameters are not separated from each other into different lambdas. These kinds of nested lambdas are not unheard of in Lisp and Scheme programming. Lisps do no…

Ah ha, yeah having a pre set one or two step currying setup is a lot easier sure. Just return a lambda that captures the value passed in from the first one.

Re: Common Lisp Implementations in 2023

#234

Post by vram22 »

blep_ wrote: post #193
SiVal wrote: post #169

Earlier quoted context omitted.

recent events around Go show why, I am extremely glad that I never payed much attention to Go... What are you referring to? This is a literal question, not advocacy. I haven't been paying enough attention to know what you mean.

Someone proposed adding telemetry to the compiler. People reacted to this as they usually do to telemetry. Google reacted to this as they usually do to criticism.

>Google reacted to this as they usually do to criticism.

Which is how? Not been folllowing them lately, for obvious reasons, so interested to know how they react these days.

Constructive non-egoistic non-spin engagement with the critics / stony silence with compressed lips / furious rebuttal / muttered denial and then look verbally down at the plebs while giving each other group-affirming backslaps in their posh pubs? With guilty looks in the mirror after the party and then downing some Valium to salve their conscience and get some sleep?

Re: Common Lisp Implementations in 2023

#235

Post by vindarel »

oblio wrote: post #223
vindarel wrote: post #188

Earlier quoted context omitted.

For https, we can now use the newer Lisp Package Manager: https://gitlab.common-lisp.net/clpm/clpm (or use a mitm proxy: https://hiphish.github.io/blog/2022/03/19/securing-quicklisp... )

It looks interesting, however this is a bit scary: > WARNING: This software is BETA quality. I use it as my daily driver, but it is still a little rough around the edges and it may accidentally eat your files. And for QuickLisp, this is scary: https://github.com/quicklisp/quicklisp-client/issues/167#iss... > It would be good to do, but there's no straightforward path to do it. Implementations do not all provide HTTPS…

LPM's warning is not surprising. It's common for libraries (dare I say open-source ones?), even if they work well. It's part of the stability game, once they are marked 1.0, they are stable. LPM works well (as reported by others).

QL wants to do it portably, there are easy workarounds, but yeah…

(just saw https://github.com/rudolfochrist/ql-https)

Re: Common Lisp Implementations in 2023

#236

Post by aidenn0 »

147 wrote: post #67
galdor wrote: post #44

Earlier quoted context omitted.

No you do not have to. ASDF knows where to find your ASD files: https://asdf.common-lisp.dev/asdf.html#Configuring-ASDF-to-f... Personally I use the (:tree (:home "dev/lisp")) form.

Thanks a lot for this actually. I just gave it a shot and it seems to have been the piece I've been missing.

You can load the contents of a .asd file (this can be useful when developing on versions other than what you want in your ASDF search path). It is unnecessary outside of that use case though.

Re: Common Lisp Implementations in 2023

#237

Post by medo-bear »

nextos wrote: post #155
anta40 wrote: post #62

Earlier quoted context omitted.

I assume you have some specific needs that couldn't be handled by open source Lisps like SBCL, CCL, etc?

I am also curious about this, what specific needs are better served by CL than Clojure or any Scheme / Racket? Starting a CL project in 2023 seems risky to me given that most libraries are stagnant. I would love to be proven wrong.

for my use case its just that the common lisp compilers, SBCL in particular, blow anything Clojure or Scheme/Racket has to offer. on the other hand the stability of the language should not be underestimated, but this is something you feel after years of use

on the other hand i think the common lisp development culture is very different to the black box library plug&play culture of other languages. if you find that you like to extend/personalise libraries it is a great language and i find the code to be much more comprehensible than the libraries from other languages i use. of course this is all a bit more demanding on the developer but for me the rewards are worth it

Re: Common Lisp Implementations in 2023

#238

Post by medo-bear »

nextos wrote: post #164
codehalo wrote: post #157

Earlier quoted context omitted.

Could it be that most of the critical libraries are stable? Can you give an example of a necessary library that is stagnant?

CLSQL, most graphics toolkits or lisp-stat.

for ORM people tend to use Mito. i think lisp-stat library is actually being developed. however one numerical cl library that doesnt get enough mention and is being constantly developed is petalisp for HPC

https://github.com/fukamachi/mito

https://lisp-stat.dev/

https://github.com/marcoheisig/Petalisp

Re: Common Lisp Implementations in 2023

#239

Post by lenkite »

blep_ wrote: post #193
SiVal wrote: post #169

Earlier quoted context omitted.

recent events around Go show why, I am extremely glad that I never payed much attention to Go... What are you referring to? This is a literal question, not advocacy. I haven't been paying enough attention to know what you mean.

Someone proposed adding telemetry to the compiler. People reacted to this as they usually do to telemetry. Google reacted to this as they usually do to criticism.

Go telemetry will be opt-in. https://groups.google.com/g/golang-dev/c/73vJrjQTU1M/m/qPpgO...

Re: Common Lisp Implementations in 2023

#240

Post by mark_l_watson »

medo-bear wrote: post #238
nextos wrote: post #164

Earlier quoted context omitted.

CLSQL, most graphics toolkits or lisp-stat.

for ORM people tend to use Mito. i think lisp-stat library is actually being developed. however one numerical cl library that doesnt get enough mention and is being constantly developed is petalisp for HPC https://github.com/fukamachi/mito https://lisp-stat.dev/ https://github.com/marcoheisig/Petalisp

Thanks for mentioning Mito, I had not seen that before. I used to rely on database migrations with Ruby’s ActiveRecord, it would be nice to have that for CL.
Post reply on HN