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

Why Lisp?

nyxt.atlas.engineer

Post reply on HN
Print view View original

311–320 of 339 posts

Re: Why Lisp?

#311

Post by medo-bear »

Blackthorn wrote: post #304
medo-bear wrote: post #223

Earlier quoted context omitted.

> They are not transparent what does this mean?

I mean "can it call blocking code without bringing everything to a screeching halt".

honnest question, can rust?

i very much doubt that there is anything in lisp that can prevent that from being implemented at a library level (library because lisp is ANSI standardized). if you can prove that lisp is inherently unable to do what you call transparent threads im pretty sure it would be a significant cs journal paper

anyway it seems to me that this discussion evolved from lisp doesnt support multicore/ concurrency/parallelism (false) to "lisp aint erlang" (truism)

if you want erlang just use erlang, or a lisp version of it https://lfe.io/

Re: Why Lisp?

#312

Post by pjmlp »

foldr wrote: post #232
pjmlp wrote: post #229

Earlier quoted context omitted.

Genera, TI and Xerox thought otherwise. Unfortunely all of them messed up on management, and fighting against free UNIX source tapes. "What you don’t use, you don’t pay for. And further: What you do use, you couldn’t hand code any better."

My original comment talked about 'portable CL'. I am interested though: how would you define an unboxed array of structs in Genera's dialect of Lisp? Your quote clearly applies to my example. You can avoid the boxing by hand coding the dot product computation over flat arrays; you can't avoid the boxing if you use a 2D vector abstraction (in CL).

You would use (make-array), and (zl:defstruct (:type :array)), so that you would use an array as backing store for the fields.

Re: Why Lisp?

#313

Post by foldr »

kazinator wrote: post #289
foldr wrote: post #262

Earlier quoted context omitted.

You're basically describing C++. Nothing in your link suggests a practical way of constructing unboxed arrays of structs in CL. And even if it did, it would presumably be one that worked only on a specific architecture.

The C++ that we have can only be used as an external tool: we write a character-level program into a pipe or file, which is read by an external program. This drops an object file that we have to process. I'm saying that we could have some Algol-like sublanguage with value semantics, and unboxed types. It could output code for a virtual machine, which could be further translated to native code. It would all be in Lisp…

That's all pie in the sky isn't it? I was talking about CL. The only practical suggestion I can take from this is that one could drop down to inline assembly in some CL implementations. It's unclear to me how that would help with the problem of defining unboxed arrays of structs.

Re: Why Lisp?

#314

Post by foldr »

pjmlp wrote: post #312
foldr wrote: post #232

Earlier quoted context omitted.

My original comment talked about 'portable CL'. I am interested though: how would you define an unboxed array of structs in Genera's dialect of Lisp? Your quote clearly applies to my example. You can avoid the boxing by hand coding the dot product computation over flat arrays; you can't avoid the boxing if you use a 2D vector abstraction (in CL).

You would use (make-array) , and (zl:defstruct (:type :array)) , so that you would use an array as backing store for the fields.

I don't think so? Judging by the documentation that's just the usual option (also available in CL) to have struct fields stored in an array, list, name value pair list, etc. There's no suggestion that it would accomplish unboxing in general. I guess it is possible that if each field of the struct had the same type (say, a float), then the backing storage for the struct would be an unboxed array of floats, and an array of such structs would then come out with its backing storage as an unboxed multidimensional array of floats. But:

* I'd really want to see this actually working to believe it. The documentation doesn't make clear what would happen in this circumstance. (Time to spin up OpenGenera? Ha!)

* At best this works for structures with homogenous field types. My example of a 2D vector happens to fit that criterion, but it is also useful to have unboxed arrays of structures with heterogenous field types.

http://www.bitsavers.org/pdf/symbolics/software/genera_8/Sym... (page 450 according to the on-page numbering).

Re: Why Lisp?

#315

Post by reikonomusha »

dataangel wrote: post #302
hajile wrote: post #142

Earlier quoted context omitted.

Check out Coalton.

Coalton static typing doesn't actually work, there's an issue filed that it breaks as soon as you do any mutation.

It is not true that "any mutation" causes issues. In fact, most idiomatic usage of mutation is problem-free and completely sound.

One can find out more about polymorphic mutation as a "counterexample" to Hindley-Milner type inference on Wikipedia [1]. It's a well-studied problem with space of solutions. Purity, weak references, the value restriction, etc. are all ways of dealing with this shortcoming of Hindley-Milner.

Interestingly, one of the first proposed solutions to this problem was suggested by Wright in the journal "LISP and Symbolic Computation" [2].

[1] https://en.wikipedia.org/wiki/Value_restriction#A_Counter_Ex...

[2] https://link.springer.com/article/10.1007/BF01018828

Re: Why Lisp?

#316

Post by lispm »

Paul-Craft wrote: post #307
lispm wrote: post #275

Earlier quoted context omitted.

I like Scheme, but prefer Common Lisp for its environments and the old-school feel of the language. > And there are some solid standards Good things don't come alone: R5RS, R6RS, R7RS, RNRS + SRFI X..Y, IEEE Scheme, Racket, ... > entry for 'kludges' That's a form of self-deprecating humor, if you missed it. There are many more funny index entries in CLtL. The core designers did not take themselves too serious. Especi…

> That's a form of self-deprecating humor, if you missed it. No, of course, I didn't miss that. ;) Yes, it was funny! But the mere fact that it's a joke made by none other than Guy Steele, and that Lisp as a language goes back to 1960, which is old enough to make it eligible for a retirement pension in most countries, tells me that there's a bit of truth to it.

Scheme is from 1975 with huge influences from Lisp -> 48 years.

Sussman is 76, Steele is 68.

I don't think it's a only a problem of Common Lisp, which, btw., is younger than Scheme (which wasn't created completely new in a vacuum). The Scheme Report revisions upto R5RS for example ignored a lot of practical problems (no error handling, no namespaces, no object system, ...). The kludges then were outside of the language definition. But having no error handling in the language definition is not better than having one with less than ideal integration into the language. It's just a different way to deal with the problem of features which need a deep language integration: writing a larger standard with compromises or just pretend that one defines a language primarily for teaching computer science concepts (and which lacks really necessary features like error handling). The language definition then should only have as many (very dense) pages, as a student could handle in introductory course.

R6RS was an attempt to get a more complete language, which then kind of failed and was controversial amongst users and implementors.

I'd think, a to defined a language with kludges, but which tries to address practical problems, is a respectable and useful approach. Being self-aware that not everything is ideal is also nothing to look down to.

Re: Why Lisp?

#317

Post by pjmlp »

foldr wrote: post #314
pjmlp wrote: post #312

Earlier quoted context omitted.

You would use (make-array) , and (zl:defstruct (:type :array)) , so that you would use an array as backing store for the fields.

I don't think so? Judging by the documentation that's just the usual option (also available in CL) to have struct fields stored in an array, list, name value pair list, etc. There's no suggestion that it would accomplish unboxing in general. I guess it is possible that if each field of the struct had the same type (say, a float), then the backing storage for the struct would be an unboxed array of floats, and an arra…

Accessors take care of reading/writing from the backing storage mechanism.

If you want to be really picky, don't forget the whole OS was written in Lisp, and even the C, Pascal and Ada compilers targeted it, and much follow the same semantics. The same folder has the manuals for C and Pascal.

And if you want to be really sure how it goes, there is the low level forms for Assembly like coding, e.g. sys:art-q, which is used to pack C structures into arrays.

Re: Why Lisp?

#318

Post by pmarreck »

ravi-delia wrote: post #297
pmarreck wrote: post #271

Earlier quoted context omitted.

I don't know of a rational basis for this other than simply being more comfortable with more syntax and fewer parentheses to trace visually. I did take a class in Scheme once so I'm not completely unfamiliar with coding in a Lisplike.

Yeah, taste is taste. I do get it- it's why I like Clojure's syntax more than CLs, but man I don't get commas. Or even Elixir, I love the language but its always painful to come back to the syntax. Pipe operator aside, that is.

Speaking of the pipe operator, do Lisplikes have anything like that, or like pattern-matching, or complex value deconstruction, yet?

One very nice thing in Elixir that ends up removing a ton of (possibly buggy) boilerplate logic on function entry is that the function heads pattern-match deeply on the structure of the input while also doing inline assignments.

Re: Why Lisp?

#319

Post by foldr »

pjmlp wrote: post #317
foldr wrote: post #314

Earlier quoted context omitted.

I don't think so? Judging by the documentation that's just the usual option (also available in CL) to have struct fields stored in an array, list, name value pair list, etc. There's no suggestion that it would accomplish unboxing in general. I guess it is possible that if each field of the struct had the same type (say, a float), then the backing storage for the struct would be an unboxed array of floats, and an arra…

Accessors take care of reading/writing from the backing storage mechanism. If you want to be really picky, don't forget the whole OS was written in Lisp, and even the C, Pascal and Ada compilers targeted it, and much follow the same semantics. The same folder has the manuals for C and Pascal. And if you want to be really sure how it goes, there is the low level forms for Assembly like coding, e.g. sys:art-q, which is…

(:type :array) is documented as the default. So there must be something more required to create an unboxed array of structs than just that.

If, for whatever reason, it is important to you to persuade the internet that the Lisp dialect of a long-defunct operating system was able to define unboxed arrays of structs, then I think you should at least show example code demonstrating this. The more salient point, however, is that Common Lisp can't do this.

Re: Why Lisp?

#320

Post by thorondor83 »

koningrobot wrote: post #246
7thaccount wrote: post #40

After learning Python, I wanted to take the next step and find what was better. I looked into a lot of languages reading books on Haskell and Lisp and many others. At least for my use cases (desktop scripting, numerical work... etc) I didn't find Lisp to be superior. Most of what I actually needed to do could be done simpler in Python. Python's REPL isn't near as good as CL, but it's good enough. Then the batteries i…

The one thing that I most wish Python had is Common Lisp's restartable conditions. They're like exceptions but they don't break your whole process if you don't handle them in the code. If you forgot to define a variable, you'll have the option to define it and resume computation. If you forgot to provide a value, you'll be able to provide one now and resume computation. As it is, Python just dies if something unfores…

This is a feature that is commonly overlooked. Interactive restarts are a life saver for long running processes.
Post reply on HN