The Blub Paradox

If Lisp is more expressive than C, why Lisp can be compiled into C and C cannot be compiled into Lisp?

>>1
Of course you can compile C into Lisp, silly girl. I mean, you can't, but people who program professionally can. Now run play with your toys, sweetheart!

C compiles into equivalently-sized Lisp.

Lisp compiles into larger amounts of C, because C is less expressive.

Also, Turing Tarpit, so fuck off.

>>1
Unlucky you. You have an idiot teacher that can't even explain why lisp is so great. Think about this: AI is the hardest problem computer scientists ever need to solve. If a language is good enough to be used for research in AI, it's good enough to solve most any other problem too.

The only problems with lisp are cultural. Many lispers are elitists who don't care for stuff other programmers need, such as distribution of binaries, portability between lisp-implementations, a standard, etc... And most mundane programmers hate lisp because it has lots of silly parentheses.

>>4

language is good enough to be used for research in AI

I don't see what this thread has to do with Prolog.

It's only more difficult because C depends on the underlying machine representation and Lisp does not.

Lisp is hardware-agnostic. You can compile it to C, to Java, to Brainfuck, to Matlab, to more Lisp, whatever. It's easy to do because Lisp doesn't care exactly how you implement it: as long as the builtins are consistent with the internal memory model (which you, the implementer, define), everything is fine.

C assumes a von Neumann architecture with contiguous memory, registers, and a bunch of other shit that (luckily!) most hardware has already. In order to compile C to anything other than assembly or binary, you basically have to write your own virtual machine. Guess what: that is really tedious!

There, IHBTT. You happy?

>>6
Wrong

>>7
Your an anus!

>>8
*you're
>>6
LISP isn't as portable as C(the portable assembler), in fact LISP in lisp machines died because it was unportable(openGenera is an emulator).
You can't claim that C,C that runs practically everywhere from a toaster to a space satellite is somehow restricted to specific hardware. C doesn't even require 8bit bytes(CHAR_BIT=8) and its types (stdint.h is a modern standard) are flexible to accept any machine word size.
Instead of claiming mythical dependency on von Neumann show a single example of hardware where Lisp does run but C does not.
C compilers exist for all architecture where it fits in RAM/ROM and its the industry tool of choice to create really specific software(microcontrollers,industrial devices,etc).

>>9

show a single example of hardware where Lisp does run but C does not

Only people unable to comprehend proofs ask for examples. I am sure that this should be considered as a logical fallacy.

>>5

language is good enough to be used for research in AI

I don't see what this thread has to do with Prolog.

Real men use awk for AI: http://awk.info/?doc/awk4ai.html

>>10
Very impressive proof, however i noticed a few flaws:
C assumes a von Neumann architecture[citation needed]
with contiguous memory[citation needed]
, registers[citation needed]
, and a bunch of other shit that [citation needed]

>>12
Are you stupid? I did not post any proof, in fact I am not >>6-san.

Cee requires von Neumann architecture
Cee needs contiguous memory

OpenCL,CUDA, Embedded C Standard:
Embedded C is a set of language extensions for the C Programming language by the C Standards committee to address commonality issues that exist between C extensions for different embedded systems. Historically, embedded C programming requires nonstandard extensions to the C language in order to support exotic features such as fixed-point arithmetic, multiple distinct memory banks, and basic I/O operations.

Cee requires registers

A declaration of an identifier for an object with storage-class specifier register suggests that access to the object be as fast as possible. The extent to which such suggestions are effective is implementation-defined.

and a bunch of other shit that

Its probably also implementation-defined or exist in non-standard C compilers(or specific non-standard extensions)

OpenCL,CUDA

These are not C you stupid faggot

Embedded C is a set of language extensions for the C Programming language

Extensions, not to mention that you need to use different address space specifiers for every architecture.

and basic I/O operations

Nobody, I say, nobody that matters implements iohw.h except QNX

A declaration of an identifier for an object with storage-class specifier register suggests that access to the object be as fast as possible. The extent to which such suggestions are effective is implementation-defined.

And?

OpenCL,CUDA

These are not C you stupid faggot

OpenCL is C89 with hardware extensions.
CUDA supports C++11 partially.

Embedded C is a set of language extensions for the C Programming language

Extensions, not to mention that you need to use different address space specifiers for every architecture.

C is often used with compiler extensions. C is designed to exploit the hardware for maximum performance and this requires close interaction with the machine(and sometimes inline assembler).

and basic I/O operations

Nobody, I say, nobody that matters implements iohw.h except QNX

Plenty of hardware-specific non-standard extensions exist. Its not the C committee privilege to decide what extensions are used.

A declaration of an identifier for an object with storage-class specifier register suggests that access to the object be as fast as possible. The extent to which such suggestions are effective is implementation-defined.

And?

This a quote from the C standard that clarifies the C 'register' does not create any dependency on hardware registers.
section 1.9 (the as-if rule) -

The semantic descriptions in this International Standard define a parameterized nondeterministic abstract machine. This International Standard places no requirement on the structure of conforming implementations. In particular, they need not copy or emulate the structure of the abstract machine. Rather, conforming implementations are required to emulate (only) the observable behavior of the abstract machine ...

an implementation is free to disregard any requirement of this International Standard as long as the result is as if the requirement had been obeyed, as far as can be determined from the observable behavior of the program. For instance, an actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no side effects affecting the observable behavior of the program are produced

>>16

OpenCL is C89 with hardware extensions.

No, it isn't

CUDA supports C++11 partially.

And?

C is often used with compiler extensions.

And?

C is designed to exploit the hardware for maximum performance and this requires close interaction with the machine(and sometimes inline assembler).
And?

Plenty of hardware-specific non-standard extensions exist. Its not the C committee privilege to decide what extensions are used.

Nothing to do with what I said.

This a quote from the C standard that clarifies the C 'register' does not create any dependency on hardware registers.

We know that.

As for the rest, what do they have to do with the topic? Absolutely nothing.

>>17

OpenCL is C89 with hardware extensions.

No, it isn't

OpenCL specifies a programming language (based on C99) for programming these devices and application programming interfaces (APIs) to control the platform and execute programs on the compute devices.
https://en.wikipedia.org/wiki/OpenCL

CUDA supports C++11 partially.

And?

CUDA is non von-Neumann programming language.
NVIDIA's CUDA Compiler (NVCC) is based on the widely used LLVM open source compiler infrastructure.
https://developer.nvidia.com/cuda-llvm-compiler

C is often used with compiler extensions.

And?

That includes non-standard extensions and implementation defined code such as iohw.h

C is designed to exploit the hardware for maximum performance and this requires close interaction with the machine(and sometimes inline assembler).

And?

C doesn't have the imaginary restrictions on hardware, it designed for the hardware: not the other way around.

Plenty of hardware-specific non-standard extensions exist. Its not the C committee privilege to decide what extensions are used.

Nothing to do with what I said.

Companies are free to implement their APIs the Embedded C standard is not stopping you to interface with your stack-only harvard 2k page-segmented memory architecture of 23-bit TrollCPU.

As for the rest, what do they have to do with the topic? Absolutely nothing.

The current branch of discussion is about C standards/extensions and portability.

>>18
Didn't they teach you at school that wikipedia can't be used as a source?
OpenCL does not implement tons of stuff presented in C.

CUDA is non von-Neumann programming language.

And? We talked about C, not CUDA.

That includes non-standard extensions and implementation defined code such as iohw.h

We know that, why are you repeating things that we know?

C doesn't have the imaginary restrictions on hardware

You can't use C with variable-word size machines.

Companies are free to implement their APIs the Embedded C standard is not stopping you to interface with your stack-only harvard 2k page-segmented memory architecture of 23-bit TrollCPU.

We know that, why are you repeating things that we know?

The current branch of discussion is about C standards/extensions and portability.

Yes, and?

iohw.h is entirely optional.
Embedded C standard is regarded more of as guideline.
C standard is frequently violated(and often by big name compilers such as Microsoft C compiler and Intel C/C++ compiler)
In particular Intel C compiler uses -ffast-math liberally

In particular Intel C compiler uses -ffast-math liberally

The C standard does not require the use of IEEE floats, so there is nothing wrong with that.

>>21
http://stackoverflow.com/questions/7420665/what-does-gccs-ffast-math-actually-do
-ffast-math does a lot more than just break strict IEEE compliance.

First of all, of course, it does break strict IEEE compliance, allowing e.g. the reordering of instructions to something which is mathematically the same (ideally) but not exactly the same in floating point.

Second, it disables setting errno after single-instruction math functions, which means avoiding a write to a thread-local variable (this can make a 100% difference for those functions on some architectures).

Third, it makes the assumption that all math is finite, which means that no checks for NaN (or zero) are made in place where they would have detrimental effects. It is simply assumed that this isn't going to happen.

Fourth, it enables reciprocal approximations for division and reciprocal square root.

Further, it disables signed zero (code assumes signed zero does not exist, even if the target supports it) and rounding math, which enables among other things constant folding at compile-time.

Last, it generates code that assumes that no hardware interrupts can happen due to signalling/trapping math (that is, if these cannot be disabled on the target architecture and consequently do happen, they will not be handled).

C cannot be compiled into LITHP, but C can be trivially converted to XML. XML to LITHP conversion is left as an exercise to the reader.

>>19

Didn't they teach you at school that wikipedia can't be used as a source?

False authority. Your arbitrary institution where you spent years being warehoused and brainwashed doesn't matter.

What have I created? It... It's beautiful.

I have to say though, every post yet ITT has neither fully supported nor succcessfully refuted each of my points, let alone the spirit of >>6 in its entirety. The whole thread has been about fucking portability, AGAIN, which is a totally and utterly boring discussion.

>>24
The rational may be fallacious, but the assertion is nonetheless true.

>>26
Wikipedia can be trusted on topics which don't have a controversial nature such as "proton decay" or "float.h".
But once there is agenda the article cannot be relied on because there are factions which benefit from editing the article to promote their own agenda.
Ask yourself "What would this article look if i wanted to introduce bias towards a viewpoint opposite of the article viewpoint", and if there are major changes in text the article is probably already reflecting such a biased viewpoint.

>>22
Most (all?) of these do not bother the standard.

>>27
no

>>24
Wikipedia shouldn't be used as a reference source because it is supposed to be a tertiary source of information. Wikipedia is supposed to be a starting pointer that points to primary and secondary sources of information.

>>24
Are you a nigger that didn't go to school?

>>30
The brood of every nigger and scumbag gets funnelled into school. You won't find anyone respectable or commendable there. They're all either home-schooled or self-taught.

>>31
Someone was bullied in school or was too poor to go to one.

>>33
CHECK'M

>>29
And that's why in internet discussions Wikipedia is a good reference source, because everyone can reach it and is not required to have access to primary or secondary sources, like books, paywalled research papers or technical specifications.

>>35
Wikipedians assume everyone can afford to buy rare books and pay for research papers. If someone would want to really read the references of a dozen articles they would need to shell enough bux to buy a new hi-end computer.
Also the referenced part is often a charter or even a few pages in a huge document/book.
C standard would be adhered by more people if it was free to use(and no these people don't bother searching free draft pdfs).

>>6
I would say that C exposes the hardware details to the programmer, whereas Lisp abstracts them away giving you a pure expression model. Lisp compiler writers create ways to infer types, model ABIs to support the Lisp environment directly in machine code, and so on, and everybody wins.

Now, since the C language itself doesn't give a fuck about machine details but will directly affect the nature of programmer-exposed variable types and operations, it will compile your code for you, but your it will break if the assumptions aren't all correct. Which is common especially since most C code ends up rely on Undefined Behavior™.

>>36
*Implementation Defined Undefined Behavior™

since most C code ends up rely on Undefined Behavior™.

Because programmers that should not be using C end up using C.

And the vast majority of projects that should not be written in C end up using C.

It's a fucking systems programming language, not an application programming language.

>>39
I'm going to apply my cock to your anus and communicate in the language of rhythmic thrusting.

>>40
Faggot.