New to Python - block grouping (spaces)

[Blake McBride]

Greetings,

I am new to Python. I am sorry for beating what is probably a dead horse but I checked the net and couldn't find the answer to my question.

I like a lot of what I've seen in Python, however, after 35 years and probably a dozen languages under my belt, I very strongly disagree with the notion of using white space to delimit blocks. Not wanting to beat what I believe is probably a dead horse, I have one question.

Is there a utility that will allow me to write Python-like code that includes some block delimiter that I can see, that converts the code into runnable Python code? If so, where can I find it?

Thanks!

Blake McBride

[Paul Rubin]

Blake McBride <blak...@gmail.com> writes:
> probably a dozen languages under my belt, I very strongly disagree
> with the notion of using white space to delimit blocks.

I suggest giving it a try before deciding something like that. I don't
guarantee you'll come around, but a lot of people decide after a while
that they like it after all.

> Is there a utility that will allow me to write Python-like code that
> includes some block delimiter that I can see, that converts the code
> into runnable Python code? If so, where can I find it?

I'm not aware of one. People who don't like Python's indentation syntax
tend to choose other languages.

[Chris Angelico]

On Thu, Apr 16, 2015 at 2:07 PM, Blake McBride <blak...@gmail.com> wrote:
> I like a lot of what I've seen in Python, however, after 35 years and probably a dozen languages under my belt, I very strongly disagree with the notion of using white space to delimit blocks. Not wanting to beat what I believe is probably a dead horse, I have one question.
>
> Is there a utility that will allow me to write Python-like code that includes some block delimiter that I can see, that converts the code into runnable Python code? If so, where can I find it?
>

Python has a mechanic for handling syntax changes in a
backward-compatible way: the __future__ module. Some handy reading:

https://docs.python.org/3/library/__future__.html
https://www.python.org/dev/peps/pep-0236/
https://docs.python.org/3/reference/simple_stmts.html#future

To make use of this, put this line at the top of your program:

from __future__ import braces

Give it a try, I'll wait for you. Or paste that in at the interactive
interpreter prompt.

Done it?

Okay. Now you understand how Python's developers feel about this kind
of thing :)

What you may want to consider is a Python-like language that uses a
different syntax: Pike. It's semantically very similar to Python, but
syntactically similar to C. Learn both, and then you'll understand a
bit more of the debate. I used to be firmly on the side of braces, but
not so much now; Python's use of indentation eliminates some
redundancy (since, after all, you're probably going to be indenting
correctly anyway). Yes, it's using something syntactically that you
might think of as pure formatting (leading whitespace on a line), but
it's not fundamentally illogical or anything.

You can, of course, come up with a syntax for a "brace-blocked
Python", and precompile it into actual runnable Python code. That'd be
fairly straight-forward. But the question is, why do it? You wouldn't
be able to take much advantage of it without making a whole lot of
other changes, which would basically mean turning it into a completely
different language, and then there's not a lot of point using Python
behind the scenes. For instance, Python has declared mutable globals,
whereas bracey languages usually have declared locals, or in the case
of PHP, declared globals (mutable or read-only). Which way would you
do it? And what about semicolons? If you're going to allow blocks of
code to be defined by visible characters instead of whitespace,
wouldn't it make sense to do the same with statements? In Python, for
instance, you can't do this:

if x==1: for i in range(3): print(i)

but you can do this:

if x==1: print(1); print(2);

and they'll both be governed by the 'if'.

I strongly recommend NOT doing a half-way change like this, just
adding braces and nothing more. All you'll end up doing is wishing
that Python were like C in some other way, and then another, and then
another, and you'll find yourself hating Python. Learn Python the way
Python is meant to be, and learn a different language if you like its
semantics but not its syntax.

And I'm happy to talk to you off-list about Pike. In my opinion, it
and Python are the two best programming languages in the world.

ChrisA

[Steven D'Aprano]

Python already supports this with the optional "block delimiter" sigil. For
example, if you like braces, you can write:


def function(x):
#{
if x > 1:
#{
print "x bigger than 1"
#}
else:
#{
print "x smaller than or equal to 1"
while x <= 1: #{
x += 1 #}
#}
return x
#}

Notice that Python is clever enough to allow many brace styles, or even
allow you to invent your own style.

If you prefer Pascal style, Python supports that too:

def function(x):
# BEGIN
return x
# END

You can even localise it:

def function(x): # ANFANGEN
return x
# BEENDEN


Best of all, Python's parser includes an advanced "Do What I Mean" expert
system which can infer the intended block grouping from the indentation
alone, even when braces are missing or in the wrong position. Unlike C,
Python will do the right thing here:


if condition:
do_this()
do_that()


No more bugs from accidentally forgetting to use optional braces!



Sorry for the flippant response, but it's 2015, not 1995, and the question
about the Offside Rule is not just a dead horse but it is positively
fossilized.

https://en.wikipedia.org/wiki/Off-side_rule

I'm not aware of any pre-processor tools for Python that will syntactically
check that added braces match the indentation. Such a tool would be
unPythonic: if they match, the braces are redundant and are not needed, and
if they do not match, then the compiler (or preprocessor) should not guess
whether the indentation is right or the braces are right. But if you enforce
the rule that braces must match indentation, then the braces are redundant!

If you find such a preprocessor, or write your own, feel free to use it. But
you won't get any respect from experienced Python programmers: we use Python
in part to get away from braces, we're not chomping at the bit to put them
back in.

I'm aware that Coffeescript provides a brace-free wrapper around Javascript;
I'm not aware of any wrapper that *adds* braces to a language without them.
I suspect such a thing would be of limited use and even less popularity. But
feel free to try developing one, I could be wrong!



--
Steve

[Paul Rubin]

Steven D'Aprano <steve+comp....@pearwood.info> writes:
> I'm aware that Coffeescript provides a brace-free wrapper around Javascript;
> I'm not aware of any wrapper that *adds* braces to a language without them.

You're not old enough to remember Ratfor ;-)

[alister]

On Wed, 15 Apr 2015 21:07:45 -0700, Blake McBride wrote:

> Greetings,
>
> I am new to Python. I am sorry for beating what is probably a dead
> horse but I checked the net and couldn't find the answer to my question.
>
> I like a lot of what I've seen in Python, however, after 35 years and
> probably a dozen languages under my belt, I very strongly disagree with
> the notion of using white space to delimit blocks.

as others have suggested this is a core to python as it enforces
readability. Many new python programmes find it strange but usually take
to it quite quickly.

what I find strange is that although these programmers initially disliked
forced indentation they were voluntarily indenting there existing code
anyway. Take a look at your existing code base & see if this would indeed
be the case.

Stephens suggestion of using comments @ the start & end of your blocks
may be useful during the learning phase.





--
Battle, n.:
A method of untying with the teeth a political knot that
will not yield to the tongue.
-- Ambrose Bierce

[Antoon Pardon]

On 04/16/2015 09:46 AM, alister wrote:

> what I find strange is that although these programmers initially disliked
> forced indentation they were voluntarily indenting there existing code
> anyway. Take a look at your existing code base & see if this would indeed
> be the case.

The problem is that the logical structure one has in one's head is not always
the same as the physical structure one has to implement in. I prefer the
indentation of my program to reflect the former instead of the latter. That
is impossible in python.

This problem sometimes shows up when possible new programming structures are
discussed and the structure is discareded, not because it lacks merrit but
because it can't me made to fit into the forced indentation mold of python.

[Chris Angelico]

On Thu, Apr 16, 2015 at 6:47 PM, Antoon Pardon
<antoon...@rece.vub.ac.be> wrote:
> On 04/16/2015 09:46 AM, alister wrote:
>

>> what I find strange is that although these programmers initially disliked
>> forced indentation they were voluntarily indenting there existing code
>> anyway. Take a look at your existing code base & see if this would indeed
>> be the case.
>

> The problem is that the logical structure one has in one's head is not always
> the same as the physical structure one has to implement in. I prefer the
> indentation of my program to reflect the former instead of the latter. That
> is impossible in python.

I agree, but as it turns out, the number of times when this actually
makes a difference are diminishingly few. The most warpedly correct
indentation I've ever done was in PHP, where I used a triply-nested
structure of switch/case blocks to simulate a logical structure that
in Python would simply be a series of top-level functions - or *maybe*
a series of class definitions with methods in them. So if I were doing
the same logical structure in Python, I wouldn't mind the indentation
matching the physical structure, because it'd be sufficiently close.

ChrisA

[Antoon Pardon]

On 04/16/2015 11:34 AM, Chris Angelico wrote:
> On Thu, Apr 16, 2015 at 6:47 PM, Antoon Pardon
> <antoon...@rece.vub.ac.be> wrote:
>> On 04/16/2015 09:46 AM, alister wrote:
>>

>>> what I find strange is that although these programmers initially disliked
>>> forced indentation they were voluntarily indenting there existing code
>>> anyway. Take a look at your existing code base & see if this would indeed
>>> be the case.

>> The problem is that the logical structure one has in one's head is not always
>> the same as the physical structure one has to implement in. I prefer the
>> indentation of my program to reflect the former instead of the latter. That
>> is impossible in python.
> I agree, but as it turns out, the number of times when this actually
> makes a difference are diminishingly few.

I beg to differ. The most common occurence is a loop with a break condition
in the middle I would prefer such a loop to be written as follows:

repeat:
some
code
break_when condition:
more
code

Actually I would prefer a more elaborate scheme but would be contend with
a possibility like the above. IMO this is the most occuring pattern where
the logical structure doesn't match the physical structure and it is not
occuring relevantly less now.

[Steven D'Aprano]

On Thursday 16 April 2015 20:09, Antoon Pardon wrote:

> I beg to differ. The most common occurence is a loop with a break
> condition in the middle I would prefer such a loop to be written as
> follows:
>
> repeat:
> some
> code
> break_when condition:
> more
> code

That structure makes no sense to me. Why is the "break_when" *outside* of
the loop? Why does the "break_when condition" introduce a new block?

> Actually I would prefer a more elaborate scheme but would be contend with
> a possibility like the above. IMO this is the most occuring pattern where
> the logical structure doesn't match the physical structure and it is not
> occuring relevantly less now.

Judging by the above example, I think it may be a good thing that Python
doesn't allow "more elaborate" indentation schemes.

repeat:
do this
do that
do something else important
and this
sometimes this
also this
but don't do this
unless today is Tuesday
# end loop



Simplicity is a virtue.




--
Steve

[BartC]

On 16/04/2015 06:49, Steven D'Aprano wrote:
> On Thursday 16 April 2015 14:07, Blake McBride wrote:

>> Is there a utility that will allow me to write Python-like code that
>> includes some block delimiter that I can see, that converts the code into
>> runnable Python code? If so, where can I find it?

> No more bugs from accidentally forgetting to use optional braces!

You get bugs instead from mistakenly using the wrong indentation or
losing the correct indentation (accidentally pressing the wrong key for
example).

> If you find such a preprocessor, or write your own, feel free to use it. But
> you won't get any respect from experienced Python programmers: we use Python
> in part to get away from braces, we're not chomping at the bit to put them
> back in.
>
> I'm aware that Coffeescript provides a brace-free wrapper around Javascript;
> I'm not aware of any wrapper that *adds* braces to a language without them.
> I suspect such a thing would be of limited use and even less popularity. But
> feel free to try developing one, I could be wrong!

I used a wrapper a couple of years ago that allowed me to write in my
own Algol68-style syntax and produce Python as output. A short example
might have this as input:

proc start=
to 10 do
println "Hello World"
od
end

and produced:

import sys
import math
import copy

def start():
_tmp1=10
while _tmp1>0:
sys.stdout.write(str("Hello World"))
sys.stdout.write("\n")
_tmp1=_tmp1-1

start()

(It actually worked quite well, for small programs, and I managed to get
the same input converted to Lisp and Lua too. Also, for very simple
programs, to C, but this requires static type declarations which are
ignored for Python output.

However the main problem was that Python was too semantically different
from the way I normally used the input language, and now that language
is self-contained and does its own thing.)

This wrapper took the form of a proper parser for the input, producing
an abstract syntax tree, which was then written out in the output syntax
of choice.

Where the input is already nearly Python, then it can much simpler, but
it can't do so much checking. If there is a 1:1 correspondence between
line numbers of input and output, then it makes it easier to match any
Python errors with the original not-quite-Python source code.

I've used this approach to add Algol-68 block delimiters (and change a
few other things I found annoying) to C code.

--
Bartc

[Antoon Pardon]

On 04/16/2015 12:43 PM, Steven D'Aprano wrote:
> On Thursday 16 April 2015 20:09, Antoon Pardon wrote:
>
>> I beg to differ. The most common occurence is a loop with a break
>> condition in the middle I would prefer such a loop to be written as
>> follows:
>>
>> repeat:
>> some
>> code
>> break_when condition:
>> more
>> code
>
> That structure makes no sense to me. Why is the "break_when" *outside* of
> the loop? Why does the "break_when condition" introduce a new block?

How do you mean outside the loop? Do you consider the "else" outside the
if statement?

>> Actually I would prefer a more elaborate scheme but would be contend with
>> a possibility like the above. IMO this is the most occuring pattern where
>> the logical structure doesn't match the physical structure and it is not
>> occuring relevantly less now.
>
> Judging by the above example, I think it may be a good thing that Python
> doesn't allow "more elaborate" indentation schemes.
>
> repeat:
> do this
> do that
> do something else important
> and this
> sometimes this
> also this
> but don't do this
> unless today is Tuesday
> # end loop
>
>
>
> Simplicity is a virtue.

As is argueing against a real position instead of making something up.
Nobody is argueing for arbitrary indentation.

[Mark Lawrence]

You're not beating a dead horse, it was reduced to a skeleton years ago.
I'd either get used to the use of whitespace or find another language.

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[Antoon Pardon]

If you really want this, and don't like using comments to achieve this,
you can do the folling.

endfor = endif = enddef = endwhile = None

def poweri(a, i):
if i < 0:
i = -i
fac = 1.0 / a
else:
fac = a
endif
total = 1
while i:
if i % 2:
total *= fac
endif
fac *= fac
i /= 2
endwhile
return total
enddef

[alister]

May I suggest that you give it a try for a month, perhaps re-writing a
small program you already have in a pythonic style (don't simply write c
in python) & see if your opinion changes.


if not then other suggestions that python is not a language of choice for
you may be appropriate.

be warned you may find it creates (or increases ) an extreme dislike for
C & other languages that require braces & semicolons, it did for me
(especially the semi-colon!)



--
If in any problem you find yourself doing an immense amount of work, the
answer can be obtained by simple inspection.

[Simmo]

On 16/04/2015 05:07, Blake McBride wrote:

Interesting point of view. Likewise, I have used more than a dozen
languages and I like Python a lot. Why? Because the use of indentation
is (mostly) unambiguous and I find it a lot cleaner than having to check
whether I need braces, parentheses or whatever delimiters are correct
for a particular language. Plus I am relieved of the stylistic debates
about whether the start-of-block marker starts after the 'IF' or on a
new line and how the subsequent lines of code should be aligned.

For me, Python is clean and easy to write and, more importantly, I find
it easier to follow and understand code written by others.

Steve Simmons

[Chris Angelico]

On Thu, Apr 16, 2015 at 9:07 PM, Antoon Pardon
<antoon...@rece.vub.ac.be> wrote:
> On 04/16/2015 12:43 PM, Steven D'Aprano wrote:

>> On Thursday 16 April 2015 20:09, Antoon Pardon wrote:
>>
>>> I beg to differ. The most common occurence is a loop with a break
>>> condition in the middle I would prefer such a loop to be written as
>>> follows:
>>>
>>> repeat:
>>> some
>>> code
>>> break_when condition:
>>> more
>>> code

The case of a loop structure with its condition in the middle is one
that few languages support, so the physical structure has to be
something like:

goto middle
while not condition:
more code
label middle
some code

or

while True:
some code
if condition: break
more code

or maybe

some code
while not condition:
more code
some code

But I'm not sure how you could represent this more appropriately,
regardless of your indentation. Unindenting an "if" in the middle of a
loop doesn't instantly scream "this is the loop header". Using a goto
to jump half way into a loop is a really REALLY bad idea in most
programs (and it's illegal in lots of languages anyway). Repeating the
setup code is fine if it's a single line, but not else.

Similar to this is the capturing condition. Say you want to process
lines until you get to one that consists solely of a full stop. In C,
you can do this (kinda); in Pike, where strings are first-class
objects (like Python, unlike C), you can definitely do it,
syntactically:

while ((line=get_next_line()) != ".")
process_line(line);

Perfectly legal. Not perfectly readable. In Python, your options are a
helper generator function:

def next_line():
while True:
line = get_next_line()
if line==".": break
yield line
for line in next_line():
process_line(line)

or a loop with a critical line of code duplicated above and at the
bottom of the loop (risks 'continue' failure):

line = get_next_line()
while line!=".":
process_line(line)
line = get_next_line()

or the "mid-loop break" model, which is what makes this similar to the above:

while True:
line = get_next_line()
if line==".": break
process_line(line)

There's no nice way to spell "grab this and retain it". But again, I'm
not sure how a change of indentation could improve this.

>> That structure makes no sense to me. Why is the "break_when" *outside* of
>> the loop? Why does the "break_when condition" introduce a new block?
>

> How do you mean outside the loop? Do you consider the "else" outside the
> if statement?

The "break_when" is part of the loop structure, not the loop body.
With an entry-checked condition, the loop structure is flush left, and
the loop body is indented:

x, y = 0, 1
while x < y:
x = (x + y) / 2
y = f(x)

Some languages have a similar construct for an exit-checked condition, eg REXX:

do until x > y
/* as above */
end

or BASIC-derived languages:

do
rem as above
loop while x < y

In all three cases, the condition is on a line that's not indented. So
logically, the mid-checked loop could also go flush left:

do
some code
while condition
more code
end

Whether this actually improves readability or not is a separate
question. The "break_when" isn't so much *outside* the loop as simply
*not inside* the loop.

ChrisA

[BartC]

On 16/04/2015 14:18, alister wrote:
> On Thu, 16 Apr 2015 13:07:22 +0200, Antoon Pardon wrote:

>> Nobody is argueing for arbitrary indentation.
>
> May I suggest that you give it a try for a month, perhaps re-writing a
> small program you already have in a pythonic style (don't simply write c
> in python) & see if your opinion changes.

You mean try writing pure Python for a month? Yes, you can get used to
anything. But that doesn't take away from the issues that some people
have with its indentation. In my case, that would be the following
(apart from the extra fragility of the code which you can't argue with):

* I need some closure, some indication of where the end of a block is.
Otherwise how do I know I'm looking at the last statement, or whether
there is more on the next page or further down the screen?

Even when I can see what follows the block, I can only infer that this
is the end of the block because I eventually hit some other arbitrary
construct with less indentation, not something specifically signalling
the end of /that/ block.

(This would come up when using copy&paste for example. If I've
accidentally left out the last line of a block, I won't know about it
until the code later doesn't work.)

* I modify code a lot, adding and removing extra nested blocks all the
time. My editor can't indent or un-indent blocks without a lot of manual
typing. With block-delimited schemes, this isn't an issue, as temporary
lack of correct indentation isn't crucial.

(However, given a choice of only brace-delimited blocks, and Python
style, I'd go for the latter! I have a longer list of complaints for
C-style braces.)

--
Bartc

[Chris Angelico]

On Thu, Apr 16, 2015 at 11:18 PM, alister
<alister.n...@ntlworld.com> wrote:
> be warned you may find it creates (or increases ) an extreme dislike for
> C & other languages that require braces & semicolons, it did for me
> (especially the semi-colon!)

I'd just like to add to this that the lack of semicolon in Python
works well because, and *only* because, Python has a lot of other
rules that also are newline-sensitive. ECMAScript code sometimes runs
foul of the "oops I left off a semicolon and my program did something
weird" problem, which Python code almost never will. (Partly that's
because Python prefers to raise SyntaxError in ambiguous cases,
whereas ECMAScript tends to assign meaning to them one way or
another.) If you're writing ECMAScript code, you probably want to keep
all the semis, but in Python, they don't help you at all.

And yet they're both classed as optional. Does that seem right to you? :)

ChrisA

[Antoon Pardon]

I'm not going to argue the merrits of various indentations styles. I
just wanted to protest the notion, that because one indents one's programs
in languages that don't require indentations, one can't have a quarrel
with how python forces you to indent.

A choice was made and although I would have preferred otherwise, I can
live with it.

--
Antoon Pardon

[William Ray Wing]

> --
> https://mail.python.org/mailman/listinfo/python-list

HO Boy - Rational FORTRAN! Right up there with WatFOR (Waterloo FORTRAN for you youngsters). It was interpreted FORTRAN. Used teaching new programmers back in the day because it kept them from crashing the system.

Bill

[Antoon Pardon]

On 04/16/2015 03:18 PM, alister wrote:

>
>> As is argueing against a real position instead of making something up.
>> Nobody is argueing for arbitrary indentation.
> May I suggest that you give it a try for a month, perhaps re-writing a
> small program you already have in a pythonic style (don't simply write c
> in python) & see if your opinion changes.
>
> if not then other suggestions that python is not a language of choice for
> you may be appropriate.
>
> be warned you may find it creates (or increases ) an extreme dislike for
> C & other languages that require braces & semicolons, it did for me
> (especially the semi-colon!)

I think you are mistaking me for someone else. I have been using python
since before 2000. I went from not liking the forced indentation to not
being bothered with it to not liking it again.

I also think that one doesn't need to discard a language just because one
doesn't like this particular feature. One can think the other characteristics
of the language are positive enough one can live with this small annoyance.

--
Antoon Pardon.

[Blake McBride]

Thanks for all the responses. I especially like the Pike pointer. To be clear:

1. I don't think languages should depend on invisible elements to determine logic.

2. Having been an employer, it is difficult to force programmers to use any particular editor or style. Different editors handle tabs and spaces differently. This is all a bloody nightmare with Python.

3. Languages that use braces (or the like) can be run through a program beautifier to correct the indentation. You are just screwed in Python. So, Python may be a cute language for you to use as an individual, but it is unwieldy in a real development environment.

4. Language beautifiers used on bracey languages removes all arguments in favor of an off-side language.

Blake McBride

[Blake McBride]

As a side note, I bought a few books on Python from Amazon for use on my Kindle. At least one of the books has the formatting for the Kindle messed up rendering the meaning of the program useless.

Case in point.

Blake

[Jon Ribbens]

On 2015-04-16, Blake McBride <blak...@gmail.com> wrote:
> 2. Having been an employer, it is difficult to force programmers to
> use any particular editor or style. Different editors handle tabs
> and spaces differently. This is all a bloody nightmare with Python.
>
> 3. Languages that use braces (or the like) can be run through a
> program beautifier to correct the indentation. You are just screwed
> in Python. So, Python may be a cute language for you to use as an
> individual, but it is unwieldy in a real development environment.

Yes, you are quite right - no employers have ever used Python, nor
has anybody ever used Python in a "real development environment".
The issues you raise are novel and have not been thought about before.

[memilanuk]

While I certainly don't have your background or depth of experience...
do you really think that over the last 20 odd years that Python has
been around that #2 and #3 have not been hammered out?

Honestly, this is starting to smell more and more like a troll...

--
Shiny! Let's be bad guys.

Reach me @ memilanuk (at) gmail dot com

[Mark Lawrence]

On 16/04/2015 15:52, Blake McBride wrote:

> So, Python may be a cute language for you to use as an individual, but it is unwieldy in a real development environment.
>

Thanks for this, one of the funniest comments I've read here in years.
It's good to see that new people share the humourous side of the Python
programming culture. Long may it continue.

[Chris Angelico]

On Fri, Apr 17, 2015 at 12:52 AM, Blake McBride <blak...@gmail.com> wrote:
> 2. Having been an employer, it is difficult to force programmers to use any particular editor or style. Different editors handle tabs and spaces differently. This is all a bloody nightmare with Python.
>
> 3. Languages that use braces (or the like) can be run through a program beautifier to correct the indentation. You are just screwed in Python. So, Python may be a cute language for you to use as an individual, but it is unwieldy in a real development environment.
>

If you're prepared to run a beautifier on your employees' code, you
should have no problem requiring that they adopt a syntactically-legal
style. You're already throwing away any option of indentation not
matching the physical structure of the code, so why not simply have
the indentation define the physical structure?

ChrisA

[Grant Edwards]

On 2015-04-16, Blake McBride <blak...@gmail.com> wrote:

> Thanks for all the responses. I especially like the Pike pointer.
> To be clear:
>
> 1. I don't think languages should depend on invisible elements to
> determine logic.

I had the same attitude when I first tried Python 15 years ago. But,
Python was the only free language implimentation I could find for
Windows that had all the features to allow me to easily write a
program to suck e-mail messages out of Outlook via DCOM and shove them
over to an SMTP server.

After a few days of use, I was a firm believer in semantically
significant indentation (and have been ever since).

> 2. Having been an employer, it is difficult to force programmers to
> use any particular editor or style. Different editors handle tabs
> and spaces differently. This is all a bloody nightmare with Python.

It's an even _worse_ problem for C, PHP, Javascript, et al. At least
Python requires some semblance of order and method. Those other
languages allow complete anarchy, and any time developer A has to
read/edit code from devloper B, it wastes all sorts of time.

> 3. Languages that use braces (or the like) can be run through a
> program beautifier to correct the indentation.

With Python, there's no need. The indenation is _already_ correct.

> You are just screwed in Python. So, Python may be a cute
> language for you to use as an individual, but it is unwieldy in a
> real development environment.

Ah. That explains why Google uses it so much.

> 4. Language beautifiers used on bracey languages removes all
> arguments in favor of an off-side language.

As trolls go, I don't think this rates much above a C-.

--
Grant Edwards grant.b.edwards Yow! VICARIOUSLY experience
at some reason to LIVE!!
gmail.com

[Steven D'Aprano]

On Thu, 16 Apr 2015 08:51 pm, BartC wrote:

> On 16/04/2015 06:49, Steven D'Aprano wrote:
>> On Thursday 16 April 2015 14:07, Blake McBride wrote:
>
>>> Is there a utility that will allow me to write Python-like code that
>>> includes some block delimiter that I can see, that converts the code
>>> into
>>> runnable Python code? If so, where can I find it?
>
>> No more bugs from accidentally forgetting to use optional braces!
>
> You get bugs instead from mistakenly using the wrong indentation or
> losing the correct indentation (accidentally pressing the wrong key for
> example).

That's nothing! Python gives you absolutely no protection from accidentally
typing:


x += 1

when you actually wanted:

y -= 2


And there there was the time I edited some code written by my boss. I
intended to write a comment:

# FIXME: this function is a little slow and should be optimized.

but I hit the wrong key a couple of times and wrote:

# This is a steaming pile of guano written by a drooling
# moron who shouldn't be allowed near a computer. It needs
# to be deleted with prejudice, and the hard drive and all
# backup tapes set on fire just to be sure.


As I'm sure you will agree, it is an easy mistake to make.


I'm not impressed by arguments "braces protect you from accidentally hitting
tab too many times (or too few)". Um, okay. Don't people read their own
code? How do you not notice that you've indented it wrongly?

To my mind, the argument from "hitting tab too many times" is like tying a
double-bed mattress to your head in case an eagle flying overhead drops a
tortoise on your head.


The great thing about Off-side rule languages like Python is that the
structure of code is easy to see:


code code code code code code code
code
code code code
code code code
code code code
code
code
code
code code code
code code
code code
code code
code
code


while braces without indentation are horribly opaque:

code code code code code code code { code } code code code { code
code code { code code code } code { code { code { code code code
{ code code } code code { code code } } } } code } code



It's true that if a tool mangles your source code and deletes all your
indentation, you cannot mechanically fix the problem without understanding
the intent of the source code. But if a tool mangles your source code by
deleting words starting with "w", the same applies. Don't use broken tools.



--
Steven

[lco...@go2france.com]

On Fri, Apr 17, 2015 at 12:52 AM, Blake McBride <blak...@gmail.com> wrote:

2. Having been an employer, it is difficult to force programmers to use any particular editor or style. Different editors handle tabs and spaces differently. This is all a bloody nightmare with Python.

3. Languages that use braces (or the like) can be run through a program beautifier to correct the indentation. You are just screwed in Python. So, Python may be a cute language for you to use as an individual, but it is unwieldy in a real development environment.

If you're prepared to run a beautifier on your employees' code, you
should have no problem requiring that they adopt a syntactically-legal
style. You're already throwing away any option of indentation not
matching the physical structure of the code, so why not simply have
the indentation define the physical structure?

ChrisA

The war of the whitespaces rages on among programmers

http://www.itworld.com/article/2909268/the-war-of-the-whitespaces-rages-on-among-programmers.html?phint=newt%3Ditworld_today&phint=idg_eid%3D997c2c0be180eb9bc32d6211712db4cb#tk.ITWNLE_nlt_today_2015-04-16

[Steven D'Aprano]

On Fri, 17 Apr 2015 12:52 am, Blake McBride wrote:

> Thanks for all the responses. I especially like the Pike pointer. To be
> clear:
>
> 1. I don't think languages should depend on invisible elements to
> determine logic.

Icompletelyagreethatinvisibleelementsareterribleandalllanguagesshouldeliminatethemcompletely.Anythingelsewillharmreadabilityandmakesitmuchhardertofollowthelogic.

> 2. Having been an employer, it is difficult to force programmers to use
> any particular editor or style. Different editors handle tabs and spaces
> differently. This is all a bloody nightmare with Python.

Do you really expect us to believe for a microsecond that the choice
between "4 spaces" or "tab" is worse than the C brace wars?

If you, as an employer, cannot get your programmers to follow your in-house
style requirements, then what instructions can you get them to follow? Do
they even bother to show up? Other than on "lunch is on the boss" day?



--
Steven

[Mark Lawrence]

On 16/04/2015 14:44, BartC wrote:
>
> * I modify code a lot, adding and removing extra nested blocks all the
> time. My editor can't indent or un-indent blocks without a lot of manual
> typing. With block-delimited schemes, this isn't an issue, as temporary
> lack of correct indentation isn't crucial.
>

The year is 2015, not 1520. Get an editor that can indent and dedent
code, there's tens if not hundreds of the things, IDLE included.

[Tim Chase]

On 2015-04-17 03:10, Steven D'Aprano wrote:
> And there there was the time I edited some code written by my boss.
> I intended to write a comment:
>
> # FIXME: this function is a little slow and should be optimized.
>
> but I hit the wrong key a couple of times and wrote:
>
> # This is a steaming pile of guano written by a drooling
> # moron who shouldn't be allowed near a computer. It needs
> # to be deleted with prejudice, and the hard drive and all
> # backup tapes set on fire just to be sure.
>
> As I'm sure you will agree, it is an easy mistake to make.

Phew, glad I'm not the only one to do that. Fortunately, I had one
of those code-reformatters the OP talks about, and it fixed the
mistake for me. :-)

-tkc

[Rustom Mody]

On Thursday, April 16, 2015 at 9:37:57 AM UTC+5:30, Blake McBride wrote:
> Greetings,
>
> I am new to Python. I am sorry for beating what is probably a dead horse but
> I checked the net and couldn't find the answer to my question.

Kudos for making dead horses fly [33 posts in 13 hours and going strong]

[alister]

On Thu, 16 Apr 2015 14:44:15 +0100, BartC wrote:

> On 16/04/2015 14:18, alister wrote:
>> On Thu, 16 Apr 2015 13:07:22 +0200, Antoon Pardon wrote:
>
>>> Nobody is argueing for arbitrary indentation.
>>
>> May I suggest that you give it a try for a month, perhaps re-writing a
>> small program you already have in a pythonic style (don't simply write
>> c in python) & see if your opinion changes.
>
> You mean try writing pure Python for a month? Yes, you can get used to
> anything. But that doesn't take away from the issues that some people
> have with its indentation. In my case, that would be the following
> (apart from the extra fragility of the code which you can't argue with):

code fragility? google "goto fail", this could not have happened with
python.
he try it suggestion was not to get you get used to it but to give you
enough experience to show that your perceived problems are actually no
existent FUD

>
> * I need some closure, some indication of where the end of a block is.
> Otherwise how do I know I'm looking at the last statement, or whether
> there is more on the next page or further down the screen?

oh please if you are not going to look at the code you cant tell in a
brace delimited language either & if you do open your eyes to scan the
code it is easier to see in python because the indentation is 100%
trustworthy where as with C you have to be careful that a brace has not
been inserted somewhere unexpected.

>
> Even when I can see what follows the block, I can only infer that this
> is the end of the block because I eventually hit some other arbitrary
> construct with less indentation, not something specifically signalling
> the end of /that/ block.

it is not arbitrary the un-indent is the signal

>
> (This would come up when using copy&paste for example. If I've
> accidentally left out the last line of a block, I won't know about it
> until the code later doesn't work.)


> * I modify code a lot, adding and removing extra nested blocks all the
> time. My editor can't indent or un-indent blocks without a lot of manual
> typing.

get a decent editor designed fro programming

> With block-delimited schemes, this isn't an issue, as temporary
> lack of correct indentation isn't crucial.
>
> (However, given a choice of only brace-delimited blocks, and Python
> style, I'd go for the latter! I have a longer list of complaints for
> C-style braces.)

so you are already 90% of the way there & just need to grasp the fact
that the braces are redundant if you (sensibly) stick to a rigid
formatting style


--
Kiss your keyboard goodbye!

[alister]

This suggestion was aimed at the Original poster.



--
Your mode of life will be changed for the better because of new
developments.

[alister]

A poor quality book
You can write bad books for any language

I do sympathise as this is something you cannot easily tell before
purchase (although there as so many good guides available on line I don't
think there is much benefit in buying a book)


--
Talking much about oneself can also be a means to conceal oneself.
-- Friedrich Nietzsche

[memilanuk]

On 04/16/2015 11:08 AM, alister wrote:
> On Thu, 16 Apr 2015 08:01:45 -0700, Blake McBride wrote:
>
>> As a side note, I bought a few books on Python from Amazon for use on my
>> Kindle. At least one of the books has the formatting for the Kindle
>> messed up rendering the meaning of the program useless.
>>
>> Case in point.
>>
>> Blake
>
> A poor quality book
> You can write bad books for any language
>
> I do sympathise as this is something you cannot easily tell before
> purchase (although there as so many good guides available on line I don't
> think there is much benefit in buying a book)

Some publishers are worse about this than others. Packt
(www.packtpub.com) has some decent material, but absolutely incompetent
when it comes to formatting python code in a Kindle .mobi file. I don't
think I've ever seen *any* errata published for any of their books. I
long since decided that anything I see from Packt that I want to read...
I might find it on Amazon, but I go to Packt's site and purchase the
PDF. They have a harder time screwing that up, apparently.

O'Reilly, on the other hand, gets it right. Period.

[Rob Gaddi]

Catapult and a dream, man. Catapult and a dream.



--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

[Serhiy Storchaka]

On 16.04.15 08:49, Steven D'Aprano wrote:
> I'm not aware of any pre-processor tools for Python that will syntactically
> check that added braces match the indentation. Such a tool would be
> unPythonic: if they match, the braces are redundant and are not needed, and
> if they do not match, then the compiler (or preprocessor) should not guess
> whether the indentation is right or the braces are right. But if you enforce
> the rule that braces must match indentation, then the braces are redundant!
>
> If you find such a preprocessor, or write your own, feel free to use it. But
> you won't get any respect from experienced Python programmers: we use Python
> in part to get away from braces, we're not chomping at the bit to put them
> back in.

https://hg.python.org/cpython/raw-file/default/Tools/scripts/pindent.py

[Ben Finney]

Chris Angelico <ros...@gmail.com> writes:

> If you're prepared to run a beautifier on your employees' code, you
> should have no problem requiring that they adopt a syntactically-legal
> style.

For teams with a mixture of text editors in use, there are even tools
nowadays to help everyone's text editor enforce consistency of the
fundamentals in the code.

One which is ready now and already widely adopted is EditorConfig:

EditorConfig helps developers define and maintain consistent coding
styles between different editors and IDEs. The EditorConfig project
consists of a file format for defining coding styles and a
collection of text editor plugins that enable editors to read the
file format and adhere to defined styles. EditorConfig files are
easily readable and they work nicely with version control systems.

<URL:http://editorconfig.org/>

--
\ “I was in Las Vegas, at the roulette table, having a furious |
`\ argument over what I considered to be an odd number.” —Steven |
_o__) Wright |
Ben Finney

[BartC]

On 16/04/2015 18:10, Steven D'Aprano wrote:
> On Thu, 16 Apr 2015 08:51 pm, BartC wrote:
>
>> On 16/04/2015 06:49, Steven D'Aprano wrote:
>>> On Thursday 16 April 2015 14:07, Blake McBride wrote:
>>
>>>> Is there a utility that will allow me to write Python-like code that
>>>> includes some block delimiter that I can see, that converts the code
>>>> into
>>>> runnable Python code? If so, where can I find it?
>>
>>> No more bugs from accidentally forgetting to use optional braces!
>>
>> You get bugs instead from mistakenly using the wrong indentation or
>> losing the correct indentation (accidentally pressing the wrong key for
>> example).
>
> That's nothing! Python gives you absolutely no protection from accidentally
> typing:
>
>
> x += 1
>
> when you actually wanted:
>
> y -= 2

>

> As I'm sure you will agree, it is an easy mistake to make.

I meant hitting Backspace or Delete.

But also, sometimes you post code to Usenet and you find leading tabs
have been stripped out. With Python code, that's problematical.

> I'm not impressed by arguments "braces protect you from accidentally hitting
> tab too many times (or too few)". Um, okay. Don't people read their own
> code? How do you not notice that you've indented it wrongly?

Take:

if cond:
stmt1
stmt2
stmt3

and:

if cond:
stmt1
stmt2
stmt3

which one is correct? Is there a tab too many, or one too few? Or two
too many? Now, much as I dislike C-style braces, at least it is a little
more resilient:

if (cond) {
stmt1;
stmt2;
stmt3;
}

or:

if (cond) {
stmt1;
stmt2;
}
stmt3;

One 'if' clearly has three statements, and the other has two, and you
are confident enough to fix the tabbing errors without consequences.

> while braces without indentation are horribly opaque:
>
> code code code code code code code { code } code code code { code
> code code { code code code } code { code { code { code code code
> { code code } code code { code code } } } } code } code

It seems to work well enough with expressions:

x = (a * (b+c) * d) / e

--
Bartc

[Ron Adam]

On 04/16/2015 01:41 PM, Steven D'Aprano wrote:
>> >2. Having been an employer, it is difficult to force programmers to use
>> >any particular editor or style. Different editors handle tabs and spaces
>> >differently. This is all a bloody nightmare with Python.
>
> Do you really expect us to believe for a microsecond that the choice
> between "4 spaces" or "tab" is worse than the C brace wars?

You know I've never thought braces where the problem in a language, and in
python, not having them isn't a problem either.

The reason I dislike C is due to the amount of boiler plate and the low
level of code, which requires managing memory, declaring prototypes and
including headers. All of which I think are much more troublesome and
harder to get right than any amount of braces.

Both sides have advantages, but Python's design is meant to represent code
in an easier to see and read way. Representing blocks by indention is
consistent with that. (And so is outlines in written language.)

I could equally like a language where blocks are literal code objects that
can be assigned to names. In that case the block delimiters would be
consistent with that language design and that would be perfectly fine to
me. The code would be representing what it does in an expected and useful way.

block = {statement_1; statement_2; ...}

The cases in between seem a bit unclean to me however. Where braces are
used to define blocks that aren't exposed. I think it's ok, but it also
seems a bit unclean to me. Adding more noise than necessary to the code.
But I understand at some time, when a language was designed it may have
been that it made parsing the language simpler. (it does.) Or it may have
just been the language designers preference at that time. <shrug>

But still, I think the whole braces are good/evil is over stated. There
are lots of more important things in languages to consider.

Cheers,
Ron

[Antoon Pardon]

Op 16-04-15 om 19:10 schreef Steven D'Aprano:

> On Thu, 16 Apr 2015 08:51 pm, BartC wrote:
>
>> On 16/04/2015 06:49, Steven D'Aprano wrote:
>>> On Thursday 16 April 2015 14:07, Blake McBride wrote:
>>>> Is there a utility that will allow me to write Python-like code that
>>>> includes some block delimiter that I can see, that converts the code
>>>> into
>>>> runnable Python code? If so, where can I find it?
>>> No more bugs from accidentally forgetting to use optional braces!
>> You get bugs instead from mistakenly using the wrong indentation or
>> losing the correct indentation (accidentally pressing the wrong key for
>> example).
> That's nothing! Python gives you absolutely no protection from accidentally
> typing:
>
>
> x += 1
>
> when you actually wanted:
>
> y -= 2

I find this a bit disingenuous. Each time assignment as an expression comes
up, so that it would be possible to have an assignment in a if or while
condition, few of the regulars seem to have a problem with the argument that
the current choice protects against a particular kind of bug.

The fact that braces protect against a kind of bug you care less about,
is just your preference. That doesn't mean a different preference is
somehow worthy of ridicule.

Mistakes of all kinds happen and I see no reason to ridicule someone for
wishing protect against one kind of mistake, while yourself having the
protection you like.

--
Antoon Pardon

[Michael Torrie]

While it appears that you had already made up your mind about the matter
long before posting, and perhaps was just looking for vindication, I
feel that some of the snide replies you got were just not tremendously
professional. However, it may be that people recognized that you likely
had made up your mind already, and posted accordingly.

[Grant Edwards]

On 2015-04-17, Michael Torrie <tor...@gmail.com> wrote:
> On 04/16/2015 08:52 AM, Blake McBride wrote:
>> Thanks for all the responses. I especially like the Pike pointer.
>> To be clear:
>

[troll bait elided]

> While it appears that you had already made up your mind about the
> matter long before posting, and perhaps was just looking for
> vindication, I feel that some of the snide replies you got were just
> not tremendously professional.

There are people who post to Usenet professionally? And I've been
doing it all these years _for_free_? And, it's not like there's some
sort of Olympics for which I needed to maintain my amateur standing.

> However, it may be that people recognized that you likely had made up
> your mind already, and posted accordingly.

I think most of us just assumed he was just trolling and were playing
along for the fun of it.

--
Grant Edwards grant.b.edwards Yow! As President I have
at to go vacuum my coin
gmail.com collection!

[BartC]

On 17/04/2015 17:28, Grant Edwards wrote:
> On 2015-04-17, Michael Torrie <tor...@gmail.com> wrote:

>> However, it may be that people recognized that you likely had made up
>> your mind already, and posted accordingly.
>
> I think most of us just assumed he was just trolling and were playing
> along for the fun of it.

What was troll-like about it? The OP made it clear he didn't like the
way Python made use of tabs, but he didn't want an argument about it or
to be persuaded to change his mind or change anyone else's.

He wanted to know if there was a simple syntax wrapper for it. That
seems reasonable enough.

(Actually *I* would quite like to know why languages don't have
switchable syntax anyway to allow for people's personal preferences.)

--
Bartc

[Rustom Mody]

On Friday, April 17, 2015 at 10:36:13 PM UTC+5:30, BartC wrote:
> (Actually *I* would quite like to know why languages don't have
> switchable syntax anyway to allow for people's personal preferences.)

Mess in programming syntax is because of html:
http://blog.languager.org/2012/10/html-is-why-mess-in-programming-syntax.html

[sohca...@gmail.com]

Allowing a switchable syntax only makes the fight even worse. If you made braces in Python an option to use instead of whitespace block delimiting, then there'd be a ton of infighting among Python developers over which to use. Just look at C/C++ developers fighting over where the opening brace goes.

By having the language itself forcing a specific style, it requires everyone using it to either shut up and get over it, or just don't use the language.

Personally, I like the Python style. It forces people to write code that is at least somewhat good to look at. Not like monstrosities like this that I see from newbie (hell, even professional) C/C++ programmers:

if (something > something_else)
{
result = do_something();
if (!result){
printf("Error!\n")
return 0;
}
do_other_stuff();
}

Can someone still write ugly code in Python? No doubt about it. But at least code blocks will be easily deciphered.

[Marko Rauhamaa]

sohca...@gmail.com:

> Can someone still write ugly code in Python? No doubt about it. But at
> least code blocks will be easily deciphered.

That's how I was originally convinced about Python: a coworker with a
terrible C++ "handwriting" produced neat, legible code in Python.

I'm still slightly annoyed by some downsides in the indentation style,
but the practical benefits more than compensate. Also, the semicolon
rules of JavaScript and Go are horrible compared with the simple line
continuation rules of Python.


Marko

[Chris Angelico]

On Sat, Apr 18, 2015 at 3:05 AM, BartC <b...@freeuk.com> wrote:
> (Actually *I* would quite like to know why languages don't have switchable
> syntax anyway to allow for people's personal preferences.)

Why do it? What's the advantage of calling two different syntaxes one
language? Simpler to just call them two separate languages - maybe two
languages that share some sort of runtime, but two languages. For
instance, Java bytecode doesn't have to be created from Java source
code, but we don't consider NetRexx to be a "switchable syntax" for
Java. It's a completely separate language that compiles to a .class
file.

ChrisA

[Dan Sommers]

On Fri, 17 Apr 2015 18:05:52 +0100, BartC wrote:

> (Actually *I* would quite like to know why languages don't have
> switchable syntax anyway to allow for people's personal preferences.)

You want LISP, the programmable programming language.

[Michael Torrie]

On 04/17/2015 11:05 AM, BartC wrote:
> He wanted to know if there was a simple syntax wrapper for it. That
> seems reasonable enough.
>
> (Actually *I* would quite like to know why languages don't have
> switchable syntax anyway to allow for people's personal preferences.)

There was a version of Python (compatible at a bytecode level) that did
implement braces for blocks. It was called pythonb, but it is now
defunct, understandably for lack of interest. It was just a
modification to the parser is all. So it's completely doable. In fact
one could probably do it with a preprocessor of some kind. But there's
little utility in it.

[Rustom Mody]

You got it!!
One of the deep paradoxes in 'getting' programming is that you cant do
programming without some syntax; and yet syntax is irrelevant.

I dont believe one can ever get that without some experience of Lisp --
Minsky's Turing award lecture is an elaboration of this:
http://web.media.mit.edu/~minsky/papers/TuringLecture/TuringLecture.html

[Ben Finney]

BartC <b...@freeuk.com> writes:

> (Actually *I* would quite like to know why languages don't have
> switchable syntax anyway to allow for people's personal preferences.)

Which people's personal preferences? Are these the same people who have
such passionate disagreement about tabs versus spaces?

If you only write programs that will only ever be read by you and no-one
else, feel free to maintain a fork of Python (or any other language)
that suits your personal preferences.

Too much effort? Or maybe you sometimes want others, whose preferences
may not exactly match yours, to collaborate on programs you write? Then
I think you have your answer of why such personal perferences are not
switchable in the languages we actually use.

--
\ “It is the integrity of each individual human that is in final |
`\ examination. On personal integrity hangs humanity's fate.” |
_o__) —Richard Buckminster Fuller, _Critical Path_, 1981 |
Ben Finney

[Larry Hudson]

On 04/17/2015 07:22 PM, Ben Finney wrote:
> BartC <b...@freeuk.com> writes:
>
>> (Actually *I* would quite like to know why languages don't have
>> switchable syntax anyway to allow for people's personal preferences.)
>
> Which people's personal preferences? Are these the same people who have
> such passionate disagreement about tabs versus spaces?
>
> If you only write programs that will only ever be read by you and no-one
> else, feel free to maintain a fork of Python (or any other language)
> that suits your personal preferences.
>
> Too much effort? Or maybe you sometimes want others, whose preferences
> may not exactly match yours, to collaborate on programs you write? Then
> I think you have your answer of why such personal perferences are not
> switchable in the languages we actually use.
>

I always find discussions like these rather amusing.

From a practical standpoint, no matter now passionately someone feels about this sort of thing,
it is ultimately totally irrelevant. The language (whatever language or subject it is) is
already defined. You either use it as it exists or go on to something else. EOD!
(End-of-discussion).

The exception, of course, is if you are actively involved in the defining and creating something
new. But otherwise, take it or leave it.

Naturally you are permitted to have your own opinions, whether passionate or otherwise, but it's
not worth arguing about.

-=- Larry -=-

[Marko Rauhamaa]

Michael Torrie <tor...@gmail.com>:

> There was a version of Python (compatible at a bytecode level) that did
> implement braces for blocks. It was called pythonb, but it is now
> defunct, understandably for lack of interest.

<URL: http://www.perl.com/pub/2001/04/01/parrot.htm>

LW: Sure. I'd probably write the program something like this:

while(@line = Sys::Stdin->readline()):
continue_next if $line[0] =eq= "#":
print @line;
}


Marko

[Marko Rauhamaa]

Ben Finney <ben+p...@benfinney.id.au>:

> If you only write programs that will only ever be read by you and
> no-one else, feel free to maintain a fork of Python (or any other
> language) that suits your personal preferences.

It would be possible to define a canonical AST storage format. Then,
your editor could "incarnate" the AST in the syntax of your choosing.

A Python source file is an AST storage format, only it's not canonical.
IOW, more than one Python source file can produce identical AST's. That
isn't a problem for the specialized editors but it can be a problem for
text editors, source code control etc.


Marko

[Rustom Mody]

On Saturday, April 18, 2015 at 12:30:49 PM UTC+5:30, Marko Rauhamaa wrote:
> Ben Finney :

Things like comments are a headache -- they have to be shoved into the AST rather
artificially

[Marko Rauhamaa]

Rustom Mody <rusto...@gmail.com>:

>> It would be possible to define a canonical AST storage format. Then,
>> your editor could "incarnate" the AST in the syntax of your choosing.
>>

>> [...]

>
> Things like comments are a headache -- they have to be shoved into the
> AST rather artificially

I don't think comments would be so bad assuming you don't write comments
like this:

result = principal * (1 + interest_rate / 100)
# expressed as percentage ^^^^^^^^^^^^^

I know, I know -- that's a lot to assume.


Marko

[BartC]

On 18/04/2015 03:22, Ben Finney wrote:
> BartC <b...@freeuk.com> writes:
>
>> (Actually *I* would quite like to know why languages don't have
>> switchable syntax anyway to allow for people's personal preferences.)
>
> Which people's personal preferences? Are these the same people who have
> such passionate disagreement about tabs versus spaces?
>
> If you only write programs that will only ever be read by you and no-one
> else, feel free to maintain a fork of Python (or any other language)
> that suits your personal preferences.
>
> Too much effort? Or maybe you sometimes want others, whose preferences
> may not exactly match yours, to collaborate on programs you write? Then
> I think you have your answer of why such personal perferences are not
> switchable in the languages we actually use.

Perhaps you don't understand what I'm getting at.

Suppose there were just two syntaxes: C-like and Python-like (we'll put
aside for a minute the question of what format is used to store Python
source code).

Why shouldn't A configure his editor to display a Python program in
C-like syntax, and B configure their editor to use Python-like tabbed
syntax?

A can write code in the preferred syntax, and B can view/modify exactly
the same code in /their/ preferred syntax. What would be the problem?
(The actual stored representation of the program would be in one of
those two styles, or something else entirely; Lisp-like syntax for
example. It doesn't matter because no-one would care.

(I think much of the problem that most languages are intimately
associated with their specific syntax, so that people can't see past it
to what the code is actually saying. a=b, a:=b, b=>a, (setf a b),
whatever the syntax is, who cares? We just want to do an assignment!)

--
Bartc

[BartC]

On 18/04/2015 03:22, Rustom Mody wrote:
> On Saturday, April 18, 2015 at 6:49:30 AM UTC+5:30, Dan Sommers wrote:
>> On Fri, 17 Apr 2015 18:05:52 +0100, BartC wrote:
>>
>>> (Actually *I* would quite like to know why languages don't have
>>> switchable syntax anyway to allow for people's personal preferences.)
>>
>> You want LISP, the programmable programming language.

I don't really want Lisp (not even with a shiny new syntax).

> You got it!!
> One of the deep paradoxes in 'getting' programming is that you cant do
> programming without some syntax; and yet syntax is irrelevant.

Yes, exactly!

When I sometimes want to code in Python, why can't I used my usual syntax?

The tabbing isn't so much of a big deal, but, for example, I normally
use ":=" and "=" for Python's "=" and "==" operators, and it can be a
nuisance when switching between syntaxes. (At least Python picks up the
use of "=" inside an expression, unlike C...)

--
Bartc

[Ben Finney]

BartC <b...@freeuk.com> writes:

> Why shouldn't A configure his editor to display a Python program in
> C-like syntax, and B configure their editor to use Python-like tabbed
> syntax?

I don't recall anyone saying that *shouldn't* be done. Feel free to
make, and maintain and support and propagate and keep pace with changes
in everything Python interacts with, a full Python stack that supports
such flexibility.

> A can write code in the preferred syntax, and B can view/modify
> exactly the same code in /their/ preferred syntax. What would be the
> problem?

I can only invite you to embark on the project of a Python compiler
which accepts such a switchable syntax, maintain it consistently over
the lifetime of a project with significant numbers of people
collaborating using different switch settings for that syntax, and
working on the same code with different editor settings.

Once you've done that, report back to us about the problems encountered.

> (The actual stored representation of the program would be in one of
> those two styles, or something else entirely; Lisp-like syntax for
> example. It doesn't matter because no-one would care.

No-one except the people who have to maintain and debug and continue
developing a Python that supports multiple radically-different syntaxes.
I suspect the efforts of those people is being discounted in your vision.

--
\ “To have the choice between proprietary software packages, is |
`\ being able to choose your master. Freedom means not having a |
_o__) master.” —Richard M. Stallman, 2007-05-16 |
Ben Finney

[Dave Angel]

On 04/19/2015 07:38 AM, BartC wrote:
....

> Perhaps you don't understand what I'm getting at.
>
> Suppose there were just two syntaxes: C-like and Python-like (we'll put
> aside for a minute the question of what format is used to store Python
> source code).
>
> Why shouldn't A configure his editor to display a Python program in
> C-like syntax, and B configure their editor to use Python-like tabbed
> syntax?
>
> A can write code in the preferred syntax, and B can view/modify exactly
> the same code in /their/ preferred syntax. What would be the problem?
> (The actual stored representation of the program would be in one of
> those two styles, or something else entirely; Lisp-like syntax for
> example. It doesn't matter because no-one would care.
>
> (I think much of the problem that most languages are intimately
> associated with their specific syntax, so that people can't see past it
> to what the code is actually saying. a=b, a:=b, b=>a, (setf a b),
> whatever the syntax is, who cares? We just want to do an assignment!)
>

If you make enough simplifying assumptions, of course it's easy and natural.

Assume that a text editor is the only way you'll be viewing the source
code. You and your coworkers are willing to each use a prescribed text
editor, rather than your previous favorite one that doesn't happen to
support the customization you're suggesting here. You're not going to
use a version control system, nor diff programs. You're not going to
post your code in messages on the internet.

You're not going to display error messages showing source code, from a
running system. You're not going to use the interactive debugger.

You're not going to copy code from one place to another without copying
sufficient context to be able to reconstruct the funny syntax.

You're going to permit only one such variation, and it's just big enough
that it's always obvious which version of the code is being examined (by
programs or by humans) [1]

You're not going to use eval() [good]. You're not going to examine
source code that comes from 3rd party or the standard library.

The changes you want are all completely reversible, regardless of
interspersed comments, and when reversed, preserve spacing and
characters completely in the way that each user expects to see the code.
And they are reversible even if you only have a small fragment of the
code.

I implemented something analogous to such a system 40 years ago. But on
that system, nearly all of the restrictions above applied. There was no
clipboard, no version control, no internet. Programs had to fit in 64k.
Each line stood completely on its own, so context was not a problem. i
wrote the text editor, much of the interactive debugger, the listing
utility, the pretty printer, the cross reference program, etc. So they
were consistent. Further, we had a captive audience -- if they didn't
like it, they could buy the competitor's product, which had similar
constraints. Would I do things differently now? You bet I would. At
least if I could upgrade the memory addressability to a few megs.


For the purposes you've described so far, I'd suggest just writing two
translators, one a mirror image of the other. Invoke them automatically
on load and save in your personal editor And learn to live with both
syntaxes, because it will leak. And if it's really not reversible,
don't use them when you're editing somebody else's code. And even if it
is reversible, don't use them when you edit code you plan to post on the
internet.

[1] So for example a=b can not mean assignment in one version, and a
comparison in the other. Because then you'd need to either discover
that it's a line by itself, or within an if expression, or ... But you
could arrange two disjoint sets of symbols readily enough. In your
version, require either := or ==, and make = just plain illegal.

PS. I haven't examined the costs in tool development to support this.
Just whether it's practical. You can easily discount any one of these
constraints, but taken as a whole, they very much limit what you can do.

--
DaveA

[Steven D'Aprano]

On Sun, 19 Apr 2015 09:38 pm, BartC wrote:

> Suppose there were just two syntaxes: C-like and Python-like (we'll put
> aside for a minute the question of what format is used to store Python
> source code).
>
> Why shouldn't A configure his editor to display a Python program in
> C-like syntax, and B configure their editor to use Python-like tabbed
> syntax?
>
> A can write code in the preferred syntax, and B can view/modify exactly

> the same code in their preferred syntax. What would be the problem?

> (The actual stored representation of the program would be in one of
> those two styles, or something else entirely; Lisp-like syntax for
> example. It doesn't matter because no-one would care.

The only people who would not care are those alone in a bubble who never
share or discuss code with anyone else. Everyone else will care a great
deal.

How could A and B talk about the code to each other? A says "line 56 is
buggy, you need to replace foo{^bar} with foo@bar" and B replies "what are
you talking about? line 56 says foo.bar and foo@bar is a syntax error".




--
Steven

[Steven D'Aprano]

On Sun, 19 Apr 2015 09:44 pm, BartC wrote:

> When I sometimes want to code in Python, why can't I used my usual syntax?

When I go to China, why doesn't everyone speak English for my convenience?

I'll tell you what. When you convince the makers of C compilers to support
Python syntax as an alternative, then I'll help with making Python
compilers support C syntax.


--
Steven

[Mark Lawrence]

On 19/04/2015 13:59, Ben Finney wrote:
> BartC <b...@freeuk.com> writes:
>
>> Why shouldn't A configure his editor to display a Python program in
>> C-like syntax, and B configure their editor to use Python-like tabbed
>> syntax?
>

> I don't recall anyone saying that *shouldn't* be done. Feel free to
> make, and maintain and support and propagate and keep pace with changes
> in everything Python interacts with, a full Python stack that supports
> such flexibility.
>

Presumably we just add BartCPython to the list containing those like
Python 2.8 and RickedPython.

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[Rustom Mody]

On Sunday, April 19, 2015 at 5:15:07 PM UTC+5:30, BartC wrote:
> On 18/04/2015 03:22, Rustom Mody wrote:
> > On Saturday, April 18, 2015 at 6:49:30 AM UTC+5:30, Dan Sommers wrote:
> >> On Fri, 17 Apr 2015 18:05:52 +0100, BartC wrote:
> >>
> >>> (Actually *I* would quite like to know why languages don't have
> >>> switchable syntax anyway to allow for people's personal preferences.)
> >>
> >> You want LISP, the programmable programming language.
>
> I don't really want Lisp (not even with a shiny new syntax).

You do... See below

>
> > You got it!!
> > One of the deep paradoxes in 'getting' programming is that you cant do
> > programming without some syntax; and yet syntax is irrelevant.
>
> Yes, exactly!
>
> When I sometimes want to code in Python, why can't I used my usual syntax?
>
> The tabbing isn't so much of a big deal, but, for example, I normally
> use ":=" and "=" for Python's "=" and "==" operators, and it can be a
> nuisance when switching between syntaxes. (At least Python picks up the
> use of "=" inside an expression, unlike C...)

See McCarthy's interview
http://www.infoq.com/interviews/Steele-Interviews-John-McCarthy
This is after a life of Lisp and AI -- he died a couple of years after the interview.
And in there he repeatedly asks for 'abstract syntax' languages -- as I see it
the same as you are asking

Of course one needs to distinguish Lisp-technology from Lisp-philosophy.
I believe you and McCarthy are asking for Lisp philosophy as I am also:
http://blog.languager.org/2012/10/html-is-why-mess-in-programming-syntax.html

JFTR: The specific connection with html is somewhat facetious
That programmers are stuck in text files 50 years after everyone else has moved
on is more serious

[wxjm...@gmail.com]

Le dimanche 19 avril 2015 15:24:10 UTC+2, Steven D'Aprano a écrit :
>
> When I go to China, why doesn't everyone speak English for my convenience?
>

Why not?
This is exactly what Python did with unicode/ascii.

jmf

[Chris Angelico]

On Sun, Apr 19, 2015 at 9:38 PM, BartC <b...@freeuk.com> wrote:
> Suppose there were just two syntaxes: C-like and Python-like (we'll put
> aside for a minute the question of what format is used to store Python
> source code).
>
> Why shouldn't A configure his editor to display a Python program in C-like
> syntax, and B configure their editor to use Python-like tabbed syntax?

You still haven't addressed the question of the extent of "C-like
syntax" for Python. It's not simply a matter of block delimiters. With
git (and I believe similarly with hg, but I'm not sure about smaller
and/or proprietary source control systems), you can define a pair of
filters which transform a file between the actual source control
system and your checked-out version, so (for instance) you could have
source control work with four-space indents where you work with tab
indents. That one's dead easy. With a little more work, you could
probably rig something up to use keywords or symbols to delimit blocks
of code; braces would be harder, because Python uses them for dicts
and sets, so you'd need some sort of context-aware parsing.

But the biggest problem is that you wouldn't actually be changing
anything else. You'd end up with a bizarre hybrid that uses a tiny bit
of C-like syntax, but entirely Python-like syntax everywhere else. For
example, Python doesn't allow this:

if condition: for i in range(3): do_stuff()

So you'd never truly be able to take advantage of the braces. In fact,
all you'd _really_ have would be a way to key in some braces, commit
to source control, check out again, and have your indentation
auto-fixed for you... and if that's all you want, I think there are
editors which make the reindenting of code a ton easier than that!

As Dave suggests, make yourself a parser which turns *any* legal[1]
Python code into your preferred "C-like" syntax, and another which
performs a perfect reverse transformation. I suspect you'll find the
task fundamentally hard.

ChrisA

[1] Coping with broken Python code is going to be important later on,
but ignore it for now. It's a ton harder to ensure that you can do a
reversible syntactic change on something with syntax errors!

[Rustom Mody]

On Sunday, April 19, 2015 at 8:45:27 PM UTC+5:30, Chris Angelico wrote:

<Description of the task of first-classing syntax snipped>

> I suspect you'll find the task fundamentally hard.

How hard?
Lets see.
Two guys wanted to write an OS.
Seeing current languages not upto their standard they first made themselves a
suitable language.
Would you call their project hard ridiculous and misguided?

Well evidently some people did but fortunately their managers did not interfere.

OTOH some others liked the ideas/outlook enough that they jumped on the bandwagon and in short order there were
- a heavy duty compilation system -- parser generators to librarians etc
- editor(s)
- source code systems
- text tools (grep sed)
- shell

In short a 'Programmer's Work Bench'
http://www.ics.uci.edu/~andre/ics228s2006/dolottamashey.pdf

Now if Thomson and Ritchie (yeah thems the guys) could do it in 1970,
why cant we revamp this 45-year old archaic program=textfile system today?

[Michael Torrie]

On 04/18/2015 01:00 AM, Marko Rauhamaa wrote:
> Ben Finney <ben+p...@benfinney.id.au>:
>
>> If you only write programs that will only ever be read by you and
>> no-one else, feel free to maintain a fork of Python (or any other
>> language) that suits your personal preferences.
>
> It would be possible to define a canonical AST storage format. Then,
> your editor could "incarnate" the AST in the syntax of your choosing.

As was just mentioned in another part of the thread, what you're
describing is essentially LISP.

[Mel Wilson]

On Sun, 19 Apr 2015 09:03:23 -0700, Rustom Mody wrote:

> Now if Thomson and Ritchie (yeah thems the guys) could do it in 1970,
> why cant we revamp this 45-year old archaic program=textfile system
> today?

Dunno. Why not? There's half of you right there.

[Steven D'Aprano]

On Sun, 19 Apr 2015 09:38 pm, BartC wrote:

> (I think much of the problem that most languages are intimately
> associated with their specific syntax, so that people can't see past it
> to what the code is actually saying. a=b, a:=b, b=>a, (setf a b),
> whatever the syntax is, who cares? We just want to do an assignment!)

You are making the mistake of thinking that we write code for the benefit of
the compiler or interpreter. We don't. If we did that, we'd all be using
machine code, programming in hex.

Source code exists to be read by human beings. If you want to communicate
with other human beings, you have to agree on a common language.

You might be interested in the Coffeescript model. You write Coffeescript
code, which is then translated (compiled? transpiled?) into pure
Javascript, which can then be run in the Javascript engine of your choice.
That's a language design model which is proven to work, unlike the idea of
having configurable syntax.

You'll notice that Coffeescript isn't a mere preprocessor or source code
transformation. The code is compiled into a different language, which may
not be reversible, and different compilers may generate different
(better/worse) code.

The Coffeescript:

eat food for food in ['toast', 'cheese', 'wine']


compiles to Javascript:

var food, j, len, ref;

ref = ['toast', 'cheese', 'wine'];
for (j = 0, len = ref.length; j < len; j++) {
food = ref[j];
eat(food);
}




--
Steven

[Steven D'Aprano]

On Mon, 20 Apr 2015 02:03 am, Rustom Mody wrote:

> On Sunday, April 19, 2015 at 8:45:27 PM UTC+5:30, Chris Angelico wrote:
>
> <Description of the task of first-classing syntax snipped>
>
>> I suspect you'll find the task fundamentally hard.
>
> How hard?
> Lets see.
> Two guys wanted to write an OS.
> Seeing current languages not upto their standard they first made
> themselves a suitable language.
> Would you call their project hard ridiculous and misguided?

No, I would call it easy and sensible. University undergraduates write their
own compilers and operating systems. Admittedly only toy ones, but Thomson
and Ritchie weren't undergraduates.

What does this have to do with creating a language with configurable syntax?
Just because C/Unix was a good idea doesn't mean every idea related to
programming language design is also a good idea.

> Well evidently some people did but fortunately their managers did not
> interfere.

You are assuming they had managers. University life isn't exactly the same
as corporate culture.

> OTOH some others liked the ideas/outlook enough that they jumped on the
> bandwagon and in short order there were - a heavy duty compilation system
> -- parser generators to librarians etc - editor(s)
> - source code systems
> - text tools (grep sed)
> - shell
>
> In short a 'Programmer's Work Bench'
> http://www.ics.uci.edu/~andre/ics228s2006/dolottamashey.pdf
>
> Now if Thomson and Ritchie (yeah thems the guys) could do it in 1970,
> why cant we revamp this 45-year old archaic program=textfile system today?

Programmers use source code as text for the same reason that wheels are
still round. Wheels have been round for thousands of years! Why can't we
try something modern, like triangular wheels? Or something fractal in
three-dimensions... maybe cauliflower shaped?



--
Steven

[Dan Sommers]

On Sun, 19 Apr 2015 09:03:23 -0700, Rustom Mody wrote:

> Now if Thomson and Ritchie (yeah thems the guys) could do it in 1970,
> why cant we revamp this 45-year old archaic program=textfile system
> today?

Revamp? What's to revamp?

C, C++, C#, Java, FORTRAN, Python, Perl, Ruby, POSIX shells, Javascript,
and a whole spectrum of arguably mainstream languages *still* work that
way. Plenty of other languages that compile to Python or Java bytecode
work that way, even if the source code isn't Python or Java. New
languages, like go, Rust, and Julia work that way. What's to revamp?
My IDE is UNIX.

Java programmers who don't dare leave their beloved pointy clicky IDE
for a command line store their source files as plain text (and they
cringe when I sed sed against those source files, but I digress). The
one project I ever did on a mainframe had a common text editor that
supported FORTRAN, JCL, and COBOL, and stored source code in files of
containing fixed length records of EBCDIC characters, IIRC. The notion
of a "line of code," even in white-space-neutral languages, is deeply
rooted in punch cards, and isn't going away anytime soon.

IMO, until git's successor tracks content-_not_-delimited-by-linefeeds,
languages will continue to work that way.

Smalltalk, Forth, and LISP don't follow the program=textfile system
(although LISP can, and does sometimes); and UCSD Pascal didn't (at
least I think it didn't; the only tools I remember from those days all
ran inside UCSD Pascal and didn't expose much of the internals).

Slash rant. Sorry.

Now that we've settled on UTF-8 as a successor to ASCII, the
program=textfile system has a long future in front of it.

Dan

[Mel Wilson]

On Mon, 20 Apr 2015 03:53:08 +1000, Steven D'Aprano wrote:

> On Mon, 20 Apr 2015 02:03 am, Rustom Mody wrote:

>> Well evidently some people did but fortunately their managers did not
>> interfere.
>
> You are assuming they had managers. University life isn't exactly the
> same as corporate culture.

IIRC Thompson, Ritchie, et al. were working at Bell Labs. Legend has it
that management would not buy them a Multics, so they were forced to
write their own using the hardware they had.

Mel.

[CHIN Dihedral]

On Thursday, April 16, 2015 at 11:06:28 PM UTC+8, Mark Lawrence wrote:
> On 16/04/2015 15:52, Blake McBride wrote:
>
> > So, Python may be a cute language for you to use as an individual, but it is unwieldy in a real development environment.
> >
>
> Thanks for this, one of the funniest comments I've read here in years.
> It's good to see that new people share the humourous side of the Python
> programming culture. Long may it continue.

>
> --
> My fellow Pythonistas, ask not what our language can do for you, ask
> what you can do for our language.
>
> Mark Lawrence

Python is a cross-platform computer
language with dynamical types,
functional programming featuers, oops, and generic programming featuers designed in the language.

Now the generic part is the main
progress in the software and IT
sectors

[Chris Angelico]

On Mon, Apr 20, 2015 at 4:07 AM, Dan Sommers <d...@tombstonezero.net> wrote:
> IMO, until git's successor tracks content-_not_-delimited-by-linefeeds,
> languages will continue to work that way.

Linefeeds are nothing to git - it tracks the entire content of the
file. When you ask to see the diff between two versions of a file,
that's when lines start to have meaning - and if you configure in your
own difftool, you're welcome to compare files in arbitrary ways. It's
not for the sake of source control that code is in lines of text -
it's for the sake of humans.

ChrisA

[Paul Rubin]

Steven D'Aprano <steve+comp....@pearwood.info> writes:
> You might be interested in the Coffeescript model....>

> You'll notice that Coffeescript isn't a mere preprocessor or source code
> transformation.

I like Purescript (purescript.org) better than Coffeescript, but either
way, I don't see Python as an attractive target for that approach.
People code in Javascript because they have to (browser apps), so if
they hate the JS language but have to use it anyway, it's reasonable to
wrap a translation layer around it. JS is basically used as a high
level assembly language.

By contrast, most people who use Python use it because they like it.
Sure there are warts here and there, but for the most part, if someone
doesn't like Python, they can pick something else that does the same
job.

[Marko Rauhamaa]

Michael Torrie <tor...@gmail.com>:

I don't see how that is more essentially Lisp than Python.

Lisp has a noncanonical textual representation just like Python.


Marko

[BartC]

On 19/04/2015 13:59, Ben Finney wrote:

> BartC <b...@freeuk.com> writes:
>
>> Why shouldn't A configure his editor to display a Python program in
>> C-like syntax, and B configure their editor to use Python-like tabbed
>> syntax?
>
> I don't recall anyone saying that *shouldn't* be done. Feel free to
> make, and maintain and support and propagate and keep pace with changes
> in everything Python interacts with, a full Python stack that supports
> such flexibility.
>
>> A can write code in the preferred syntax, and B can view/modify
>> exactly the same code in /their/ preferred syntax. What would be the
>> problem?
>
> I can only invite you to embark on the project of a Python compiler
> which accepts such a switchable syntax, maintain it consistently over
> the lifetime of a project with significant numbers of people
> collaborating using different switch settings for that syntax, and
> working on the same code with different editor settings.
>
> Once you've done that, report back to us about the problems encountered.
>
>> (The actual stored representation of the program would be in one of
>> those two styles, or something else entirely; Lisp-like syntax for
>> example. It doesn't matter because no-one would care.
>
> No-one except the people who have to maintain and debug and continue
> developing a Python that supports multiple radically-different syntaxes.
> I suspect the efforts of those people is being discounted in your vision.

I used actual languages Python and C in my example, I should have used A
and B or something.

If this was actually Python, then clearly source must be stored in
Python syntax, to get around some of the objections that have been
raised. Then all existing tools will work as before.

But it means an editor would need to understand Python extremely well in
order to do the 2-way transformation I was suggesting. And while that
would need maintaining, I don't think it's impossible (don't smart
editors already understand a lot of the syntax? And if I was doing this,
I would use a conventional editor, and an separate translator). But it
would all be optional; everything would then still work as before.

However, I have played around with an actual project along these lines,
but with some differences. Let's call actual Python source ".PY", and my
preferred syntax ".JPY" (since those were the file extensions I used;
"J" was the name I used to designate my syntax - syntax, not language,
as the language must still be Python).

Here, the intention was to store source code in .JPY files, with .PY
used as an intermediate form when I need to use an existing Python tool.
So the translation was one-way (which suited me because I tend to do my
own thing).

There are a few issues: I can still import .PY files created by others,
but if it's one of mine created as .JPY, it just means it needs
translating before running Python. Things such as eval() that have been
mentioned, I haven't attempted. (Probably, it would be written as
jeval() and would need to invoke the translator on the string, the
results of which are passed to eval(). You can get around most such
problems.)

So I'm aware of some of the things that are involved.

(BTW that project worked reasonably well, but I decided to go in a
different direction: turning "J" from a mere syntax into an actual
language of its own.)

--
Bartc

[Ron Adam]

On 04/19/2015 05:42 PM, BartC wrote:
>
> So I'm aware of some of the things that are involved.
>
> (BTW that project worked reasonably well, but I decided to go in a
> different direction: turning "J" from a mere syntax into an actual language
> of its own.)

Something you might try with your new language is to have an editor that
can parse the source text to a tokenised "text" data file. It should be a
fairly direct text to text translation, so putting it into the editor
should be doable.

Once you get that far, you can add pluggable token parsers to the editor
that can unparse the token files to a specific user format for editing, and
reparse it back to the standardised token file for storage. Now the users
can choose a customised dialect of your language. And the compiler will
work on a single token file type.

This will also remove the need for pretty printers and formatters as they
will be built into the editors pluggable token parser. Just have the
editor tokenise and then immediately untokenise and you just checked for
syntax errors and reformatted the program. The highlighter could also
work with the token parser as well. The only catch is how to handle
compile and run time errors. The editor will need to read an error file
and translate it back to the source. I think it's doable but it will be
tricky to get it to work well.

The reason to make the split at tokens is, it's at a stage that most of
what is needed is already in a text editor.

The token file format becomes the bridge that spans the gap between the
user/editor and the compiler/interpreter.

Then your compiler/interpreter is all implementation details that work on a
single standardised token file format rather than unformatted text files.

Ron

[Ben Finney]

BartC <b...@freeuk.com> writes:

> I used actual languages Python and C in my example, I should have used
> A and B or something.

If you had, then the topic drifts so far from being relevant to a Python
programming forum that I'd ask you to stop.

Perhaps that should have happened much sooner.

--
\ “If we have to give up either religion or education, we should |
`\ give up education.” —William Jennings Bryan, 1923-01 |
_o__) |
Ben Finney

[BartC]

On 20/04/2015 00:59, Ben Finney wrote:
> BartC <b...@freeuk.com> writes:
>
>> I used actual languages Python and C in my example, I should have used
>> A and B or something.
>
> If you had, then the topic drifts so far from being relevant to a Python
> programming forum that I'd ask you to stop.
>
> Perhaps that should have happened much sooner.

Maybe it should have. This sub-thread started by you replying to this
parenthesised comment of mine:

"(Actually *I* would quite like to know why languages don't have
switchable syntax anyway to allow for people's personal preferences.)"

I didn't mention any language by name at all!

--
Bartc

[Rustom Mody]

On Sunday, April 19, 2015 at 11:38:45 PM UTC+5:30, Dan Sommers wrote:


> What's to revamp? My IDE is UNIX.

Precisely my point: source-file = text-file is centerstage of Unix philosophy
If you want to start by questioning that, you must question not merely the language (python or whatever) but the matrix in which it is embedded

>
> Java programmers who don't dare leave their beloved pointy clicky IDE
> for a command line store their source files as plain text (and they
> cringe when I sed sed against those source files, but I digress). The
> one project I ever did on a mainframe had a common text editor that
> supported FORTRAN, JCL, and COBOL, and stored source code in files of
> containing fixed length records of EBCDIC characters, IIRC.

And in all likelihood different from the files (not really text) created
by Cobol

> The notion
> of a "line of code," even in white-space-neutral languages, is deeply
> rooted in punch cards, and isn't going away anytime soon.
>
> IMO, until git's successor tracks content-_not_-delimited-by-linefeeds,
> languages will continue to work that way.

Yeah...
For what I (and I guess bartC) are talking about to succeed we would need
- more structured diff/merge in git (etc)
- corresponding sed/grep etc
- editor (plugins)
- etc

http://blog.languager.org/2013/09/poorest-computer-users-are-programmers.html

So yes its more work than making a new language

[Rustom Mody]

On Monday, April 20, 2015 at 2:11:13 AM UTC+5:30, Marko Rauhamaa wrote:
> Michael Torrie:

Technically correct
Pragmatically: its like saying a meal that costs a penny, 100 EURO and 10K EURO
are all the same.
In C, access to parsing /unparsing is one of open up gcc/use lex/yacc
In python, it is use the introspective module(s)
In lisp its one call (read)/(print) -- at most; none if the REPL is used
effectively

[Rustom Mody]

On Sunday, April 19, 2015 at 11:23:20 PM UTC+5:30, Steven D'Aprano wrote:
> Programmers use source code as text for the same reason that wheels are
> still round. Wheels have been round for thousands of years! Why can't we
> try something modern, like triangular wheels? Or something fractal in
> three-dimensions... maybe cauliflower shaped?

So also did people believe for a good 2000 years that acceleration due to gravity
is proportional to mass until Galileo climbed up the tower of Pisa and dropped
2 different weight objects
http://en.wikipedia.org/wiki/Galileo%27s_Leaning_Tower_of_Pisa_experiment

Analogies can work both ways

And before you ask something like

| What does this have to do with creating a language with configurable syntax?
| Just because C/Unix was a good idea doesn't mean every idea related to
| programming language design is also a good idea.

let me spell it out:
Prestige of Aristotle stymies progress of physics of 2 millennia
likewise
Prestige of Unix development environment keeps us stuck with text files when
the world has moved on

[Chris Angelico]

On Mon, Apr 20, 2015 at 12:08 PM, Rustom Mody <rusto...@gmail.com> wrote:
> Prestige of Unix development environment keeps us stuck with text files when
> the world has moved on

And what, pray, would we gain by using non-text source code? Aside
from binding ourselves to a set of tools, which would create an even
worse lock-in?

ChrisA

[Mark Lawrence]

On 20/04/2015 03:08, Rustom Mody wrote:
> Prestige of Unix development environment keeps us stuck with text files when
> the world has moved on
>

If it ain't broke, don't fix it.

[Steven D'Aprano]

On Mon, 20 Apr 2015 04:07 am, Dan Sommers wrote:

> Smalltalk, Forth, and LISP don't follow the program=textfile system
> (although LISP can, and does sometimes);

Correct, and the fact that they wrapped code and environment into a
completely opaque image was a major factor in their decline in popularity
for all three languages.

http://www.ianbicking.org/where-smalltalk-went-wrong.html
http://www.ianbicking.org/where-smalltalk-went-wrong-2.html


Source as text means that you can use any text based tool with little or no
effort. Using a non-text binary blob for source code means that your
options are much more limited. Look at source control software like git and
mercurial (hg): they automatically work on any language based on lines of
text code. There is no need for hg-for-java, hg-for-python, hg-for-ruby,
hg-for-javascript, hg-for-c, there is just hg. But if languages were
image-based like Smalltalk, hg would require special knowledge of the
internals of each compiler's image file format.


--
Steven

[Rustom Mody]

On Monday, April 20, 2015 at 7:54:37 AM UTC+5:30, Chris Angelico wrote:

> On Mon, Apr 20, 2015 at 12:08 PM, Rustom Mody wrote:
> > Prestige of Unix development environment keeps us stuck with text files when
> > the world has moved on
>
> And what, pray, would we gain by using non-text source code? Aside
> from binding ourselves to a set of tools, which would create an even
> worse lock-in?

Threads like this one would become passé.
In html for example there's things like fluid-layout.
So also if indentation was strictly delimited by tabs
then whether you like to see your tabs as 4 spaces and I like to see them as 2
would be as relevant to our discussing shared code as the fact that I wearing
pyjamas and you are in a 3 piece suit.

The key thing to make this work is that the tab needs to be a reasonably solid
non-leaky abstraction for denoting an indent.
As soon as you allow both tabs and spaces all the interminable bikeshedding starts

In many ways this is like the browser wars.
If browsers had been made like half-decent compilers then non-compliant html
wouldn't render and would get corrected on short order.
Instead browsers overreach themselves to be nice (to users) and end up being
horrible to web-developers who now need to maintain 1 dozen browsers × 2 dozen versions.

Likewise all the overreaching to be allow 'free-form' layout puts paid to all
attempts at richer structure comprehending tools.
As a quick example try this:
You've a 10-file python project in which you want to replace function 'f'
by function 'longname'
How easy is it?

I am ready to bet that if you use IE-ish its easy if you use classic editors
not so.

This unfortunate choice between sophistication+lockin vs uncivilization+freedom
is unnecessary

[Steven D'Aprano]

On Mon, 20 Apr 2015 06:41 am, Marko Rauhamaa wrote:

> Lisp has a noncanonical textual representation just like Python.

Python has a noncanonical textual representation?

What is a noncanonical textual representation, and where can I see some?



--
Steven

[Chris Angelico]

On Mon, Apr 20, 2015 at 12:43 PM, Rustom Mody <rusto...@gmail.com> wrote:
> The key thing to make this work is that the tab needs to be a reasonably solid
> non-leaky abstraction for denoting an indent.
> As soon as you allow both tabs and spaces all the interminable bikeshedding starts
>

Whatever you change, there will be stuff for people to argue about.
Trust me, that's nothing to do with the nature of programming
languages... it's about the nature of people.

> In many ways this is like the browser wars.
> If browsers had been made like half-decent compilers then non-compliant html
> wouldn't render and would get corrected on short order.
> Instead browsers overreach themselves to be nice (to users) and end up being
> horrible to web-developers who now need to maintain 1 dozen browsers × 2 dozen versions.
>
> Likewise all the overreaching to be allow 'free-form' layout puts paid to all
> attempts at richer structure comprehending tools.
> As a quick example try this:
> You've a 10-file python project in which you want to replace function 'f'
> by function 'longname'
> How easy is it?
>
> I am ready to bet that if you use IE-ish its easy if you use classic editors
> not so.

If you have a ten-file project that's identifying a key function
globally as 'f', then you already have a problem. If your names are
more useful and informative, a global search-and-replace will do the
job.

What's your point, though? Somewhere along the way, you need to have
identifiers, and those identifiers need to explain *to the human* what
code you're referring to. Whether they're line labels in assembly
language, memory locations in machine code, linker relocation table
entries, fully-qualified module/class/method names, or simple flat
identifiers, they exist as much for the humans as for the compiler. If
you change the basic syscall from INT 21 to CALL __SYSTEM, everyone
who uses your code needs to change his/her *head* to cope with your
change. There is fundamentally no tool which can do this for you.

You can add a level of indirection to program loading by having the
function name turn into some sort of internal identifier when you save
the source file, and then you can rename the function in one place.
Great! But somehow you still need to have humans recognize which
functions they want to call. Do they have to point-and-click to pick a
function? I've used IDEs like that, and they are a pain.

ChrisA

[Chris Angelico]

I think what Marko means is that there is a textual way to represent
Python source code, and there are multiple files that represent
identical Python programs, hence "noncanonical". If you have two UTF-8
encoded files that contain the same text, they will have the exact
same bytes in them, because UTF-8 defines a canonical byte
representation for text. You can't say that about Python source.

ChrisA

[Rustom Mody]

On Monday, April 20, 2015 at 8:34:12 AM UTC+5:30, Chris Angelico wrote:

> On Mon, Apr 20, 2015 at 12:43 PM, Rustom Mody wrote:
> > The key thing to make this work is that the tab needs to be a reasonably solid
> > non-leaky abstraction for denoting an indent.
> > As soon as you allow both tabs and spaces all the interminable bikeshedding starts
> >
>
> Whatever you change, there will be stuff for people to argue about.
> Trust me, that's nothing to do with the nature of programming
> languages... it's about the nature of people.
>
> > In many ways this is like the browser wars.
> > If browsers had been made like half-decent compilers then non-compliant html
> > wouldn't render and would get corrected on short order.
> > Instead browsers overreach themselves to be nice (to users) and end up being
> > horrible to web-developers who now need to maintain 1 dozen browsers × 2 dozen versions.
> >
> > Likewise all the overreaching to be allow 'free-form' layout puts paid to all
> > attempts at richer structure comprehending tools.
> > As a quick example try this:
> > You've a 10-file python project in which you want to replace function 'f'
> > by function 'longname'
> > How easy is it?
> >
> > I am ready to bet that if you use IE-ish its easy if you use classic editors
> > not so.
>
> If you have a ten-file project that's identifying a key function
> globally as 'f', then you already have a problem. If your names are
> more useful and informative, a global search-and-replace will do the
> job.

Are you sure your global search-and-replace will do a proper job inside
strings and comments?

>
> What's your point, though?

Point?

Nnotions like identifier (and dozens of others) are straightforwardly
present and available inside the python implementation.
However the language implementation is a hard-n-high silo
For the programmer accessing the language through an editor these notions are
not available unless hi-power explosives are used to punch holes in the silo
-- eg open Cpython sources.

The Smalltalks and Lisps organized the world differently -- the programmer was
inside the silo with the corresponding advantages of power and disadvantages of
imprisonment.

I (and I guess BartC) like to dream of a Utopia that is powerful and free

[Chris Angelico]

On Mon, Apr 20, 2015 at 1:28 PM, Rustom Mody <rusto...@gmail.com> wrote:
>> If you have a ten-file project that's identifying a key function
>> globally as 'f', then you already have a problem. If your names are
>> more useful and informative, a global search-and-replace will do the
>> job.
>
> Are you sure your global search-and-replace will do a proper job inside
> strings and comments?

Yep! Any occurrence inside a string literal or comment is generally
going to be referring to the same function, and thus should be
renamed. Can your system handle _that_? Example:

def add_grab(widget):
"""Add a widget to the grabbed widgets"""

def remove_grab(widget):
"""Undo the effect of add_grab() on a given widget"""
# Note that multiple add_grab() calls will add multiple instances,
# so we remove only the first.

Every occurrence of add_grab here is referring to the function. If you
do a global search-and-replace, they'll be caught automatically. With
your non-text magic, you'd need to explicitly implement this as a
feature. Text files make life easier!

>> What's your point, though?
>
> Point?
>
> Nnotions like identifier (and dozens of others) are straightforwardly
> present and available inside the python implementation.
> However the language implementation is a hard-n-high silo
> For the programmer accessing the language through an editor these notions are
> not available unless hi-power explosives are used to punch holes in the silo
> -- eg open Cpython sources.

Would it help if Python grew a function like Pike's
Function.defined(), which tells you exactly where, even in C source,
something was defined? I don't honestly see that looking in the
CPython source is such a common need that it begs for assistance, and
I definitely don't see how a non-text source code format would improve
on it. Feel like elaborating?

ChrisA

[Marko Rauhamaa]

Chris Angelico <ros...@gmail.com>:

Yes, more than one Python source file produces an identical AST, and
none of them is obviously the "normal form."


Marko

[Gregory Ewing]

Steven D'Aprano wrote:
> Wheels have been round for thousands of years! Why can't we
> try something modern, like triangular wheels?

http://en.wikipedia.org/wiki/Reuleaux_triangle

http://blog.geomblog.org/2004/04/square-wheels.html

--
Greg