4 ms·

Those are excellent examples. I was debating putting in a disclaimer about hard-coded numerical programs in Fortran or similar, but decided not to go into the d

Those are excellent examples. I was debating putting in a disclaimer about hard-coded numerical programs in Fortran or similar, but decided not to go into the detail I will write below, nor give you the benefit of the doubt. Compound data types, and procedure argument lists, describe the grammar of the data that your programs operate on. That this data is in the source code and the parsing from text to intermediate representation is done by the compiler only offloads the first steps of the parsing. Obviously if you deal with simple data types like vectors and matrices there will not be a lot of grammar there. If you think about typing your program and more intricately structured data into a REPL, this becomes apparent (just because your compiler accepts something as valid input, may not give many guarantees about how your program will behave - this is the crux of type theory). I am not sure how you can claim generative programming as a counter-example to needing to learn parsing theory. The entire field started out from formal language theory.

mkl 8y ago
Perhaps "generative" was the wrong word. I just mean programs that generate things. For example, I make programs that generate illustrations and animations for teaching maths, programs that generate exam questions that have suitable properties (appropriate difficulty, answers that come out nicely, etc.), and so on (pretty pictures, music, fold patterns...), and few of them need any input data beyond the code itself. I agree that the programs are doing work to assign meaning to the numbers and data structures etc. in the code and put them to use in context, though I wouldn't have called that part of the parsing myself. I think the grammar of my "input" data structures is usually pretty simple, as you suggest, and that more complicated source structures are likely to be kind of self-organised, e.g. involving dictionaries with meaningful keys or calls to class constructors. Complex data structures can then be built from the simpler source ones if needed.

mkl 8y ago

Perhaps "generative" was the wrong word. I just mean programs that generate things. For example, I make programs that generate illustrations and animations for teaching maths, programs that generate exam questions that have suitable properties (appropriate difficulty, answers that come out nicely, etc.), and so on (pretty pictures, music, fold patterns...), and few of them need any input data beyond the code itself. I agree that the programs are doing work to assign meaning to the numbers and data structures etc. in the code and put them to use in context, though I wouldn't have called that part of the parsing myself. I think the grammar of my "input" data structures is usually pretty simple, as you suggest, and that more complicated source structures are likely to be kind of self-organised, e.g. involving dictionaries with meaningful keys or calls to class constructors. Complex data structures can then be built from the simpler source ones if needed.