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

41–50 of 212 posts

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

#41

Post by zzo38computer »

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…

Is Haskell context-free if you don't use the indentation layout mode? Haskell does support using braces and semicolons too. However, this is not true of Python (as far as I know).

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

#42

Post by h-cobordism »

WalterBright wrote: post #29
nafey wrote: post #25

Earlier quoted context omitted.

Are you familiar with Jai language being developed by Jonathan Blow? What is your opinion on its design?

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 assume most people run the code they compile on the very machine they compile it on, so how does preventing compile-time system calls help stop malware?

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

#43

Post by tomp »

WalterBright wrote: post #29
nafey wrote: post #25

Earlier quoted context omitted.

Are you familiar with Jai language being developed by Jonathan Blow? What is your opinion on its design?

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…

Why not instead alert the programmer that compiling this code would call such-and-such system calls?

That's IMO how all software should work. Apple did something similar, AFIAK, in the latest version of MacOS, and failed - it's obviously something that is extremely hard to retrofit onto existing software. But allowing arbitrary execution for new software, and sensibly limiting it (e.g. "this program cannot access the internet") is, I predict, fairly feasible.

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

#44

Post by neutronicus »

tom_mellior wrote: post #28
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…

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.

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

#46

Post by JoeSmithson »

WalterBright wrote: post #29
nafey wrote: post #25

Earlier quoted context omitted.

Are you familiar with Jai language being developed by Jonathan Blow? What is your opinion on its design?

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?

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

#47

Post by tomp »

pbiggar wrote: post #24

This advice is quite good for certain types of programming language, if you look at the world the same was as he does. We're implementing Dark from a completely different worldview, and from that vantage point, a lot of these aren't exactly wrong, but different. > Syntax matters The approach we took with Dark is that there isn't a syntax, per se, in that there isn't a parser. There's certainly a textual view of Dark…

> The approach we took with Dark is that there isn't a syntax, per se, in that there isn't a parser.

Can you explain how that works? Unless Dark is a purely visual programming language (in which case I'd say that there is "syntax", it's just a bit more abstract, and in any case, it seems that visual languages haven't really caught up as an idea), I find that hard to believe.

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

#48

Post by david2ndaccount »

WalterBright wrote: post #29
nafey wrote: post #25

Earlier quoted context omitted.

Are you familiar with Jai language being developed by Jonathan Blow? What is your opinion on its design?

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…

Other languages (such as python) have install-time code execution. When you pip install a library, the library can run arbitrary code and of course has access to anything and everything via the python interpreter. The only thing protecting you is faith in pypi. How is compile-time code execution any different?

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

#49

Post by chubot »

matheusmoreira wrote: post #27
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…

> A main point here is that you have to consider the lexer and parser separately. Grammars don't address this distinction, which arises in essentially all programming languages. So why does this happen? Couldn't context-free language parsers emulate a lexer by treating individual characters as symbols?

If there's no feedback, you can consider the lexer and parser separately as languages.

- The lexer recognizes a set of strings of characters.

- The parser recognizes a set of strings of tokens (as returned by the lexer)

But those two languages will have different power in general, so, like Jim points out, when you say something like "Python is context-free" or "Haskell context-free", it's not clear what you're talking about. And it's really false under any reasonable interpretation.

So you can consider them separately, and make a precise statement. But if there's feedback between the two, then you can't do that anymore. The theory doesn't tell you any properties a that the (lexer + parser + feedback mechanism) possess.

That is, regular languages and context-free languages have all sorts of properties proven about them, including ones that let you write code generators. You don't get any of those properties when you have ad hoc feedback mechanism between the lexer and parser.

----

Someone could come up with formalisms for specific types of feedback.

I think OCaml's Menhir has done some of this, but I don't remember the details off hand.

They have written parsers for C (CompCert) and POSIX shell and addressed some of the gaps between theory and practice. I don't use it but they're at least tackling the right problems.

But note that C uses a specific type of feedback (the lexer hack), which isn't identical to what other languages use. So you would have to come up with a formalism for each one, and probably nobody has done that.

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

#50

Post by jakear »

Off topic:

Annoying that this is totally unreadable even at 300% zoom on an iPhone 11 Pro.

I feel like a set of people refuse to learn proper HTML/CSS as some sort of statement, not realizing their laziness renders their work unavailable to the visually disabled.

HN behaves similarly poorly.

Post reply on HN