They insist on 'reader macros' being essential to modifying the JSON parser and parsing(reading-macro) JSON files.
Sorry, nope. Reader macros are central to extending and adapting a language, from within.
As if you need 'reader macros', them being an essential component
of JSON parsing.
Sorry, nope. JSON was just an example, not the focus.
>>287
Cool, now please parse this
JSON object1 = { "complex": 5, "object": [6, 7, 8] }l
char *string = "this is a regular string";
JSON object2 = [
1, 2, 3, object1, [[string], 10]
];And do this in the pro-processor, not during run-time.
Just one function. Lisptards cannot fathom this approach is much simpler and efficient, and instead propose we need to learn to write JSON inline, inside the C code for some esoteric reason.
Just a a reminder, >>251 wanted to see a feature that Lisp has that GNU C doesn't do. >>253 claimed reader macros, a well known tool in Lisp, that the poster obviously wasn't familiar with, due to a lack of experience with Lisp.
>>288
Again, due to the absence of basic reading comprehension, you fail to understand why the JSON example was brought up. The point isn't to show that Lisp has the best JSON parser or that this is the best way to pass gigabytes of JSON (the post says so too). Instead, it's a demonstration of the flexibility that reader macros give Lisp programmers, that C withholds.
All you would have to do, is to "extend GCC" to support something like this, which you seem to imply is a trivial feat. They are by no means trivial in (Common) Lisp, but they exists and are part of the standard, meaning that you can write portable code, with custom syntactic extensions, making programming easier, where good old S-Expression would be too cumbersome.
>>289
these features are only useful inside the paradigm of functional programming and many are too lisp/scheme specific to be useful elsewhere - its highly unlikely something like 'reader macros' will be adapted by C/C++ in their LISP form, unless you somehow convince
I'm not surprised, that is because the concept doesn't make any sense in C/C++ to begin with -- they have renounced the ability with the fundamental design, by adapting a... strange set of limitations...
>>290
Lispers, please concentrate on making Lisp deal with case in a sane manner instead of attacking other languages.
What do you mean, it's already been done: http://clhs.lisp.se/Body/f_rdtabl.htm
Also, nobody is attacking other languages, we're just saying that Lisp is different in a positive way :)
Don't worry, even though you're obviously and embarrassingly wrong, your wrong-ness is still valid, UwU~~~