kbp

One distinction between Lisp and Python's docstrings that he didn't mention is that in Lisp, you can (and it's normal to) give docstrings to variables; you can then look these up later with DOCUMENTATION or however else you read docstrings:

    CL-USER> (documentation '*print-readably* 'variable)
    "If true, all objects will be printed readably. If readable printing
      is impossible, an error will be signalled. This overrides the value of
      *PRINT-ESCAPE*."
    CL-USER> (documentation '+ 'variable)
    "the value of the most recent top level READ"
    CL-USER> (defvar *variable* nil "a variable")
    *VARIABLE*
    CL-USER> (documentation '*variable* 'variable)
    "a variable"

> Yeah, because people usually compile their programs before running them.

The developers do, yes; with Javascript, they don't have to worry about compiling for multiple platforms like, say, a C developer would, they could even just ssh into a server and edit a single text file while everybody across Windows/Linux/MacOS/iOS/Android/etc can run the new version as soon as you save the file (mod browser compatibility issues, of course). I think their point was that Javascript is the only language that can do end-to-end simplicity like that.

> I'm not current on Node features, but that looks dangerous to do. Is that equivalent to reading the file and `eval()`ing it?

No:

    > const fs = require('fs')
    undefined
    > fs.writeFileSync('file.js', 'console.log("yes")'); require('./file')
    yes
    {}
    > fs.writeFileSync('file.json', 'console.log("no")'); require('./file.json')
    SyntaxError: file.json: Unexpected token c in JSON at position 0

Sure, but the point is that that exact same code will throw a type error in SBCL. It at least complicates what you need to do before you can say "what implementation doesn't behave like that?".

> what implementation really does that with SAFETY being 3?

LispWorks:

    CL-USER 1 > (declaim (optimize safety))
    NIL
    
    CL-USER 2 > (defun f (x) (declare (fixnum x)) x)
    F
    
    CL-USER 3 > (f "foo")
    "foo"

> And there is no undefined behavior at all.

Well, there is. Violating type declarations is UB in Common Lisp, the only thing the standard says about it is "the consequences are undefined". In SBCL, an error will be signalled, but there's no guarantees about what other compilers might do. This could show up if a Lisp programmer who primarily used SBCL was relying on the type system to do some of their input validation for them when portable code would have to actually check it (ie, in their head they might think their program will raise an error if you pass it garbage, when really it just invokes UB if you pass it garbage). I still don't think it's that big of an issue, and mentioning it alongside benchmarks certainly indicates some misunderstanding, but it's not completely baseless.

> What SBCL is doing to Common Lisp is similar to what C compiler vendors did to C. In order to win at benchmarks, C compiler vendors started to use UB as a license to miscompile optimized code, which got them better benchmarks.

I sort of see what you're getting at, but I think what SBCL does isn't really comparable to the C situation. The complaint people have with UB in C is compiler-writers treating it as a licence to do very unintuitive optimisations; it uses it as a justification for being extremely hostile to the programmer and then the defence is "well the standard said the behaviour was undefined, why would you think there's "obvious" code for the compiler to emit here?". In the SBCL situation, the standard doesn't guarantee any behaviour around that feature, and SBCL is using it as a licence to be more helpful to the programmer, so I think most of the issues people might have with the C situation don't really transfer.

For the great majority of programs, the difference doesn't matter either: breaking type declarations being an error (as in SBCL) vs being undefined (as in portable CL) aren't incompatible, as long as your program doesn't rely on a condition being signalled when you violate a type declaration.

I can see how relying on SBCL's interpretation of the standard would cause problems, but when the difference is that SBCL just changed "the behaviour is undefined" to "it is an error", I don't see that introducing a wave of unportable code.

> They get their benchmarks

Type declarations that can't be statically verified transparently degrade to runtime assertions; I don't think that choice was made to do better on benchmarks.

> at the cost of saturating the ecosystem with code that overuses UB, basically poisoning the ecosystem.

I don't think there's that much code out there that relies on errors being signalled when it violates type declarations as a part of normal execution (quick, link a few projects that make use of this), certainly not enough to say that trend poisoned the ecosystem.

Interestingly, in PicoLisp, if the car of a list evaluates to a number (but isn't a literal), it's taken to be the address of an fsubr (this is how all of the builtins are implemented; if you evaluate their symbols, you'll see they're bound to integers). If you want to do this with a literal number, you have to quote it, like ('1 2 3)

One thing about PicoLisp that might stick out for people coming from CL, Scheme, or Clojure is that it's dynamically scoped (like most Lisps, historically), so you can't make closures. Compare this Scheme session:

    #;1> (define (make-counter)
           (let ((i 0))
             (lambda () (set! i (+ i 1)) i))))
    #;2> (define counter (make-counter))
    #;3> (counter)
    1
    #;4> (counter)
    2
    #;5> (counter)
    3

To this PicoLisp one:

    ? (de make-counter ()
        (let (i 0)
          '(() (setq i (+ i 1)) i)))
    -> make-counter
    ? (setq counter (make-counter))
    -> (NIL (setq i (+ i 1)) i)
    ? (counter)
    -> NIL
    ? (setq i 10)
    -> 10
    ? (counter)
    -> 11

Using `curry` and patterns, you can do substitutions into a "lambda", which can look like a closure, or not:

    ? (de make-adder (@base)
        (curry (@base) (n) (+ @base n)))
    -> make-adder
    ? (setq add-three (make-adder 3))
    -> ((n) (+ 3 n))
    ? (add-three 5)
    -> 8
    ? (de make-counter ()
        (let (@i 0)
          (curry (@i) () (setq @i (+ @i 1)) @i)))
    -> make-counter
    ? (setq counter (make-counter))
    -> (NIL (setq 0 (+ 0 1)) 0)
    ? (counter)
    !? (setq 0 (+ 0 1))
    0 -- Variable expected ; oops, we're trying to redefine 0

> Taking recursion away seems like an unnecessary limitation

Modern Cobol doesn't seem to have this limitation, eg http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/handhel.... When Cobol originally appeared, call stacks weren't standard, Lisp didn't exist yet, and neither Fortran nor Algol supported recursive functions; it made sense at the time.

> So no function calls?

No recursive ones. If you forbid (direct or indirect) recursion, then a function's local variables can all be static rather than stack-allocated. Similarly, each function could have a hidden, static "return address" variable (since all parameters are static, it's really just a hidden parameter) that is set behind the scenes when a procedure is invoked and jumped to when it exits.

edit: I was just guessing how you'd do return addresses, but it looks like that is how they used to work. From Wikipedia: "Machines before the mid 1960s—such as the UNIVAC I, the PDP-1, and the IBM 1130—typically use a calling convention which saved the instruction counter in the first memory location of the called subroutine. This allows arbitrarily deep levels of subroutine nesting, but does not support recursive subroutines."

Ancient Fortran also didn't support recursive procedures, and they were only sneaked into Algol 60: https://vanemden.wordpress.com/2014/06/18/how-recursion-got-...

> For my expander I actually implemented all let forms, for instance, as macros that reduced to lambda applications.

> Now other lisps might have more forms that don't reduce quite nicely, I'm not sure, I still strongly believe in my original point that lisp practically has no syntax

This isn't an argument against Lisp having syntax: it does have those operators, and each one defines its own syntax. The fact that they can be written entirely in the language itself doesn't mean Lisp doesn't have syntax, it means that Lisp has extensible syntax: you can add more syntax whenever you like, and in some dialects, you can remove or replace the pre-defined syntax forms. Syntactic sugar is still syntax, too: in C, arr[i] is just sugar for *(arr + i), but I don't know anyone who would claim that array indexing isn't part of C's syntax.

Closely related are generators and gatherers: http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node362.html

The section in the preface that GLS' note refers to reads:

"X3J13 expressed interest in the other two approaches (series and generators), but the consensus as of January 1989 was that these other approaches were not yet sufficiently mature or in sufficiently widespread use to warrant inclusion in the draft Common Lisp standard at that time. However, the subcommittee was directed to continue work on these approaches and X3J13 is open to the possibility of standardizing them at a later date. Please note that I do not wish the prejudge the question of whether X3J13 will ever choose to make the other two proposals the subject of standardization. Nevertheless, I have chosen to include them in the second edition, in cooperation with Dr. Richard C. Waters, as appendices A and B, in order to make these ideas available to the Lisp community. In my judgement these proposals address an area of language design not otherwise covered by Common Lisp and are likely to have practical value even if they are never adopted as part of a formal standard."

They didn't end up making it into the Common Lisp standard, but they're on Quicklisp, so getting (both of) them is as simple as (ql:quickload :series), and then you can load them with (series::install).

It sounds like you're the kind of person who'd prefer DOTIMES[0], DOLIST[1], and so on. Lisp has a lot of different ways to handle iteration, it's the curse of flexibility when people have such varying tastes. Another great option that often gets overlooked is the Series package[2], which lets you write in a functional style and then mostly optimises that away.

0: http://www.lispworks.com/documentation/HyperSpec/Body/m_doti...

1: http://www.lispworks.com/documentation/HyperSpec/Body/m_doli...

2: http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node348.html#S...

Wasn't thinking when I wrote that Lisp example; obviously you don't use OPEN alongside WITH-OPEN-FILE, it just takes the filename.

Here's a Javascript program:

    const x = 'lexically scoped';

    const f = () => x;

    const g = () => {
        const x = 'dynamically scoped';
        return f();
    };

    console.log(g());

It prints which scoping Javascript uses. When `f` is executed, `x` isn't defined in that scope (the body of `f`), but `x` is used in that scope: does the language look in the scope that `f` itself was defined in (the top-level in this case, but you can have nested scopes), or does it look, at run-time, at the scope that `f` was called from (the body of `g`)? That's the difference. The local-to-`g` `x` that dynamic scoping would use when `f` is called is not a global; it's an entirely different variable from the other `x` (even in a dynamically scoped language, calling `g` won't change the outer `x`'s value).

Dynamic scoping can be useful: for example, in Common Lisp (which supports both lexical and dynamic variables), STANDARD-INPUT is a dynamically scoped variable, so you can temporarily redirect stdin like:

    (with-open-file (*standard-input* (open "file.txt"))
      (function-that-reads-from-stdin))

And not have to worry about setting STANDARD-INPUT back to its old value when you're done. Scala's implicits are also often used to produce the same effect as dynamic scope.

As an aside, you could argue that `this` is dynamically scoped in Javascript (outside of new lambdas).

> Saying C doesn't have functions would be more like saying Java doesn't have objects

Your point was that that state of being able to have pointers to non-first-class values was a paradox, and my point was that C manages just fine (you clearly take it as an axiom that C has pointers).

> this is the kind of mistake someone who believes "C has arrays" may make and someone who believes "C doesn't have arrays, only some syntax sugar over pointers" won't make).

Sure; what are the corresponding gotchas with believing that Java has reference types? The fact that misunderstanding something in different ways will still give you problems (just believing that arrays are pointers will give you new mistakes to make, too, like with linkage and modifying string literals) isn't a very good justification for not attempting to understand it properly.

> you're going to have to explain the importance of not calling .equals()/.hashCode()/.toString() on random Objects either way

It's an obvious implication of what the default implementations do, and how they work is trivial to understand and an obvious choice for the default implementations if you know the concepts. If you understand reference types, then no further explanation is needed.

> you don't have to teach any extra special rules to avoid ==, != or arrays or primitives - you just don't teach any of those things.

You started off talking about working Java programmers in the real world, so I thought that's what we were discussing. Real-world Java programmers will see those things; you can't even write a main function without declaring an array. What about null? You can't get away with just leaving these things out, you do have to explain them as traps.

> I don't think either of those things are true. You have a bunch of extra concepts: class instances, references, and arrays

Those things you "removed" are in Java, though. Your advice was to treat them as black magic, not to actually modify the language (working programmers will see them). Knowing what features to avoid and be careful with when you can't avoid them (and presumably how to be careful with them) are things you have to learn and carry around in your head. And, as I pointed out, your version still requires people understand what references are (if you don't know what a reference is then what the hell is pass by reference passing by?). And wait then, so yours doesn't have references, primitives, arrays, or object instances? What values do you think are left in your theoretical subset?

C++11 and 17 both added a lot of big new features, and there's more planned for C++20. For the language itself, I think it's completely comparable.

This would introduce a weird inconsistency with cases for match and cases for switch regarding fallthrough, though. If it's going to look like cases in a switch statement, it should act like them, for better or worse.

> AFAIK pattern-matching is not a historical Lisp feature

Aside from full packages like what lispm mentioned, implementing pattern matching (and later, full Prolog-style unification) in Lisp is a very common exercise in beginner Lisp textbooks, going back decades.

Additionally, the Java language spec[0] does use the word pointer: "The reference values (often just references) are pointers to these objects, and a special null reference, which refers to no object." That isn't an implementation note, it's the language the spec uses to describe how reference values relate to object instances.

0: https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html...

> If the thing language has doesn't point to another thing in the language, you can't call it a pointer

It points to a tangible thing in the language, the object that you're operating on, that thing just isn't a first class value, so you can't store it in a variable or pass it to a function. If this reasoning means that Java doesn't have pointers, then C doesn't have functions or arrays, either.

> If you learn: objects are passed by reference

They're visibly not passed by reference, though, you forgot the extra rule that using '=' on a parameter is also broken and to be avoided (from the perspective of pass by reference). So your explanation has 7 additional special rules to learn, including leaving multiple very common elements of the language at "just don't touch that", and still assumes the learner knows what a reference is anyway; why not just use the language of the Java spec and describe the actual semantics as they're defined, instead of this awkward simplifcation that takes longer to explain and involves more concepts?

> without having to involve anything from outside the language.

You also keep repeating this point even after it's been explained to be false; what language are you referring to when you keep saying Java doesn't have these concepts? The Java language spec from Oracle says:

"4.3.1. Objects

"An object is a class instance or an array.

"The reference values (often just references) are pointers to these objects, and a special null reference, which refers to no object."

They are also a part of the visible semantics of the language, as has been explained over and over in this thread, and that way you get a simple, consistent language, and it's one that people actually use instead of a made-up, more complicated subset.

> > You get at the thing being pointed to by dereferencing the pointer.

> Which you can't do in Java! There's no * operator.

. and array indexing dereference pointers in Java, just as -> and array indexing do in C. I've already mentioned this several times.

> all these concepts from C/C++ that just aren't there in Java.

The Java language spec disagrees with you (before you said that explanation was pedantic; now it's incorrect?). As well, C and C++ did not invent pointers; you're the one insisting that Java's pointers aren't pointers because they don't behave identically to C's, I was saying that the specific differences don't change the fact that they're both flavours of pointer. No one is claiming that Java is source-compatible with C.

And really, there's no alternative explanation. You can learn each special case individually if you want and let your brain connect the dots to form the notion of how to use a reference without having sat down and thought about it and unified the concept, but that seems like so much work to get around learning a pretty simple idea that fully explains all of it without any special cases.

> I would say: a pointer has to point to something. Java doesn't have those because you can't get talk about "the thing the pointer points to" as a thing distinct from the pointer itself.

You get at the thing being pointed to by dereferencing the pointer. When you copy around handles to it, you can tell that you're only passing around handles, because if the object is mutable, then changes made from one handle show up in others, but your swap function still won't work. All you can do with the handle is pass it around, copy it, compare it to another handle with == or !=, dereference it, and add an index to it before dereferencing it. Dereferencing is specific to pointers, but for all the other things, they behave just like every over Java primitive does.

The effect of object variables just being pointers comes up in a lot of places, like "why doesn't my swap function work", using "==" to compare objects, initialising multiple variables to the same instance when you expected copy semantics, etc. These aren't rare things, and they're not difficult to think of. The fact that they're just pointers is the clearest explanation for all of that, and it by itself works for all of that.

Well, that's just the little difference I mentioned about C conflating arrays and pointers to them. The char ^ is being viewed as an array, which in C happens to be synonymous with a pointer to the start of the array. It's certainly not inherent to pointers that they be mixed up with arrays like that (or to strings that they be represented as char arrays).

As an aside, C's conflation of arrays and pointers was done because they're very closely related, and you can get very similar results to a C pointer-to-pointer by wrapping an object in a one-element array. In C, ^x is equivalent to x[0], and Java doesn't have ^x, so you can just use x[0].

More generally, though, a C programmer is virtually never thinking of 'the address 54fc892d': unless they're doing really low-level stuff, they won't think of it like that any more than a Java programmer, even using pointers all day, just like the Java programmer is; that's what I don't get about your point. The C programmer will think of ^x (or alternatively x[0]) as a handle on the string "foo", the same way a good Java programmer would. Some programmers (Java or otherwise) might confuse a handle on "foo" with "foo" itself, but they'll be bitten by that when they try to write a swap function or mutate a string literal or whatever.

Java's reference types are restricted pointers that you can only dereference using . or array indexing, you can't use array indexing on any arbitrary reference (it has to be of the right type, but C pointers were already strongly typed), you can only do arithmetic on them via indexing, and you're not allowed to refer to the non-pointer type. None of those differences make them not pointers, to me.

> > It still seems to me that the only good definition of an object variable's "value" in Java is its pointer.

> Good for technical pedantry maybe. Good for working programming, no - 99.9% of the time when you're talking about the "value" (not in terms of function-passing semantics, just generally) you want to talk about "foo", not about "an object reference to address 54fc892d".

This is almost exactly the same as pointers in just about every language that has them, though. You pass pointers around, copy them, and dereference them (which includes struct member access and array indexing), and that's about it. C is a little different because it somewhat conflates arrays with pointers to arrays, but that's hardly reason to decide that pointers are totally different. In C, you have a variable 'foo' whose type is 'T *' that when cast to an int happens to equal 0x54fc892d. The only abstraction mechanism you're asking for is the ability to store pointers in variables, it's nothing to do with their type. They're handles on objects, they're called pointers because they're values that 'point' to another value somewhere else, they're exactly what Java object variables are.

> Java is not pass-by-reference. C++ is

I'm sure you know this, but just to clarify, C++ allows parameters to be specially marked so as to be passed by reference. By default, arguments are passed by value.

> Pointers are part of the Java implementation, not part of its abstract computational model. Calling it pass-by-value when the values being passed are deliberately hidden from the user is a recipe for confusion.

Its abstract computation model is entirely equivalent to if someone did `typedef object_val *Object`, made `.` do the same thing as `->` and got rid of `->`, and then said you could only have `Object` variables, not `object_val`s. Saying that that's enough to make it not pass-by-value anymore seems ridiculous (especially when Java does still have primitives). If that were enough to make it something else, then following a style guide for C could make your code not pass-by-value anymore.

I understand what you're saying about the helpfulness to learners, but I think that they would be better served by just learning that Java classes are all reference types, their value is a reference to an object that '.' dereferences and so on, and that even if you don't want to use the word 'pointer', they happen to behave exactly like pointers. The reason I think that's better is because it also covers other common mistakes, like initializing multiple variables to the same instance and expecting copy semantics. The same mistake is being made in both that and the swap function from earlier, but the term 'pass-by-value' could only be to blame for one of them. Once you have your head around reference types, there's no problem with calling it 'pass-by-value'.

> The real problem here is that we have only two terms which we're using to try to distinguish between three different concepts.

It's still only two concepts, there's just the side effect of Java and friends' implicit pointers that makes things muddier. The Java function

    void swap(Object x, Object y) {
        Object temp = x;
        x = y;
        y = temp;
    }

is equivalent to the C program

    void swap(void *x, void *y)
    {
        void *temp = x;
        x = y;
        y = temp;
    }

and it has the same bug for the same reason. It's only the implicit nature of references in languages like Java that makes it not look like pass by value, but that implicit nature is there in other places as well (eg, the Java code 'Object x = y' is equivalent to the C code 'void *x = y').

I think the best approach is to just call it what it is, pass by value, and then also remind people if need be that objects are always pointers so it's passing a pointer by value.

> I still find it hard to picture an immutable OO language.

Picture an object-oriented procedural language like Java, and then make everything immutable; for every 'void' method, return an updated copy of 'this'; for every non-void function, return a tuple of the updated copy and the value you were going to return. No change to const methods, obviously. And you're done, and you can still take advantage of encapsulation, polymorphism, and inheritance without any hoops. You can even do it in Java itself as a style thing without too much effort and only a modest amount of boilerplate. Alternatively, it's not that much work to build this same thing out of lambdas and dictionaries, if your language has those but not objects (adding mutation into that object system would then be trivial) (and of course, you can build dictionaries out of lambdas and lambdas out of objects, if need be).