What happens when you type a wrong 'LISP-based JSON' block inside LISP?
When reader macros reach this "inline JSON file segment", what kind of errors start appearing?
My guesses
1.They resort to some overarching ParseJson()??? function generating exception
2.They generate some local "reader macro" error
What do lispers think of this C++ inline JSON parser?
https://github.com/nlohmann/json
>>2
When C++ uses operator overloading and templates its horrifying and disgusting(Analog Literals, anyone?), when Lisp does it with reader macros its Elegant and Beautiful.
I have the feeling if reader macros were added to C today, most programmers would ban them from their projects because they'll be treated as C++ abominations that result in code that is too complex to debug, dealing with inline template/operator expansion in every potential line of code. Obviously C preprocessor cannot handle such 'power' and C lexer would not be able to determine the intent when syntax is dynamically altered by code.
One of C's strength is readability, and C code is obvious when you
read it(macros can be mentally expanded too with some effort).
>>4
Is this a joke? C is famous for its nonsense type declarations and the endless confusion around the differences between pointers and arrays.
>>5
http://c-faq.com/decl/spiral.anderson.html
http://c-faq.com/aryptr/index.html
Isn't it kind of annoying that a Lisp/Scheme textboard has to listen to so much C spam?
>>6
Of course by readable we mean following arcane and counter-intuitive rituals.
>>7
Lets instead talk about the languages that are used to develop Lisps and Schemes. Its far more important than some C.
>>9
What do you mean, Lisp can be self-hosting, so it depends on nothing beyond the physical computing hardware.
>>10
Which Lisp compilers are self-hosting?
I'd like to check something that is entirely dependent on LISP itself.
>>11
Usually when a lisp compiler is self-hosting there is some small amount of assembly involved to avoid the bootstrapping problem, this is the approach Loko, and T take for example, I think T also has a trivial amount of C, which is not uncommon:
https://scheme.fail/
http://mumble.net/~jar/tproject/
>>11
I thought SBCL/CMUCL would be self hosting, but I check and they have a part written in C that. But in principle, there should be no problem with it, you'd just have to generate a Lisp environment and dump it.
>>9,11
I find the implication behind this argument hillarious. Just because a compiler or interpreter for language A is written in B, B must be "better" than A? Like A wasn't compiled by some other compiler, or written by hand? And as anyone knows, no processor runs interprets programming languages, just binary code. There are many things to care about a langauge (how it handles errors, what overhead it incurrs, etc.) but this is a kindergarden-tier mentality.
>>14
Insecure lispers cannot admit dependence on C/C++, because it stings their 'unique and special' mentality. Its like discovering that plastic is made from oil, then pointing out that plastic can be made from organic materials and showcasing how you can recycle plastic to demonstrate 'plastic independence'.
>>15
I'm not really interested in getting involved with this discussion, but I think I might make some comments to see if it cools things at all. Wouldn't your argument be more precisely that Lisp implementations as they exist today are dependent on low-leveler languages (such as Ada, Fortran, C, C++, or assembly) for bootstrapping. Loko Scheme as mentioned earlier is bootstrapped on nothing but assembly, and the author writes drivers and such in their implementation. There are also a few lower-level Lisp implementations like Scopes, Bone, and Carp; there's nothing inherent about Lisp which says it has to be meaningfully "higher floor" than Ada. I could see someone making the argument that due to C's momentum that to program real programs today you need to interact with it, but I don't think this is anything inherent about the language.
>>15
You still have to explain how Lisp "depends" on C. The way you use that word is meaningless.
>>17
You need a C compiler to compile most Lisp/Scheme compilers,
compiled code heavily depends on C libraries(and of course libc, but libc is linked by everything except maybe FreePascal).
>>12
On that topic, this seems to have just come out: http://t3x.org/lfn/index.html
>>18
So? You still haven't presented any argument.
>>19
Arguments are not required when you have facts on your side.
>>20
Yes they are, facts are not arguments. Facts are facts and prove or disprove arguments.
A fact is that most operating systems in use today are either of the unix lineage or related to it, so the fact that C is being used, is a historically contingent point. If I choose to write in Common Lisp, my programms are portable enough to run on entierly different operating systems, and entierly different compilers/interpreters. Hence, Lisp is not "dependent" on C, because there is no causual necessity between that statment and the observations that C is commonly used to implement or bootstrap compilers, on operating systems inclinded to C to begin with.
My LISP code is totally portable as long as I write a compiler for every platform I want to run it on.
>>22
That's true for every language...
>>22
You have reached a new low if you feel the need to attack Lisp on portability.
>>22
Yeah, exactly. C itself has nothing to do with Lisp, it just happens to be the language that was used to implement it. C has no specific features that cause Lisp to "depend" on it, besides being the main language of many operating systems. If a different language had similar status to C, it could also be used.
Lisp was created long before C and there are modern implementations that do not need C.
So programmers deliberately choose C to implement LISP. Why is that?
LISP is sophistry.
C is truth.
>>27
Because C is one of the main system programming languages on *nix platforms?
>>27,29
C is also a language that's very often taught in universities, the only other low-level language taught is typically assembly, and this is at once lacks many of the higher-level features of C, and is not portable, making it difficult to make an implementation targeting multiple platforms. If you want to write a compiler then chances are you are going to use the best language for the job that you are aware of, I think many people are also not even aware that there are alternatives which are meaningfully different, like Ada, so they don't know that it might be of some utility to actually learn these languages in order to bootstrap their compiler. Regardless one should consider Hume's law: can't get and ought from an is, that is you can't reason directly from descriptive statements to prescriptive statements.
Imagine a CS graduate that knows nothing but LISP.
>>31
I'm not sure the implication.
Why are LISP/Scheme developers choosing C/C++, not Ada,Rust or FreePascal? There has to be something competitive about C/C++ that isn't mentioned often that makes it better for designing compilers/interpreters. What is it?
>>33
Why not state an opinion instead of asking loaded questions and ignoring existing responses which don't sufficiently align with your opinion?
C is a complete language, compiler, operating system, documentation system, development system, etc. for controlling computer hardware.
LISP is a neat thing you can do if someone else controls the hardware for you.
>>35
I can live with that; although, I'll add that our all-in-one solution was just too expensive at the time, and it turns out worse-is-better is very affordable.
Your all in one solution was a marketing hoax that killed AI for several decades. LISP machines have never been cheaper or more readily available than right now due to FPGAs. Still no interest.
>>37 "all in one solution" is actually an old meme "the Right Thing(LISP machine) vs Worse is Better(Cheap C-based Unix workstation)";
"The right thing" is a big system dependent on all its parts being right - its marketed as fully solving all problems it was designed to do, a LISP machine e.g. solved all problems with LISP memory use by tagging objects in hardware.
"Worse is better" system produces systems that are better in some critical aspects that customers demand and ignore everything else, lowering cost of production.
Your all in one solution was a marketing hoax that killed AI for several decades.
Interesting, I always blamed this on DARPA cuts, and The Fifth Generation Computing Project. I don't really know enough about the history of this truthfully, you might be right I don't know.
LISP machines have never been cheaper or more readily available than right now due to FPGAs. Still no interest.
I think a lot of this has to do with momentum. Ever since the IBM System/360 people have been far from eager to start from ground zero. There's a lot of risk, costs, and uncertain rewards (especially in terms of capital). It doesn't help that of course without economies of scale you'd never actually be able to do more computations on a Lisp machine in terms of raw flops or really any other relevant measure. Further FPGA's don't give you tagged memory, which is still an important aspect of a performant Lisp system and historically one of the most costly components.
"The right thing" is a big system dependent on all its parts being right - its marketed as fully solving all problems it was designed to do, a LISP machine e.g. solved all problems with LISP memory use by tagging objects in hardware.
Yah, tagged memory and garbage collection in hardware were pretty sweet for Lisp. This is sort of the nature of the game though, I doubt C would be excellent on many non-von Neumann architectures for example. Regardless it seems to me that this is a crucial point that we should learn from in the future. We should certainly look to make compromises with reality as it exists to make the best product for us rather than some ideal essence of perfect computation. "The Right Thing" in the context of a different reality is irrelevant, if not harmful.
"Worse is better" system produces systems that are better in some critical aspects that customers demand and ignore everything else, lowering cost of production.
I'm not sure if this actually reflects the history of UNIX. Research UNIX was licensed for existing affordable hardware such as the PDP-7, PDP-11, etc. that were present in universities at the time, for exceedingly low prices. It then gained momentum as students wanted to continue to use the thing that was familiar to them from university, and because it turns out that UNIX is easy to port. It seems to me from the beginning cost and momentum were the motivators, along with ease of ports. I'm actually not trying to make a moral judgement here, evolution is not something you debate, to make moral claims about this would be like being fussed about not being able to grow new arms like Chameleons or something.
(I was going to go to bed but I can't sleep)
C is a complete language, compiler, operating system, documentation system, development system, etc.
Are you out of your mind? There's no C operating system. What the fuck are you even talking about?
>>40
A C Operating system includes a C Processing Unit(secretly a stolen LISP machine surplus part modified to interpret C opcodes) with a basket of live lambdas connected to give lifeforce to unholy void pointer table where functions are created and destroyed in a cycle of Garbage Collection(hidden by epithets such as Cache Eviction). The machine weights 30 tons and is requiring 200 Amp current cables to operate. Only authorized Intel mainframe programmers who have advanced to the rank of Cee Grandmaster can be eligible for about 3 hours of computing time per week. Distribution of C operating system is subject to USA DoD export restrictions, as it appear to be a powerful artifact able of containing Spirits of Computation(not included with the purchase).
>>41
I'm saving this, the somewhat real C Processing Unit is called hobbit, only ever used in BeBox prototypes and theoretical hobbit based Apple newton. The widely accepted C standard describes some parts of an operating system and a development system, I'm not sure if that's what >>35 meant to push compared to a dialectic that has everything. The closest thing to a C operating system running on a C machine is Plan9 first edition using a hobbit BeBox prototype or Plan9 beta using a CRISP evaluation backplane from AT™T, if that even existed with support.
a powerful artifact able of containing Spirits
This is sometimes described as goetia but that extents to what everyone is using right now, not a specific artifact.
I doubt C would be excellent on many non-von Neumann architectures
C dominates Harvard as well as von Neumann.
>C dominates Harvard as well as von Neumann.
Most code written today is actually not C.
Orly? What is "most code written today"?
>>45
JavaScript