On May 16, 12:34 pm, "Edward K. Ream" <edream...@gmail.com> wrote:
> From time to time, however, I have the desire to use Leo to do > something else besides develop Leo itself. Now is such a time. I > plan to revisit the leoInspect module. The idea is to develop a very > fast inference engine based on what might be called local type > induction. > > The idea is simple: we programmers mostly understand code locally. We > don't have to understand very much to determine what a program is > supposed to do. > > For example, most instances of vars called "c" in Leo are (or should > be) leoCommands objects. The induction step simply verifies that *if* > all input vars c, c1, and c2 *are* leoCommands objects, then any > assignments to other c vars (including via return statements) are > *also* leoCommands objects. > > In other words, mathematical "proofs" that type induction must be slow > may be valid in a mathematical sense, but they are not valid in an > engineering sense. The idea is to "cheat" in such a way that > inferences become very fast and easy. That's actually what we humans > do. But we need checks to verify that our "intuitions" are correct. > Those checks are lint-like. If they fail, they will indicate where > our programs (and especially their naming conventions) can be > improved. > > That's the idea. We'll see how leoInspect can be generalized to > support it. a worthy goal. though I may have only vaguely been aware of why beyond a potential speed improvement a week ago. it's practically a given that every so many months to reach for an opportunity or overcome an obstacle you learn a new language. maybe a new paradigm. maybe it's a one off domain specific language. every so often you get deeper into the culture of a more substantial language. I kept bumping into Haskell and won't say what the obstacle is but recently decided I liked enough of what's available and jumped in past the feet wet understanding. it's more a functional language than anything else, pure by default, there is type inference yet it is strongly and strict typed. there are some bizarre naming and indentation rules, maybe rules is too loose a word, could be considered strait jackets. yet you can, within limits mix various programming styles. JavaScript it ain't. there are both interpreters and compilers. darcs RCS is one notable project written in it. a Haskell motto might be that once a program runs it is more likely to be correct, at least as far as type errors are concerned. with many less internal and external tests required. little of this would apply directly to python, being part of the specification of the language & tools you pay for with up front design time vrs a more dynamic language. 2 weeks ago I couldn't spell Haskell. python does obviously have type inference, isn't it good enough? -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
