Live data from Hacker News

Dennis Ritchie's first C compiler on Github

github.com

51–60 of 88 posts

Re: Dennis Ritchie's first C compiler on Github

#51
post #50
post #7

Coincidences... I thought "How come Warren Toomey (one of the guys of the Unix Heritage Society [1]), has never posted this?" Turns out, this Github-repo is just a mirror/copy of his work, but with attribution [2]. Still worth reading through there, tuhs also stores some extremely old UNIX versions. [1] www.tuhs.org [2] http://cm.bell-labs.com/cm/cs/who/dmr/primevalC.html Edit: Warren has written a paper on restoring…

> Edit2: Now that I've thought a little bit about it, I'm not happy that the sources are on GitHub in this form. If one releases code under an open license and people use/copy/fork it, why should you or the original author be unhappy. (As long as the license terms are not being broken.) If we had to worry about this each time we forked/cloned someone's work, it would make code reuse very hard. [Edit] I am working on…

If you're within the terms of the license, you're fine. The developer should say so in the license (or choose another license) if they don't want it reproduced anywhere. A link to the original is common courtesy, however.

In the case of the C compiler, I think the modifications are under the same license as the original, but I'm not totally certain. If they aren't it would be cause for concern.

Re: Dennis Ritchie's first C compiler on Github

#52

Reading Dennis Ritchie's code is as close to reading a religious text as I'll ever come. The straightforward elegance of it is so inspiring!

The lack of type noise makes it easier to read too.

I can't disagree more! Everything is an int -- Basically untyped, in C terms! Maybe less noisy, but hard to figure out what's going on.

Re: Dennis Ritchie's first C compiler on Github

#53

Earlier quoted context omitted.

In an appropriately powerful language, it could be a function call.

after #define if(X) LET(_it,X) if (_it) it would be a macro call

I'm fairly certain that shadowing a keyword with a macro is forbidden by the standard (or invokes UB?) but this will still work for most compilers, provided LET is defined reasonably. Hm, something like

     #define LET(name, X) \
       for (int let_once_=1, name=(X); \
            let_once_; \
            let_once_=0)
may be reasonable, though tokenpasting in __LINE__ for good measure might be necessary for nesting.

Re: Dennis Ritchie's first C compiler on Github

#54
post #45
post #4

Earlier quoted context omitted.

Looks like a very early dialect. C assumes everything is an int unless specified otherwise. You can declare parameter types after the function name. So: init(s, t) char s[]; { would be equivalent to: int init(char s[], int t) { This still works with modern compilers. I'd be interested if anyone has any more info about this: waste() /* waste space */ { waste(waste(waste),waste(waste),waste(waste)); waste(waste(waste),…

> Looks like a very early dialect. C assumes everything is an int unless specified otherwise. It looks beautiful, almost like a scripting language. No monster type signatures like const std::foo_bar >&

I think the modem carrier dropped on your last line. Can you resend?

Re: Dennis Ritchie's first C compiler on Github

#56
If you like c compilers, also check out http://bellard.org/tcc/ and http://bellard.org/otcc/

The later is a c compiler in about 1kb of source code! It's quite functional and can compile itself.

The first link is what came out of it: A compiler so fast, that it can boot Linux from source code in a few seconds: http://bellard.org/tcc/tccboot.html

Re: Dennis Ritchie's first C compiler on Github

#58
post #57

I don't understand this main(argc, argv) int argv[]; { Is that still valid today?

I don't know if it's still valid by the spec, but it's still supported by some compilers. There was a post on vim reaching 7.3.0.1000 the other day, and that's still using that style of typing.

Re: Dennis Ritchie's first C compiler on Github

#59
post #53

Earlier quoted context omitted.

after #define if(X) LET(_it,X) if (_it) it would be a macro call

I'm fairly certain that shadowing a keyword with a macro is forbidden by the standard (or invokes UB?) but this will still work for most compilers, provided LET is defined reasonably. Hm, something like #define LET(name, X) \ for (int let_once_=1, name=(X); \ let_once_; \ let_once_=0) may be reasonable, though tokenpasting in __LINE__ for good measure might be necessary for nesting.

Shadowing keywords is perfectly valid, although I believe you can't shadow keywords in standard headers so that compiler writers don't need to worry about it. It gives rise to some "useful" C/C++ features that should never be used, like if you want to access private members in foo.cpp, do

     #define private public 
     #include "foo.cpp"
     #undef private

Re: Dennis Ritchie's first C compiler on Github

#60
post #43

Earlier quoted context omitted.

In an appropriately powerful language, it could be a function call.

This is all very well if you have a friendly, high level scripting language like Ruby, but I'm definitely glad I don't have to write a C compiler where functions can take arbitrary blocks of code.

> In an appropriately powerful language, it could be a function call.

> This is all very well if you have a friendly, high level scripting language like Ruby, but I'm definitely glad I don't have to write a C compiler where functions can take arbitrary blocks of code.

That's a surprisingly good setup because in Smalltalk(one of ruby's main ancestor languages)

if/else is a method which takes a block closure.

    a ifTrue: [ l log: 'a is true'] ifFalse: [ 'a is false']
while

in ruby if else is a syntatic construct

    if a
        l.log ('a is true')
    else
        l.log ('a is false')
    end
probably more for perceived clarity/comfortability then speeds sake.
Post reply on HN