Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Carbon’s most exciting feature is its calling convention

foonathan.net

Post reply on HN
Print view View original

151–160 of 223 posts

Re: Carbon’s most exciting feature is its calling convention

#151

Post by zasdffaa »

chrisseaton wrote: post #149
ithkuil wrote: post #146

Earlier quoted context omitted.

In parser theory there is such a thing as an ambiguous grammar. Parser generators detect such a grammar and never produce an actual parser for it. So in a sense most parser that you actually use don't have ambiguous grammars by definition. That said, you could have a manually written parser that thinks it implements an "ambiguous grammar", but in reality chose an deterministic (even if possibly arbitrary l) resolutio…

I guess I don't understand why we use languages for writing grammars that let you express ambiguity in the first place. I think parser generators were a mistake.

for someone who is the founder of TruffleRuby (I've checked, and you are https://docs.oracle.com/en/graalvm/enterprise/21/docs/refere...>), you sure have made some very odd comments and I don't know what to make of them.

Re: Carbon’s most exciting feature is its calling convention

#152

Post by chrisseaton »

zasdffaa wrote: post #151
chrisseaton wrote: post #149

Earlier quoted context omitted.

I guess I don't understand why we use languages for writing grammars that let you express ambiguity in the first place. I think parser generators were a mistake.

for someone who is the founder of TruffleRuby (I've checked, and you are https://docs.oracle.com/en/graalvm/enterprise/21/docs/refere... >), you sure have made some very odd comments and I don't know what to make of them.

> you sure have made some very odd comments and I don't know what to make of them

Well they’re from practical experience aren’t they.

Re: Carbon’s most exciting feature is its calling convention

#153

Post by chrisseaton »

ithkuil wrote: post #150
chrisseaton wrote: post #149

Earlier quoted context omitted.

I guess I don't understand why we use languages for writing grammars that let you express ambiguity in the first place. I think parser generators were a mistake.

I agree it's a pain. Could you share some alternatives?

Imperative parsing - PEGs or just plain old recursive descent.

Re: Carbon’s most exciting feature is its calling convention

#154

Post by temac »

usrnm wrote: post #142
olliej wrote: post #102

Earlier quoted context omitted.

...yes? The C++ is absolutely ABI stable, and is described in excruciating detail, as demonstrated by all those C++ libraries, that you don't have to recompile for on every OS update. I suspect you're confusing when you make an ABI change, without changing the A P I, which is indeed an easy thing to do: You have to make sure that you only add members to the end of objects, however that exact constraint also applies t…

> The C++ is absolutely ABI stable C++ ABI doesn't even exist, there are several competing standards (much fewer now than there used to be) and nothing is guaranteed even between different compiler versions, let alone different compilers. Not that long ago we used to have two implementations of std::string in gcc you had to choose from and if the library you're linking with chose another one, you were out of luck.

A thing that does not exist, still is leveraged to build whole distros, and its too high stability resulted in the creation of Carbon.

Re: Carbon’s most exciting feature is its calling convention

#155

Post by ithkuil »

chrisseaton wrote: post #153
ithkuil wrote: post #150

Earlier quoted context omitted.

I agree it's a pain. Could you share some alternatives?

Imperative parsing - PEGs or just plain old recursive descent.

Ok that's about the "parser generator" part. But what about the "formal grammar" part?

Do you really want your language to be defined by a particular imperative parser implementation?

I'm asking because I do have a practical problem: my team has a hand crafted parser for a language. It should follow a spec written in EBNF. That spec could be ambiguous it's not because an automated tool checks that that EBNF grammar is not ambiguous.

I find the ability to document the grammar using something that everybody understands (BNF and variants) to be very useful. Yet, your comment seems to imply that since it allows ambiguous grammars we should be using it.

EDIT: our grammar is implemented by three different parsers, written in two programming languages.

Re: Carbon’s most exciting feature is its calling convention

#156

Post by chrisseaton »

ithkuil wrote: post #155
chrisseaton wrote: post #153

Earlier quoted context omitted.

Imperative parsing - PEGs or just plain old recursive descent.

Ok that's about the "parser generator" part. But what about the "formal grammar" part? Do you really want your language to be defined by a particular imperative parser implementation? I'm asking because I do have a practical problem: my team has a hand crafted parser for a language. It should follow a spec written in EBNF. That spec could be ambiguous it's not because an automated tool checks that that EBNF grammar i…

> Do you really want your language to be defined by a particular imperative parser implementation?

Yes please. The code defines completely and unambiguously how the language is parsed.

Re: Carbon’s most exciting feature is its calling convention

#157

Post by zasdffaa »

chrisseaton wrote: post #152
zasdffaa wrote: post #151

Earlier quoted context omitted.

for someone who is the founder of TruffleRuby (I've checked, and you are https://docs.oracle.com/en/graalvm/enterprise/21/docs/refere... >), you sure have made some very odd comments and I don't know what to make of them.

> you sure have made some very odd comments and I don't know what to make of them Well they’re from practical experience aren’t they.

Well, first you don't seem to understand what 'ambiguity' means in the context of parsing "Nobody writes a parser that has a random decision..." which is weird. It's a very establish meaning here.

Then you say "I guess I don't understand why we use languages for writing grammars that let you express ambiguity in the first place" without any suggestions, or even if this is possible, or if it is, whether the resulting language might be too constrained to be useful (interesting question though. Edit: even context-free grammars have ambiguity, eg. the regexp "aa" is legal but ambiguous for sentence "aaa").

Then "I think parser generators were a mistake" which is surreal. If you've ever had the tedious misfortune to write one manually, you know how much faster it is to have the computer do that work.

So I am thrown a bit here.

Re: Carbon’s most exciting feature is its calling convention

#158

Post by JonChesterfield »

dthul wrote: post #134
matrix_overload wrote: post #115

Spent a terrible amount of time hunting down C++ bottlenecks. It has almost never been about unintended copying of structs or classes. It usually boils down to someone assuming that a particular collection or algorithm won't be on the critical path, and using a lazy O(N^2) solution. Then the codebase grows, use cases shift, someone puts another O(N^2) algorithm around an existing O(N^2) and the whole thing explodes.…

To chime in with my personal experience, I did actually lose almost two days on hunting down an unintended copy constructor call. The method expected a "const B&" but was called with a "const A&". It also happened to be called a lot. The actual type names were longer and very similar, and looking at the code it was hard to see they were different. Type B had a copy/conversion constructor from type A so every time the…

Implicit type conversions are a hazard. Iirc the constructor can be marked explicit to make call sites more obviously expensive.

Re: Carbon’s most exciting feature is its calling convention

#159

Post by tsimionescu »

tialaramex wrote: post #118
gumby wrote: post #90

Earlier quoted context omitted.

You made an object rather than using an existing one. How is the compiler supposed to know that you wanted an existing object?

I don't want an existing object? You seem to be having a lot of trouble with this very basic idea. Objects do not necessarily need distinct addresses. "But that's how C++ works" is just a fact about how C++ works, it has no larger significance, and where it conflicts with the sensible way to do things it's actually a defect.

How would you define object identity if different objects can have the same value and the same address?

To my mind, an object is a value with a unique identity. How else would you define it?

And if you want a billion empty values, then yes, those could all be implemented by the same object - it's pretty easy to implement, even though it would be ncie for a compiler to do it automatically (like how Java normally gives you the same Integer object if you box the same int value in two different places, even though it will give you a different Integer of the same value if you explicitly ask for it with new).

Re: Carbon’s most exciting feature is its calling convention

#160

Post by JonChesterfield »

girvo wrote: post #140

My one annoyance with Carbon’s promise is the lack of ABI stability; I know why they are doing that, and I know that C++ has the same downside, but as someone who binds C libraries constantly in other languages and finds the pain of C++ and now likely Carbon frustrating, it makes me a little sad to see the same mistake repeated. A C++ replacement that is just as difficult to bind/link/work with in other languages as…

It's pretty much the reason for it to exist I think. C++ has painted itself into a corner wrt ABI, leaving space for a faster language to replace it.
Post reply on HN