Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

I know this isn't the identity function, but it's the same idea and a feeling I get when using Lisps that the language is kind of "complete". Including the identity function and having built in 0-ary functions where it makes sense are examples of this.


sort by: page size:

Isn't that just lisp-2-like behavior where functions and data maintain separate identities?

I don't understand. This looks like an implementation of lisp functions on top of an already existing Common Lisp implementation.

Seems a bit closer to the lambda calculus than most lisps. Building stuff up from such primitive types.

And whoever wrote it out took the time to follow syntax. Although I think this is actually Scheme? Defining a function in Lisp is slightly different if I recall.

it's not just the functionalness. you couldn't do it this way in Lisp/Scheme (I think?) because of the lack of multiple dispatch.

If you did (f 'x) for instance, you'd end up with things like (* 2 'x) which would blow up, since Lisp would try to compute the answer instead giving you '(* 2 x) back.


Ah. That's nice. Thanks for pointing that out. That's something I've not seen in any introductions to Common Lisp.

Are all of the standard functions documented this way?


Paving over the difference could seem convenient but it smells like a possible source of non obvious coding errors. AFAIK it's still worthwhile to know the difference between function identity and the value that produces identities.

Though, lots of this is inherited from common lisp where the list operations have more to do with lambda calc and the physical construction of the old lisp machines than they do anything else.


This is true, but the style of the code layout follows Lisp tradition, which may be more than 50 years old! :-)

It seems they're trying to formalize what Common Lisp and other languages do.

Yeah, currently this is a lisp without lambda or define.

I think the point to take home here is that LISP has a rich set of functions and building blocks around lists. Indeed, if you have something you want to do to a list, that function probably already exists.

Contrasted with many other languages that are catching up, but sometimes have surprising amount of boilerplate to process data.


You'd think this would be more understood given that pretty much the whole point of lisp is to be pretty close to just representing an AST without relatively few frills. The idea that we can represent most languages with a tree-like structure isn't particularly novel.

I hope you didn't say it's fun id(x): x;

Well, I did. :)

That's an interesting example. My first reaction was that one might be able to construct a similar anomaly by abusing optional arguments, but perhaps not: optional arguments to F don't get magically passed on to G. Still, I feel like I've seen function-signature constructs that would break the identity function similarly to how multiple-return does in your example. Maybe some twisted aspect of Common Lisp...


I don't see what that specifically has to do with Lisp. Virtually every programming language in use has a recursive hierarchical structure.

Because it's a lisp, code is a data structure

Neat! Reminds me of the Lisps around that still have f-exprs, like NewLisp (f-exprs are functions that take their arguments unevaluated, functions are mutable lists of code you can overwrite, etc)

I guess you could view it that way.

I am more used to thinking of it in terms of having function values (closures), but I think you could argue the lexical scoping that leads to SSA is all that's necessary once you have closures.

In any case, the vast majority of the lisp code I've read has been imperative and non-functional.


Lisp idioms like (mapcar function list) replace both looping and recursion with an aggregate operation, similar to APL; it's just not obsessively condensed into a single character syntax.

It reminds me the earliest implementations of Lisp where numbers have considered as lists of certain length.
next

Legal | privacy