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.

http://en.wikipedia.org/wiki/Turing_completeness

>>2
Well, main selling point of LISP = Powerful macro system. Show some of that power.

If provided C macro is obviously inferior it would show how superior and elegant LISP syntax is(wtihout judgement on performance):
If there is no clear way to accomplish some LISP macro it would show a deficiency in C
If the LISP macro is easily translated into C preprocessor, it would make C superior.
If the LISP macro requires a complex C hack or multiple C function calls, this would also showcase simplicity of LISP.

Regular expression matcher macro, which compiles to machine code.

>>5
provide LISP code with clear and exact explanation of what it does.
Don't provide abstract examples or claims or LISP superiority.

>>3
nope, it is elegancy. writing in LISP more like an art than programming.

also not sure about what you mean by "lines". LISP code is basically a single line.

>>5
also, C file(with regex library) can produce a C output file(fprintf result strings) which would be compiled as second stage
system("compiler -flags output.c")
Its not complex just awkward.

hey frozenfurfag if you want people to like you here do something awesome like port the code into a simple turing-equivalent cellular automaton or something.
no one cares if you can rewrite code in C.

>>5 it would work like this:
1.C code produces Output.C using regexes and string parsing functions.
2.C code calls compiler to compile output.c to output.exe
3.control is transffered to output.exe,C code stops.

>>6
When you pay me enough.

http://www.youtube.com/watch?v=iAjMIeKAuI8

>>10
Feel the elegancy of raw C!

>>13
In some cases you may want to compile and load dynamically object files like tiny .dll's or .o files into the parent process executable space,
but they all require calling the compiler at least once(to produce the executable object file: it may be even 1 function long).
Anyway i've not seen any clear example of LISP macro which does something exclusive to LISP, so i could compare and propose an equivalent(which could even not use regexes or some complex features, just C code).

>>14
exclusive to LISP
>>2

>>15
Not that, show something which is requiring to writing a page of code to work to replicate a line of LISP.
Even better: show equivalent "ugly" C code vs "elegant" LISP code, so i could try to rewrite it in far less space.

Inb4 Frozen writes a horrible LISP interpreter inside C

Executable XML users challenge?

It's not spelled ``LISP''.

>>17
I wouldn't write any run-time based code. Its very counterproductive to achieving any performance.
Compilation always has an advantage since it it not limited in time: a 1 hour compilation of an executable will outperform interpreted file which cannot spend time to interpret and optimize much, since it has to run at real-time.

>>18
http://www.defmacro.org/ramblings/lisp.html

>>16

(sort '(6 5 8 1 10 4) #'<)
(sort '(6 5 8 1 10 4) #'>)


#include <stdio.h>
#include <stdlib.h>

int comparator(const void *num1, const void *num2) {
    return *(const int *)num1 - *(const int *)num2;
}

int comparator2(const void *num1, const void *num2) {
    return *(const int *)num2 - *(const int *)num1;
}

int main(int argn, char *args[]){
  int arr1[] = {6, 5, 8, 1, 10, 4};
  int arr2[] = {6, 5, 8, 1, 10, 4};
  int i;
  qsort(arr1, sizeof(arr1)/sizeof(int), sizeof(int), comparator);
  for(i=0; i<(int)(sizeof(arr1)/sizeof(int)); i++) printf("%d ", arr1[i]);
  printf("\n");
  qsort(arr2, sizeof(arr2)/sizeof(int), sizeof(int), comparator2);
  for(i=0; i<(int)(sizeof(arr2)/sizeof(int)); i++) printf("%d ", arr2[i]);

  return 0;
}

>>22
I don't see anything wrong with the C code, here is equivalent macro
#define sort(array,function)   qsort(array, sizeof(array)/sizeof(array[0]), sizeof(array[0]),function)
#include <stdio.h>
#include <stdlib.h>
int comparator(const void *num1, const void *num2) {
    return *(const int *)num1 - *(const int *)num2;}
int comparator2(const void *num1, const void *num2) {
    return *(const int *)num2 - *(const int *)num1;}


int main(int argn, char *args[]){
  int arr1[] = {6, 5, 8, 1, 10, 4};
  int arr2[] = {6, 5, 8, 1, 10, 4};
  int i;
sort(arr1,comparator);
   for(i=0; i<(int)(sizeof(arr1)/sizeof(int)); i++) printf("%d ", arr1[i]);
  printf("\n");
sort(arr2,comparator2);
  for(i=0; i<(int)(sizeof(arr2)/sizeof(int)); i++) printf("%d ", arr2[i]);

  return 0;
}

>>23
except that it is ugly as shit and huge comparing to lisp version? seriously, in lisp you simply say "sort" and give an array and a comparison operator and viola. in C you are surrounded with type casting, stupid tricks like sizeof a/sizeof *a, had to redefine a simple comparison operator etc

is it pretty now?
#define STDMAIN int main(int argc,char**argv){;
#define STDEND ;return 0;};
typedef unsigned int u4;
u4 i;
#define sort(array,function)   qsort(array, sizeof(array)/sizeof(array[0]), sizeof(array[0]),function)
#define printints(array) ;for(i=0;i<(sizeof(array)/sizeof(array[0]));i++){printf("%d ",array[i]);};puts("");
#include <stdio.h>
#include <stdlib.h>
int comparator(const void *num1, const void *num2) {
    return *(const int *)num1 - *(const int *)num2;}
int comparator2(const void *num1, const void *num2) {
    return *(const int *)num2 - *(const int *)num1;}
STDMAIN
  u4 arr1[] = {6, 5, 8, 1, 10, 4};
  u4 arr2[] = {6, 5, 8, 1, 10, 4};
sort(arr1,comparator);printints(arr1);
sort(arr2,comparator2);printints(arr2);
 STDEND

>>25
it hurts to look

>>25
I lol'd hard. It's been FrozenVoid'd

>>22
You forgot to bring your ENTERPRISE C MACRO SYSTEM FOR SYNERGISTIC LEVERAGE.

#include <stdio.h>
#include <stdlib.h>

#include "CUDDER.h"

int main (void) {
  int array_1 [] = {6, 5, 8, 1, 10, 4};
  int array_2 [] = {6, 5, 8, 1, 10, 4};

  sort(array_1,
       lambda (const void * a, const void * b) {
     return *(const int *) a - *(const int *) b;
       } lambda_end);

  puts("first:");
  foreach (int i, array_1) {
    printf("%d\n", i);
  } foreach_end;

  sort(array_2,
       lambda (const void * a, const void * b) {
     return *(const int *) b - *(const int *) a;
       } lambda_end);

  puts("second:");
  foreach (int i, array_2) {
    printf("%d\n", i);
  } foreach_end;

  return 0;
}

CUDDER.h
#ifndef __CUDDER_H
#define __CUDDER_H

#include <stdlib.h>

#define lambda(...)                \
  ({                        \
    int (*__lambda_fptr)(__VA_ARGS__);        \
    int   __lambda (__VA_ARGS__)

#define lambda_end                \
    __lambda_fptr = __lambda;            \
  })

#define foreach(var, array)                \
  ({                            \
    int __foreach_i;                    \
    for (__foreach_i = 0;                \
     __foreach_i < sizeof(array)/sizeof(array[0]);    \
     __foreach_i++) {                \
      var = array[__foreach_i];

#define foreach_end                \
    }                        \
  })

#define sort(array, comparator)            \
  qsort(array,                    \
    sizeof(array) / sizeof(array[0]),    \
    sizeof(array[0]),            \
    comparator)

#endif

C is PIG DISGUSTING.

I'm happy to let the C autists squabble about performance. Just keep hacking away, cretins - make my LISP interpreter grow stronger!

//void.h 610 bytes
#define STDMAIN int main(int argc,char**argv){;
#define STDEND ;return 0;};
#define cv0p  const void*
#define cs4p const int*
#define is4 inline int
#define sort(array,function)   qsort(array, sizeof(array)/sizeof(array[0]), sizeof(array[0]),function)
#define printints(array) ;for(i=0;i<(sizeof(array)/sizeof(array[0]));i++){printf("%d ",array[i]);};puts("");
#define sortp(array,function)  sort(array,function);printints(array);
#include <stdio.h>
#include <stdlib.h>
is4 cmpn(cv0p num1, cv0p num2){return *(cs4p)num1-*(cs4p)num2;}
is4 cmpr(cv0p num1, cv0p num2){return *(cs4p)num2-*(cs4p)num1;}
//main.c 78 bytes
STDMAIN int i;int arr[]={6,5,8, 1,10,4};sortp(arr,cmpn);sortp(arr,cmpr);STDEND

Any other LISP macro which is hard to make in C?

>>31
I still can't see an elegant replacement to sort.

>>32
Are you blind? Legit question.

>>33
Yes, after seeing >>30 I carved my own eyes

A bit better without those void pointers
//523 bytes void.h
int i;
#define STDMAIN main(int argc,char**argv){;
#define STDEND ;return 0;};
#define cs4p const int*
#define sort(array,function) qsort(array, sizeof(array)/sizeof(array[0]),sizeof(array[0]),function)
#define printints(array) ;for(i=0;i<(sizeof(array)/sizeof(array[0]));i++){printf("%d ",array[i]);};puts("");
#define sortp(array,function) sort(array,function);printints(array);
#include <stdio.h>
#include <stdlib.h>
cmpn(cs4p num1,cs4p num2){return *num1-*num2;}
cmpr(cs4p num1,cs4p num2){return *num2-*num1;}
//main.c 71 bytes
STDMAIN;int arr[]={6,5,8,1,10,4};sortp(arr,cmpn);sortp(arr,cmpr);STDEND

(defmacro once-only ((&rest names) &body body)
  (let ((gensyms (loop for n in names collect (gensym))))
    `(let (,@(loop for g in gensyms collect `(,g (gensym))))
      `(let (,,@(loop for g in gensyms for n in names collect ``(,,g ,,n)))
        ,(let (,@(loop for n in names for g in gensyms collect `(,n ,g)))
           ,@body)))))

Used in other macros to make sure arguments are only evaluated once. For example:

(defmacro m1 (x)
  `(+ ,x ,x))

(m1 (f)) expands to (+ (f) (f)).

(defmacro m2 (x)
  (once-only (x)
    `(+ ,x ,x)))

(m2 (f)) expands to something equivalent to (let ((y (f))) (+ y y)).

>>35
//removed bloated strings identifiers
//411 bytes void.h
int i;
#define STDMAIN main(int argc,char**argv){;
#define STDEND ;return 0;};
#define cs4p const int*
#define R return
#define s(a,f) qsort(a,sizeof(a)/sizeof(a[0]),sizeof(a[0]),f)
#define pi(a) ;for(i=0;i<(sizeof(a)/sizeof(a[0]));i++){printf("%d ",a[i]);};puts("");
#define sp(a,f) s(a,f);pi(a);
#include <stdio.h>
#include <stdlib.h>
cn(cs4p n1,cs4p n2){R *n1-*n2;}
cr(cs4p n1,cs4p n2){R *n2-*n1;}
//main.c 55 bytes
STDMAIN;int a[]={6,5,8,1,10,4};sp(a,cn);sp(a,cr);STDEND

>>36
Why you would need such a cludge to protect yourself from evaluating arguments?
Can you explain it in C terms?

Ok, I want you to implement a special sorting algorithm. in this algorithm you will implement a list with floating point numbers and integers. return a list that floating point at the beginning and sorted, after that sorted odd numbers and finally sorted even numbers. oh and append "hello world" to end of the list

(setq l '(6 5 2.0 9 0.0 2 1 4.5 8))
(append (sort (remove-if #'integerp l) #'<) (sort (remove-if  #'evenp (remove-if #'floatp l)) #'<) (sort (remove-if  #'oddp (remove-if #'floatp l)) #'<) "Hello World")

>>39
and output list is
(0.0 2.0 4.5 1 5 9 2 6 8 . "Hello World")

>>38
#define square(x) ((x) * (x))

square(rand() % 10) expands to ((rand() % 10) * (rand() % 10)). The macro is for when you only want the argument to be evaluated once, and then you use the returned value in the body of the macro.

Add syntax to C using the preprocessor.

>>41
if you want the rand() function to be evaluated once and this used for such cases, you easily use a function
inline int square(int x){int y=x; return y*y;}

Hey FV, what's your job?

>>44
I'm a free artist

>>45
And what "a free artist" does for living?

for ints:
square(int x){return x*x;}
for floats:
fsquare(float x){return x*x}
for doubles:
dsquare(double x){return x*x}

>>46
Anything he likes.

>>48
And how do earn money? You parents?

>>46
wastes welfare

I don't have a job
Just say it, bro

>>45
read: free autist

>>52
Should autists really be allowed to roam free?

>>53
As long as they don't invent any programming languages they are relatively harmless.

>>39
>list with floating point numbers and integers
Why are you storing the array of floats and ints at the same place?

>>55
to irk your static typed shit,
duh.
inb4 void*

>>56
I would just use 2 arrays and sort them separetely, with most effective sort speciazlied for the specific type.
using a mixed type array(actually an array of pointers for each element, incredibly bloated compared to int array)
make any comparison
1.first check the type of element
2.convert to common comparator type
3.compare and return result in common type
vs
1.compare two elements

>>57
Thats just an excuse. You can't write such code in C.

>>58
int i;
#define STDMAIN main(int argc,char**argv){;
#define STDEND ;return 0;};
#define cs4p const int*
#define cf8p const double*
#define sort(array,function) qsort((void*)array, sizeof(array)/sizeof(array[0]),sizeof(array[0]),function)
#define printints(array) ;for(i=0;i<(sizeof(array)/sizeof(array[0]));i++){printf("%d ",array[i]);};puts("");
#define printdoubles(array) ;for(i=0;i<(sizeof(array)/sizeof(array[0]));i++){printf("%f ",array[i]);};puts("");
#define printevens(array) ;for(i=0;i<(sizeof(array)/sizeof(array[0]));i++){if(!(array[i]&1))printf("%d ",array[i]);};puts("");
#define printodds(array) ;for(i=0;i<(sizeof(array)/sizeof(array[0]));i++){if((array[i]&1))printf("%d ",array[i]);};puts("");
#define sortpd(array,function) sort(array,function);printdoubles(array);
#define sortp(array,function) sort(array,function);printints(array);

#include <stdio.h>
#include <stdlib.h>
int cmpn(cs4p num1,cs4p num2){return *num1-*num2;}
int cmpr(cs4p num1,cs4p num2){return *num2-*num1;}
int dcmpn(cf8p a,cf8p b){return (*a>*b)- (*a<*b);}

STDMAIN;//i'm not going to re/allocate anything useless at run-time.
int intarr[]={6,5,9,2,1,8};
double doublearr[]={2.0,0.0,4.5};
sortpd(doublearr,dcmpn);
sort(intarr,cmpn);
printodds(intarr);
printevens(intarr);
puts("hello world");
STDEND

>>59
#define STDMAIN main(int argc,char**argv){;
why the fuck. why is function macro define srsly wtf.
SexuallyTransmittedDiseaseMAIN

>>60
STanDardMAIN
STanDardEND(Program)

>>61
I know what it's supposed to mean.
I'm just asking why the fuck would you define every function as a macro.

>>62
To make reusable code. I could stick those macro in void.h and use them for years.

>>62
consider writing 1000 C files, each could be started with
int main(int argc,char**argv){;
or
STDMAIN
which one would be easier?

>>59
so you are still arguing that C can do anything LISP does in an elegant way? I can't see an array of floats, ints in your code. it does not create a sorted array, just prints a string. and lisp code is like in two lines yet your (insufficent) C version is huge
also
(*a>*b)- (*a<*b)
lol

to make 1000 empty C files with same exact line #include <void.h> is left as exercise to the reader.

>>64
The one where I don't use C I use scheme because I'm not programming for an 8-bit embedded microcontroller.

>>65
>(*a>*b)- (*a<*b)
see http://dis.4chan.org/read/prog/1320462348/5-6

>>68
why simply it is not *a-*b

>>63
I could stick those macro in void.h
Why did I even ask -_-
stick your dick in void.h get STD

>>69
doubles don't return 0, they return double 0.0

Your macros expands wrong half the time you know it right? for example

if(test)printints(array);
will expand like
if(test);for(i=0;i<(sizeof(array)/sizeof(array[0]));i++){printf("%d ",array[i]);};puts("");

do you really know C?

the type of return of *a-*b is double, and qsort expects the return of function to be integer.

>>72
I don't use such style:
if(test){printints(array); }

>>71
qsort is not stable, why do you even care equality?

If you expect to use short function syntax, write inline versions.
These are designed to avoid typing ;;; each time.

>>75
Its a comparator function which follow the standard qsort return type
1 first >second
0 equals
-1 second>first

>>74
it does not mean it is correct.

any way, I am done with this bullshit. enjoy your life

>>77
And standard qsort comparator function takes const void *.

>>78
I don't write inline version unless i need the return value from the macro.
printints(array) does not return a value, so it can be written as ;printints(array); to avoid typing extra ;; like
printints(array) puts("STD END MAIN");

>>79
 void* is the the universal type you can cast anything to it.

>>81
Yes but you are casting
int ( * comparator ) ( const void *, const void * )
to
int ( * comparator ) ( float *, float * )
which is not standard

>>82
whoops, reversed

>>82
I don't want any Haskell type restrictions in my C.

>>43
It was just an example. Sometimes you need to use a macro instead of a function, but you want the arguments (at least some of them) to only be evaluated once.

>>85
The function is textually identical to a macro call and can be used inline identically to a macro.

here are all variants of such calls:
int i;
#define STDMAIN main(int argc,char**argv){;
#define STDEND ;return 0;};
#define square_inline(x) ((x)=(x)*(x)) //evaluates X three times
#define square(x) ((x)*(x))  //evaluates X two times
inline int square_func(int x){return x*x;} //evaluates X one time
//pick any you like
STDMAIN;
int x=2;
printf(" %d",x);
square_inline(x);
printf(" %d",x);
x=square_func(x);
printf(" %d",x);
x=square(x);
printf(" %d",x);
STDEND

and a bonus void function
void square_via_pointer(int* x){*x*=*x;}

int i;
#define STDMAIN main(int argc,char**argv){;
#define STDEND ;return 0;};
#define square_inline(x) ((x)=(x)*(x))
#define square(x) ((x)*(x))
inline int square_func(int x){return x*x;}
void square_via_pointer(int* x){*x*=*x;}
STDMAIN;
int x=2;
printf(" %d",x);
square_inline(x);
printf(" %d",x);
x=square_func(x);
printf(" %d",x);
x=square(x);
printf(" %d",x);
square_via_pointer(&x);
printf(" %d",x);
STDEND

So, will anyone write an equivalent C macro for >>39
, or LISP wins?

>>90
if you can compare "hello world" to "0.0" you have problems

>>91
"hello world"
"0.0"
If you can't compare two strings, your language has problems.

>>91
Not that, 0.0 as double, which is 5th position
and "Hello World" as string at end.
Your macro can be used to compare 0.0 to "Hello World"
since i lack any Lisp interpreters, can you tell me what happens when you sort your "array" after the "hello world" is added?

>remove-if #'integerp
and he claims that using a separate array is different
Typical LITHP retard

>>94
Its functionally different, he checks the value type(which is stored by LISP) so the array is constructed in-place.
Its incredibly inefficient, but "elegant". Still he didn't answer what happen when you sort the entire array with doubles ,ints, and "Hello world"

>>93
You don't even need an interpreter for that, since the only function attached to "Hello world" is append, and it's obvious what does it do (if not, see http://www.gnu.org/software/emacs/emacs-lisp-intro/html_node/append.html). How were you going to compete with LISP without knowing it?

1. lambda can't be done without heap allocation and some kind of non-trivial memory model. See
http://en.wikipedia.org/wiki/Funarg_problem
http://www.paulgraham.com/accgen.html
so stop posting your preprocessor garbage


2. but that has nothing to do with macros. Here's an idea: add monads to C. https://github.com/richhickey/clojure-contrib/blob/78ee9b3e64c5ac6082fb223fc79292175e8e4f0c/src/main/clojure/clojure/contrib/monads.clj#L51

Even just picking a single Monad for C would be hard, to say the least for generalizing the design pattern. Take Maybe for instance. Write a macro that makes it so that if any assignment in a block resolves to NULL, the whole block immediately returns NULL (and the other statements are not even evaluated.)

>>96
Can you describe what happens after append, can you sort the list or not?

>>97
If i want to juggle lambdas and compare double to strings, i'd rather use JavaScript.

>>98
I can't, but how is it related to the code snippet from >>39?

>>99
Mah boi, you probably want to re-read your OP post.

document.write([6, 5,2.0, 9, 0.0, 2, 1, 4.5, 8].sort(function(a,b)a-b)+" Hello World")

>>101
What is this supposed to write? "Javascript is better than LISP"?

>>100
it shows that
A.provided C code does what LISP code does
B.LISP code is inefficient, checking each single value type, while constructing a new array for each sort.
C.LISP introduces a leaky abstraction of mixed array, while in reality you can't sort such mixed arrays(its undefined) even in LISP
D.the code in >>39 treats lists as sortable objects.

>>102
its the only possible non-defective way to write such retarded code.

>>63
To make reusable code. I could stick those macro in void.h and use them for years.
You can just use them for years without redefining the names as well you know.

>>105
I've written them from scratch just for the thread. Its not hard.

>>103
Wait, we do not talk here about efficiency. You have claimed you'll write an equivalent of the given LISP macro. Word equivalent includes, but not limited to doing what the LISP macro does. And we still can't see the equivalent C code yet.

>>106
It's not hard but it's pointless.
There is no good reason to make well known features into unknown features.

>>98
Stop asking if people can describe things to you. No one can describe things to you in a way that you will understand.

if you want something that can sort list of mixed objects you have to define what the results would be.
What if list contains another list? whats its position? what if list is a string array? or complex number?
Can you say if List A is comparable to String C which comparable to double R?

If you just stores objects in the list, why you object to storing each type in its own list?
DO you see how retarded is to mix objects and write functions specifically designed to fish out your specific object out of a LISP pile?

>>110
Please, point me at a LISP code which compares a list to a string, or a string to a double? Can't seem to find one ITT. As stated above, we do not want to abuse you with sorting lists of "mixed objects", but just numbers.

LITHP toilet midgets collecting integers from shitpiles.
I Lol'd, good one from FrozenTroll.

Such an easy victory, err.

>>112
>a LISP code which compares a list to a string
The macro sort when applied to your list.

>>113
No no, the integers don't come from C stdlib.

>>115
Cite that, please.

>>117
If sort is a sorting function, it should
A.sort an array
B.provided array is a list of objects
If it does not the provided code is defective since no functionality is present.
If it does sort an "array" with strings and doubles the implementation is defective enough to allow such retarded code to be written.
And results of treating such "comparable objects" are bound to cause any sort of errors you cannot think from safe-from-type-casts language.

I.e. you can't even use your sort function without writing yourself into
A.filtering code for each sort to fish out comparable types
B.undefined behavior for comparing incomparable types.

>>118
I have no idea what're you talking about. I just wanted to make sure we're talking about the same code snippet.

Any other shining examples of elegance from our local LISP user group?

>>120
code from >>39

>>122
That code does not compare lists to strings.

Ok, I want you to implement a special sorting algorithm. in this algorithm you will implement a list with floating point numbers and integers. return a list that floating point at the beginning and sorted, after that sorted odd numbers and finally sorted even numbers. oh and append "hello world" to end of the list
durr

>>123
The code could compare 0.0 to "Hello world", and it specifically fishes out integers exactly to avoid such mishaps.
As function, why it could not be used after you append "Hello world"?
Does it magically become unparseable when you add an item?
sort the list without your filtering code, i dare you.

After you finish your elegant LISP masterpiece, it would be helpful to comment its functionality, instead of abstract description.

>>125
There's no way for that code to compare 0.0 to "Hello world" since the only function applied to "Hello world" is append (I have already said that, haven't I?) The given task explicitly states that only numbers (namely integers and floating point numbers) should be sorted, everything else are your assumptions only, and don't belong to the task scope.

>>127
So sort function stops working after you append "Hello World" but not before? Isn't that defective?

>>128
Sort function exits right where it should exit, i.e. when there're no numbers left in the list. How is "Hello world" related to that function? It looks for me like you haven't read your task properly.

>>129
what will be output of this:
sort("Hello World",1,0.1)// since you add Hello World, it assumed you can deal with sorting it.
["Hello World",1,0.1].sort()  result in [0.1,1,Hello World] in JavaScript
What would be the result in LISP?

>>130
sort("Hello World",1,0.1) is not a valid LISP code, so it won't work at all. We do not try comparing strings to numbers as it has no sense, just numbers to numbers. Right as I said: your assumptions are beyond the topic, you were given a problem, and you're solving it for 6 hours already. This is definitely VIP quality.

>>131
First your "sort" "function" does not sort anything, it not actually a complete function,
since it require filtering code, and it doesn't handle lists with strings as you admitted.
Translating this defective code to C is impossible, but some(limited) semblance to that code is possible to write in JavaScript, see >>101

Second: to sort an array mean you can sort the entire array, not partially.
LISP cannot redefine the meaning of sort

ITT: FV nigga mad cuz he lost the game
Someone archive this thread...oh wait, you don't have to

Third: since you pretend the mixed array is homogenous, explain why you need to filter floats and integers?
If you need the filter to sort, why not prefiltering the array into float_array and int_array is not elegant enough?

>>99
If you wanted to juggle lambdas, it would mean you were enlightened.

>>135
There are some interfaces that virtually any data type can implement. An example is "pretty print".

Another reason to mix types in a container is if you're using it as an interface itself. To use Javascript as an example: you might choose to represent {name: "Frozen Void", age: 12} as ["Frozen Void", 12]. Containers and objects don't have to be different.

The reason to forgo static typing in these cases is that it means you don't have to do "interface calculus" ala Java and you don't have to worry about how much of an interface certain arguments are using etc. It's just less ceremony (and less naming of half-concepts) for the same thing.

Not that there aren't benefits to static typing, but they are mostly lost on languages like C and Java anyway...

>>136
sort(function(a,b)a-b) is not particularly enlightening. Also, i find it insulting to buddhism to assume some lisp programmer can figure our the nature of reality with eval and apply, which are merely empty forms hiding the underlying computational process to which LISPers are blind as before.

I hate your language X very much, not because it lacks feature Y, but because code that I write in X has a nasty habit of just not working, without any indication of why it isn't working. Lisp never gives me that trouble, and even when my Lisp code doesn't work, the tools available for debugging it (namely REPL, dynamic-typing, code-as-data, stack traces, profilers and functional style free of side effects) are so vastly superior to anything that I have found for X that fixing my problem is simple. And, seriously people, a language's speed is becoming less relevant with each new increase in processor speed, I would much rather program in a fast enough language that works and makes sense than in an unintuitive, convoluted piece of shit like X. --Lisper

>>132
No, you're wrong (dooh), it is a comprehensive function which can sort any type of lists by provided comparing function. I haven't said it can only sort numbers, that's your another assumption.

>>39
Hmm, i don't get it, why frozen is against this all the way about this, its just a void pointer array with pointers to floats, ints and char* strings.

>>141
Its trolling he doesn't intend to solve it as long as he can troll lispers with it.

>2011
JUST IGNORE HIS THREADS

>>138

If you don't find lambda even a little bit mind-blowing, you're either already there or will never make it.

((lambda (x) (x x)) (lambda (x) (x x)))

>>145
oh shit nigger what are you doing?

Fucking lambdas, how do they work?
And I don’t wanna talk to a computer scientist
Y’all motherfuckers lying, and getting me pissed.

>>147
I think you should talk to a computer scientist.

>>146

Nothing to add to this shit thread, but wanted to thank you for the hearty laugh. I think this is one phrase I'll never not find hilarious.

Additional Requirement 4.Provided code must be real, consistent with its purpose and bug-free. No hacks, glitches, or undefined behavior is allowed. If such defective LISP code is provided it will be judged as trolling and no C equivalent will be produced.

>>150
Thats not the problem. There are ways to replicate any LISP cludge or hack.
It would just be incredibly messy, long and retarded to even consider writing such stuff in 99.9% of cases.
If i start writing such bad code, i might as well switch to LISP so not to rape C with such idiocy.
LISPtards inventing toy languages inside LISP and expecting C code to replicate their braindead toy language, are also going to be ignored.
LISPtards making macros which use any regexs or calling internal LISP functions to produce code, expecting C to match them in compile-time flexibility, will be ignored(it is possible with ugly, long hacks and messy string processing with malloc/free which i'm not goign specigically write to match such LISP code. It is not that such macros are useless, they might be useful in some complex LISP code, but i won't touch such macros which would construst its code from regular expressions or require the compiler itself(its too convoluted and non-portable to write such code in C especially expecting to compile C output with a compiler as second stage:its possible but such code is defective by design,like 50 levels of nested Java Objects))
LISPtards making code which is not working for its advertised purpose like >>39 will be provided with C code which does what LISP code outputs or computes. Claiming that C code is not doing what LISP code does(abusing LISP generic data structures to write a cludgy half-working code), and trolling about its superiority will be ignored.

For the record >>39 is a dynamic structure which filters out a specific datatype to construct lists of datatype and sort it.
Such things are possible with realloc'ing an array and checking every datatype to ensure it fits the sorting function(defective, cludgy design).
Or you would not write such retarded contraption and store the data in separate arrays which is far more elegant, does not require specific filtering code for the sorting function, does not break the sorting function if the array is modified and is easily translated to C.

>>10
output.exe
.exe

facepalm.sh

Any Lisp macro is expandable into regular Lisp code, which could also be compiled to C. The only difference is that in Lisp, your code is easy to understand and compact, while the non-macro variant that you'd write in C will be a hard-to-understand mess (unless you don't know Lisp, then that's your only option). I could give some examples which are difficult to do in C(you'd have to have a program which generates another program which generates another program and you'd need a lexer/parser to avoid symbol conflicts that arise when using C's textual substitution macros, while in CL you'd get hygene for free with the gensym (in Scheme you'd get it for free without gensyms, but you'd give up the low-level defmacro which is just a function generating code at compile-time).

>need a lexer/parser to avoid symbol conflicts
When i need a lexer to write macros, i'm actually writing a complex code-generation script inside C, which a nested design of layered architectures: this signals something deeply wrong in design.
Its common here to assume that nesting a command mode in VIM(and extra command processor) or nesting extra layer of (LISP interpreter) on top of LISP is easy and elegant solution to problem, while in fact such half-baked solutions are far harder to debug,use and maintain.
The textual macros which are inferior in expressive power, serve their purpose better and don't require another layer of C.
So using LISP-type macros would be "more powerful" nesting macros ad infinitum and abusing recursion, but once you write it, can you reuse it or modify such complex code? I can handle 5-6 layers of C macros, but i can easily see what #define it expands into since its pure text.
In LISP case,i need to mentally compile code and cope with the entire language. Macro which are not obvious text replace require an order of magnitude more work to understand, let alone use.

>>155
When i need a lexer to write macros, i'm actually writing a complex code-generation script inside C, which a nested design of layered architectures: this signals something deeply wrong in design.
Yet this makes certain kinds of code much easier to write in Lisp since you don't need a lexer/parser, and much harder to write in C.
The generalized example would be how easy it is to write DSLs in CL, and how you need a whole lexer/parser to do them properly in C (and they may be slower if you're interpreting instead of compiling, which is again something that comes for free in Lisp).

>>156
how you need a whole lexer/parser to do them properly in C
First of all, you'll have to get PhD in compiler theory, becase parsing C/C++ is a hell - even seasoned pros spend years to force something done. Ask Stroustrup, how easy it's to come with new C++0x standard.

>>157
First of all, you'll have to get PhD in compiler theory, becase parsing C/C++ is a hell
Parsing isn't part of compiler theory.

>>158
Please, point a C/C++ compiler without a parser.

>>159
Please, point a Web browser without a font renderer.

>>160
Please, point a CPU without turing-completness.

>>161
Please, point a /prog/ thread without trolls.

>>162
Please, point a woman without a vagina.

>>162
http://dis.4chan.org/read/prog/1323338463/

>>163
http://en.wikipedia.org/wiki/Chromosome_abnormalities

>>165
http://en.wikipedia.org/wiki/Eugenics

>>166
http://en.wikipedia.org/wiki/Sociological_and_cultural_aspects_of_autism

>>167
http://en.wikipedia.org/wiki/Nigger

>>168
http://en.wikipedia.org/wiki/Most_nigger_mature

>>169
Wikipedia does not have an article with this exact name. Please search for Most nigger mature in Wikipedia to check for alternative titles or spellings.

    * Search for "Most nigger mature" in existing articles.
    * Look for pages within Wikipedia that link to this title.

>>167
Sociological_and_cultural_aspects_of_autism
Even the title sounds autistic.

Serious failure from both sides. You guys just suck.
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.

There is nothing which states that a macro may be disqualified based on whether or not it is efficient, or that the idea behind the macro may or may not be coherent. The rules stated inside the original post are the only official rules.

Conclusion: C is shit. >>1-171 is a faggot.

http://okmij.org/ftp/Scheme/CK.scm

>>173
In case you missed it, here is the central macro:
(define-syntax ck
  (syntax-rules (quote)
    ((ck () 'v) v)            ; yield the value on empty stack

    ((ck (((op ...) ea ...) . s) 'v)    ; re-focus on the other argument, ea
      (ck s "arg" (op ... 'v) ea ...))

    ((ck s "arg" (op va ...))        ; all arguments are evaluated,
      (op s va ...))            ; do the redex

    ((ck s "arg" (op ...) 'v ea1 ...)    ; optimization when the first ea
      (ck s "arg" (op ... 'v) ea1 ...)) ; was already a value

    ((ck s "arg" (op ...) ea ea1 ...)    ; focus on ea, to evaluate it
      (ck (((op ...) ea1 ...) . s) ea))

    ((ck s (op ea ...))            ; Focus: handling an application;
      (ck s "arg" (op) ea ...))        ; check if args are values
))
It's a continuation machine with a stack, mentioned originally in Programming Languages and Lambda Calculi, which eventually became the work Semantics Engineering with PLT Redex. Enjoy you are failure.

>>174
I don't understand such abstract bullshit with such vague concepts as "continuation machine"
Explain it in C terms, not your Computer Science major-speak. I learned C and every programming technique on my own.

>>175
http://homepages.math.uic.edu/~jan/homotopy.html

>>176
That not explaining anything. I want a clear and concise explanation, as i already stated in >>1
>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.

Do this one frozenvoid:


(defmacro (backwards-lol lis) (reverse lis))

This is a textbook example used to show lisp's generality with macros. It lets you write code backwards lol!


(defmacro backwards-lol (lis) (reverse lis))
#<unspecified>
(backwards-lol ("hi" display))
hi#<unspecified>
(backwards-lol ((newline) (display "The backwards ness isn't nested though.") begin))
The backwards ness isn't nested though.
#<unspecified>


Anyways, I'd like to see a proof of concept for it with C. I like pushing C's preprocessor to its limits.

>>178
What exactly you want
1. code which reverse a string of code
2. code which reverse a string of text

I don't understand
Explain it in C terms
IHBT

>>179
code is text

(reverse '(1 2 3))
(3 2 1)

>>179
1 is the case in >>178. The actual atom/elements of the macro are reversed before being passed to the compiler. In C, you need a lexer/parser to manipulate the AST like that. It's kind of an artificial example which has little use in practice, but I've written macros which did quite fancy code manipulations which are just not possible in text-substitution macro systems. The only way they would be possible is if you could hook/extend your C compiler within the actual program you're coding.

>>181,183
In case of reversing a string of code this does make sense in C, code will be corrupted.
In case of reversing a string of text, this would be a trivial string function, not a macro.

The process of reversing a string of text and sending it to compiler again is not complex either.
You just reverse a string of text, print it to file, and compile it.
Except it won't compile. Since reversing code will not be viable in C(C has real syntax, not textual soup of random words)and i can't find any practical example for the useless function i outlined above, and thus this code would not need to be written at all.

>>179

implement:


int c = 5;
BACKWARDS_LOL(c, "fuck da police because %d\n", printf)

I think the above has a chance of being done. Then try expressing:


int c = 0;
for(int i = 0; i < 11; ++i) {
  if(i&7) {
    ++c;
  }
  printf("%d: %d\n", i, c);
}

as:


BACKWARDS_LAWL(
{
  ;(c ,i ,"%d: %d\n")printf
  {
    ;c++
  }(7&i)if
} (i++ ;11 < i ;0 = i int)for
; 0 = c int
)

>>184
In case of reversing a string of code this does make sense in C, code will be corrupted.
A C equivalent can be given that wouldn't result in corrupt code, but it's non-trivial, unlike the Lisp code as AST=S-Exp for Lisp. Imagine parsing the code into an AST, reversing the tree and outputting the C code. For example, one way would be to have it reverse the order of the expressions.
In case of reversing a string of text, this would be a trivial string function, not a macro.
Even if I accept that, a macro would generate the code corresponding to the reversed string. This is kind of doable in C, if you're fine with having your own preprocessor which generates C code. It's still more work than the Lisp equivalent (I'd write it as a reader macro which reverses some string after it (for example quoted) and then passes the string to the lexer/parser to be processed further).

>>186
>I think the above has a chance of being done.
I think you're deeply mistaken if i'm going to write macro for this, this is string processing function which would process text and output code.
However i'm not writing the backwards code in the first place, i would just writing the correct code, i would not any preprocessor bloat layer to write it.

>>185

It seems that you are giving up. It might not be practical to reverse arbitrary code, but it could be practical to do a similar traversal of the code and locate certain symbols, and do something special to them. Reversing the code is just showing that you can do it. Anything you can do to a list a run time, you can do to your code at compile time. There is no need to resort to FILE IO and recompilation, or scripts and tools to parse your program and generate code which you then link with. Both methods work, but less work and less complexity for the user is involved if it can all be integrated into the compiler by providing one syntactic tool in the language. Just think, what if someone could implement Qt using only ANSI C/C++, and all the QT meta object code generation was created by definitions within the language standard. Using Qt would be as easy to use and provide any other library.

if you need a preprocessor for such problems as making your own toy language, you might want to write a complete toy language in the first place, which would be independent of Lisp.

>>189
There is no specific need to FILE IO, you could compile to a ram drive(which is done in cases when compilation is limited by disk)

>>190

If Qt is a toy language (extension), then what is a toy language?

for the "compile to RAM" thing:
see http://en.gentoo-wiki.com/wiki/Speeding_up_portage_with_tmpfs

>>191

If you are using a ram drive, you are still going through the operating system, and that is still file io. It just happens that you are not writing to a physical disk, or solid state device, or network file system, or a floppy drive.

What you could do is store the code in a buffer in the program's memory, and link the program with a library for a c compiler, and call a compile function on the buffer.

mai brai is brokn

Because useful programs are so bloated!

You can even make your own optimized ramdrive too, even on windows(Microsoft provides source @ http://support.microsoft.com/kb/257405 )

cool stuff!

The process of replicating such Lisp code at maximum performance:
1.make optimized ramdrive, set it to store temporaries and compiler file paths.
2.open new C file on the ramdrive on notepad
3. write your retarded Lisp strings
4.call the compiler, run the result program->which will output second-stage program code.
5. Now after it compiled, your first program will stop waiting and transfer control to second program.

>>190
No, you wouldn't. Writing a DSL in CL takes me very little effort (a page or two of code for something trivial), while doing the full-fledged thing in C is much more worse than I'd ever want to spend my time on, thus like most good C users, we'd resort to hacks when writing it in C because we're lazy to do it properly and just do it properly when writing it in Lisp. That's one of the main differences between coding styles in C and Lisp. To be fair, there are techniques of doing certain such limited DSLs in C with little effort(examine the code of some high-quality, high-performance open source C applications/servers/clients to get some ideas, if you're not familiar with such techniques), but they are never easier than doing it in Lisp.

I'd understand doing it in C if you just hate Lisp, but for someone who finds it quite natural to write Lisp code, it will be the thing I'll reach for most of the time.
To give a practical example, I was looking at some fairly complex data (de)serialization code written in C++, many pages long and very dense and hard to read. A while ago I had written a more some more general library for handling such data (not intended for this use, it was purely general purpose), and a description for that data in my DSL took about a page of code and was very easy to read and understand  and the generated code just worked the first time I wrote it.

Obviously the mess/repetitive code solution is unacceptable for serious developers who cannot afford having to change dozens of files each time they commit trivial changes to some high-level description of their data (not to mention the risk of errors/bugs/vulnerabilities). How do serious developers like Google that insist on writing in popular languages (like C++) handle it? They make huge ENTERPRISE DSLs for describing their data (see: http://code.google.com/p/protobuf/downloads/list for an example, about 10MB of C++ code). To use such DSLs you have to run the compiler to generate the code for your description, which you can then use in your code (of course, you need to modify the build chain/makefile to call the code generator). It's not that Lisp macros wouldn't generate similar monsters (just look at the expansion), but the macros won't take 10MB of code just for a simple data description language DSL, and you won't have to run separate code generating utils as part of your build process. Of course, that was just one example, creating DSLs is very cheap in Lisp, and people do it all the time, which isn't a luxury you can afford in C-likes that much.

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.

>>175
You're a faggot. I am a self-taught programmer, too. It's not my fault your horizon is the end of your nose. Read the fucking link I provided, everything is explained there.

>>238
Oh shit. Do you mean we gotta get rid of dlopen now?

>>241
It's frozenvoId , what were you expecting? Someone that actually knew how to program? Based on previous posts in different threads it's clear he doesn't even know the C standard let alone how certain things work.

the moron didn't even know what actually happens when you malloc(-#)

>>243

Come on! Don't be too picky on him. He's trying to "fix the C language" for all of us!

>>242
You do realize that dlopen is not part of the C standard, right? Or do you not know what POSIX is?

the loop macro is a good example of lisp's macro power: http://www.ai.sri.com/pkarp/loop.html

>>246
loop is a good example of how good shit gets out of control.

Replies to posts >>236-246 are compiled here:
http://pastebin.com/6cwJqV2n

>>248
I have a challenge for you. Try not to fail. Just once.

>>246
Additional reply;
Loop macro is not really needed in C code, and you can abstract over with function calls.
Its not a pretty as map/reduce but you can work at a similar level of abstraction/code density without the requirement of entire high-level bloat layer. Add a couple of function pointers, and you can abstract away at your leisure.
The people who add things like foreach macros are trying to force it the wrong way(its not semantically wrong just lacks native support: i would want such thing supported only at the level of a language, not as a macro i would have to rely on), since they think container-specific functions are unelegant.

>>250

The people who add things like foreach macros are trying to force it the wrong way(its not semantically wrong just lacks native support: i would want such thing supported only at the level of a language, not as a macro i would have to rely on), since they think container-specific functions are unelegant.

People like are trying to emulate an interator you fucking nob. Again, you wouldn't know something like this because you have never written an actual line of C code. Now tell us again why you want to introduce platform specific shit into the C standard you fucking idiot.

>>251
"Emulating" an iterator us better left to functions.
I don't believe in C standard as some religion. Please avoid treating it as such, it makes arguing about changes to C much more subjective(one likes C standard, one want another C standard, one wants to scrap the entire standard and start over and all of them have their arguments replaced by blind adherence/disapproval of some abstract bureaucratic bullshit)

>>252

"Emulating" an iterator us better left to functions.

Have you ever actually written any non trivial C code in your life?

I don't believe in C standard as some religion. Please avoid treating it as such, it makes arguing about changes to C much more subjective(one likes C standard, one want another C standard, one wants to scrap the entire standard and start over and all of them have their arguments replaced by blind adherence/disapproval of some abstract bureaucratic bullshit)

C is meant to portable. The standards are meant to ensure portability. If you want to make changes to C, then create your own language.

>>253
There are ways to be portable without crippling the language.

>>254
Yes, it's called include guards you idiot. Again, you wouldn't know about such things because you have never written any kind of real C code for any kind of major firm.

>>255 quick question, are you >>254 or are you actually that trolled?


'>Frozenvoid: Ill make C equivalent lisp macros because im gay
>Someone posts nice simple small elegant lisp macro
>Frozenvoid posts 20+ lines of unreadable C macro abuse that looks like pure shit
>Someone posts something nice again
>Frozenvoid: yeah i can do that but i wont because i dont have to


great thread, yet another example of how Frozenvoid sucks dick and doesn't know C, especially that reddit post.

Why are you fucking retards replying to FrozenShit?

it's the same reason why people throw shit at /dev/null