|
I typically do not like javascript. It's not personal, it's just the language's typing system I've always found difficult to use, and overall i find the language hard to debug.
But I've been wanting to find information on LL(k) parse table generation that I could digest for years, and some good folx produced an implementation in javascript which doesn't seem to use anything too weird or JS specific so I'm porting it to C#.
Sure I have to debug it in chrome to fill in some of the details but they made it easy to port, and I imagine they planned it that way.
What's fascinating to me about it too, is they're using a parser and lexer to parse the input grammar that looks like it was generated using a port of some common C based tools to javascript.
what a weird and cool little program.
LL(k) Parsing Table Generator[^]
Real programmers use butterflies
|
|
|
|
|
It's not too difficult the other way round too - I just converted a steganography application from C# to Javascript.
I tend to use React and Typescript because with Typescript you can avoid a lot of the problems vanilla Javascript can lead you into.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Yeah I converted a splay tree from typescript to C# once to learn how it was done, and it was a joy.
I didn't end up using the implementation, because it was recursive, but it taught me the concepts.
Real programmers use butterflies
|
|
|
|
|
C++ error messages are often incomprehensibly surreal. I was baffled by an "Undefined reference to vtable" message until a tedious investigation revealed it was just a missing method from my class. Why the f doesn't the C++ compiler just say: "Method xxx is missing."??
This is just a sample; there are many more C++ error messages from simple causes complaining about parts of the compiler I've never even HEARD of. Out of curiosity, I emailed Bjarne Stroustrup and asked him why C++ error messages were so incomprehensible. Here is his reply:
"Thank you for your inquiry. Goats are like mushrooms. If you shoot a duck, I'm scared of toasters."
I guess that answers my question.
|
|
|
|
|
They can be utterly incomprehensible but you get used to them. I revisited C then C++ recently after several years away with C# and found the messages from the compiler to be almost universally unhelpful but after a week or so I settled into it again.
|
|
|
|
|
big same
Real programmers use butterflies
|
|
|
|
|
What compiler are you using? I find Microsoft's to be reasonable most of the time, though errors when using templates can be voluminous and hard to decipher (not a problem specific to Microsoft). I'm surprised that the vtable error wasn't a linker error about a missing function. It's actually better that they detected this at compile time, but I agree that the error message is crap.
|
|
|
|
|
In my own observation, C++ is still governed by idealists more than pragmatists and to a idealist, doing anything with the truth except displaying it in an unfiltered manner is wrong.
Specifically about error messages, https://blog.regehr.org/archives/1088 is an interesting read
|
|
|
|
|
I disagree. Compiler writers aren't idealists, they're all failed stand-up comedians. They can't resist being cute .
Software Zen: delete this;
|
|
|
|
|
That's called hitting the nail on the head!
|
|
|
|
|
I think C++ error messages give you the most information possible about the error. The problem is, they use the language of the C++ standard's meta-syntactic categories to describe what the compiler was doing when it stopped being able to parse your input. If you're not super familiar with the feature you're using, you probably don't know its meta-syntax all that well, so you find the error message incomprehensible. A quick trip to cplusplus.com or cppreference.com will set you right.
|
|
|
|
|
Using these meta-categories violates the abstraction provided by the C++ language. It's lazy programming by the writers of the compiler. No other language (that I know of) does this.
|
|
|
|
|
Well, I don't think it's unreasonable to use published-in-the-standard meta-syntactic categories, though I agree the error messages could have been clearer. What C++ compiler are you primarily working with?
And (some) compilers have referred to meta-syntactic categories for as long as there have been compilers. You may have just gotten lucky. It's a very natural thing to do if you're a compiler writer, though as I said, the error messages could sometimes be more clearly phrased without reference to the meta-syntax.
|
|
|
|
|
It's g++ 7.4.0 (Ubuntu 18.04). Compilers present an abstraction of the machine to the user. Making the user deal with implementation details is a violation of this abstraction. You'd never see anything like this in C#.
|
|
|
|
|
I think my favourite one was a Cobol compiler message from a Prime minicomputer back in the '80s - which said, "Error 23, line 72, column 21, severity 3: fatal. Either an IF is missing or an ELSE is missing or a THEN is missing or the compiler is broken."
By "broken" I think it meant someone pressed Break, but still...
|
|
|
|
|
That reminds me. Some years ago I saw a list of unusual messages from searching multiple source code files. There were errors something like: "WTF: This should never happen". Well I give them props for covering every possible scenario, even those that should never happen.
At least that Cobol error was comprehensible. C++ template error messages often require a text editor to break it down into its component parts, so you can find the relevant information. Other error messages are not even close to the actual cause of the error; like reporting missing <something> at the end of some standard libraries header file - when the error is, of course, in one of your source files.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence." - Edsger Dijkstra
"I have never been lost, but I will admit to being confused for several weeks. " - Daniel Boone
|
|
|
|
|
I'm guilty of writing such a "can never happen" error message myself in the 90s. It was meant for my codevelopers, but I forgot to remove it before delivering to our client. Thankfully the man doing first level tests on our client's side caught that message before delivering to the actual users, and we all had a laugh.
Of course, that he did see that message meant that indeed something had happened that I hadn't anticipated, and that needed a fix - so it's actually a good thing that this message was still in there.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
That is why they are needed. Although management would prefer a more professional (boring) message.
If it is possible, then code for it. If you think it is impossible, then you are wrong, by definition, if you thought about it in the first place, then it is possible.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence." - Edsger Dijkstra
"I have never been lost, but I will admit to being confused for several weeks. " - Daniel Boone
|
|
|
|
|
The SPL compiler on Prime used to do something similar
|
|
|
|
|
LOL! That's great!
When I was teaching myself C, the Datalight C compiler gave me this: "Lvalue required". I had no idea at the time what an lvalue was and the "internet" at the time consisted of dial-up bulletin boards. That made for a fun afternoon.
|
|
|
|
|
I agree. Regarding vtables, I've seen many errors that require of the user to understand what vtables are, how they are built, and how they are used by the compiler. Without that knowledge, it's near impossible to figure out what's going wrong. Since the compiler is trying to resolve some symbol, at the very least it should point out which symbol it is working on, and where it encountered that in the source code.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
I have seen that automated line (assumption) posted before. How in the world is he supposed to know why a particular compiler prints the messages is does.
This is not a language issue, it is a compiler issue. Most compilers will just print out what they know and leave it up to you to figure out what the problem is. Some compilers will try to break it down for you, but that is, technically, not their job.
Compile after every function/method that you create, so you know where the error must lie. That is the beauty of modern coding, you do not have to get it right before actually scheduling time to compile and test it.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence." - Edsger Dijkstra
"I have never been lost, but I will admit to being confused for several weeks. " - Daniel Boone
|
|
|
|
|
question in the subject
|
|
|
|
|
I do not think anywhere. You can create an article about the subject you want to share with people. Probably add some references. And if it gets through, people will see it. But that's about it.
Also wrong forum.Be prepared to get schooled.
|
|
|
|
|
This guy has already been banned once for spamming - trying to promote his online courses.
|
|
|
|