Live data from Hacker News

The naked truth about writing a programming language (2014)

digitalmars.com

101–110 of 212 posts

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

#101

Earlier quoted context omitted.

> Mixtures of the two tend to have syntax problems. My gripe isn’t the syntax, it’s the lack of guarantees/constraints. When I’m working in a language with immutable data structures, I know what to expect. A language like Python with some added functional sugar is much harder for me because I make stupid assumptions. Spent a half hour once chasing down a bug just because I was carelessly assuming list.pop() didn’t al…

You make a good point in general, but I'd be upset if a function called 'pop' didn't mutate anything. That is not the right name to use for returning an element without side effects.

Ruby has a nice convention where impure functions like those have a "!" appended to the name. For example String#gsub takes immutable string arguments and returns a new string, but String#gsub! operates on a String instance and mutates it.

I guess if you write a new programming language, it would be nice to establish that convention early on, when it's still possible to be done.

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

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

> s-expressions don't like using precedence

I'd rather say that in s-expressions, precedence is regular and explicit. To me that's a strong argument in favor of it being more widely accepted as the standard.

With infix notation, operators have implicit precedences, which feel natural to us only because it's what we were taught from an early age.

I'm with the parent comment, that s-expressions ought to be advocated and evangelized (haha), as a foundational approach - even with arithmetic in basic school. If we had started thinking with it as a child, or at least later able to shed the legacy of infix notation, s-expressions are objectively simpler to understand, with fewer things to keep in mind.

Well, that sounds stronger than I meant to. I mostly write in infix-style languages, and they flow fine. But I ideologically align with Lisps - there's a conceptual simplicity and beauty that really should have been the mainstream, and still may in the future.

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

#103

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 be parseable without having to look things up in a symbol table

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

#104
post #54

That's a good set of questions for 2014. Questions that have become important more recently include: - Imperative? Functional? Some mixture of both? Mixtures of the two tend to have syntax problems. - Concurrency primitives. The cool kids want "async" now. Mostly to handle a huge number of slow web clients from one server process. Alternatively, there are "green threads", which Go calls "goroutines". All this stuff i…

> more recently

2014 was yesterday. If you look, you’ll see that nothing on your list is ”more recent.”

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

#105
post #54

That's a good set of questions for 2014. Questions that have become important more recently include: - Imperative? Functional? Some mixture of both? Mixtures of the two tend to have syntax problems. - Concurrency primitives. The cool kids want "async" now. Mostly to handle a huge number of slow web clients from one server process. Alternatively, there are "green threads", which Go calls "goroutines". All this stuff i…

> more recently 2014 was yesterday. If you look, you’ll see that nothing on your list is ”more recent.”

[deleted]

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

#106
post #6

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

[deleted]

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

#107

Earlier quoted context omitted.

You make a good point in general, but I'd be upset if a function called 'pop' didn't mutate anything. That is not the right name to use for returning an element without side effects.

Ruby has a nice convention where impure functions like those have a "!" appended to the name. For example String#gsub takes immutable string arguments and returns a new string, but String#gsub! operates on a String instance and mutates it. I guess if you write a new programming language, it would be nice to establish that convention early on, when it's still possible to be done.

The problem with Ruby’s approach, if I recall correctly (been 10 years) is that it’s inconsistent.

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

#108
post #54

That's a good set of questions for 2014. Questions that have become important more recently include: - Imperative? Functional? Some mixture of both? Mixtures of the two tend to have syntax problems. - Concurrency primitives. The cool kids want "async" now. Mostly to handle a huge number of slow web clients from one server process. Alternatively, there are "green threads", which Go calls "goroutines". All this stuff i…

> more recently 2014 was yesterday. If you look, you’ll see that nothing on your list is ”more recent.”

The importance of GPUs for performance is new this century. The other items, ok, no.

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

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

what is context free language anyway? context free grammar had a clear definition in parsing, not sure i understand how that can be extended to languages.

I read it to mean that the language's grammar is context free, but I guess I'm not sure if that's what was meant.

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

#110

Earlier quoted context omitted.

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.

Does that make the grammar context-sensitive, or just the lexer?
Post reply on HN