Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Teaching Compilers Backward

blog.sigplan.org

Post reply on HN
Print view View original

71–80 of 87 posts

Re: Teaching Compilers Backward

#71

Post by konjin »

peteretep wrote: post #65
lisper wrote: post #22

Earlier quoted context omitted.

> Too many compilers classes get bogged down in grammar classifications and parsing. Oh so very this. This has repercussions far beyond students who can't write compilers. It infects the entire culture of software engineering with people who think that syntax is everything, and who spend their lives designing grammars and writing parsers for them. The problem with that is for every new grammar, it's not just that you…

> Two examples: XML and JSON are bad re-inventions of S-expressions. What? This sounds like you read something that was true but you’ve misunderstood and regurgitated. XML is absolutely S-expressions, JSON is absolutely not. How in the heck is JSON a reinvention of an S-expression?

>XML is absolutely S-expressions

You need a lot of predefined structure to capture attributes using brackets, much more than you do for dictionaries - which are just ordered pairs in a list when serialized.

Re: Teaching Compilers Backward

#72

Post by konjin »

agnokapathetic wrote: post #13

This approach has the added benefit of teaching "mechanical sympathy". We're often told "Let the complier do the work" without really understanding what "work" the compiler is doing. Learning concepts like branch prediction, out-of-order execution, pipelining, register planning, caches, memory management is far far more important than Lexing/Parsing/Intermediate Representations and SSA.

>Learning concepts like branch prediction, out-of-order execution, pipelining, register planning, caches, memory management is far far more important than Lexing/Parsing/Intermediate Representations and SSA.

These are incidents of technology. If this were 1970s you'd be talking about in place sorting because we're stuck with tapes for anything past a toy compiler. Something that would be useless in a decade.

The point of education is to teach you how to learn, not how to collect stamps.

Re: Teaching Compilers Backward

#73

Post by tomjakubowski »

munificent wrote: post #53
lisper wrote: post #51

Earlier quoted context omitted.

Sure, but 1) s-expressions also have native symbols whereas JSON has only strings, and 2) it is trivial to extend standard s-expression syntax to include a native dictionary serialization, and to extend existing s-expression parsers to parse that extension. It is much, much harder to add symbols to JSON. JSON is also very profligate with its use of punctuation, with tons of unnecessary commas and colons all over the…

> 1) s-expressions also have native symbols whereas JSON has only strings, This is inconsistent with the claim that s-exprs are better because of their simplicity. Having two very similar string-like things is unnecessarily complex for little (no?) benefit in return. 2) > it is trivial to extend standard s-expression syntax to include a native dictionary serialization Sure, and when you do you get something at about…

> Having two very similar string-like things is unnecessarily complex for little (no?) benefit in return.

Using symbols (or :keywords) and strings together offers many benefits:

1. Like with JSON's richer syntax for aggregates, omitting the "" makes for much easier visual parsing. Especially if symbols are usually used for keys.

2. Symbols may be suitable for interning, perhaps into a set used to validate input data. Strings usually aren't.

3. Most importantly, with this distinction, symbols can be imbued with particular semantics: they can be commands, references, lookup keys, whatever the program needs. Strings are just data, usually to be displayed somewhere to be read by someone, or to be parsed by something nasty like an interpreter.

The most human-readable data notation I know of is EDN. It combines the best of JSON and s-expressions.

Re: Teaching Compilers Backward

#75

Post by peteretep »

lisper wrote: post #70
peteretep wrote: post #65

Earlier quoted context omitted.

> Two examples: XML and JSON are bad re-inventions of S-expressions. What? This sounds like you read something that was true but you’ve misunderstood and regurgitated. XML is absolutely S-expressions, JSON is absolutely not. How in the heck is JSON a reinvention of an S-expression?

How is it not? Both are serialization formats for trees with strings and numbers at the leaves.

Is there a serialization format you don't consider to be a bad re-invention of S-expressions?

Re: Teaching Compilers Backward

#76

Post by peteretep »

konjin wrote: post #71
peteretep wrote: post #65

Earlier quoted context omitted.

> Two examples: XML and JSON are bad re-inventions of S-expressions. What? This sounds like you read something that was true but you’ve misunderstood and regurgitated. XML is absolutely S-expressions, JSON is absolutely not. How in the heck is JSON a reinvention of an S-expression?

>XML is absolutely S-expressions You need a lot of predefined structure to capture attributes using brackets, much more than you do for dictionaries - which are just ordered pairs in a list when serialized.

(apologies, ninja deleted, I do not wish to continue this discussion)

Re: Teaching Compilers Backward

#77

Post by konjin »

peteretep wrote: post #76
konjin wrote: post #71

Earlier quoted context omitted.

>XML is absolutely S-expressions You need a lot of predefined structure to capture attributes using brackets, much more than you do for dictionaries - which are just ordered pairs in a list when serialized.

(apologies, ninja deleted, I do not wish to continue this discussion)

There isn't a difference when it's serialized.

Re: Teaching Compilers Backward

#78

Post by lisper »

peteretep wrote: post #75
lisper wrote: post #70

Earlier quoted context omitted.

How is it not? Both are serialization formats for trees with strings and numbers at the leaves.

Is there a serialization format you don't consider to be a bad re-invention of S-expressions?

Of course. There are many. Any binary format. Any ASN.1 format. DEF and LEF for hardware descriptions. The output of mysqldump.

Here's another example:

https://github.com/rongarret/tweetnacl/blob/master/ratchet.l...

starting at line 82. (That's one that I designed.)

Re: Teaching Compilers Backward

#80

Post by [deleted] »

lisper wrote: post #78
peteretep wrote: post #75

Earlier quoted context omitted.

Is there a serialization format you don't consider to be a bad re-invention of S-expressions?

Of course. There are many. Any binary format. Any ASN.1 format. DEF and LEF for hardware descriptions. The output of mysqldump. Here's another example: https://github.com/rongarret/tweetnacl/blob/master/ratchet.l... starting at line 82. (That's one that I designed.)

[deleted]
Post reply on HN