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

171–180 of 212 posts

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

#171

Post by gbear605 »

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…

I'd suggest that generally the grammar should be context-free, but that a few features = can be non-context-free. Formatting like this should specifically be a separate check IMO.

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

#172

Post by cxr »

billconan wrote: post #55
WalterBright wrote: post #14

Earlier quoted context omitted.

The implementation of D has a lexer that is independent of the parser, and a parser that is independent of the rest of the implementation. I have resisted enhancement proposals that would put holes in those walls.

could you give an example for > Any programming language that is massively adopted is context free? I want to have an intuition on what is context free and what is not. Is D context free? I mean I want to make a useful language, is being context free practical?

The best way would probably be to work on a language that isn't context-free. When you run into the problems context-sensitivity introduces, then you'll really start to understand it.

In the past, Pascal was widely used in teaching contexts, for both learning to program and later how to implement a compiler. I've seen Walter say in the past that he got into doing languages from a series of articles in Byte magazine that included the listings for a small Pascal compiler. For your task, you can use Oberon instead, which is a smaller and simpler than Pascal. Oberon-07 is context free up to a point, which is another way of saying that it's not context-free. It'll work well for this exercise. Don't worry about writing a full-fledged compiler, because you'd end up spending forever on the code generator backend. Instead implement half of a compiler.

Here's one project that fits the description of being one half of a compiler—a documentation generator:

https://github.com/schierlm/OberonXref/

Implementing this requires doing the lexer and the parser, but its "backend" streams out documentation pages instead of object files or assembler. The truth is, you wouldn't even need to go that far. Just do the lexer and then start implementing the parser—let's say that your program should just read in source code and then say whether it's valid or not—whether it will parse. Since Oberon is mostly context-free and the natural way to do things is to use a recursive descent parser, you'll get into a rhythm implementing things, until you run into the part that's context-sensitive, at which point things will get uncomfortable. You will find true enlightenment then. This can be done over a weekend, but if you reach the end of the first weekend and realize it will take you two, don't sweat it.

> I mean I want to make a useful language, is being context free practical?

It is. If you do the exercise above, it should be straightforward to figure out several different ways to change the grammar to eliminate context-sensitivity in your parser. You'll realize that the transformations would be minor. They won't compromise the power or practicality of the language, and it's possible to end up with one that is almost exactly the same. The biggest casualty in this case would be reworking a dubious design decision made for aesthetic reasons.

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

#173

Post by dwenzek »

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…

Great list!

I specifically agree that the triple (transformation between data representations + ability to define where the code should execute + built-in profiling) can be a game-changer. It would help to solve the tension between clarity and performance by decoupling the what from the how.

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

#174

Post by neutronicus »

zzo38computer wrote: post #58
Animats wrote: 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…

I would say possibly to use a different programming language for GPU than CPU. I like the idea of Checkout (see [0]) for GPU programming, although unfortunately it is not implemented and the preprocessor is not yet invented. (The trigonometric functions are also missing. They should probably have at least sine, cosine, and arctangent, since these functions seem like useful to me when doing graphics.) [0] http://esola…

I think using trig and especially inverse trig is almost always an antipattern in graphics code. Careful use of dot and cross product will almost always be both more performant and more robust.

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

#175

Post by tom_mellior »

gbear605 wrote: post #170
tom_mellior wrote: post #163

Earlier quoted context omitted.

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

Yeah, you're right. I got confused by the original phrasing.

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

#176

Post by mrlonglong »

WalterBright wrote: post #131
a9h74j wrote: post #130

Earlier quoted context omitted.

Years ago IIRC you put out a request for original Zortech C++ disks and packaging, if anyone had some. I was sorry that I had just disposed of mine six months earlier. .. That was my one-and-only C++ in the early 90's, and I am still programming in D. Sorry I couldn't help!

No problem. By the kind work of many people, I managed to accrete a fairly complete collection.

I still have Zortech C 1.06 on my old P166. I should boot it up to see if it still lives !

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

#177

Post by Dylan16807 »

uryga wrote: post #164
Dylan16807 wrote: post #123

Earlier quoted context omitted.

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

> so i'm not sure i understand what the problem is tbh. we might be in violent agreement...

A two-return pop like that is a little weird, but still basically reasonable.

But a one-return pop is a misleading term for immutable data structures. Use list[-1] or last(list) or something.

When I say I'd be upset at pop not mutating a list, I'm talking about a one-return pop specifically.

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

If the structure is immutable and unordered, a one-return pop is almost totally useless.

You use it, it gives you some element. Then what? You can't meaningfully use it again, because it might give you the same element, or it might not. You can't whittle the structure down one element at a time, processing each element as you go.

The only things you can dependably do with it are check if the data structure is empty or not, and get an arbitrary example element.

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

#178

Post by jakear »

entha_saava wrote: post #152
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"?

It doesn’t work like that. I believe one should strive to make their content accessible to all possible viewers (it’s not like mobile Safari is niche), not simply throw their hands up in the air and blame it on the OS when some visually impaired are unable to access the content. iOS has the mechanisms to zoom, and websites by default will work with zoom. But this person has written just enough CSS to break native accessibility, but not enough to bring it back.

Reader mode is enabled for many websites, but not this one. Another case of someone writing just enough CSS to screw over their visually impaired viewers.

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

#179

Post by pbiggar »

GreedCtrl wrote: post #145
pbiggar wrote: post #136

Earlier quoted context omitted.

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?

That's not really how Dark works. You're not manipulating text in your editor - you use our editor, and our editor only uses ASTs. So when cutting and pasting, you're cutting and pasting AST, not text. So to answer your question, you can paste an entire handler or function at once, but it will be one you copied from another place in DArk and it will be structured.

We've looked at allowing people to paste text (eg from Stackoverflow) into Dark. We think we can do it by just inserting each character one at a time (though there's a technical flaw with that at the moment, which could be addressed). In that sense, Dark is sort-of a parser (I don't know if it technically counts).

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

#180

Post by pbiggar »

tomp wrote: post #151
pbiggar wrote: post #76

Earlier quoted context omitted.

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

The code always lives as AST, and the code that you see in the editor is a pretty-print of the AST. We don't go back and forth between AST and text - when you make a change in the editor, we look up the "token" where your cursor was, and use it to find the place in the AST that needs a change, and changes only that.
Post reply on HN