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

The Idea of Lisp

dev.to

Post reply on HN
Print view View original

221–230 of 348 posts

Re: The Idea of Lisp

#221

Post by qwertyuiop924 »

pjmlp wrote: post #194
qwertyuiop924 wrote: post #191

Earlier quoted context omitted.

However, IIRC, unlike Lisp, ST doesn't have any AST transformation or parsing hooks (macros and readtables, in Lisp parlance), so while ST has a lot of the semantic extension capabilities of Lisp (indeed, it's more semantically extensible than some of the less Object Oriented Lisps), it lacks the syntactic capabilities for extension. However, you know ST better than me. Am I right?

As far as I can remember no (Smalltalk was long time ago for me, 1995). But I think there is already quite a few things possible via messages and metaclasses, even if one cannot do actual AST transformations. After all, the whole image is accessible, so you can dynamically ask any object for its definition, or even compiled code (bytecode or JIT) and change them.

>But I think there is already quite a few things possible via messages and metaclasses, even if one cannot do actual AST transformations.

That's true. In fact, there are things that messages and metaclasses can do that you can't do with AST transformations without implementing those abstractions.

>After all, the whole image is accessible, so you can dynamically ask any object for its definition, or even compiled code (bytecode or JIT) and change them.

I still miss this in Lisp. Some Lisps had that, once, but it's uncommon nowadays. it happens in the commercial CLs, but those are expensive. OS CL implementations rarely have good image support (in SBCL, image saving actually corrupts the RAM state to the point of nonrecoverability, and the docs recomend fork(2)ing if you want to save an image and continue your app).

Aside from the proprietary CLs, PicoLisp is the only modern lisp environment that has this kind of dynamic capability AFAICT (and while it does sort of have images, in the form of external symbols, the language doesn't encourage using them like this. Also, calling it modern is a stretch: it has more in common with LISP 1.5 than, say, CL). And the Schemes? Don't make me laugh. Scheme has many strengths, but reflection isn't one of them. It's something that I really wish the Lisps had.

One of the reasons I want to try my hand at implementing Lisp on the Spur VM at some point.

Re: The Idea of Lisp

#222

Post by mypalmike »

sbov wrote: post #154
clarkd99 wrote: post #55

This great idea of Lisp (the simple syntax of function calls in round brackets) isn't much different than a good macro assembler even back in the 1960's. The only major difference was that more than 1 function could be defined in 1 source code line. (I think that machine code is nothing but a sequence of function calls where the function is the logic encoded in the CPU itself for each opcode.) Is it fair to compare t…

There's a lot here, but this one jumped out at me: > You can indent a Lisp program in any way but the language doesn't require any at all. Off the top of my head, isn't this true of basically all languages? Except one, and it got a lot of criticism for it (Python).

Fortran (at least the last version I used, which was F77) requires specific indenting.

Re: The Idea of Lisp

#223

Post by DonaldFisk »

clarkd99 wrote: post #185
sbov wrote: post #154

Earlier quoted context omitted.

There's a lot here, but this one jumped out at me: > You can indent a Lisp program in any way but the language doesn't require any at all. Off the top of my head, isn't this true of basically all languages? Except one, and it got a lot of criticism for it (Python).

After I wrote that statement I started thinking that C programs can be formatted so that they don't read very well also. In C, an 'if' is always an 'if' (unless you use the pre-processor to screw it up) but in Lisp an 'if' could be anything. I do like the idea of Lisp macros where you can run a Lisp program at compile time to generate the code that is then compiled inline. What I should have said was that Lisp has no…

I get an error when trying to redefine 'if' in SBCL, though you could probably do it through the abuse of packages. The C preprocessor does allow 'if' to be redefined, though. No one does that sort of thing outside of obfuscated C competitions, though, so it isn't really a problem in either language.

What you find easy to read depends on what you're used to reading.

Re: The Idea of Lisp

#224

Post by DonHopkins »

agentgt wrote: post #2

The conditional expression or more specifically everything being an expression is my favorite thing about Lisp. I did not know that McCarthy pushed to add it to Algol which apparently today is the ternary operator for most languages. It is annoying that so many languages (C, Java, C#, etc) have both a conditional statement (if-else) and conditional expression (ternary ?:). Really the if-else should be an expression (…

Expressions are limited, because they can only return one result. In stack based languages like Forth and PostScript, any function can take and return any number of parameters. In fact they can decide at runtime how many to take and return.

PostScript is a lot like Lisp in that it's purely and simply homoiconic: PostScript code is just normal PostScript data. The "ifelse" operator takes a boolean and two expressions (executable PostScript polymorphic arrays, or any other PostScript object, executable or not -- non-executable objects are just pushed onto the stack), and executes one or the other depending on the value of the boolean parameter.

I think Lisp's multiple-value-bind is an inelegant hack, compared to the simplicity of PostScript.

Re: The Idea of Lisp

#225

Post by smitherfield »

DonaldFisk wrote: post #213
smitherfield wrote: post #172

Earlier quoted context omitted.

No you don't, you merely need each index into an array to be a monad over all possible values it can contain. An array is itself and modifications are (take as arguments and return) its indices.

And how is that implemented under the hood?

Same as in a higher-level statically typed imperative language: mutable arrays contained within larger dynamic buffers for amoritized constant-time append and prepend.

Re: The Idea of Lisp

#226

Post by virtualwhys »

vertex-four wrote: post #201
virtualwhys wrote: post #200

Earlier quoted context omitted.

True, neither are useful as values, though Unit typically conveys programmer intent (to produce a side effect), whereas the empty tuple is, in Scala at any rate, quite rare. The empty tuple: scala> val empty = Tuple1(()) empty: (Unit,) = ((),) vs. Unit: scala> val empty = () empty: Unit = ()

Isn't that a tuple containing a unit, and therefore not empty?

It's the closest you can get in Scala to represent an empty value whose type is `Tuple`.

Re: The Idea of Lisp

#227

Post by wtetzner »

mroll wrote: post #93
wtetzner wrote: post #81

Earlier quoted context omitted.

I'm not sure I understand why it matters if the syntax requires braces or not. The things inside the braces are still expressions.

It matters because if the braces are not syntax, you can decide what code to execute as the condition body at runtime. set condition-body {puts "Hello, world"} if { $condition } $condition-body To get this to run, you need to splice in the condition-body like so, if { $condition } {*}$condition-body But you get the point.

But the "then" and "else" parts of the Rust "if" are expressions. What you're talking about doesn't seem to be related to which things are expressions, it's more like being able to eval code at runtime.

Re: The Idea of Lisp

#228

Post by ericbb »

rntz wrote: post #219
ericbb wrote: post #209

Earlier quoted context omitted.

> `lambda` and function application alone are Turing-complete, as McCarthy would have known. The credit here belongs with Turing and Church, not McCarthy. `atom`, `cons`, `car` and all the rest are just icing on the cake of the lambda calculus when it comes to computability. This point reminds me of something interesting that I noticed recently despite having been familiar with basic LISP ideas for a long time. If yo…

> Also, recursion arises in a different form in lambda calculus than it does in the approach to computability that is based on general recursive functions. Again, I think that LISP is closer to Gödel here than to Church. I think I understand most of the rest of your post, but I got lost here. Could you describe what difference you see here, and how it applies to LISP?

When I mentioned "general recursive functions", I was thinking about systems that define functions using a system of functional equations rather than using a lambda term.

Example:

    odd 0 = False
    odd n = even (n - 1)
    even 0 = True
    even n = odd (n - 1)
I think "rewriting system" is something similar. (I'm not an expert in this stuff so I'm providing hints for further reading more than anything else).

In these systems, recursion is "built in" to the formal language itself.

On the other hand, lambda calculus does not have recursion "built in". All variables are bound by function application so it is not possible to have recursive bindings like you see in these recursive function systems. You can define recursive functions using mechanisms like the Y combinator but these work by reconstructing something over and over as the computation evolves. It's different.

In McCarthy's paper, there is a system of toplevel recursive functions and there is a LABELS form that behaves in a similar way. Lambda calculus has neither of these.

One resource that describes recursive function systems of the kind I'm thinking of is the book "Lambda-Calculus and Combinators, an Introduction" by Hindley and Seldin (especially chapter 4).

Re: The Idea of Lisp

#229

Post by pg314 »

jjnoakes wrote: post #169
pg314 wrote: post #151

Earlier quoted context omitted.

Tcl does have a lispy feel to it, but s-expressions in Lisp are much more elegant than strings in Tcl, imho. Greenspun called Tcl the Lisp without a brain[1], which can be taken both as a compliment or an insult. [1] http://philip.greenspun.com/tcl/introduction.adp

Tcl commands are lists, not strings. Or more precisely, they are coercible to strings or lists, but a well-formed Tcl command string is always coercible to a well-formed Tcl list (not all Tcl strings are coercible to lists).

Thanks for the correction. It's been a while since I used Tcl and my memory of it was incorrect.

Re: The Idea of Lisp

#230

Post by lispm »

agumonkey wrote: post #41
lispm wrote: post #24

Earlier quoted context omitted.

And ML was originally written in Lisp. https://github.com/theoremprover-museum/LCF77/tree/master/sr... https://github.com/theoremprover-museum/HOL88/tree/master/sr...

someone tweeted that dan ingalls first smalltalk was in BASIC, I always assumed it was in lisp (considering Kay mention lisp in influences and that lisp was teh PL clay)

https://en.wikipedia.org/wiki/L_Peter_Deutsch

He worked on both the Lisp and Smalltalk low-level implementations at Xerox PARC.

Post reply on HN