Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-12-08 5:01
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.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-12-08 14:24
Any other shining examples of elegance from our local LISP user group?
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-12-08 14:25
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
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-12-08 14:32
>>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.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-12-08 14:36
After you finish your elegant LISP masterpiece, it would be helpful to comment its functionality, instead of abstract description.
Name:
Anonymous2011-12-08 14:40
>>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.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-12-08 14:42
>>127
So sort function stops working after you append "Hello World" but not before? Isn't that defective?
Name:
Anonymous2011-12-08 14:50
>>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.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-12-08 15:03
>>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?
Name:
Anonymous2011-12-08 15:12
>>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.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-12-08 15:15
>>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
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-12-08 15:17
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
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-12-08 15:19
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?
Name:
Anonymous2011-12-08 15:20
>>99
If you wanted to juggle lambdas, it would mean you were enlightened.
Name:
Anonymous2011-12-08 15:24
>>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...
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-12-08 15:25
>>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.
Name:
Anonymous2011-12-08 15:26
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
Name:
Anonymous2011-12-08 15:27
>>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.
Name:
Anonymous2011-12-08 15:33
>>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.
Name:
Anonymous2011-12-08 15:33
>>141
Its trolling he doesn't intend to solve it as long as he can troll lispers with it.
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.
Name:
Anonymous2011-12-09 0:19
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.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-12-09 0:35
>>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.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-12-09 0:56
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.
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).
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-12-09 6:24
>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).
Name:
Anonymous2011-12-09 6:54
>>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.