Continued from /prog/174
https://www.youtube.com/watch?v=YaWVHyIBVeI
Transcript:
John McCarthy was a good programmer. I was a not very good programmer. And he had invented this wonderful language called LISP, which was based on the nice language that Newell and Simon had invented called... no... its called IPL. Information processing language. IPL is made of little atoms and its very tedious. And McCarthy's invention was... it was more like FORTRAN, which was... which is a language... IPL just had little instructions. FORTRAN has statements. Make this true. And LISP had statements with a very clean syntax. It only had... it basically has 5 basic verbs. Whereas FORTRAN is a big mess of arbitrary... has a big library. So, McCarthy's was a very elegant cleaning up of computer science. And thereafter there were two kinds of languages. The algebraic language FORTRAN and this recursive language based on Lisp, which they're now dying out because... of... In a Lisp program you can write a program that writes Lisp programs. So it has a kind of open future. Now no one actually does that yet, but its still possible. In the other languages its almost... you can't write a C program that will write a C program. Its just... there aren't any verbs of the right kind. So, to me programming hasn't changed much in 50 years because they got locked into this... strange set of limitations.
there is no need to continue this discussion.
Think of it as a chance for a fresh start. You have a brand new opportunity to list beautiful things LISP can do that other languages cannot.
Why continue with this? That was the worst thread I've ever seen here. I can see what I wrote earlier was ignored by the ignorant C programmers, as expected:
Notice one of the only things a fanatical C programmer will defend C with is popularity. AIDS is also popular, often by being forced upon others who don't want it.
This is another form of that popularity defense which I detest. If I implemented a C in Lisp, no one would claim that C is really Lisp, but implement Lisp in C and suddenly it's evidence everything is C. Meanwhile, C isn't the underlying machine code, no, that's just silly. The buck stops at C, for no particular reason other than it does.
When a language has a standardized semantics, the implementation is irrelevant. Learn this.
http://textboard.org/prog/174/249
That's simple. Unlike C, with its take-it-or-leave-it approach to system design, Common Lisp is more flexible, and tries to avoid making demands on how programs should be structured or written:
(setf (readtable-case *readtable*) :invert)
(defvar x 0)
(defvar X 1)
(format 't "~a == ~a" x X)
0 == 1That's a nonsensical thing for the program to tell me, but it works just fine. Another example is Common Lisp allowing the programmer flexibility in what default values should be for things, which many other good languages do. We can contrast this with the C and Go I-know-better approach, where the default value is zero or garbage, and the programmer is told to cope with it.
It does not work just fine.
You're not making LISP case-sensitive there. You're forcing the reader to invert the case of every character at read time. This creates the illusion of case sensitivity while silently breaking things in non-intuitive.
For example, readline tab completion is broken by using :invert. And if someone else wrote code using the default :upcase and used any capital letters that code will be broken if it is run in an environment using :invert.
An example:
(defvar openFuture 't) ; works fine
(setf (readtable-case *readtable*) :invert) ; no problems yet
(format 't "openFuture == ~a" openFuture) ; variable openFuture does not existWhat actually happens there is the first line creates a variable called OPENFUTURE not openFuture. Then we switch to :invert mode. Then the third line tried to print a variable called OPENfUTURE.
The supposed freedom of LISP here actually creates an environment in which everyone is forced to pretend the language is case insensitive.
Why continue with this?
[lets continue where I left off in the last thread ...]
>>5
I addressed the concern provided. Continue moving the goalposts. I'll continue to not give a damn.
>>6
I'd already written it for the last thread.
The obvious solution would be making Common Lisp case sensitive and turning keywords lowercase, to emulate the current status-quo.
Why would LISP developers want to maintain these :invert/:preserve cludges when case-sensitivity is the standard in most sane languages?
>>8
Common Lisp is already case-sensitive, and merely hides it very well. Case-sensitivity is overrated, and many languages don't accomodate it. Common Lisp technically accomodates it, but it can be ignored in practice.
Why would LISP developers want to maintain these :invert/:preserve cludges when case-sensitivity is the standard in most sane languages?
Most languages are insane, because they mimic C. A language like Ada, which is designed to avoid many common programming mistakes, is also case-insensitive. Anyway, the Common Lisp standard isn't changing anytime soon, because there's no reason to. Every Common Lisp program written still works. This is unlike sane languages, where books just a decade old are outdated.
The goalposts are not being moved. LISP is case-sensitive. But you can't use it like it is. Your choices are:
1) Pretend LISP is case-insensitive by secretly upcasing every character. This is the default behavior.
2) Pretend LISP is case-sensitive by secretly inverting the case of each character. This doesn't work in all scenarios and it breaks existing code for non-obvious reasons.
3) Stop pretending and preserve case of all characters which forces the user to type every LISP command in all caps and also breaks all existing code.
The option to simply use LISP in the way that everyone assumes it already works is not available. And if you try you will get seemingly nonsensical errors when you least expect them.
So one of the absolute simplest acts in computer programming, to type a character and have it interpreted in a consistent and predictable manner, an act so simple that programmers generally take it for granted, an act that other languages build entire hierarchical systems upon with ease, is 100% impossible in the freedom loving open future world of LISP.
What a strange limitation.
The obvious solution would be making Common Lisp case sensitive and turning keywords lowercase, to emulate the current status-quo.
You are exactly correct. LISPers actively choose to not do this. You can read mailing list posts in which adult humans in the 21st century argue about lowecase ASCII. The current state of affairs came from deliberate acts and is now maintained by deliberate acts.
To be clear, Common Lisp is not the only language to work like this. It is a foundational concept in all dialects including Scheme. If you find an implementation that seems to work the way it should, it generally is just using :invert as default reader mode instead of :upcase.
Every Common Lisp program written still works.
Unless you use the wrong reader mode.
Perhaps there is some body of ancient LISP code still in all-uppercase notation that is important to maintain backward compatibility with?
I'm really getting sick of this shit. Congratulations on complaining about one minor aspect of Common Lisp. Meanwhile, your C programs shit themselves and start convulsing at the lightest touch. C programmers have repeatedly made the same fucking mistakes for decades, and will continue to, and I don't give the slightest fuck that I've been forced into using C systems, that doesn't make them good. It's just a testament to how well unstable shit can work in practice, that it barely works well enough for people to be duped into using it.
The owner should delete these threads already.
Meanwhile, your C programs shit themselves and start convulsing at the lightest touch
That is correct. C is a low-level language that requires precision and understanding of every aspect: one mistake and segfaults start rolling.
I don't give the slightest fuck that I've been forced into using C systems
This is because LISP/scheme cannot be used as basis for system language instead of C due their current 'strange limitations' and quirks that prevent popularity. There are way to fix that: FFIs, better syntax, inline assembler,etc.
Lets take for example Mezzano Operating System:
Why would LISPers refuse to use it as basis for their workstation?
No one is stopping you from listing beautiful things that LISP can do in this thread.
Also, most LISP implementations are C programs. We already went over this in /prog/174.
>>15 It even has audio/video drivers!
https://github.com/froggey/Mezzano
Has anyone ITT even run it in a VM?
>>16
William Byrd on "The Most Beautiful Program Ever Written"
https://www.youtube.com/watch?v=OyfBQmvr2Hc
Mezzano Demo:
https://www.youtube.com/watch?v=Wd_-h5kRQLo
Introduction to Mezzano :
https://www.youtube.com/watch?v=-5Dw9FeSYZo
Making a Diablo clone in LISP:
https://www.youtube.com/playlist?list=UURb4fTtfgVtXbvjlqGDocDg
Notice one of the only things a fanatical C programmer will defend C with is popularity. The C programmer is generally unable to point to any particular design decision as beautiful. Is it beautiful, to be able to interleave control structures in nonsensical ways even other C programmers may not recognize as valid, with Duff's device being an example?
Is Pigeon's Device beautiful:
int pigeons_device(int a, int b, int mode) {
int result;
/* Isn't C a wonderful language? */
switch (mode) {
case 0: if (gloop(a, b)) {
case 1: result = arfle(a, b);
break;
} else {
case 2: result = barfle(a, b);
break;
}
}
return (result);
}What does anyone possibly gain from being able to write such a monstrosity? Lisp, owing to its list structure, doesn't permit this kind of vile shit. There's no gain from this. It makes everything more complicated, confuses the programmers, and benefits nothing whatsoever, but the defensive C programmer will just shrug it off as a quirk or footgun and let that be the end of it. Then, certain C programmers will have the gall to call Lisp ugly for well-documented behaviour they simply don't care for.
Is array decay beautiful? Is the decision to trade O(1) space and O(1) time in string length operations for O(1) space and O(N) time, with null terminators beautiful? Is associativity in array indexing beautiful? There's absolutely nothing the C programmer can point to as beautiful, but he'll point to millions of lines of code he had naught to do with and will likely never so much as try to read, and pretend that matters. It's an affront to good design that operating systems and other programs are so large. I'll end it with this.
He writes more than this then deletes some of it. This is the minimum needed to run his "proof it works" example.
(define eval-expr
(lambda (expr env)
(pmatch expr
[,n (guard (number? n))
n]
[,x (guard (symbol? x))
(env x)]
[(lambda (,x) ,body)
(lambda (arg)
(eval-expr body (lambda (y)
(if (eq? x y)
arg
(env y)))))]
[(,rator ,rand)
((eval-expr rator env)
(eval-expr rand env))])))pmatch.scm is loaded but not made available. We can make an educated guess that this[0] is pmatch.scm.
His "proof it works" example using chez.
> (load "pmatch.scm")
> (eval-expr '((lambda (x) x) 5) (lambda (y) (error 'lookup "unbound")))
5Isn't C a wonderful language?
Sure it is:
https://github.com/FrozenVoid/C-headers/blob/main/cor.h