>>24
http://www.reddit.com/r/haskell/comments/da7w7/grempa_embedded_grammar_dsl_and_lalr_parser/c0yprcg
>Dynamic typing is only used internally, for example because the semantic action functions are put in an array indexing rule and production numbers (Ints) to functions, and they all have different types (and so can not be put in an ordinary array expecting the same type for each element). I know there are ways to do it using references into a typed environment, but from my experiments with it I felt it was too much work with little gain.
Next, translate the bit that says (pseudocode):
if(attempt_file_open)
if(attempt_file_read)
process
That's it. No fancy, complex error messages. Just check the error
returns and only proceed if I have something to proceed with. Like
grown-ups do. I *will* check my error returns. I have tormented too
many newbies to *ever* consider doing anything else. If I cannot check
my error returns I will not write the program. This is production
programming 101, and I suspect that there's a real issue with
priorities between the traditional Haskell community and production
programmers.
So the time of madness began. I could find examples which did:
if(attempt_file_open)
attempt_file_read
process
Which is useless. Other examples did:
attempt_file_open
if(attempt_file_read)
process
Which is also useless. So I'm looking through the wxHaskell examples.
They're all contrived, using very high level functions to (for
example) read a complete image structure from a named file, which as
one function had one possible source of errors. I go back to scanning
and Googling like crazy. Eventually I notice a bit in "Yet Another
Haskell Tutorial" - page 65 - which introduces "bracket", immediately
explains that it is useless for my (very common) need, and refers the
reader to Section 10 - "Advanced Techniques". The author of this
excellent document hasn't yet written Section 10. I wonder why. I
pause to examine bracket some more. I really can't tell if the
"always" clause gets called if the initialization fails. From the use
with file opening it looks like it isn't (or the handle to be closed
would be invalid) but that wouldn't help if the initializer had two
steps, e.g. called socket(2) and bind(2). This is the kind of thing
good production programmers get really het up about.
I'm still grovelling through reams of stuff, trying to find out how to
open **and** read a file in a grown up way, and I find various programs
on haskell.org. There's an implementation of cat(1)! That's the thing!
A file concatenator must be able to open *and* read it's file. Eagerly
I download it. Curiously there doesn't seem to be any error handling.
I compile it and point it at a non-existent file. The program crashes.
Horribly. So much for Cat.hs. I feel glad I hadn't been able to cope
with the video of Simon Peyton-Jones OSCON talk, because the camera
operator kept filming his face while he's gesturing at the specific
line of code he's talking about with a pointer! After seeing Cat.hs do
essence of FAIL just opening a file, claims that Haskell could serve
as a scripting language suitable for the crew of the Black Pearl in
yonder corner to use would pain me.