Translators

The way to get rid of C & Sepples hegemony is through translators. Whenever you invent a new and much better language, you just invent a translator from C & Sepples to your new language. Then anyone will be able to completely replace their legacy shit-language code and C, C++, Java etc will quickly die off.

And this would help how?

>>1
Lisp weenies have been doing this for decades. I wouldn't expect to have any more success then they have had.

>>3
We all succeed in our own little ways. Leave us alone!

>>2
By making worthless shit languages like C and Sepples obsolete.

>>3
I don't get it. What may be so hard about translating C to CL? Both are imperative, have native arrays, strings, etc. C "macros" can be translated to Lisp macros in a jiffy. C types can be just erased. malloc, free can be trivially handled too. Is it pointer arithmetic? But it's very rarely used outside of array traversal.

>>6

How do I express the difference between auto_ptr and shared_ptr in Common Lisp?

>>7
That's Sepples. But what about plain old C?

>>7
Besides, the translation needn't be invertible. Different types of pointers can be translated to the same Lisp code, and the result will be no less correct than the C++ code.

>>8,9
Excuse me friend, but >>1 chama specifically mentioned Sepples being translated away to get rid of shitty languages like it. Obsoleting C but keeping C++ is the worst possible outcome.

Also, in ENTERPRISE code, things rely on that the small differences in behavior of similar features like that. No one knows why, but I have seen it.

To do this right and cover all the edge cases, we need a solution to the halting problem or strong AI.

we need a solution to the halting problem

http://bbs.progrider.org/math/read/1428099144

>>5
And how would your solution achieve that?

>>8
You can do things in c that have no comparison in ``safe'' languages.

>>13
Like?

>>14
I would post, but my code is too identifying. So I can't share it. But to sum it up, in C you have pointers. And you can perform pointer arithmetic. Before you say pointer arithmetic doesn't have a practical value, you are wrong. It is useful for both efficiency and code reuse. You will have a very difficult time emulating pointer arithmetic in a ``safe'' language.

>>14
Pointer synthesis. Common example in CCAN's htable module, where hash bits and the perfect bit are stored in common bits of the hash table's entries. This requires that the language have a way to recover a valid data pointer from a bit-pattern that's identical to one that a data pointer was converted to.

(and if this sounds like a trivial-as-shit matter, imagine a hideous corporate 80s semi-mainframe with segmented memory where a "far" address is 40 bits, but native wordsize is only 32...)

>>15

I would post, but my code is too identifying. So I can't share it.

all talk and no action

>>17
I might not be willing to photograph my naked body and upload it to the public internet for you to see, but that doesn't mean I don't have a body. Fuck you and your free software movement. I code for my own enjoyment and to support myself when I have to. If a requirement of me being ``action'' is to take one of the things I hold dear, something that is almost a diary, and flop it open, upload it to the public, so that every devious organization in the world can look through it, then I am happily a person of no action. I'm not all talk either. I wouldn't have said anything if >>14-san didn't ask a question.

>>16
Pointer synthesis can be faked easily via indexing if the base address is always known. Admittedly that's not always possible, but best performance is to be had in cases where it is.

Your <C=to-language> will compile into much slower program than native C/C++ binary.
In fact many compilers compile to C and enjoy the optimizations available with C compilers.

>>19
It's not fake if it works exactly like C. Which is to say: common implementations do it in constant time and space by converting the pointer into a word-length integer and leaving a whole heap's worth of patterns undefined.

duubs

duubs

>>15
Pointers are just integers that index into an array, not sure why that's hard to emulate.

>>24
If I had to guess, I'd say that >>15-chan did not read her STANDARD and is under delusion that the translator would have to implement some stuff that is actually undefined behavior.

Whenever you invent a new and much better language written in Cee and Sepples.

>>26
Whom are you quoting?

>>4
It would nicer if someone would succeed in a big way.

>>25
Sounds like >>16 is exploiting some property of the pointer representation for an uncommon architecture. A translator could be made to support this if it were informed of the behavior of the original C implementation. The translator output might not compile down to the same hardware instructions as the C version, but that's not a necessary condition for the correctness of most C programs.

>>15
Of course you could do it, but it would never be the best way. The use case I was thinking of for pointer arithmetic in C was more about getting from one object in memory to another by exploiting knowledge of memory layout. Like converting a pointer to a member of a struct to a pointer to a different member of the parent struct. Or whatever else you want to think up. Inserting every object in the program into a table with an index represented by a pointer value that obeys the C standard will work, but it will introduce significant overhead.

Oh an C -> javascript compilers have existed for a while. You can play doom this way.

>>30
DON"T TRY TO TELL ME HOW I CAN OR CANNOT PLAY DOOM< FUCKER>

>>28
That's the wrong reading. What CCAN's htable does is sniff out what bits in hashtable entries are the same, and then stores hash-value bits in them instead. This exploits the fact that those entries tend to have been allocated near one another in the heap, with the advantage that lookup can limit comparisons by checking the stored hash bits against the key's hash value.

So, it exploits C's property of being able to convert a data pointer into an uintptr_t, and then not just that literal value but any that look like it exactly, back to the same data pointer. This makes a O(1) pointer synthesis difficult for implementations where wordsize < ptrsize, in turn inconveniencing translation into any language where pointer-to-integer-to-pointer casting isn't allowed by the target language's specification.

Hope this is clear enough.

nodejs is "good enough" as a replacement for both C and C++

There is something called chicken scheme, but I guess you have not heard of it.
This is right, you have not heard of it because it's just as good as your idea.

>>33
The Javashit kike is back and his ``jokes'' are as pathetic as ever!

>>35
Node.js is the future. Its gaining popularity every day.

>>32

This makes a O(1) pointer synthesis difficult for implementations where wordsize < ptrsize

I don't think you know how big-O notation works and you probably shouldn't use it.

In addition, nowhere in the C Standard it claims that pointer size should be the same as "word size" (whatever that is, it's not mentioned in the Standard at all). There are many architectures where it's not true, for example all 8-bit processors and many 16-bit processors, most notably the Intel x86 family up to and including 80286.

Furthermore, the standard doesn't demand that the representation of a pointer as an uintptr_t should make any sense wrt its internal structure. You are guaranteed that converting that exact value to a pointer would produce the original pointer, the actual bits of the representation could be shuffled and xored with a random constant for all you know.

Furthermore, even if you could depend on that, nothing in the standard guarantees that sizeof(int) > 1 so you have those extra unused bits due to alignment. For example, if your target architecture only supported aligned loads and stores, its native indirect addressing instructions could enumerate addresses in words, not in bytes. And even if your implementation wanted to avoid wasting space and allow storing several chars in a word, it could use native address representation for word and larger pointers and some special representation for char pointers (see the previous point).

All that was said with an assumption that we are talking about translating Standard conforming C software.

in turn inconveniencing translation into any language where pointer-to-integer-to-pointer casting isn't allowed by the target language's specification.

However as someone has already pointed out, for that particular purpose you can just store objects in arrays and use their indices as addresses, no problem. Accessing subobjects would be trickier.

I did not read what you guys said but I would like to mention that uintptr_t is optional and may not even exist. But I guess someone could still make calculations with pointers if he copied the pointer into a variable that is able to fit that pointer (I can think of char p[sizeof (type *)]) but I can't see how would anyone make a use of that (except to use a non-standard behavior).

Furthermore, even if you could depend on that, nothing in the standard guarantees that sizeof(int) > 1

This is right, this also causes problems with int c = getchar (); and then checking for EOF, as EOF could be a valid byte.
http://stackoverflow.com/questions/3860943/can-sizeofint-ever-be-1-on-a-hosted-implementation

>>38

I did not read what you guys said

Why did you reply then? Explain yourself.

>>39
Because I wanted to enrich this thread with my awesomeness.