On Feb 26, 7:36 am, [EMAIL PROTECTED] wrote: > This is the best praise of semantic indentation I have read so far, by > Chris > Okasaki:http://okasaki.blogspot.com/2008/02/in-praise-of-mandatory-indentatio... > > A quotation: > > >Imagine my surprise when I started teaching this language and found the > >students picking it up faster than any language I had ever taught before. As > >fond as I am of the language, I'm certainly under no illusions that it's the > >ultimate teaching language. After carefully watching the kinds of mistakes > >the students were and were not making, I gradually realized that the > >mandatory indentation was the key to why they were doing better.< > > I have appreciated that article, and I have personally seen how fast > students learn Python basics compared to other languages, but I think > that it's way more than just indentation that makes the Python > language so quick to learn [see appendix]. > > I used to like indentation-based block delimiting years before finding > Python, and this article tells me that it may be a good thing for > other languages too, despite some disadvantages (but it's little > probable such languages will change, like the D language). Some people > have actually tried it in other > languages:http://people.csail.mit.edu/mikelin/ocaml+twt/ > So I may try to write something similar for another language too. > > One of the most common complaints about it is this written by James on > that blog: > > >I prefer explicit delimiters because otherwise the line wrapping of code by > >various email programs, web mail, mailing list digesters, newsgroup readers, > >etc., often results in code that no longer works.< > > A possible solution to this problem is "optional delimiters". What's > the path of less resistance to implement such "optional delimiters"? > Is to use comments. For example: #} or #: or something similar. > If you use such pairs of symbols in a systematic way, you have cheap > "optional delimiters", for example: > > def insort_right(a, x, lo=0, hi=None): > if hi is None: > hi = len(a) > #} > while lo < hi: > mid = (lo + hi) // 2 > if x < a[mid]: > hi = mid > #} > else: > lo = mid+1 > #} > #} > a.insert(lo, x) > #} > > It looks a bit ugly, but a script is able to take such code even > flattened: > > def insort_right(a, x, lo=0, hi=None): > if hi is None: > hi = len(a) > #} > while lo < hi: > mid = (lo + hi) // 2 > if x < a[mid]: > hi = mid > #} > else: > lo = mid+1 > #} > #} > a.insert(lo, x) > #} > > And build the original Python code (it's possible to do the opposite > too, but it requires a bit more complex script). Such #} may even > become a "standard" (a convention. Not something enforced by the > compiler. What I'd like to see the Python compiler enforce is to raise > a syntax error if a module mixes tabs and spaces) for Python, so then > it's easy to find the re-indenter script when you find flattened code > in some email/web page, etc. > > ------------------------------- > > Appendix: > I believe there can exist languages even faster than Python to learn > by novices. Python 3.0 makes Python even more tidy, but Python itself > isn't the most semantically clear language possible. I have seen that > the widespread reference semantics in Python is one of the things > newbies need more time to learn and understand. So it can be invented > a language (that may be slower than Python, but many tricks and a JIT > may help to reduce this problem) where > > a = [1, 2, 3] > b = a > Makes b a copy-on-write copy of a, that is without reference > semantics.
Why not b = copyonwrite( a )? > Other things, like base-10 floating point numbers, and the removal of > other complexity allow to create a language more newbie-friendly. And > then I think I too can see myself using such simple to use but > practically useful language for very quick scripts, where running > speed is less important, but where most possible bugs are avoided > because the language semantics is rich but very clean. Is some one > else interested in such language? > Such language may even be a bit fitter than Python for an (uncommon) > practice called "real time programming" where an artist writes code > that synthesizes sounds and music on the fly ;-) Subclass the interpreter-- make your own session. -- http://mail.python.org/mailman/listinfo/python-list