Live data from Hacker News

The naked truth about writing a programming language (2014)

digitalmars.com

141–150 of 212 posts

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

#141

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…

Note that "context free grammars", in the technical sense, is completely the wrong thing. Eg, enforcing consistent indentation is not context free: foo() { return; } ↓↓↓↓↓↓↓↓↓↓↓ aaaa{ bbbbreturn; cccc} ↓↓↓↓↓↓↓↓↓↓↓ aaaabbbbcccc This is equivalent to aⁿbⁿcⁿ, which is pretty much the canonical example of a non-context-free language. What you acually want is not context-free grammar, but, as TFA says: > the code should b…

There is a trick for indentation: Use a context-sensitive lexer in front of a context-free parser. The lexer serves indent and dedent tokens to the parser.

With this trick, you can parse Python with a context-free grammar.

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

#142

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…

Notwithstanding the other comments on context free vs sensitive, the 2014 article predates the language server protocol, which neatly moves the support for programming languages from the IDE to a stand alone tool tied to the language: https://microsoft.github.io/language-server-protocol/

https://en.m.wikipedia.org/wiki/Language_Server_Protocol

So that IDE support point has become much weaker, if not moot.

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

#143
I just started down this road. I’ve mucked with scanning text into object trees but want learn how to make my own language. The difference is this would be a very small domain-specific language that controls an in-memory graph data store targeting interactive stories.

There are great existing tools for this sort of thing, but I have theories/ideas I want to explore.

I’m glad there are healthy discussions on compilers.

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

#144
post #100

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…

Context-free has nothing to do with symbol tables, it just means that in the grammar, the left-hand side of a production rule can only have a single non-terminal symbol, which can always be replaced by the expression on the right-hand side, without ambiguity. Language features are an orthogonal issue--you can implement any language feature with a CFG, but you just can't reuse the same keyword or operator to have diff…

In BASIC the equal symbol "=" can mean assignment or equality depending on "context". Is this an example of a non context free?

On the other hand, I've seen EBNF definition of BASIC (VB, actually). Is this a contradiction?

(just someone still learning)

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

#145

Earlier quoted context omitted.

You have a grammar... you're just enforcing the rules when data is entered. The same as if my editor stopped accepting input if I miss typed a line until it was fixed.. or if I was required to select one of it's autocomplete suggestions. let x = 5 "hi " ++ name DB::set{} Are you saying these lines from the video are not consistent throughout? Like in one part I'll type "x = 5" to assign 5 to x, but somewhere else I'l…

I had to look up whether you were technically accurate (I've a PhD in compilers but parsing's not really my thing), and I think the answer is "it depends, maybe?" To get to the root of the issue though, there is not a parser. Well, one could consider the function that takes each keystroke to be a parser - though I don't know if that's technically correct either. So perhaps the more accurate thing to say is there is n…

What would happen if you paste a complete program in all at once?

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

#146

Earlier quoted context omitted.

Hi Walter, I've been thinking for a few years that it might be fun to fork the C toolchain and create a modernized version of C which is 80% backwards compatible with standard C but fixes the most egregious issues of C. Do you think this is a worthwhile project?

You'll have to make it better than DasBetterC to make it worthwhile!

For reference, "Better C" subset from D: https://dlang.org/spec/betterc.html

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

#147

Earlier quoted context omitted.

My opinion is that Jonathan Blow is an amazing developer and he should be joining us on D! It's been a while since I reviewed the language, and I'd have to re-review it to say anything sane here. But one thing stuck out at me. In D, the support for Compile Time Function Execution (CTFE) is very extensive, and opens the door to a lot of incredible metaprogramming abilities. Jai has this too, but has extended it to all…

I mean, do those people who download and compile code not then generally... run it...? Perhaps I'm missing something but the issue here seems to be whether you trust the source, not whether syscalls are made at compile time or run time?

Trusting the compiler, CI/CD pipelines and verifiable builds.

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

#148
post #45

Author here. AMA!

What is your opinion about self-hosting (i.e. writing the parser/compiler in its own language)? Is that really desirable, or even necessary, or just a gimmik (I know what Wirth says, wonder what you think)?

If it is a general purpose programming language, this should always be done.

Not necessary at the beginning, but eventually as the language gains mindshare.

It is very hard to understand the language, if all contributions to improving it are done in another language.

Somehow it is similar to being a library author without having ever written a full blown application using the library, thus being blind to what are the possible usability issues.

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

#149
post #100

Earlier quoted context omitted.

Context-free has nothing to do with symbol tables, it just means that in the grammar, the left-hand side of a production rule can only have a single non-terminal symbol, which can always be replaced by the expression on the right-hand side, without ambiguity. Language features are an orthogonal issue--you can implement any language feature with a CFG, but you just can't reuse the same keyword or operator to have diff…

In BASIC the equal symbol "=" can mean assignment or equality depending on "context". Is this an example of a non context free? On the other hand, I've seen EBNF definition of BASIC (VB, actually). Is this a contradiction? (just someone still learning)

A context free grammar can handle this fine - as you can see from the EBNF - so no, it's not an example.

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

#150

Earlier quoted context omitted.

> 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…

Do you mean precedence or infix? The choice of infix vs prefix vs postfix is semantic. What s-expression syntax imposes is to have everything balanced between brackets. For example, nothing prevents an S-expression based language to allow: (2 + 3) The only thing is there are no precedence rules, you must have parenthesis always: ((3 * 2) + 5)

Why are you trying to explain s-expressions to me like I’ve never heard of them when I’m already in a thread debating their pros and cons for language design and implementation?
Post reply on HN