Indentation and optional delimiters

[castironpi at gmail.com]

On Feb 26, 7:36 am, bearophileH... at lycos.com 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.