201–210 of 348 posts
Earlier quoted context omitted.
How is that different from a value of type "empty tuple"?
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 = ()
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…
As someone that's also written hundreds of thousands of lines of assembly with macros I don't really see the comparison. Lisp macros are written in lisp itself. You can create complicated data structures, interate over loops, do file io, query databaes, access the network, whatever you want at compile time in lisp where as assembly language macros were never much more complicated than then the C preprocessor. I certa…
I also know that Lisp or assembler can do anything/everything. I don't like polish notation or the lack of structure in Lisp programs. Everything is a function (with only a couple of exceptions).
When I was a kid they made us learn C and Lisp as part of Cognitive Science degree. I don't really use either language, unless you count C++. But I do feel that between those two languages you can understand two ideals really well. One is the idea of a clean symbolic expression, the other is the idea of a portable language that lets you get to the core of what the machine is really doing. Both are useful ways to thin…
Some years ago, Paul Graham wrote about there being too conceptually clean approaches to programming Languages, C and Lisp. The C family is far more popular, but the trend is to take C as your starting point, and add Lisp features to it. Gosling said that Java drug the C++ crowd halfway to Lisp.
Earlier quoted context omitted.
Rust also has (almost) everything being an expression - things like this aren't uncommon: let x = if something { foo() } else { bar() } Things which don't have a logical value evaluate to `()` (the empty tuple), I believe.
> Things which don't have a logical value evaluate to `()` (the empty tuple), I believe. If Rust follows Scala then `()` is not the empty tuple, but rather Unit (void in C*).
Question: what would a LISP dialect with static typing look like? EDIT: Found an answer: http://stackoverflow.com/questions/3323549/is-a-statically-t...
I designed and built a statically-typed F-Expr LISP for my thesis, using some partial AST evaluation to trace and ensure every value had at least an initial value, and from that, type inference. So it looked like: (define fib (lambda (n) (let loop ((a 0) (b 1) (n n)) (if (= n 0) a (loop b (+ a b) (- n 1))))) Which would do nothing by itself, and be eliminated as dead code unless called. If we called it with: (fib 10)…
Earlier quoted context omitted.
Some years ago, Paul Graham wrote about there being too conceptually clean approaches to programming Languages, C and Lisp. The C family is far more popular, but the trend is to take C as your starting point, and add Lisp features to it. Gosling said that Java drug the C++ crowd halfway to Lisp.
I wonder what aspects of Lisp he was referring to. The programming model of Java is basically C++ with garbage collection, minus a lot of stuff that makes C++ unsafe and hard to parse.
Here is the context:
http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...
Earlier quoted context omitted.
And the implementation of garbage collection was, on at least two occasions, postponed. Once in the first implementation [1] and a second time in the early MIT Lisp Machines [2] (you just ran the machine until you ran out of memory which could take days or weeks, after which you saved the world to disk and rebooted). [1] http://www-formal.stanford.edu/jmc/history/lisp/node3.html [2] https://www.csee.umbc.edu/courses/…
McCarthy's writing style is highly entertaining. Although I still have no idea what "Pornographic Programming" is...
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…
Code readability depends mostly on giving variables and functions meaningful names, and function size/number of variables. That applies to all languages. Code layout/indentation is also an issue, but there's a single standard for Lisp, which Emacs is aware of.
This article has many misstatements in its first half. > John McCarthy wrote 6 easy things in machine code, then combined them to make a programming language. John McCarthy didn't implement Lisp in machine code. Steve Russell did. Implementing Lisp properly in machine code is not easy; you have to write a garbage collector. To do that in the early 60s, you had to first invent garbage collection . Lisp was and is bril…
This point reminds me of something interesting that I noticed recently despite having been familiar with basic LISP ideas for a long time.
If you carefully read McCarthy's original presentation of LISP, you can see that he seemed to be influenced at least as much by Kurt Gödel's work as by Alonzo Church's work.
In Church's lambda calculus, functions are abstract values that can only be used by means of function application. LISP evolved toward this style over time, but in the early history of LISP, functions were not abstract values but were represented by encoding into S-expressions. This encoding process resembles Gödel numbering.
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.
Earlier quoted context omitted.
They do if always matched 1:1, it doesn't usually happen, specially in big codebases, thus leading to CVEs.
They surely do not. Malloc is specified in such a way such that the request for memory can fail (which leads to returning NULL).