On 5/1/2020 4:35 PM, Dexter Lagan wrote:
Is there value in Rob Pike’s comment on avoiding significant white
space in the Go language?
“We have had extensive experience tracking down build and test
failures caused by cross-language builds where a Python snippet
embedded in another language, for instance through a SWIG invocation,
is subtly and invisibly broken by a change in the indentation of the
surrounding code.” — Rob Pike, 2012
<https://talks.golang.org/2012/splash.article>
I'm not really sure what Pike is getting at there: I haven't used SWIG
myself, but if I understand it correctly, Python code would have to be
in a module to be called from "other" language code. If so, I don't see
how the indentation of the "other" code could affect the Python.
That aside:
Even working only in Python, programmers routinely get tripped up by
copy/paste errors - so it is evident that indentation sensitivity is not
any real solution to scope related logic problems. It might [for some
definition] help newbies identify stupid errors, but I believe that even
moderately experienced programmers are more hindered than helped by it.
I personally dislike white space and prefer either mustaches or
parenthesis, just so I know my code will still work if line feeds are
stripped somehow, or that some piece of code is embedded or quoted in
another language, which is what I gather Rob was talking about.
However, Haskell and Python people don’t seem to mind, and if it saves
us more keystrokes while keeping expressiveness, why not?
Well, few people use Haskell, so I would discount it as a data point.
Even so, one of the tutorials includes this interesting tidbit:
With good text editor, programming is fun. Of course, you can get
along with simplistic
editor capable of just cut-n-paste, but good editor is capable of
doing most of the chores
for you, letting you concentrate on what you are writing. With
respect to programming
in Haskell, good text editor should have as much as possible of the
following features:
• Syntax highlighting for source files
• Indentation of source files
• Interaction with Haskell interpreter (be it Hugs or GHCi)
• Computer-aided code navigation
• Code completion
The implication is that Haskell is difficult to write without proper
editor support. So too is Python. Decent syntax and structure aware
editors are not really a problem any more, but they can go only so far:
they can fail spectacularly when code gets complicated and the language
syntax provides no clues to figure out the scoping.
S-exprs do not suffer from this affliction.
Also mentioned previously is my concern that indentation sensitivity may
make implementing macros as we enjoy them in Racket difficult. Or maybe
impossible. Although certainly there are indentation languages which
have macro facilities, I am not aware of any in which the macros can be
written in the same language. All the ones I know of implement a
separate DSL macro language.
I have designed and implemented a few languages: including a Scheme-ish
mostly functional language [but lacking macros]. I have not thought
through all the nuances of implementing a language that can reflectively
manipulate the structure of a program in the midst of compiling it [or
in the case of Lisp - running it]. However, I have to think there are
reasons for existing indentation languages not having done so.
YMMV,
George
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/e92ee43b-5d6c-000d-dc04-25fe76149284%40comcast.net.
