7 ms·

Linked from another thread: http://cm.bell-labs.co/who/dmr/chist.html http://cm.bell-labs.co/who/dmr/chist.html It explains the memory limits and what happened

by speps 3y ago

Linked from another thread: http://cm.bell-labs.co/who/dmr/chist.html http://cm.bell-labs.co/who/dmr/chist.html It explains the memory limits and what happened :) > After the TMG version of B was working, Thompson rewrote B in itself (a bootstrapping step). During development, he continually struggled against memory limitations: each language addition inflated the compiler so it could barely fit, but each rewrite taking advantage of the feature reduced its size. For example, B introduced generalized assignment operators, using x=+y to add y to x. The notation came from Algol 68 [Wijngaarden 75] via McIlroy, who had incorporated it into his version of TMG. (In B and early C, the operator was spelled =+ instead of += ; this mistake, repaired in 1976, was induced by a seductively easy way of handling the first form in B's lexical analyzer.)

bee_rider 3y ago
I wonder why =+ is so obviously a mistake. It does look vaguely wrong for some reason, but I’m prejudiced by current languages.
- vgel 3y ago
  I think because it's ambiguous with unary plus (a = +b), since C isn't supposed to have significant whitespace in most circumstances.
  - kazinator 3y ago
    But originally there wasn't a += or =+ lexical token! Those things were scanned as separate tokens, and could be written = +. So that is problematic; If {a}{=}{-}{b} means a = a - b, then you have no way to write a = -b without parentheses like a = (-b).
  - tom_ 3y ago
    You also run into problems with a=*p and a=-b, which are perhaps more likely.
    - zeusk 3y ago
      But they could've fixed that by going a=(*p) and a=(-b); Kind of how we use (*p)->next instead of *p->next where p is node_t**
      - kdmccormick 3y ago
        That seems a little backwards and barbaric, though right? Imagine if we had to watch out for this as a common pitfall: // BUG! Actually subtracts x from current val of neg_x. neg_x = -x; Even moreso, how would these two lines behave? Would they differ in semantics? n = -5 n =- 5 Overall, -= is just so much less ambiguous. EDIT: To your point about ->, I personally think C would be better if: *p->next parsed as: (*p)->next instead of: *(p->next) but maybe now I'm not thinking through all the parsing impliciations :)
        zeusk 3y ago
        As you note in your edit; we already have to watch for that pitfall :) so really the best way out is to be as verbose as possible imo; a = a + c or auto nodep = *nodepp; nodep->next; Compilers and compute performance have grown to make the difference negligible for code output and compilation times but they definitely take a lot of mental complexity out of such scenarios (anything helps when grokking 10k+ lines of code).
        tom_ 3y ago
        I've found struct fields that are pointers far more common than pointers to pointers to structs, so if nothing else it feels like *(p->target) is a more widely useful interpretation of *p->target than (*p)->target would be. Regarding "n = -5", it would presumably be interpreted as "n=(-5)", same as today. Operators don't have spaces in them. So "n- -5" is "n-(-5)", rather than "n--5" (not valid).
- coldtea 3y ago
  >I wonder why =+ is so obviously a mistake Consider x = -5 now how about: x =- 5 One makes x negative 5, the other subtracts 5 from it. And under this design of the operator the only difference is a space. It's the same with +, just that we're not used to seeing unary plus in the wild.
  - thr0w__4w4y 3y ago
    >> x =- 5 I think you mean: x -= 5, which indeed is different.
    - coldtea 3y ago
      I'm showing how it would be under the original operator design which was reverted, which was "=-".
bsder 3y ago
Infix parsing chews up a remarkable amount code and memory. It's scary just how much easier it is to parse languages without infix parsing.
- fodkodrasz 3y ago
  where it takes up the memory in the human brain, where we have more limited working set, than in computers. That is probably why postfix notation is mostly a thing of the past by now in languages intended to be used by humans.
  - algas 3y ago
    (in (is "prefix notation" (and "alive" "kicking")) "all lisps")
    - pritambaral 3y ago
      (-<> "alive" (and "kicking") (is "prefix notation" <>) (in "all lisps"))
  - bsder 3y ago
    But creates a habit of having exactly two individual items for an operation. Which led us to imperative programming and object oriented programming. Which everybody now recognizes as limited in various artificial ways. Which we are now struggling to shake off given that the majority of chips have a whopping number of parallel cores. Programming languages restrain your thinking about your solution space.

by speps 3y ago

bee_rider 3y ago

I wonder why =+ is so obviously a mistake. It does look vaguely wrong for some reason, but I’m prejudiced by current languages.

vgel 3y ago
I think because it's ambiguous with unary plus (a = +b), since C isn't supposed to have significant whitespace in most circumstances.
- kazinator 3y ago
  But originally there wasn't a += or =+ lexical token! Those things were scanned as separate tokens, and could be written = +. So that is problematic; If {a}{=}{-}{b} means a = a - b, then you have no way to write a = -b without parentheses like a = (-b).
- tom_ 3y ago
  You also run into problems with a=*p and a=-b, which are perhaps more likely.
  - zeusk 3y ago
    But they could've fixed that by going a=(*p) and a=(-b); Kind of how we use (*p)->next instead of *p->next where p is node_t**
    - kdmccormick 3y ago
      That seems a little backwards and barbaric, though right? Imagine if we had to watch out for this as a common pitfall: // BUG! Actually subtracts x from current val of neg_x. neg_x = -x; Even moreso, how would these two lines behave? Would they differ in semantics? n = -5 n =- 5 Overall, -= is just so much less ambiguous. EDIT: To your point about ->, I personally think C would be better if: *p->next parsed as: (*p)->next instead of: *(p->next) but maybe now I'm not thinking through all the parsing impliciations :)
      - zeusk 3y ago
        As you note in your edit; we already have to watch for that pitfall :) so really the best way out is to be as verbose as possible imo; a = a + c or auto nodep = *nodepp; nodep->next; Compilers and compute performance have grown to make the difference negligible for code output and compilation times but they definitely take a lot of mental complexity out of such scenarios (anything helps when grokking 10k+ lines of code).
      - tom_ 3y ago
        I've found struct fields that are pointers far more common than pointers to pointers to structs, so if nothing else it feels like *(p->target) is a more widely useful interpretation of *p->target than (*p)->target would be. Regarding "n = -5", it would presumably be interpreted as "n=(-5)", same as today. Operators don't have spaces in them. So "n- -5" is "n-(-5)", rather than "n--5" (not valid).
coldtea 3y ago
>I wonder why =+ is so obviously a mistake Consider x = -5 now how about: x =- 5 One makes x negative 5, the other subtracts 5 from it. And under this design of the operator the only difference is a space. It's the same with +, just that we're not used to seeing unary plus in the wild.
- thr0w__4w4y 3y ago
  >> x =- 5 I think you mean: x -= 5, which indeed is different.
  - coldtea 3y ago
    I'm showing how it would be under the original operator design which was reverted, which was "=-".

bsder 3y ago

Infix parsing chews up a remarkable amount code and memory. It's scary just how much easier it is to parse languages without infix parsing.

fodkodrasz 3y ago
where it takes up the memory in the human brain, where we have more limited working set, than in computers. That is probably why postfix notation is mostly a thing of the past by now in languages intended to be used by humans.
- algas 3y ago
  (in (is "prefix notation" (and "alive" "kicking")) "all lisps")
  - pritambaral 3y ago
    (-<> "alive" (and "kicking") (is "prefix notation" <>) (in "all lisps"))
- bsder 3y ago
  But creates a habit of having exactly two individual items for an operation. Which led us to imperative programming and object oriented programming. Which everybody now recognizes as limited in various artificial ways. Which we are now struggling to shake off given that the majority of chips have a whopping number of parallel cores. Programming languages restrain your thinking about your solution space.