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

151–160 of 212 posts

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

#151

Post by tomp »

pbiggar wrote: post #76
tomp wrote: post #47

Earlier quoted context omitted.

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

Sure. You can see it in action at http://darklang.com/launch/demo-video (also, we've gone through our waiting list, so we're pretty much adding new folks who sign up immediately, if you want to try it out). The main idea is that you when you make a change (let's say, you type a key in the editor), that change happens directly on the AST (the internal set of objects that represent the program). So for example, if you'…

So, looks like it's a textual language, it clearly has a syntax. How you manage the transition from text to AST and back, that's a different story - it might be that your approach is much better! (Though on the other hand it looks similar to how CLR/Roslyn C# compiler does it.)

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

#152

Post by entha_saava »

jakear wrote: post #50

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.

Probably the problem with iOS browser. Works well with Firefox on Android as well.

Also does your apple phone browser not have anything like a "reader mode"?

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

#153

Post by WalterBright »

pbiggar wrote: post #76
tomp wrote: post #47

Earlier quoted context omitted.

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

Sure. You can see it in action at http://darklang.com/launch/demo-video (also, we've gone through our waiting list, so we're pretty much adding new folks who sign up immediately, if you want to try it out). The main idea is that you when you make a change (let's say, you type a key in the editor), that change happens directly on the AST (the internal set of objects that represent the program). So for example, if you'…

> That means, if it isn't a "syntactically" valid program, you can't create it in the first place.

It's an interesting idea. I don't know if it would work for me, though. I don't write code as a stepwise refinement of a valid program, I massage the text gradually into a valid program. This is especially true when refactoring.

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

#154

Post by loicd »

WalterBright wrote: post #13

Author here. AMA!

Although the explanation of what you mean by "context-free grammars" is clear, it seems to me that you should be using "unambiguous grammars" instead. An ambiguous context-free grammar is not going to facilitate the job of an IDE. I also think you are mistaken about the C++ grammar not being context-free. The problem is that it is ambiguous. I could be wrong here since I have not kept up with the C++ standards. So can you provide an example of C++ grammar productions you think are not context-free?

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

#155

Post by valera_rozuvan »

One should consider creating a VM first - it simplifies life a bit, and makes the language more portable in the future. The implementation task is split in two - compiler and VM. First, compiler targets the VM. Second, the VM targets the CPU. This way porting to different architectures is just a matter of adding to the VM to interface with the new arch. A compiler and VM definitely are 2 separate projects with their own set of issues.

Also we should consider the possibility of going the eDSL (embedded domain-specific language) route. Working at a very high level, re-using existing constructs of the host language. If one is interested, looking into SICP [1] will show an example of such a project. Using Scheme to build an interpreter. This can easily be done in several days. Best to try to reduce doing work that has been done many times before.

----------

[1] https://mitpress.mit.edu/sites/default/files/sicp/index.html

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

#156

Post by bmn__ »

chubot wrote: post #140
tanilama wrote: post #70

Earlier quoted context omitted.

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.

The OP is abusing the term "context free". He's saying it avoids "the lexer hack" [1]: Context free grammars. What this really means is the code should be parseable without having to look things up in a symbol table That's NOT what context free means. That's a narrow view from someone designing a C-like language and trying to avoid a very specific property of C. Another example of being context-sensitive, which has n…

> [CF] was discovered and described by linguists and mathematicians before any programming language existed

Nitpick: that was 1956, by then a few PL did already exist.

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

#157

Post by bmn__ »

kyllo wrote: post #100
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…

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…

> without ambiguity

This is not a distinguishing feature. (I'm assuming you meant something else.) Example of a CFG with ambiguity:

    S → S S
    S → x

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

#158

Post by bmn__ »

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…

There are plenty, the majority even, of programming languages that do not enforce consistent indentation. You make a false generalisation when you claim that CFG are completely the wrong thing.

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

#159

Post by bmn__ »

chrisseaton wrote: post #18
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...

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

I would guess so, too. In my experience, they do strive to be CF, the CS parts express mildly/are few and far between and often are accidental.

That makes using a CFG parser practical and hacking around the problems caused by CS does not take much effort.

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

#160

Post by tom_mellior »

geophile wrote: post #53
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…

I'm pretty sure that the JetBrains products (Intellij, PyCharm, etc.) have a pretty deep understanding of the languages they handle. Java is strongly typed, and Intellij does a perfect job, (as far as I can tell), of highlighting, and more importantly, refactoring. Hard to see how they could do that with just regex matching. By contrast, Python is more dynamic, and so the refactoring in PyCharm is pretty weak. It usu…

> highlighting, and more importantly, refactoring. Hard to see how they could do that with just regex matching.

The former is easy, the latter is impossible with regexes only. Which tells you that they are very different things. For refactoring you need not only a proper parse, but also the ability to "look things up in symbol tables". Which is what I said: There are good reasons to run a proper language frontend from the IDE. But syntax highlighting isn't one of these reasons. And refactoring isn't possible with only a simple parse without using symbol tables.

Post reply on HN