Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Notice 'parseLogLoudly'. You could not implement that using your set of functions: you are not allowing for other code besides 'resume' inside the 'handle' blocks.

Also, I don't believe the mass duplication of code necessary for your approach is acceptable, even within a library.



>Notice 'parseLogLoudly'. You could not implement that

Fair point, and that's due to my failure in not providing an optional side-effect function arg to `parse-log-skip`. And this brings up a related point, namely that the author of the lib is still responsible for crafting the API. For example, if the author of `parseLog` had not included `recover FixEntry`, would it be possible for the caller to implement it via a condition system? Would that even be a good idea? Using the pseudo-python, the only approach I can think of would be:

    def parseLogInteractively(file):
      do:
        return parseLog(file)
      handle ParseError, e:
        line = askToFixEntry(e.text)
        retry
That reference to `line` is pretty horrific.

Perhaps this is one of those cases where a simplified example helps convey the concept, but is too simple to show where other approaches would fall short.

>mass duplication of code

I'm not clear on what you mean. Multiple functions with different behaviour seems not to altogether different from one function with implicit switches that change its behaviour.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: