4 ms·

Isn't the problem here imports in general? Imagine these examples written in a literate Haskell file .lhs: 'Let us discuss graph search... > import Control.Mona

by aab0 10y ago

Isn't the problem here imports in general? Imagine these examples written in a literate Haskell file .lhs: 'Let us discuss graph search... > import Control.Monad'

akkartik 10y ago
I think lisper was raising a tangential but still valid point. Haskell imports don't suffer from the problem he was pointing out; we only see the function type in one place. It's not the fault of Haskell imports that literate programs put them first.
- dllthomas 10y ago
  But it is a fault of Literate Haskell, which doesn't provide mechanisms allowing you to put them elsewhere.
  - akkartik 10y ago
    Yeah, absolutely.
dllthomas 10y ago
Note that in Knuth's formulation of literate programming, you could freely reorder the program source. So those imports needn't be at the start of the literate program - they could be off in a parenthetical appendix.
- feklar 10y ago
  Which basically nulls one half of the beef this blog post has re canonizing typesetting over organization.
  - akkartik 10y ago
    Hey, give me some credit here. My beef wasn't that CWeb doesn't let you reorder code. I was talking about policy rather than mechanism, that the ability of CWeb wasn't being put to best use.
    - feklar 10y ago
      Can't blame me for misunderstanding when you have clearly written: >These are systems that focus on generating beautifully typeset documentation without allowing the author to arbitrarily order code. As CWEB does allow the author to arbitrarily order code. There's also this statement: >I speculate that nobody has actually read anybody else's literate programs in any sort of detail. Which suggests you yourself have never read any literate programs in detail. Thankfully this statement is provably false as the MMIX Group at MUAS exist? = true so I can merely comment that buggy line out and read the second half of your argument without it being entirely invalidated.
      - akkartik 10y ago
        > "These are systems that focus on generating beautifully typeset documentation without allowing the author to arbitrarily order code." The previous sentence was: "When I look around at the legacy of literate programming, systems to do so-called semi- or quasi-literate programming dominate." Semi- or quasi- being intended to distinguish with classic literate programming as in CWeb. I usually try to go out of my way to assume that if someone misunderstands me it's a failure of my writing, but in this case my post is filled with Knuth's original CWeb programs. It didn't seem realistic that you missed them all, or that you thought I missed that CWeb permits reordering in spite of having read so many CWeb programs. And then you make this new jab about me not having read any literate programs, in spite of me showing repeatedly in the article that I went all the way down the list at http://www-cs-faculty.stanford.edu/~uno/programs.html http://www-cs-faculty.stanford.edu/~uno/programs.html. Are you sure you read my post? --- Thanks for the pointer to http://mmix.cs.hm.edu/local http://mmix.cs.hm.edu/local. Not immediately obvious that it cares about literate programming, but I'll take your word for it. I'd appreciate intros to anybody in that group with experience reading literate programs (email address in profile).
lisper 10y ago
> Isn't the problem here imports in general? That's a very complicated question. In a complex world, you have to do something to establish the context in which a particular piece of code is being evaluated. It's a matter of taste whether that context establishment should come before or after the code for which the context is being established. Personally, I prefer the context establishment to come before, but reasonable people can disagree. This extends even to the language level, where you have some languages (like the C family, and Lisp) where variable bindings always precede their usage, and others like ML and Haskell, where the bindings can come after they are used. But what I was complaining about was specific to #includes, which use a very particular (and badly broken) mechanism to establish context, namely, textual inclusion. It was a horrible hack invented to appease a brain-damaged compiler which could only deal with one file at a time. In 1970 this was an understandable engineering trade-off. In 2016, not so much. The right way to fix it is to get rid of it and replace it with something less brain-damaged rather than layering more hacks on top of it (IMHO).

by aab0 10y ago

Isn't the problem here imports in general? Imagine these examples written in a literate Haskell file .lhs: 'Let us discuss graph search... > import Control.Monad'

akkartik 10y ago

I think lisper was raising a tangential but still valid point. Haskell imports don't suffer from the problem he was pointing out; we only see the function type in one place. It's not the fault of Haskell imports that literate programs put them first.

dllthomas 10y ago
But it is a fault of Literate Haskell, which doesn't provide mechanisms allowing you to put them elsewhere.
- akkartik 10y ago
  Yeah, absolutely.

dllthomas 10y ago

Note that in Knuth's formulation of literate programming, you could freely reorder the program source. So those imports needn't be at the start of the literate program - they could be off in a parenthetical appendix.

feklar 10y ago
Which basically nulls one half of the beef this blog post has re canonizing typesetting over organization.
- akkartik 10y ago
  Hey, give me some credit here. My beef wasn't that CWeb doesn't let you reorder code. I was talking about policy rather than mechanism, that the ability of CWeb wasn't being put to best use.
  - feklar 10y ago
    Can't blame me for misunderstanding when you have clearly written: >These are systems that focus on generating beautifully typeset documentation without allowing the author to arbitrarily order code. As CWEB does allow the author to arbitrarily order code. There's also this statement: >I speculate that nobody has actually read anybody else's literate programs in any sort of detail. Which suggests you yourself have never read any literate programs in detail. Thankfully this statement is provably false as the MMIX Group at MUAS exist? = true so I can merely comment that buggy line out and read the second half of your argument without it being entirely invalidated.
    - akkartik 10y ago
      > "These are systems that focus on generating beautifully typeset documentation without allowing the author to arbitrarily order code." The previous sentence was: "When I look around at the legacy of literate programming, systems to do so-called semi- or quasi-literate programming dominate." Semi- or quasi- being intended to distinguish with classic literate programming as in CWeb. I usually try to go out of my way to assume that if someone misunderstands me it's a failure of my writing, but in this case my post is filled with Knuth's original CWeb programs. It didn't seem realistic that you missed them all, or that you thought I missed that CWeb permits reordering in spite of having read so many CWeb programs. And then you make this new jab about me not having read any literate programs, in spite of me showing repeatedly in the article that I went all the way down the list at http://www-cs-faculty.stanford.edu/~uno/programs.html http://www-cs-faculty.stanford.edu/~uno/programs.html. Are you sure you read my post? --- Thanks for the pointer to http://mmix.cs.hm.edu/local http://mmix.cs.hm.edu/local. Not immediately obvious that it cares about literate programming, but I'll take your word for it. I'd appreciate intros to anybody in that group with experience reading literate programs (email address in profile).

lisper 10y ago

> Isn't the problem here imports in general? That's a very complicated question. In a complex world, you have to do something to establish the context in which a particular piece of code is being evaluated. It's a matter of taste whether that context establishment should come before or after the code for which the context is being established. Personally, I prefer the context establishment to come before, but reasonable people can disagree. This extends even to the language level, where you have some languages (like the C family, and Lisp) where variable bindings always precede their usage, and others like ML and Haskell, where the bindings can come after they are used. But what I was complaining about was specific to #includes, which use a very particular (and badly broken) mechanism to establish context, namely, textual inclusion. It was a horrible hack invented to appease a brain-damaged compiler which could only deal with one file at a time. In 1970 this was an understandable engineering trade-off. In 2016, not so much. The right way to fix it is to get rid of it and replace it with something less brain-damaged rather than layering more hacks on top of it (IMHO).