The naked truth about writing a programming language (2014) • Hacker News Board

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

#191

Post by didibus » Sun, May 03, 2020, 8:07 PM UTC

chrisseaton wrote: post #150

didibus wrote: post #128

Earlier quoted context omitted.

Do you mean precedence or infix? The choice of infix vs prefix vs postfix is semantic. What s-expression syntax imposes is to have everything balanced between brackets. For example, nothing prevents an S-expression based language to allow: (2 + 3) The only thing is there are no precedence rules, you must have parenthesis always: ((3 * 2) + 5)

Why are you trying to explain s-expressions to me like I’ve never heard of them when I’m already in a thread debating their pros and cons for language design and implementation?

I'm sorry that you are getting defensive and feeling like I'm attacking your expertise. But there's all kind of people with different experience levels on HN, so I prefer asking for clarification when I can instead of assuming things and talking over each other.

If you truly meant precedence, well, I guess I disagree with you. Even in math, I prefer explicit parenthesised expressions for readability.

If you meant infix, that's not a concern of s-expression so it's irrelevant to the syntax question.

I know that personal preference is basically the reason for various syntaxes off course. But I think similar to how there's a movement that a common standard code formatting is better than everyone having their own custom formats, you could argue that having a common syntax which I think s-expression would make a great common syntax, could also yield an overall better outcome. And that's my argument here.

Most languages have a: here's an s-expression based version of it. Like Python has Hy, Lua has Fennel, etc. So you already see a trend in how s-expression could easily cover all those languages, which is normal since they get closer to the parse tree anyways.

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

#192

Post by einpoklum » Sun, May 03, 2020, 9:56 PM UTC

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…

> GPUs. Biggest compute engines we have. How do we program them?

1. Carefully. They only give you - roughly and unless you're super-lucky - around one order of magnitude improvement in raw flops and raw GB/sec memory bandwidth over a perfectly-exploited CPU. (Not that it's easy to properly exploit a CPU of course; it's actually quite difficult.) That means that if you cut even a few corners - you're just going to lose that edge, and a (again, perfectly-programmed) CPU beats you.

2. With a programming language which has zero or very-low cost abstractions, and models well the computations a GPU "thread" can perform. Preferably with some JIT'ing capability to be dynamic enough. For the first two, that trusty warthog, C++, does fairly well - especially with some help from nice libraries. (Shameless self-plug time... this kind of help: https://github.com/eyalroz/cuda-kat ; I'm thinking of submitting that to "Show HN" soon.) JITing for GPUs is maaaaasively under-explored and under-developed IMHO, and if someone is interesting in collaborating on that, feel free to write me.

Would other languages do? If there's not enough ability to abstract, you get a mountain of specialized code; if there's too much abstraction, you start paying through your nose. Could Rust work? I don't know. Perhaps one of those "better C"'s like Zig? The fact that CPU-side libraries can't really run on the GPU kind of levels the playing field against languages with a large base of already-written software.

> Ownership... C++ now tries to do "move semantics", with modest success, but has trouble checking at compile time for ownership errors

Actually, C++ has, over the past decade or so, introduced several measures to address the issue of ownership and resource leakage. If you combine move semantics, library facilities (mostly smart pointers), the problem is half-solved. Static analysis is improving too, especially when you "decorate" parameters, e.g. with `owner>` or `non_null>` and such. The "C++ Core Guidelines" (https://github.com/isocpp/CppCoreGuidelines) aim to be machine-checkable whenever possible.

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

#193

Post by kyllo » Sun, May 03, 2020, 10:11 PM UTC

bmn__ wrote: post #157

kyllo wrote: post #100

Earlier quoted context omitted.

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

You're right, I meant that each valid RHS matches one and only one LHS--but that's also true of CSGs.

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

#194

Post by kyllo » Sun, May 03, 2020, 10:17 PM UTC

signaru wrote: post #144

kyllo wrote: post #100

Earlier quoted context omitted.

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…

In BASIC the equal symbol "=" can mean assignment or equality depending on "context". Is this an example of a non context free? On the other hand, I've seen EBNF definition of BASIC (VB, actually). Is this a contradiction? (just someone still learning)

It's still context-free, the reason is because by the time you hit the '=' symbol you already know whether you're in a or a production rule, based on the preceding symbols (namely the LET keyword), based on these excerpts from the BASIC EBNF:

       ::= CLOSE '#' Integer
                    | DATA  
                    [...]    
                    | LET Id '='  
                    [...]
                    | Remark

     ::=  '='   
                    |  ''  
                    |  '> 
                    |  '>'   
                    |  '>='  
                    |  ' 
                    |  ' 
                    |

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

#195

Post by kyllo » Sun, May 03, 2020, 10:22 PM UTC

johannes1234321 wrote: post #114

kyllo wrote: post #100

Earlier quoted context omitted.

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…

> A classic example is that in C++ it is impossible to know whether The classic example, I guess, is the most vexing parse: https://en.m.wikipedia.org/wiki/Most_vexing_parse """ The line TimeKeeper time_keeper(Timer()); is seemingly ambiguous, since it could be interpreted either as a variable definition [...] a function declaration [...] """ These things you can only resolve by having the symbol tables around and ch…

Yes and programming languages are human interfaces to machine instructions, so context sensitivity can be manageable and even desirable to human users of the language, even if it makes the implementation of the language interpreter more complex or less elegant. Programming language designers make this trade-off all the time.

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

#196

Post by simonebrunozzi » Mon, May 04, 2020, 5:43 AM UTC

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…

How would you try to describe the future of software development based on these (excellent) questions of yours, e.g. in 5 years from now?

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

#197

Post by teleforce » Mon, May 04, 2020, 7:48 AM UTC

loicd wrote: post #154

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

Not OP but there were discussions last week regarding this matter in HN [1]. According to the original article C++ is neither context-free nor context-sensitive, it is actually undecidable [2].

[1] https://news.ycombinator.com/item?id=23008599 [2]https://medium.com/@mujjingun_23509/full-proof-that-c-gramma...

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

#198

Post by teleforce » Mon, May 04, 2020, 7:58 AM UTC

WalterBright wrote: post #13

Author here. AMA!

Hi Walter, just wondering about the seamless integration of the imperative and functional paradigm in D, do you implement Static Single Assignment (SSA) form for that at the compiler back-end [1]?

[1] https://www.cs.princeton.edu/~appel/papers/ssafun.pdf

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

#199

Post by teleforce » Mon, May 04, 2020, 8:09 AM UTC

As you are probably aware that the author of the article is the designer of the D programming language.

For background reading of the design of D programming language, this is a very interesting and insightful paper on the history and the origins of D programming language up to 2018 [1].

[1] http://erdani.com/hopl2020-draft.pdf

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

#200

Post by teleforce » Mon, May 04, 2020, 9:04 AM UTC

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…

Regarding your last point, as of now we have four main processor hardware namely CPU, GPU, FPGA and TPU (the new kid on the block). The hard question or problem is how can we program these different animals seamlessly?

Chris Lattner of LLVM and Swift fame is currently working on MLIR to program heterogeneous processors [1].

At the same time ETH Zurich is working on LLHD, to unify hardware design and programming (e.g. Verilog, VHDL) including the testing or testbench that is using conventional software programming (e.g. TCL, Perl and SystemVerilog) [2].

Apparently it seems that the key concept to solving this problem is Static Single Assignment (SSA) form. It is well known that SSA can seamlessly support imperative and functional programming [3].

For the past several years, both Chris (CPU, GPU & TPU) and ETH Zurich (CPU, FPGA and Circuit Design) are independently using SSA to solve this hard problem.

I personally believe SSA concept will empower the compiler community as the quaternion concept empower physicists like Einstein overcome Maxwell Equation and 3D game programmers to overcome gimbal lock.

Only time will tell how this idea will pan out.

[1] https://mlir.llvm.org/

[2] http://llhd.io/

[3] https://www.cs.princeton.edu/~appel/papers/ssafun.pdf