fjfaase

What do you mean with bad grammars? Do you mean grammars that are hard to parse (require a lot of backtracking) or do you mean that it leads people to creating bad languages?

My experience is that if a back-tracking parser list all the possible terminals it is expecting at the first location (with some additional information about the rules they occurred in) it fails to get passed, that this usually gives enough information to understand what is wrong about the input or the grammar.

I agree, that if you want to write a production grade parser, this is probably the best way to go. I also agree that parsing is not a solved problem for all cases. But that is the case with many more problems. However, for many cases it is a solved problem and that often it is not the first thing you should focus on to optimize.

If you teach a course about compiler construction, I think it might be better to teach your students how to write a grammar for some language and use some interactive parser that can parse some input according to the grammar (and visualize the AST). See for example: [1] and [2] (Even if you feed it the C grammar, it succeeds parsing thousands of lines (preprocessed) C code at every keystroke. This interpreting parser is written in JavaScript and uses a simple caching strategy for performance improvement.)

For the scripting language [3] in some of the Bizzdesigns modeling tools, a similar interactive parser was used (implemented in C++). This scripting language is also internally used for implementing the various meta-models. These scripts are parsed once, cached, and interpreted often.

I think it is also true for many domain-specific languages (DSL).

[1] https://info.itemis.com/demo/agl/editor

[2] https://fransfaase.github.io/MCH2022ParserWorkshop/IParseStu...

[3] https://help.bizzdesign.com/articles/#!horizzon-help/the-scr...

I mend to say: No, even if a grammar is not ambiguous ...

Sorry, I mend to say: Even if a grammar is not ambiguous, it can require unbound look-ahead to be parsed correctly [1].

The grammar of C is ambiguous. The statement "a * b;" can be both parsed as a variable declaration of the variable 'b' of type pointer to 'a' and as an expression consisting of a multiplication of 'a' and 'b'. It all depends on whether 'a' is a type or not. In most cases it would be a type definition, because why multiply two variables and ignore the result. One trick to deal with this is to give precedence for the type declaration grammar rule over the expression grammar rule. However, this is not something that can be done with many parser generating tools.

Yet the first C compiler where single pass compilers with a single look-ahead lexical token probably implemented as a recursive descent parser. It worked, because it kept a (reverse) list of all variable declarations, which allowed it to determine when 'a' was parsed if it was the start of some declaration or the start of a statement based on whether it was defined before as a type or not.

[1] https://stackoverflow.com/questions/12971191/grammars-that-r...

No, even if a grammar is ambigious it can require unbound look-ahead to be parsed, although this is very rare the case for meaningfull grammars such as the ones you would write for a programming language.

What I wanted to say that you do not need complex algorithms to implement parser if you do not have a grammar that can be parsed with look-ahead lexical element.

It surprises that they are still teaching parsing techniques that are based on limitation from 40 years ago, when memory was limited and you had to parse a file one character at the time. Why not start with a back-tracking recursive descent parser on a file stored in memory? Can be made efficient with some simple caching. In an introduction course there is no need to aim for maximum performance if parsing a 10k lines program takes less than a second.

I wonder how much this experience is similar to the Alien Hand Syndrome, where people experience that part of their body, usually a hand, act on their own.

Would be nice if you could block all accounts from specified regions.

I remember creating an oscilator by soldering a transistor onto an inductor with two windings in series with loudspeaker an battery.

I have one at home, which is the one we had to buy to use in highschool. In the math classrooms we had a 6 feet version that could be mounted on the blackboard such that the teacher could used for instruction. See for a picture on the Dutch page https://rekenlat.barneveld.com/rekenliniaal.htm

Makes the typical error of first giving a very high level description of what is going to be explained, which can only be understood if you already have some knowledge in the field, instead of starting with the most simple example and build from there.

No you don't because the same kind of quatum randomness is also at work in all of your cells and sometimes have far reaching effects. The reason why we do not free will, at least not as it is commonly understood, is independent of whether there is true randness randomness involved or not. It is because it our decisions are the result of (unconsious) processes over which we have no control. They just happen. The idea of 'free will' is a socialogical (and thus psychological) construct to influence behaviour. It allows you to blame yourself or others for things that just happened.

This is just an introduction to mathematics, but it already assumes some knowledge about mathematics. In the first equation it uses the superscript 2 for squaring without explaining it. It also does not explain that 'ab' stands for a and b multiplied.

It also does not address the fact that mathematics is a form of modeling. In reality there are no numbers, there are only number of things or distances. Mathematics is also the use of a language, with specific rules, to describe and reason with those models.

Because this virus is do deathly and because it not airborn, like covid, there is not much reason to fear it will become a pandemic.

Great. Are you going to open source it? If so, let me know. You find my email address on my website mentioned in my profile.

Interesting page. The latest language I designed is an stack based intermediate language for a C compiler. Not realy intended for human usage, but readable in the sense that you can compare it with the original C code.

Begriffsschift was the first formal notation for second order logic.

I am using a stack based language as an intermediate language for a C compiler I am writing. The language can be mapped to assembly and I wrote a memory safe interpreter for it. Both are not geared to performance as that is not a primary concern for the compiler and tool chain.

I used this language in a workshop on parser construction at MCH2022. The particepants where asked to construct the grammar for the language, which proved harder than I had expected for most of them.

I use HTML for my presentations and publish them online mentioning the URL at the top, such that people can open them on their device, which is often a smart phone. I take that into account for the interactive parts of the presentation.

I wonder if foreign airlines are going to demand compensation, like US airlines have done in the past when a country made one sided changes.

I am a bit surprised that the build_all_fast_glibc.sh script requires 31Gbyte of memory to run. Can somebody explain? I would like to try out Fil-C.

The link https://leetarxiv.substack.com/sinkhorn-solves-sudoku reports 'Page not found'.

If you convert a sudoku to an exact cover you can usually solve it by finding colums that are a subset from another column and remove all rows that are only in one of them.

Sudokus that can be solved with reasoning alone, can be solved in polynomial time.

I recently discovered that solving exact covers, and probably also with SAT, using a generic strategy, does not always result in the most efficient way for finding solutions. There are problems that have 10^50 solutions, yer finding a solution can take a long time.

I wonder if they also have a strategy for deleting generate tiles, otherwise the infinite is limited to the size of available memory. I also wonder if with their method can exactly recreate tiles that have been deleted. Or in other words, that they have a method for generating unique seeds for all tiles. The paper does not give much technical details. If the seed has a limited size and there is a method for generating seeds for each 2D coordinate, I wonder if it is possible to make a non-repeating infinite world. I think it is not possible with a limited size seed.

No, but I don't care. I guess that most hiring managers do not know what AoC is.

Next week, I will be 64, and I am no longer searching for a full time job. In the past decade I only worked for 24 or 30 hours per week. I am financial independent and plan to only work freelance if there is some opportunity. Currently, I am not actively searching for a job.

I have created a private leaderboard which you can join with `1563228-d419ba6d.`

The basic rule is: you are only allowed to use code you wrote yourself. That does include code you wrote before the start of the contest, for example, standard functions you wrote for earlier AoC editions.

The temptation to start a competative private leader board will be great, just for the mentioned reason. I have a reference my scores in my CV. The competative part of AoC is one of the things that I find attractive and also has taught me some valuable lessons about coding, like taking some time to review the code the first time before submitting. I experienced several times that I spend of time to debug a small bug due to a minor error, that I could have caught had I spend some time reviewing. Especially with the first puzzles, I try to get it right the fitst time with respect to compiling and execution.

I will search for a pure C private group to join that only allows a small library for things like reading the input as an array of strings.

Kaem is a very minimal shell, a program that can set environment variables and start other programs using Linux system calls.

To compile GNU Mes compiler you need a minimal C compiler. Half of the steps in stage0 consist of building that minimal C compiler through a number of steps starting with a very minimal assembler. I am working on an approach that use far less steps and is easier to review than the hunderds of files that are used now.

One can find it out with a decompiler and a lots and lots of free time. Compilers are not trivial programs, especially the ones needed to compile operating systems, with the required optimizations, and there are many ways to obfuscate code.

A better approach is to start with a small executable, one that translate hexadecimal numbers to binary, and from that build all the tools to compile a simple C compiler (such as the Tiny C Compiler, which is not very tiny), to compile the optimizing C compiler that can compile operating systems. That is the approach followed by the live-bootstrap project.