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

161–170 of 212 posts

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

#161

Post by tom_mellior »

neutronicus wrote: post #44
tom_mellior wrote: post #28

Earlier quoted context omitted.

This point in the article is pretty weird (the rest is good). I don't think IDEs do a lot of parsing to do syntax highlighting, isn't it all just regex matching to identify the types of tokens? I'd be interested in real-world examples of IDEs doing something more complex to achieve syntax highlighting. And conversely, examples of imperfect syntax highlighting of C++ due to the undecidability of its input language. I…

Emacs definitely does parsing of C/C++ (or delegates to an LSP server, depending) in order to do indentation, users' preferences for which tend to depend heavily on syntactic context.

Indentation is a good point, you need a proper parse for that. But for that you don't need the ability to consult symbol tables, or resolve nasty C++ template metaprogramming stuff. A context-free grammar suffices, and C++ has that. C++ also has some very complicated (undecidable) rules for what programs are well-formed and should be accepted by the compiler, but the editor's indentation tool doesn't need to worry about those.

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

#162

Post by tom_mellior »

pasquinelli wrote: post #32
tom_mellior wrote: post #28

Earlier quoted context omitted.

This point in the article is pretty weird (the rest is good). I don't think IDEs do a lot of parsing to do syntax highlighting, isn't it all just regex matching to identify the types of tokens? I'd be interested in real-world examples of IDEs doing something more complex to achieve syntax highlighting. And conversely, examples of imperfect syntax highlighting of C++ due to the undecidability of its input language. I…

>> Any programming language that is massively adopted is context free? > Statically typed languages require semantic analysis and symbol table lookups, so they are out. Isn't that the typechecker, not the parser?

Depends on what level you're thinking of: "Pure" grammar or "well-formed programs acceptable to the compiler". C++ does have a context-free grammar (it's in the standard), and also a lot of additional constraints on what constitutes a well-formed programs (this includes type checking). Since we're discussing a claim that "C++ is famously not a context free grammar", we must be thinking of the latter notion and include the type system in our considerations. In which case, we must consider the entire frontend as a whole.

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

#163

Post by tom_mellior »

a1369209993 wrote: post #103
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…

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…

> This is equivalent to aⁿbⁿcⁿ

Is it? You only indent with spaces, so a = b = c = ' ', and the problem you claim disappears.

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

#164

Post by uryga »

Dylan16807 wrote: post #123
uryga wrote: post #112

Earlier quoted context omitted.

> That is not the right name to use for returning an element without side effects how do you feel about `str.replace`? i'd say that that name implies side-effects too, but everybody's used to the fact that [in python] strings are immutable, so it's no big deal. it's all a matter of expectations and language conventions – e.g. in Haskell, `replace`, `reverse`, `insert` etc. would all be pure functions and no one would…

> how do you feel about `str.replace`? i'd say that that name implies side-effects too, but everybody's used to the fact that [in python] strings are immutable, so it's no big deal. In that case it's returning a modified string, at least. 'pop' and 'replace' both create modifications to the item you feed in. You can return the modified version, or you can mutate it in place, or you can do both. But it makes zero sens…

> So as long as 'pop' is returning the element from the list/map/set/whatever, and nothing else, it is the wrong verb for immutable structures.

right, but would anyone really write a functional `pop` like that? that's just `last`. any sensible functional `pop` would return a tuple:

  (x, new_xs) = pop(xs)
so i'm not sure i understand what the problem is tbh. we might be in violent agreement...

and re: unordered containers, i'd say it "makes as much sense" for immutable and mutable ones. maybe it returns the most recently inserted element or whatever's convenient/efficient to implement; but it's arbitrary regardless of any (im)mutability.

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

#165

Post by tom_mellior »

Rochus wrote: post #45
WalterBright wrote: post #13

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)?

Contrary opinion to the others: In almost all cases, don't bother self-hosting the entire compiler. At least not if you want an end result that optimizes nicely and can generate code for a wide range of architectures. That's a lot of work, and you're better off targeting an existing compiler framework (ahead of time: GCC or LLVM; JIT: the JVM or the CLR; in both cases there are probably other good choices as well). Of course if you start your project with "I wonder what an X compiler in X would look like", you will self host your hobby project end to end. But if you are trying to make something that is maximally useful for others, use the already existing stuff that is out there, and that is much better than what you would pull off on your own.

As for the parser, it's probably true that for many languages, self-hosting the frontend may be attractive. For others it might not. Someone else wrote: "if people who are really good (let's say) Go programmers want to make the Go compiler better they then don't have to try and write go in C++ if the main compiler is written in C++", which is somewhat true. On the other hand I once had to do stuff in the gfortran frontend, and I was very happy that it was written in C and not Fortran, because I know C but don't know Fortran. So I guess as long as your language is niche among people likely to be compiler developers, the point about attracting that talent doesn't hold. If your language gets popular enough, self hosting the frontend should become more interesting. Before that it's more of a gimmick.

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

#167

Post by tom_mellior »

nostrademons wrote: post #115

I used to be big into programming language design, but eventually decided that there just wasn't enough headroom to do something innovative enough to warrant the switching costs. The world doesn't need yet another syntax on top of basic C-style or Lisp-style semantic constructs. Lately I've been wondering if I should reconsider, though, and have had a bunch of ideas that blur the lines of what should be considered in…

1. OpenACC kind of goes into this direction, but the specification is a bad joke, and it's less ambitious than your goal. Still, might be interesting.

4. This sounds cool. I wonder how difficult it would be to implement a version of this using fork. The user would write:

    if (some_condition_I_want_do_debug) {
        suspend_a_copy();
    }
where suspend_a_copy would fork and continue. The forked version would log its PID somewhere and go to sleep until woken up by an external signal, then continue from there. Possibly you would attach a debugger first.

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

#168

Post by olvy0 »

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…

FWIW, I've learned s-expressions and never particularly liked them either. I like their elegance, sure, but I found working with them to be cumbersome in practice.

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

#169

Post by steveklabnik »

wtetzner wrote: post #110
steveklabnik wrote: post #17

Earlier quoted context omitted.

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.

Does that make the grammar context-sensitive, or just the lexer?

This is not an area of my expertise, so I can't say.

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

#170

Post by gbear605 »

tom_mellior wrote: post #163
a1369209993 wrote: post #103

Earlier quoted context omitted.

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…

> This is equivalent to aⁿbⁿcⁿ Is it? You only indent with spaces, so a = b = c = ' ', and the problem you claim disappears.

I'm not sure that's a solution. The problem is verifying that the three 'n's are equal, not that 'a', 'b', and 'c' are equal. Solving this cannot be done in a context free grammar [0].

[0]: https://cs.stackexchange.com/questions/33153/is-an-bn-cn-con...

Post reply on HN