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

The naked truth about writing a programming language (2014)

digitalmars.com

Post reply on HN
Print view View original

11–20 of 212 posts

Re: The naked truth about writing a programming language (2014)

#11

Post by chubot »

On regexes, he is generalizing from a small number of examples. Some lexers are straightforward to write by hand, but others are better done with a code generator.

edit: I should really say that you should consider using regular languages to lex your programming languages, not (Perl-style) regexes. Those are different things:

https://swtch.com/~rsc/regexp/

I used re2c for Oil and it saves around 5K-10K lines of "groveling through backslashes and braces one a time" (e.g. what other shells do)

http://www.oilshell.org/blog/2019/12/22.html#appendix-a-oils...

And the parser is faster than bash overall:

http://www.oilshell.org/blog/2020/01/parser-benchmarks.html

Re: The naked truth about writing a programming language (2014)

#12

Post by amelius »

daenz wrote: post #10
didibus wrote: post #8

After learning s-expression based syntax, I am just baffled why we even bother with anything else. When you play around with different Lisps, the syntax is always the same, the language differences becomes the semantics only. Other languages put too much emphasis on the syntax in my opinion. And while I understand the "popularity" appeal. I've almost never seen someone learning the s-expression syntax and afterwards…

It's simple, but it's fundamentally reductionist. You can ease the cognitive load by making certain programming structures first-class citizens in the language.

Yes but now you have to worry about parentheses and at what nesting level certain constructs should live.

Re: The naked truth about writing a programming language (2014)

#14

Post by WalterBright »

chubot wrote: post #9
desc wrote: post #6

Earlier quoted context omitted.

https://stackoverflow.com/questions/898489/what-programming-... Most languages have context-free syntax, which is what the article refers too. There really is no reason to sacrifice that. Even modern PHP recognises the value of having a parse tree independent of an entire compiler. Context-free semantics is an entirely different matter, and I'm not even sure what it'd mean...

The two top answers are in conflict. The second answer with 43 points is closer to right: There are hardly any real-world programming languages that are context-free in any meaning of the word. The first answer with 41 points is totally wrong: The set of programs that are syntactically correct is context-free for almost all languages ----- A better source is this whole series by Trevor Jim, which has nice ways of rel…

The implementation of D has a lexer that is independent of the parser, and a parser that is independent of the rest of the implementation. I have resisted enhancement proposals that would put holes in those walls.

Re: The naked truth about writing a programming language (2014)

#15

Post by adimitrov »

xiphias2 wrote: post #5

,,grammar should be redundant. You’ve all heard people say that statement terminating ; are not necessary because the compiler can figure it out. '' I'll stay with my non-redundant Julia language, thank you very much. It gave me a lot of joy to programming, and I don't remember having big problems with error messages. Even if I have, syntactic errors are trivial to find. The hard parts of efficient programming are me…

Whilst you're not wrong about what you value about a programming "language", I'd say there is an important distinction to be drawn between two things people tend to conflate: the language and the runtime.

Perhaps a counterexample is in order to explain it: Java the language and Java the runtime (VM, stl) are two different things entirely. Kotlin, for example makes a lot of different choices in language design (e.g. semicolons) while reusing the same runtime (GC, threads, etc.)

Of course, you can often not tease these two concerns apart easily and neatly, but there is merit in giving thought to the ergonomics of the pure language side of things. At the end of the day, a programming language doesn't need an implementation to be useful (e.g. as a teaching tool) as it's an abstract, formal concept.

Re: The naked truth about writing a programming language (2014)

#17

Post by steveklabnik »

h-cobordism wrote: post #4
steveklabnik wrote: post #3

Earlier quoted context omitted.

Rust is almost context free; there’s one relatively rarely used bit that requires context. And usually it’s only one or two bytes of it.

You're referring to raw string literals, right?

Yes. You need to include more #s than you have in the string, and it’s rare to have a ton of them, let alone a raw string literal in the first place.

Re: The naked truth about writing a programming language (2014)

#18

Post by chrisseaton »

desc wrote: post #6
billconan wrote: post #2

I want to implement a toy programming language, but I have questions regarding the following in that article: > Context free grammars. What this really means is the code should be parseable without having to look things up in a symbol table. C++ is famously not a context free grammar. A context free grammar, besides making things a lot simpler, means that IDEs can do syntax highlighting without integrating in most of…

https://stackoverflow.com/questions/898489/what-programming-... Most languages have context-free syntax, which is what the article refers too. There really is no reason to sacrifice that. Even modern PHP recognises the value of having a parse tree independent of an entire compiler. Context-free semantics is an entirely different matter, and I'm not even sure what it'd mean...

> Most languages have context-free syntax

Do they? I haven't done a survey of languages but I would guess most are context-sensitive.

Re: The naked truth about writing a programming language (2014)

#19

Post by [deleted] »

WalterBright wrote: post #14
chubot wrote: post #9

Earlier quoted context omitted.

The two top answers are in conflict. The second answer with 43 points is closer to right: There are hardly any real-world programming languages that are context-free in any meaning of the word. The first answer with 41 points is totally wrong: The set of programs that are syntactically correct is context-free for almost all languages ----- A better source is this whole series by Trevor Jim, which has nice ways of rel…

The implementation of D has a lexer that is independent of the parser, and a parser that is independent of the rest of the implementation. I have resisted enhancement proposals that would put holes in those walls.

[deleted]

Re: The naked truth about writing a programming language (2014)

#20

Post by chrisseaton »

didibus wrote: post #8

After learning s-expression based syntax, I am just baffled why we even bother with anything else. When you play around with different Lisps, the syntax is always the same, the language differences becomes the semantics only. Other languages put too much emphasis on the syntax in my opinion. And while I understand the "popularity" appeal. I've almost never seen someone learning the s-expression syntax and afterwards…

> I've almost never seen someone learning the s-expression syntax and afterwards not liking it.

I don't particularly like s-expression syntax - I think s-expressions suit the computer at the expense of the programmer, which I think is backwards. I think they're verbose and noisy and that obscures the meaning I want to see in the text as a person. Yes they're easier to parse, but I want to make my life easier, not the computers. And yes they're convenient for metaprogramming but I don't want to optimise for the meta case.

A concrete example - I'm very happy working with precedence. I've been doing it since I started school. My five-year-old can understand precedence. Using precedence I can reduce ceremony and noise in my code and allows me to more naturally look at an expression and take in its meaning. But s-expressions don't like using precedence.

Post reply on HN