Executable XML users challenge

provide any LISP macro with clear explanation of its structure and function
that is :
1.concise (max 10 lines)
2.does not have a C equivalent(at least not anything above 100 lines)
3.does not use any libraries or imported complex functions which are not in C
If you provide an exact explanation/commentary on what it does i'll try to make a C solution which
is equivalent to LISP one. If i fail to do so, LISP wins, if i provide a solution you can make another macro.
If all examples in the thread are provide with C equivalents, LISP loses.

in Lisp:
1. Use features provided in the language.

>>200
You compaining the C lack the full string processing suite, which is a bunch of separate, external library.
You LISP compiler simply includes this string processing code built-in.
If i use a library(and i can choose any library regex/parser/interpreter, i'm not limited by Lisp) i could accomplish the same thing.
I could even embed a full-blown LISP intepreter library, but you could call this "cheating".

>>202
This isn't just about processing strings, it's about the cost of making your own compiler for each trivial thing. It's a high cost in C. A compiler isn't just string processing.

>>203
Well if you're dead-set on replicating some braindead LISP byte by byte, you would have to write shim layers to interpret it, and obviously
not writing your own compiler/interpreter:this will too much hassle and you would need to write tons of LISP(...)
freely available compiler/intepreter : http://ecls.sourceforge.net/
You could just use ECL and the rest of the code would use C. It would not be as fast as C, and even maybe slower than some real form of Lisp, but it serves the purpose of exact processing.

>>204
I wasn't talking about anything specific to Lisp code in >>200 or in >>203. I was talking about how you can make up any language on the fly for describing whatever you want and write a mini-compiler that generates the code for that language (this comes with all the optimization your native Lisp compiler provides). In >>200, I showed you an example of DSL and the cost that was paid by 1)google's coders' time in implementing it (DSL compiler is 10MB of code) and 2) you who are using it (custom makefile, separate compiler, specialized API and funtionality which isn't trivial to extend and so on). The cost in Lisp for making DSLs is very low (like trivial general purpose code).

So you can see that this is easy in Lisp, but not easy in C. Sure, you can just include CL in your C code if you wanted to, but if you're using CL, why not just use CL? I find it a lot less work to write CL than it is to write C, and I wrote more C code than Lisp in the past few months.

This is as far as I have gotten:


#include <stdio.h>

#define BACKWORDS(a, ...) BACKWARDS(__VA_ARGS__) a
#define BACKWARDS(a, ...) BACKWORDS(__VA_ARGS__) a

void main() {
  int c;
  BACKWARDS(c, "fuck da police: %d\n", printf);
}

After preprocessing, this yields:


void main() {
  int c;
  BACKWARDS(printf) "fuck da police: %d\n" c;
}

If I can make the macro handle the case of one argument as just returning it, then it'll work...

>>205
If i was was designing languages everytime i program my productivity will be zero, since i would be designing the perfect language while the real  code, would be neglected, unoptimized mess which i would think of not as a living, running program but as bunch of meaningless strings my Perfect Language would transform into the perfect program.Of course since my Perfect language is so complex, only i could read it and only if don't forget the entire language.
i.e. your macro layer is inferior,convoluted version of void.h(which includes reusable functions) with arcane syntax you designed on the weekend out of LISPtration over the inability of LISP to achieve stuff normal languages can do without a separate sublanguage.

>>207

They come prepackaged with a sub language that will eventually fail to meet all of your needs.

>>207
The point is I don't see C programmers suddenly stopping, and writing LISP interpreters to maximize their productivity.
I could theoretically add a LISP-macro preprocessor which would transform my C code, but i would not be able to debug such macros
they would be like C code packed into lovecraftian structures you would need to mentally compile to understand their function.
It it a additional work which i'm not going to subject myself to, and i'll just simply write unmacroed, simple code and reusable functions.
it would be somewhat longer than Lisp, but i could understand it easily and it could be fixed, optimized and debugging without
any problem: its instantly self-evident, maximum i would lookup a macro from void.h(an C preprocessor can be much easier to understand instantly, since it just replaces text with text)

>>207
If i was was designing languages everytime i program my productivity will be zero, since i would be designing the perfect language [...]
It's not always a 'perfect' language, it's just what maps best to your mental model of the problem.
Of course since my Perfect language is so complex, only i could read it and only if don't forget the entire language.
Complex? Why?
i.e. your macro layer is inferior,convoluted version of void.h(which includes reusable functions)
This is just hilarious.
would be neglected, unoptimized mess which i would think of not as a living, running program but as bunch of meaningless strings my Perfect Language would transform into the perfect program.

As a matter of fact, here's some real-world situation of how development proceeded on a mid-sized project that I wrote a while ago:
- 2 days (on and off) to write about 1500 LoC of CL, about 300 written in a DSL, and the DSL implementation itself wasn't too big (some 200 LoC)
- Initial performance not bad (some 10-20 times slower than I would expect in C), at least for what it was meant to be used for (PHP or Ruby would be much slower for this).
- I decide to profile. After about 30 minutes of optimizing the functions profiling identified as being executed often and being slow, prformance was increased immensely (various algorithms were slightly changed to reduce their time complexity). Performance 1.5-3 times slower than C, way beyond what I actually needed for the task at hand.

Had I chosen to write that in C, it would have taken me a week to write and I estimate about 10KLOC and I would have to cringe each time I would have had to edit all the repetitive code that I would have to write by hand (autogenerated in my Lisp version).

In the end, I really don't care what you think about Lisp, I only care about what Lisp can do for me, but I do find all this Lisp-bashing that's been going on around here lately a bit hilarious. It's a bit like having some piece of locally verifiable truth ("theorem") for yourself (which you use for practical things) and then you have some people claiming that that trivial truth is false (and they can't use that truth("theorem") to attain some particular shortcuts, so their life is harder) - I see it as people making their own lifes more difficult than they have to and thinking their life is actually less difficult than my own - I can only pass by smiling and move on with my business.

Have fun with your void~

>>210
if its not a secret what project was that? 1500 LoC of CL sounds like a small program for C.

>>209

Yes, debuggin macros is a pain. When I use macros, I always write them first as a regular function that operates on a list of symbols, and then I test the function on various inputs for syntax, and I make sure that its output is what is intended. Then I have the macro use the function.

One other issue is that introducing new syntax to a language requires adding new compile errors for the user. If the user gets errors for code ey didn't write, it is very confusing for ey and they'll have to examine your macro to deduce what went wrong, which is time consuming and frustrating.

>>211
It's what I was talking about in >>200. A complex file format with a fairly rich structure and some compiled bytecode contained within it. The project was to make a tool that can translate/decompile it into readable/editable text which is then meant to be compiled back into the binary after editing, so basically a disassembler/assembler which can also go more high-level and act as a compiler/decompiler.

It wasn't the protobuff stuff, but it's similar enough that it would give you an idea about what you'd have to go through to implement something similar in C-like languages. Since the cost of doing a DSL in C is that high, it's just easier to give up and write the 10KLOC that just do the job directly, even though it would be a hack that you'd have to go through pain to maintain.

>>212
Have you used SLIME+Emacs macro expansion key-chords? Also, some implementations allow stepping into macros. Some macros can be a pain to debug, especially those which generate code which generates code (think of once-only as the classical example), but the average garden variety macro isn't that bad.

>>213
You could use some XML,regex or string processing library.

it is not necessary to write your own C code from scratch, unless you know you can optimize the problem much better than available solutions.
Reusing a bunch of libraries would be a simpler choice.

>>214

that's nice. I haven't written too many complex macros, so I haven't had the need for a more sophisticated technique yet, but I'll keep that in mind. I usually try to limit myself to storing code in lambdas, and calling them when needed. I haven't gotten into things like once-only yet.

>>216

You can't always do that. Sometimes the format of what you are working with is proprietary or not well known, and the support just isn't out there, or you can't use the support because of licensing issues, or cost. It is good to have a powerful language that lets you get things done quickly from scratch when you need to do it that way..

>>215
A few details on the DSL: it described the format directly and the macros generated Lisp code for serialization/deserialization (binary<->internal in-memory object) and compilation/decompilation (text<->internal in-memory object). Generated code was reasonably decent in performance as it just did everything directly.

Now consider the options for doing it in C(taking your XML description language advice):
- Load XML tree, interpret it as needed when doing any of the 4 actions mentioned before (compile/decompile/serialize/deserialize), performance for a C application doing that may even be lower than the Lisp one because it's interpreting the structure at runtime when the Lisp code doesn't look much different than what would be if you wrote all that code by hand
- Load XML tree, compile it into C code which does all that needs to be done, link and enjoy. Doing code generation may be tricky if you want to avoid symbol conflicts as well as other more advanced issues, maybe you can hack your way around it since you're the author, but don't expect other people to be able to easily modify the XML and avoid conflicts, at least unless you're very careful when you implement the compiler. It's still a lot more work to do it properly. Performance might be better than the CL version by some 1.5-3 times. Code generator might be bigger than actually writing it by hand (for this one example, you may or may not need to reuse the compiler much after this, so incentive is lower for going this way).
- Write it all by hand. Painful to write and painful to maintain.

Well, I don't see the problem of reverse engineering some format so arcane so i would need to write a language for it.
I would just write couple of parsing functions, which would fill a struct/malloced arrays of specific length with the decoded values
and convert it to XML-type format. probably reusing some library would help, but i could write much faster functions if i have the source code.
After a couple of hours optimizing my format converter/parser would outperform any LISP code on the planet,(unless the said LISP uses alot of inline assembler). After a couple of days it would be a work of art(and i consider myself an artist), which asm programmers would work hard to achieve(in general writing asm is much longer and time consuming), since writing correct
pipeline filling and cache-friendly asm is not as easy as letting the compiler optimize it(though it must be checked if manual optimization compile to correct sequences of opcodes, and in benchmarking if I see C code much inferior to asm, i would refine it until there is minimum difference, short of writing inline asm(which i'm not going to reuse: thus making C code parts superior)).
However i would not spend as much time on such projects, if i don't really need it.
If i used said format converter everyday, i would write it optimized from the start.
If it is a one-time job for rare case, i would reuse any libraries which would fit the task and forget about code quality(quick and dirty hacks need no quality).

of course if your format requires decryption or DRM bypass, the process might be longer, but not something i would start writing languages for.

In general such specific problems can be optimized to death(since the problem space is clearly defined), and i doubt only a LISP converter written by you exists if there is need for this format. Probably someone wrote such a parser/converter and you're reinventing the wheel

1 100 101 110 1000 1010
I need a [strike]0[/strike]0

>>222
You'd be surprised by the sheer amount of undcoumented proprietary formats which lack tools.

XML is like violence. If it doesn't solve your problem, you're not using enough of it.

>>225
XML is extremely unoptimized cludgy shit i would avoid(its bloated structure is horrible), if it was not a common format for porting data i would ignore XML entirely.
XML is for making the format parseable by software who have XML processing capability and its generally readable.

>>224
You should only use GNU/Freedom formats, infidel.

>>227
I'm pretty sure even rms wouldn't object to writing ``free'' tools for proprietary formats, especially if they're not patented. He might even encourage it as an act of liberating those formats.

>>226
XML was designed is intended as a data interchange format. One goal for XML is to be human editable and another is to be completely regular. You're using XML for its designated purpose.

>>228
RMS would condone the development of free tools that works with proprietary data formats, even if it was patented. He wouldn't sanction becoming reliant upon those specific tools as an integral part of a free system and would encourage the development (and usage) of a free equivalent.

Thinking about it all, i'm not against some improvement in the ancient C preprocessor.
Its not "perfect", and its not really expressive for code generation.
I proposed instead of Lisp macros allowing the programmers to define the preprocessor commands
If it was supported by at least one compiler, it would help writing C for many programmers and make code unreadable for others, with general improvement in code density, with shorter syntax and less cludges like >>28

>>230
Will it be possible to even read void.h after these changes? Don't try to explain it away with some drivel like "C is for expert programmers".

>>231
If you can read a file of Lisp macros why C macros pose such problems?

XML is extremely unoptimized cludgy shit i would avoid(its bloated structure is horrible), if it was not a common format for porting data i would ignore XML entirely.
I actually agree with this. THE WORLD IS GOING TO END

>>232
The problem isn't macros, but how the EXPERT C programmers abuse them to create void.h nonsense.

You can read about the improvements i have in mind here:
http://www.reddit.com/r/ExpertProgrammers/comments/lajbc/my_vision_for_future_c/
It would fix most of C problems, though C doesn't evolve in this direction.

>>235
This coming from someone who doesn't understand C well enough to have served on either C89 or the C99 committee...

>>235
And this is my personal favorite braindead statement..

11. casting eliminated from the language.

And what happens if I do some kind of packet checksum? Exactly. You don't know because you've never actually written any kind of real C code.

>>235
Also you brain dead stupid fucker...

22. Native support for binary file inclusion e.g. x=import("C:\data\logo.JPG")

This will never happen because this is implementation dependent. THIS BREAK THE FUCKING CORE IDEA THAT C IS MEANT TO BE PORTABLE! Holy shit are you stupid. Go fucking kill yourself.

most of C problems
u mena my C problems?

>>235

1. Not any improvement here; many compilers allow inline assembly in ways much superior to this;
2. This would actually worsen things out. Pointer types are required for alignment issues in processors. It would make things worse for both the compiler and the programmer;
3. Bitfields are simple to use, simple to write, highly extensible and even portable to a great extent. Bitfields were not designed to be "DERP BITVECTORS". No one uses bitfields as such. No one probably never needed "bitvectors", and if they did, they would simply have used a couple of words to represent their bit arrays, and shift operations to manipulate them straight ahead;
4. This is so against the overall design of your other suggestions, and the C language itself, it is not even worth an extensive comment;
5. You don't have many clues of how a compiler works, do you? The compiler must look up code references somewhere, and this "lookup" is the compilation itself, even if it is simply compiling a header file, without definitions. Actually that's precisely what happens when you include standard library header files. The fact is that the C language is the compiler's program metadata representation itself; replacing this with other form of representation (which would be required anyway) is unnecessary and removes flexibility, because C compiles fast enough to be used as such;
6. C shouldn't be what you think it should either. There's a reason why C is a language in which you actually can write unportable code. There's a reason why libraries exist. There's a reason why most people frown upon suggestions to "evolve" the language by stuffing them with "extra native functionality";
7. What? You must be kidding. You must be either a troll or must've been completely stoned when you suggested this. Excuse me. Do you know C at all?
8. Agreed. Wow!
9. Really? How would one design such a language feature without either breaking everything else, or removing the overall simplicity and straightforwardness of the language? Indeed, C programmers never implemented "shared pointers", because C programmers never needed them. C programmers write C programs. And C programs are still the fastest and smallest programs around. Think about that for a while, you might reach some enlightment;
10. sizeof is "native" (whatever the fuck you intend that to mean). offsetof is standard. typeof is stupid and vehemently against the spirit of the language;
11. This actually seems reasonable from your other suggestions, since casting is most useful for pointers anyway (and you "wisely" decided to remove all pointer types from the language). Otherwise, braindead, as one would quickly infer from the already stabilished pattern;
12. I'm starting to believe you don't have a single hint what C really is (or C++, or even other programming languages);
13. Another stupid suggestion. There are a number of ways variadic functions access their arguments. This would simply worsen things out, as expected;
14. Incredible. My comment in #12 seems to gain even more evidence. You do not have a clue what C is all about;
15. What?
15. WHAT?! You're stoned. You're definitely high as fuck. Not even raw stupidity can explain such a suggestion;
16. So, it means you have simply ripped the ISO standard apart. It also means you don't have a clue (wow!) of what a standard is, why does this kind of document exists, and why what you say is awesomely nonsense;
17. Interesting. I rather agree with this. Look! Many compilers implement things good enough in this aspect. You're really a visionary, ain't you?
18. Again, stupid. Registers do not simply work as in-processor variables you can operate on freely. Specially in CISCs, registers have specific purposes and not every register can be used on every operation; making them look generic is not simply stupid and inefficient, but conceptually wrong;
19. This will cripple language semantics, much like everything you've suggested so far. One program would behave differently from another which look exactly the same simply because one decided to mess with "DERP PRECEDENCE OF OPERATORS";
20. This would remove much flexibility (libraries are selected at link-time, they may be changed to whatever you decide when you compile the program), since the language is unaware of "libraries", and it should be unaware of libraries for that reason and many others;
21. Agreed in a tiny part. Many standard library features are better used as it is: library features. You must understand one thing: language is a relation between syntax and semantics, not "derp functionalities" piled up within specific syntactical kludges. This is why C and Lisp are real languages, and "Python" and many others are abominations. Probably the only parts in which it would make sense to fit inside the language are some very specific macros (offsetof and NULL, for example) and type definitions, which are always used and fit well in the overall grammar structure. But actually, the way it is now works exceedingly well for making people even bother about these ridiculous issues;
22. This would be interesting if serious, experienced people didn't care about bloating their code with data they can simply load during runtime anyway, much more efficiently (since it wouldn't pollute the address space with the entire file content). If the data is small enough to avoid this problem, it would be typed in the code as an static array;
23. Simply useless, and even confusing; the idea of a preprocessor is to do simple preparation tasks, it is not a metaprogramming tool. C is not Lisp;
24. Great. Now every type will look syntactically the same as a structure. This surely is among the worst suggestions made so far;
25. What the fuck do you mean by that?

Seriously, dude. No offense, but you really, really should avoid pot when posting online. And maybe study something before trying to "fix" a 40-year old language.