Re: [racket-users] Reducing parentheses without language damage.

[Dexter Lagan]

  Spoiled is an understatement. I wrote a lot of programs in debug (DOS). And 
it was nice! Turbo Pascal was what really spoiled me. :) I miss the in-line asm 
days.

Dex

> On May 3, 2020, at 9:46 PM, George Neuner  wrote:
> 
> 
>> On 5/2/2020 4:58 AM, Dexter Lagan wrote:
>>   For the sake of discussion, here’s a long rant:
>> 
>>   I might have a very uninformed opinion here, but wouldn’t having 
>> significant white space and no scope-defining character amount to multiple 
>> spaces and line feeds being part of the syntax? The next best thing being, 
>> allowing semicolons in place of line feeds. I’m no language designer, so let 
>> me try to give you my perspective as an average programmer:
>> 
>>   I find editing Python and Haskell a pain, because of white spaces. I can’t 
>> count the times I got that dreaded ‘invalid indentation’ error, because I’m 
>> editing code with a different editor on a different system. I also had to 
>> reformat entire programs after somebody saved using the incorrect tab 
>> setting, and I avoid Python because of this. Yet I haven’t heard this 
>> complaint from Python programmers, so I always believed I was just too dumb.
> 
> Python is as much a cult as a programming language.
> 
> 
>>   I haven’t seen a better solution than s-expr to make expressions and scope 
>> ultra-visible and easy to manipulate. Yet s-expressions still bring their 
>> own requirements for comfortable editing: most people still require a 
>> specialized editor or a plugin for lisps. I fact, is there any language that 
>> doesn’t require some sort of plugin or specialized editor to be attractive 
>> to new programmers? Thinking of it, isn’t the IDE almost as important as the 
>> syntax or the language these days?
> 
> For most languages, IDEs are mainly needed for debugging.  For just editing, 
> the majority of languages really don't need syntax or structure awareness.  
> Syntax coloring is nice, but programmers got along fine without it for ~50 
> years.
> 
> Most languages in use now have syntax based (however loosely) on C and mostly 
> are not WS sensitive.  The compiler doesn't care about how the code is 
> formatted:  there is a statement terminator (or separator [there is a 
> difference]) character that serves to keep the compiler synchronized with the 
> source.
> 
> In Pascal, you can write an entire program on a single edit line. In C and 
> C++, the preprocessor is line sensitive, so it isn't possible to write a 
> whole program in one line - but the mainline code is WS indifferent, and you 
> can write entire functions, or even multiple functions, in one line.
> 
> But no one does that except in those competitions trying to pack a whole 
> program into 255 characters or less.
> 
> For most languages it is visual debugging: tracing and breaking execution, 
> probing runtime values, while seeing the source ... *that* is where an IDE 
> comes into its own.
> 
> 
> S-expr languages are different in this respect because they are expression 
> based rather than statement based.  Expressions can be nested arbitrarily, 
> and it is more difficult to visually identify things without some editor 
> assistance like coloration, parenthesis matching, and syntax directed 
> indentation.
> 
> S-expr languages have long used - though not required - indentation as a 
> guide to visualize program structure.  When you program with Racket (or 
> Scheme or Lisp) for a while, you cease to see the parentheses and really 
> mostly see only the indentation structure.
> 
> For debugging: tracing and breaking S-expr code is more complicated to 
> *display* and interact with reasonably - the UI matters greatly to programmer 
> efficiency.  But the actual debugger internally is not really much different 
> from a debugger for a statement language - it's mostly how the programmer 
> interacts with it that needs to change.
> 
> 
>> Some JavaScript programmers can’t work without VSCode, scope-sensitive 
>> autocomplete, a linter and god knows how many other plugins. PHP programmers 
>> also feel naked without a fancy IDE and a host of plugins. I keep hearing 
>> people complain about x or y language because it doesn’t have a good editor, 
>> IDE or plugin for VSCode. Globally, people use more and more tools to 
>> program in the same languages.
> 
> Programmers today are spoiled.  My first program was written on a teletype 
> connected by modem to a PDP-10 at some nearby college.  It took half an hour 
> to get a 10 line program working.
> 
> 
>>   That’s what turned me into a sort of ‘digital minimalist’. I take comfort 
>> in not being dependant on anything other than a compiler/interpreter and a 
>> simple editor I can whip out of any system in seconds. I think there’s value 
>> in reducing our dependencies, including on tools, editors, IDEs and plugins. 
>> That being said, I love DrRacket and its facilities, also because it’s 
>> self-contained and bundled with Racket. One less thing to install.
>> 
>>   

Re: [racket-users] Reducing parentheses without language damage.

[George Neuner]

On 5/2/2020 4:58 AM, Dexter Lagan wrote:

  For the sake of discussion, here’s a long rant:

  I might have a very uninformed opinion here, but wouldn’t having 
significant white space and no scope-defining character amount to 
multiple spaces and line feeds being part of the syntax? The next best 
thing being, allowing semicolons in place of line feeds. I’m no 
language designer, so let me try to give you my perspective as an 
average programmer:


  I find editing Python and Haskell a pain, because of white spaces. I 
can’t count the times I got that dreaded ‘invalid indentation’ error, 
because I’m editing code with a different editor on a different 
system. I also had to reformat entire programs after somebody saved 
using the incorrect tab setting, and I avoid Python because of this. 
Yet I haven’t heard this complaint from Python programmers, so I 
always believed I was just too dumb.


Python is as much a cult as a programming language.


  I haven’t seen a better solution than s-expr to make expressions and 
scope ultra-visible and easy to manipulate. Yet s-expressions still 
bring their own requirements for comfortable editing: most people 
still require a specialized editor or a plugin for lisps. I fact, is 
there any language that doesn’t require some sort of plugin or 
specialized editor to be attractive to new programmers? Thinking of 
it, isn’t the IDE almost as important as the syntax or the language 
these days?


For most languages, IDEs are mainly needed for debugging.  For just 
editing, the majority of languages really don't need syntax or structure 
awareness.  Syntax coloring is nice, but programmers got along fine 
without it for ~50 years.


Most languages in use now have syntax based (however loosely) on C and 
mostly are not WS sensitive.  The compiler doesn't care about how the 
code is formatted:  there is a statement terminator (or separator [there 
is a difference]) character that serves to keep the compiler 
synchronized with the source.


In Pascal, you can write an entire program on a single edit line. In C 
and C++, the preprocessor is line sensitive, so it isn't possible to 
write a whole program in one line - but the mainline code is WS 
indifferent, and you can write entire functions, or even multiple 
functions, in one line.


But no one does that except in those competitions trying to pack a whole 
program into 255 characters or less.


For most languages it is visual debugging: tracing and breaking 
execution, probing runtime values, while seeing the source ... *that* is 
where an IDE comes into its own.



S-expr languages are different in this respect because they are 
expression based rather than statement based.  Expressions can be nested 
arbitrarily, and it is more difficult to visually identify things 
without some editor assistance like coloration, parenthesis matching, 
and syntax directed indentation.


S-expr languages have long used - though not required - indentation as a 
guide to visualize program structure.  When you program with Racket (or 
Scheme or Lisp) for a while, you cease to see the parentheses and really 
mostly see only the indentation structure.


For debugging: tracing and breaking S-expr code is more complicated to 
*display* and interact with reasonably - the UI matters greatly to 
programmer efficiency.  But the actual debugger internally is not really 
much different from a debugger for a statement language - it's mostly 
how the programmer interacts with it that needs to change.



Some JavaScript programmers can’t work without VSCode, scope-sensitive 
autocomplete, a linter and god knows how many other plugins. PHP 
programmers also feel naked without a fancy IDE and a host of plugins. 
I keep hearing people complain about x or y language because it 
doesn’t have a good editor, IDE or plugin for VSCode. Globally, people 
use more and more tools to program in the same languages.


Programmers today are spoiled.  My first program was written on a 
teletype connected by modem to a PDP-10 at some nearby college.  It took 
half an hour to get a 10 line program working.



  That’s what turned me into a sort of ‘digital minimalist’. I take 
comfort in not being dependant on anything other than a 
compiler/interpreter and a simple editor I can whip out of any system 
in seconds. I think there’s value in reducing our dependencies, 
including on tools, editors, IDEs and plugins. That being said, I love 
DrRacket and its facilities, also because it’s self-contained and 
bundled with Racket. One less thing to install.


  These are the considerations I’d take in account when thinking of a 
new syntax. Still, like I said before, I’m excited by the fact that 
the Racket team is looking for a solution to this problem, and I’ll be 
the first to applaud a way to keep the next Racket expressive and 
powerful, while making it more attractive to people used to more 
familiar syntax. Parentheses are, and always will be a barrier to 
entry for 

Re: [racket-users] Reducing parentheses without language damage.

[Stephen De Gabrielle]

Quick question: Would it better if this discussion happened over at 
https://github.com/racket/rhombus-brainstorming/blob/master/resources/goals.md

or on the Racket Slack #rhombus channel?

I’m aware that email and slack is a bit ephemeral - it is probably a good idea 
to turn any proposals into RFC’s or issues at 
https://github.com/racket/rhombus-brainstorming - so they are not lost.

Kind regards
Stephen

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/277b6aa7-f44c-45a1-917a-e9c5340473fc%40googlegroups.com.

Re: [racket-users] Reducing parentheses without language damage.

[Dexter Lagan]

  For the sake of discussion, here’s a long rant:

  I might have a very uninformed opinion here, but wouldn’t having significant 
white space and no scope-defining character amount to multiple spaces and line 
feeds being part of the syntax? The next best thing being, allowing semicolons 
in place of line feeds. I’m no language designer, so let me try to give you my 
perspective as an average programmer:

  I find editing Python and Haskell a pain, because of white spaces. I can’t 
count the times I got that dreaded ‘invalid indentation’ error, because I’m 
editing code with a different editor on a different system. I also had to 
reformat entire programs after somebody saved using the incorrect tab setting, 
and I avoid Python because of this. Yet I haven’t heard this complaint from 
Python programmers, so I always believed I was just too dumb.

  I haven’t seen a better solution than s-expr to make expressions and scope 
ultra-visible and easy to manipulate. Yet s-expressions still bring their own 
requirements for comfortable editing: most people still require a specialized 
editor or a plugin for lisps. I fact, is there any language that doesn’t 
require some sort of plugin or specialized editor to be attractive to new 
programmers? Thinking of it, isn’t the IDE almost as important as the syntax or 
the language these days? Some JavaScript programmers can’t work without VSCode, 
scope-sensitive autocomplete, a linter and god knows how many other plugins. 
PHP programmers also feel naked without a fancy IDE and a host of plugins. I 
keep hearing people complain about x or y language because it doesn’t have a 
good editor, IDE or plugin for VSCode. Globally, people use more and more tools 
to program in the same languages.

  That’s what turned me into a sort of ‘digital minimalist’. I take comfort in 
not being dependant on anything other than a compiler/interpreter and a simple 
editor I can whip out of any system in seconds. I think there’s value in 
reducing our dependencies, including on tools, editors, IDEs and plugins. That 
being said, I love DrRacket and its facilities, also because it’s 
self-contained and bundled with Racket. One less thing to install.

  These are the considerations I’d take in account when thinking of a new 
syntax. Still, like I said before, I’m excited by the fact that the Racket team 
is looking for a solution to this problem, and I’ll be the first to applaud a 
way to keep the next Racket expressive and powerful, while making it more 
attractive to people used to more familiar syntax. Parentheses are, and always 
will be a barrier to entry for potential Racket adopters, and this is no small 
matter. I think Julia is a good example of the right balance between simple, 
attractive syntax and power. Are there downsides to their approach?

Cheers,

Dex

> On May 2, 2020, at 2:12 AM, George Neuner  wrote:
> 
>  
> On 5/1/2020 4:35 PM, Dexter Lagan wrote:
>>   Is there value in Rob Pike’s comment on avoiding significant white space 
>> in the Go language?
>> 
>> “We have had extensive experience tracking down build and test failures 
>> caused by cross-language builds where a Python snippet embedded in another 
>> language, for instance through a SWIG invocation, is subtly and invisibly 
>> broken by a change in the indentation of the surrounding code.” — Rob Pike, 
>> 2012
> 
> I'm not really sure what Pike is getting at there:  I haven't used SWIG 
> myself, but if I understand it correctly, Python code would have to be in a 
> module to be called from "other" language code.  If so, I don't see how the 
> indentation of the "other" code could affect the Python.
> 
> That aside: 
> 
> Even working only in Python, programmers routinely get tripped up by 
> copy/paste errors - so it is evident that indentation sensitivity is not any 
> real solution to scope related logic problems.  It might [for some 
> definition] help newbies identify stupid errors, but I believe that even 
> moderately experienced programmers are more hindered than helped by it.
> 
> 
>>   I personally dislike white space and prefer either mustaches or 
>> parenthesis, just so I know my code will still work if line feeds are 
>> stripped somehow, or that some piece of code is embedded or quoted in 
>> another language, which is what I gather Rob was talking about. However, 
>> Haskell and Python people don’t seem to mind, and if it saves us more 
>> keystrokes while keeping expressiveness, why not?
> 
> Well, few people use Haskell, so I would discount it as a data point.  Even 
> so, one of the tutorials includes this interesting tidbit:
> 
> With good text editor, programming is fun. Of course, you can get along with 
> simplistic
> editor capable of just cut-n-paste, but good editor is capable of doing most 
> of the chores
> for you, letting you concentrate on what you are writing. With respect to 
> programming
> in Haskell, good text editor should have as much as possible of the following 
> 

Re: [racket-users] Reducing parentheses without language damage.

[David Storrs]

On Fri, May 1, 2020, 11:25 PM Raoul Duke  wrote:

> $0.02, whitespace sensitivity is just bad ux in the long run. haskell can
> get away with it more than python because haskell can be written more
> concisely i feel than python. but even in H it is sorta unfortunate.
>
> i like how iirc clojure uses sexprs but allows other kinds of parens,
> fairly arbitrarily.
>
> (foo '{2 3 4} '[a b c])
> same thing as
> (foo '(2 3 4) '(a b c))
>
> so humans can make some parts stand out a little bit differently.
>

Racket does the same thing. (), [], and {} are all equivalent as long as
they match consistently. (i.e. you can't do '(] because that doesn't match
consistently.)

> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/CAJ7XQb67vFEX7D0hHOxJXVG6344ngYU1%3DtmmQ0m6%3DVijqODEQw%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAE8gKocmAWMH4TUdJEPCBTPSSe8qEeaixNybDAsERMJaVOBDhQ%40mail.gmail.com.

Re: [racket-users] Reducing parentheses without language damage.

[Raoul Duke]

$0.02, whitespace sensitivity is just bad ux in the long run. haskell can
get away with it more than python because haskell can be written more
concisely i feel than python. but even in H it is sorta unfortunate.

i like how iirc clojure uses sexprs but allows other kinds of parens,
fairly arbitrarily.

(foo '{2 3 4} '[a b c])
same thing as
(foo '(2 3 4) '(a b c))

so humans can make some parts stand out a little bit differently.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAJ7XQb67vFEX7D0hHOxJXVG6344ngYU1%3DtmmQ0m6%3DVijqODEQw%40mail.gmail.com.

Re: [racket-users] Reducing parentheses without language damage.

[Liwei Chou]

Any one consider this style? Minimizing visual interference while 
preserving parentheses. Even Java program can be written like Python.

[image: main-qimg-8d66f35cd3da4c55a380d0d08c11d930.png]

https://www.quora.com/What-is-the-most-frustrating-thing-about-being-a-computer-programmer/answer/Jesse-Jaun

Though it's kind of like making fun with different coding style. There 
might be some inspiration for us.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/a7b75492-0a76-4d18-b586-2cde1c7acee4%40googlegroups.com.

Re: [racket-users] Reducing parentheses without language damage.

[George Neuner]

On 5/1/2020 4:35 PM, Dexter Lagan wrote:
  Is there value in Rob Pike’s comment on avoiding significant white 
space in the Go language?


“We have had extensive experience tracking down build and test 
failures caused by cross-language builds where a Python snippet 
embedded in another language, for instance through a SWIG invocation, 
is subtly and invisibly broken by a change in the indentation of the 
surrounding code.” — Rob Pike, 2012 





I'm not really sure what Pike is getting at there:  I haven't used SWIG 
myself, but if I understand it correctly, Python code would have to be 
in a module to be called from "other" language code.  If so, I don't see 
how the indentation of the "other" code could affect the Python.


That aside:

Even working only in Python, programmers routinely get tripped up by 
copy/paste errors - so it is evident that indentation sensitivity is not 
any real solution to scope related logic problems.  It might [for some 
definition] help newbies identify stupid errors, but I believe that even 
moderately experienced programmers are more hindered than helped by it.



  I personally dislike white space and prefer either mustaches or 
parenthesis, just so I know my code will still work if line feeds are 
stripped somehow, or that some piece of code is embedded or quoted in 
another language, which is what I gather Rob was talking about. 
However, Haskell and Python people don’t seem to mind, and if it saves 
us more keystrokes while keeping expressiveness, why not?


Well, few people use Haskell, so I would discount it as a data point.  
Even so, one of the tutorials includes this interesting tidbit:


   With good text editor, programming is fun. Of course, you can get
   along with simplistic
   editor capable of just cut-n-paste, but good editor is capable of
   doing most of the chores
   for you, letting you concentrate on what you are writing. With
   respect to programming
   in Haskell, good text editor should have as much as possible of the
   following features:

   • Syntax highlighting for source files
   • Indentation of source files
   • Interaction with Haskell interpreter (be it Hugs or GHCi)
   • Computer-aided code navigation
   • Code completion


The implication is that Haskell is difficult to write without proper 
editor support.  So too is Python.  Decent syntax and structure aware 
editors are not really a problem any more, but they can go only so far:  
they can fail spectacularly when code gets complicated and the language 
syntax provides no clues to figure out the scoping.


S-exprs do not suffer from this affliction.


Also mentioned previously is my concern that indentation sensitivity may 
make implementing macros as we enjoy them in Racket difficult. Or maybe 
impossible.  Although certainly there are indentation languages which 
have macro facilities, I am not aware of any in which the macros can be 
written in the same language.  All the ones I know of implement a 
separate DSL macro language.


I have designed and implemented a few languages: including a Scheme-ish 
mostly functional language [but lacking macros].   I have not thought 
through all the nuances of implementing a language that can reflectively 
manipulate the structure of a program in the midst of compiling it  [or 
in the case of Lisp - running it].  However, I have to think there are 
reasons for existing indentation languages not having done so.


YMMV,
George

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/e92ee43b-5d6c-000d-dc04-25fe76149284%40comcast.net.

Re: [racket-users] Reducing parentheses without language damage.

[Dexter Lagan]

  Is there value in Rob Pike’s comment on avoiding significant white space in 
the Go language?

“We have had extensive experience tracking down build and test failures caused 
by cross-language builds where a Python snippet embedded in another language, 
for instance through a SWIG invocation, is subtly and invisibly broken by a 
change in the indentation of the surrounding code.” — Rob Pike, 2012

  I personally dislike white space and prefer either mustaches or parenthesis, 
just so I know my code will still work if line feeds are stripped somehow, or 
that some piece of code is embedded or quoted in another language, which is 
what I gather Rob was talking about. However, Haskell and Python people don’t 
seem to mind, and if it saves us more keystrokes while keeping expressiveness, 
why not?

Dex

> On May 1, 2020, at 10:20 PM, George Neuner  wrote:
> 
> 
> I haven't followed all the discussion regarding a potential successor to 
> Racket.  AFAIHS, no one actually has suggested a required indentation scheme 
> ala Python, but since source indentation (and formatting in general) 
> currently is under discussion, I wanted to make known my feelings on the 
> matter.
> 
> If you don't feel strongly about source indentation, you can skip this.
> 
> George
> 
> 
>> On 5/1/2020 1:19 PM, Christopher Lemmer Webber wrote:
>> Sorawee Porncharoenwase writes:
>> 
>> >
>> >> I hate being at the mercy of whatever editor I'm stuck using.
>> >
>> >
>> > I agree with this in principle, but in practice, it's really a matter of
>> > what mainstream editors support. Editors in the past don't universally
>> > support automatic indentation, and I could imagine a criticism like
>> > "Indentation sucks, because I hate being at the mercy of whatever editor
>> > I'm stuck using." But now, automatic indentation is universal, and the
>> > criticism goes away.
>> 
>> You don't even need to imagine it... when Python was taking off, one of
>> the biggest arguments was that it forced people to learn to do
>> reasonable indentation.  Doesn't seem like as much of a good argument
>> now as I thought it was then, and that's partly because most code is
>> indented fine these days due to, as you say, good IDE support.
> 
> The indentation requirement - aka "significant whitespace" - is one of the 
> main things I dislike about Python [the other is its comprehension syntax].  
> An argument certainly can be made for advocating a readable coding style ... 
> but on principle I disagree with a language *requiring* any particular style.
> 
> 
> As it happens, I am old enough to remember when Fortran required very 
> particular formatting: worse even than Python, Fortran was designed around 
> 80-column punch cards, and for a VERY long time it was necessary that 
> particular things be placed in particular columns ... else the statement 
> would not compile.
> 
> see https://web.stanford.edu/class/me200c/tutorial_77/03_basics.html
> 
> Fortran's adherence to rigid source formatting really did not simplify the 
> compiler much at all  (actually an argument can be made that it unnecessarily 
> complicated recognizing certain constructs). And if it ever helped, it wasn't 
> necessary for long - by 1962 [Fortran was introduced in 1959] compilers were 
> able to deal with free form code.  The first version of Lisp [1961] was on 
> punch cards as well, but from the beginning Lisp never had column based 
> restrictions on source format.
> 
> Fortran ... still recognizes the old style, but ... no longer requires column 
> based formatting.  Free form source has been supported by compilers since 
> Fortran90.
> 
> Historically, there have been a handful of (higher level, non-assembly) 
> languages that had odd source formatting requirements, but none were as 
> onerous as Fortran, and none of them survived very long.  But just as Fortran 
> finally was giving up on the idea, Python came along to revive it.  [Python 
> began at about the same time Fortran90 was in committee.]
> 
> 
> Forcing programmers to do menial tasks like configuring editors to certain 
> modes [spaces vs tabs], and to manually count spaces when corresponding 
> scoped lines are too far apart to eyeball the vertical alignment is simply 
> counterproductive - there are plenty of more important things that 
> programmers should be worrying about. Programming editors having language 
> structural awareness have been around since the 80's ... there is no reason 
> ever to bake such things as indentation requirements into the language.
> 
> Just my 2 cents.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/e180703e-6e2e-ea6b-d918-b46ff4eebb07%40comcast.net.

-- 
You received this message because you are 

Re: [racket-users] Reducing parentheses without language damage.

[George Neuner]

I haven't followed all the discussion regarding a potential successor to 
Racket.  AFAIHS, no one actually has suggested a required indentation 
scheme ala Python, but since source indentation (and formatting in 
general) currently is under discussion, I wanted to make known my 
feelings on the matter.


If you don't feel strongly about source indentation, you can skip this.

George


On 5/1/2020 1:19 PM, Christopher Lemmer Webber wrote:

Sorawee Porncharoenwase writes:

>
>> I hate being at the mercy of whatever editor I'm stuck using.
>
>
> I agree with this in principle, but in practice, it's really a matter of
> what mainstream editors support. Editors in the past don't universally
> support automatic indentation, and I could imagine a criticism like
> "Indentation sucks, because I hate being at the mercy of whatever editor
> I'm stuck using." But now, automatic indentation is universal, and the
> criticism goes away.

You don't even need to imagine it... when Python was taking off, one of
the biggest arguments was that it forced people to learn to do
reasonable indentation.  Doesn't seem like as much of a good argument
now as I thought it was then, and that's partly because most code is
indented fine these days due to, as you say, good IDE support.


The indentation requirement - aka "significant whitespace" - is one of 
the main things I dislike about Python [the other is its comprehension 
syntax].  An argument certainly can be made for advocating a readable 
coding style ... but on principle I disagree with a language *requiring* 
any particular style.



As it happens, I am old enough to remember when Fortran required very 
particular formatting: worse even than Python, Fortran was designed 
around 80-column punch cards, and for a VERY long time it was necessary 
that particular things be placed in particular columns ... else the 
statement would not compile.


    see https://web.stanford.edu/class/me200c/tutorial_77/03_basics.html

Fortran's adherence to rigid source formatting really did not simplify 
the compiler much at all  (actually an argument can be made that it 
unnecessarily complicated recognizing certain constructs). And if it 
ever helped, it wasn't necessary for long - by 1962 [Fortran was 
introduced in 1959] compilers were able to deal with free form code.  
The first version of Lisp [1961] was on punch cards as well, but from 
the beginning Lisp never had column based restrictions on source format.


Fortran ... still recognizes the old style, but ... no longer requires 
column based formatting.  Free form source has been supported by 
compilers since Fortran90.


Historically, there have been a handful of (higher level, non-assembly) 
languages that had odd source formatting requirements, but none were as 
onerous as Fortran, and none of them survived very long.  But just as 
Fortran finally was giving up on the idea, Python came along to revive 
it.  [Python began at about the same time Fortran90 was in committee.]



Forcing programmers to do menial tasks like configuring editors to 
certain modes [spaces vs tabs], and to manually count spaces when 
corresponding scoped lines are too far apart to eyeball the vertical 
alignment is simply counterproductive - there are plenty of more 
important things that programmers should be worrying about. Programming 
editors having language structural awareness have been around since the 
80's ... there is no reason ever to bake such things as indentation 
requirements into the language.


Just my 2 cents.

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/e180703e-6e2e-ea6b-d918-b46ff4eebb07%40comcast.net.

Re: [racket-users] Reducing parentheses without language damage.

[Christopher Lemmer Webber]

Sorawee Porncharoenwase writes:

>>
>> I hate being at the mercy of whatever editor I'm stuck using.
>
>
> I agree with this in principle, but in practice, it's really a matter of
> what mainstream editors support. Editors in the past don't universally
> support automatic indentation, and I could imagine a criticism like
> "Indentation sucks, because I hate being at the mercy of whatever editor
> I'm stuck using." But now, automatic indentation is universal, and the
> criticism goes away.

You don't even need to imagine it... when Python was taking off, one of
the biggest arguments was that it forced people to learn to do
reasonable indentation.  Doesn't seem like as much of a good argument
now as I thought it was then, and that's partly because most code is
indented fine these days due to, as you say, good IDE support.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/87a72rshcl.fsf%40dustycloud.org.

Re: [racket-users] Reducing parentheses without language damage.

[Hendrik Boom]

On Thu, Apr 30, 2020 at 02:40:00PM -0700, Sorawee Porncharoenwase wrote:
> 
> This is Nia's parendown: https://docs.racket-lang.org/parendown/index.html

Just wondering:  Is there a way to write division if Nia's parendown is in 
effect?
There would be no problem with this if it was originally designed into the 
language,
but language add-ons give the probem of syntax-versus-name confliicts.

-- hendrik

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/20200501131750.seligwkp7zifoddu%40topoi.pooq.com.

Re: [racket-users] Reducing parentheses without language damage.

[sleepnova]

Thanks for sharing. I see "Nested parentheses" only one way to represent
tree structure. There are certainly other cleverer ways to do it. Once it
appears, the representation of the tree transform (macro) may also be
better. I'm looking forward to seeing better representation.
https://en.wikipedia.org/wiki/Tree_structure#Nested_parentheses

Sorawee Porncharoenwase  於 2020年5月1日 週五 上午5:40寫道：

> I hate being at the mercy of whatever editor I'm stuck using.
>
>
> I agree with this in principle, but in practice, it's really a matter of
> what mainstream editors support. Editors in the past don't universally
> support automatic indentation, and I could imagine a criticism like
> "Indentation sucks, because I hate being at the mercy of whatever editor
> I'm stuck using." But now, automatic indentation is universal, and the
> criticism goes away.
>
>
>> I stongly recommend that we get a language with less of a
>> parenthesis problem so that code is readable without having to haul
>> it into a specialised editor.
>>
>
> Personally, I don't find parenthesis makes code unreadable by itself. The
> rightward drift, in my opinion, is the real problem. I believe that
> `define*` that I proposed at
> https://github.com/racket/rhombus-brainstorming/issues/46 will somewhat
> mitigate the problem.
>
> In an old List I used '/' for this, so i got expressions like
>>(if a b / if c d / let s t /if s foo bar)
>>
>
> Using `/` to reduce parentheses looks nice once it's written down, but my
> concern is that it might not be easily editable. In fact, it ironically
> looks like this notation needs an extra support from editors to consider
> `/` as a delimiter.
>
> To clarify what I mean: non S-exp languages usually have a line as a unit
> of code, so editors need to support "jump to the beginning/end of line"  to
> make editing pleasant. S-exp languages in contrast has a parenthesized
> expression as a unit of code, so editors need to support "jump to a
> matching parenthesis" to make editing pleasant. In your notation, it looks
> like editors need to also support "jump to closest /" to make editing
> pleasant.
>
> Also, does it actually make code more readable? I guess I'm not accustomed
> to it, and might find it easier to read it once I am.
>
>
>> There must be some # code we could use for this (I believe one
>> has already been mentioned on this list sometime in the past year
>> os so) but this symbol tends to become *so* prevalent that it
>> should ideally feel like a single character with a dostinctieve
>> apearance.
>>
>
> This is Nia's parendown: https://docs.racket-lang.org/parendown/index.html
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/CADcuegsYr6KKeZg5sV1ocgcywnCTbi8rf_gB5_MiQG9%3D_W_cFQ%40mail.gmail.com
> 
> .
>


-- 
- sleepnova
呼叫小黃創辦人 & CEO

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CABa2-7OwuDSkXca3Of86E0uKoNgCUUCSE01S1k%3Dx1JZ80EHiXw%40mail.gmail.com.

Re: [racket-users] Reducing parentheses without language damage.

[Hendrik Boom]

On Thu, Apr 30, 2020 at 02:40:00PM -0700, Sorawee Porncharoenwase wrote:
> >
> > I hate being at the mercy of whatever editor I'm stuck using.
> 
> 
> I agree with this in principle, but in practice, it's really a matter of
> what mainstream editors support. Editors in the past don't universally
> support automatic indentation, and I could imagine a criticism like
> "Indentation sucks, because I hate being at the mercy of whatever editor
> I'm stuck using." But now, automatic indentation is universal, and the
> criticism goes away.
> 
> 
> > I stongly recommend that we get a language with less of a
> > parenthesis problem so that code is readable without having to haul
> > it into a specialised editor.
> >
> 
> Personally, I don't find parenthesis makes code unreadable by itself. The
> rightward drift, in my opinion, is the real problem. I believe that
> `define*` that I proposed at
> https://github.com/racket/rhombus-brainstorming/issues/46 will somewhat
> mitigate the problem.

Yes, rightward drift is one of the problems.  That's why I introduced '/'
in a Lispish language I implemented decades ago.

> 
> In an old List I used '/' for this, so i got expressions like
> >(if a b / if c d / let s t /if s foo bar)

If course this is a different let from the traditional, age-old one.

> >
> 
> Using `/` to reduce parentheses looks nice once it's written down, but my
> concern is that it might not be easily editable. In fact, it ironically
> looks like this notation needs an extra support from editors to consider
> `/` as a delimiter.

Yes, of course.  Whatever you use has to be ecognised as a delimiter.

> 
> To clarify what I mean: non S-exp languages usually have a line as a unit
> of code, so editors need to support "jump to the beginning/end of line"  to
> make editing pleasant. S-exp languages in contrast has a parenthesized
> expression as a unit of code, so editors need to support "jump to a
> matching parenthesis" to make editing pleasant. In your notation, it looks
> like editors need to also support "jump to closest /" to make editing
> pleasant.

In practise, you get things like

( if a (cadr foo)
/ if c
(d u / v w)
/ let s t
/ if s foo bar
)

> 
> Also, does it actually make code more readable? I guess I'm not accustomed
> to it, and might find it easier to read it once I am.

I foud it so.  Especially for large, complicared expressions involving
intermixed let's and if's.

Of course, I also adapted mu Lisp to make better advantage if the "/" syntax.

multiple let's just become tail-nested let's, without rightward drift.

(let a b
/let c a
/let e (f c)
/big expression incolving these
)

> 
> 
> > There must be some # code we could use for this (I believe one
> > has already been mentioned on this list sometime in the past year
> > os so) but this symbol tends to become *so* prevalent that it
> > should ideally feel like a single character with a dostinctieve
> > apearance.
> >
> 
> This is Nia's parendown: https://docs.racket-lang.org/parendown/index.html

That is lovely.

-- hendrik

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/20200501014133.hoyw2pksi4lpkebz%40topoi.pooq.com.

Re: [racket-users] Reducing parentheses without language damage.

[George Neuner]

On 4/30/2020 5:40 PM, Sorawee Porncharoenwase wrote:

  :
To clarify what I mean: non S-exp languages usually have a line as a 
unit of code, so editors need to support "jump to the beginning/end of 
line"  to make editing pleasant.


Actually, in the majority of programming languages there is no 
connection between program source and line grouping in an editor. 
Statement based languages define some character to be the statement 
"terminator" (or statement "separator" - yes, there is a semantic 
difference), but most often that character is the semi-colon, not 
#\return or  #\linefeed.


Racket, like Scheme and Lisp, is expression based, NOT statement based, 
and it can't do the same (at least not easily) because expressions can 
be nested arbitrarily, and they can't be limited to a single line.



S-exp languages in contrast has a parenthesized expression as a unit 
of code, so editors need to support "jump to a matching parenthesis" 
to make editing pleasant. In your notation, it looks like editors need 
to also support "jump to closest /" to make editing pleasant.


Also, does it actually make code more readable? I guess I'm not 
accustomed to it, and might find it easier to read it once I am.


Once you use Racket (or Scheme or Lisp) long enough, you cease to see 
the parentheses and instead perceive the structure of the code from its 
indentation.  Most editors will happily match parentheses and many can 
understand Scheme structure enough to properly indent things.


George

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/c49cbf7a-c66b-88ed-5e6f-489a1c075009%40comcast.net.

Re: [racket-users] Reducing parentheses without language damage.

[Sorawee Porncharoenwase]

>
> I hate being at the mercy of whatever editor I'm stuck using.


I agree with this in principle, but in practice, it's really a matter of
what mainstream editors support. Editors in the past don't universally
support automatic indentation, and I could imagine a criticism like
"Indentation sucks, because I hate being at the mercy of whatever editor
I'm stuck using." But now, automatic indentation is universal, and the
criticism goes away.


> I stongly recommend that we get a language with less of a
> parenthesis problem so that code is readable without having to haul
> it into a specialised editor.
>

Personally, I don't find parenthesis makes code unreadable by itself. The
rightward drift, in my opinion, is the real problem. I believe that
`define*` that I proposed at
https://github.com/racket/rhombus-brainstorming/issues/46 will somewhat
mitigate the problem.

In an old List I used '/' for this, so i got expressions like
>(if a b / if c d / let s t /if s foo bar)
>

Using `/` to reduce parentheses looks nice once it's written down, but my
concern is that it might not be easily editable. In fact, it ironically
looks like this notation needs an extra support from editors to consider
`/` as a delimiter.

To clarify what I mean: non S-exp languages usually have a line as a unit
of code, so editors need to support "jump to the beginning/end of line"  to
make editing pleasant. S-exp languages in contrast has a parenthesized
expression as a unit of code, so editors need to support "jump to a
matching parenthesis" to make editing pleasant. In your notation, it looks
like editors need to also support "jump to closest /" to make editing
pleasant.

Also, does it actually make code more readable? I guess I'm not accustomed
to it, and might find it easier to read it once I am.


> There must be some # code we could use for this (I believe one
> has already been mentioned on this list sometime in the past year
> os so) but this symbol tends to become *so* prevalent that it
> should ideally feel like a single character with a dostinctieve
> apearance.
>

This is Nia's parendown: https://docs.racket-lang.org/parendown/index.html

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CADcuegsYr6KKeZg5sV1ocgcywnCTbi8rf_gB5_MiQG9%3D_W_cFQ%40mail.gmail.com.

Re: [racket-users] Reducing parentheses without language damage.

[Dexter Lagan]

  No it’s not, I checked again and couldn’t reproduce the problem. Please 
ignore my earlier comment.

  I’ve been tracking a bug that causes the colouring of a part of the code as 
comment and disable parenthesis handling, and since I switch debugging on and 
off often, I assumed it was related. I’ll dig further and post the issue if I 
can find out what triggers it.

Dex

> On Apr 30, 2020, at 10:06 PM, Stephen De Gabrielle  
> wrote:
> 
> 
> 
> 
>> On Thu, 30 Apr 2020 at 20:01, Hendrik Boom  wrote:
>> [...]
>> > Also is there a programming editor that *won't* do parenthesis matching?
>> 
>> Evidently the Racket editor whan debugging is disabled,
> 
> I’m not sure that’s true.
> 
> Kind regards
> Stephen
> 
> -- 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/CAGHj7-K_AbF4jmakuSixjnY_rNwPCqYgrd-JSWOrKFjash1Cvg%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/E7008AC4-B012-4686-9244-93378E990C46%40gmail.com.

Re: [racket-users] Reducing parentheses without language damage.

[Stephen De Gabrielle]

On Thu, 30 Apr 2020 at 20:01, Hendrik Boom  wrote:

> [...]
> > Also is there a programming editor that *won't* do parenthesis matching?
>
> Evidently the Racket editor whan debugging is disabled,


I’m not sure that’s true.

Kind regards
Stephen

-- 


-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAGHj7-K_AbF4jmakuSixjnY_rNwPCqYgrd-JSWOrKFjash1Cvg%40mail.gmail.com.

Re: [racket-users] Reducing parentheses without language damage.

[Hendrik Boom]

On Thu, Apr 30, 2020 at 02:46:00PM -0400, David Storrs wrote:
> On Thu, Apr 30, 2020 at 11:16 AM Hendrik Boom 
> wrote:
> 
> > On Thu, Apr 30, 2020 at 09:36:15AM +0200, Dexter Lagan wrote:
> > >   There’s one thing I noticed: if debugging is disabled, then
> > parenthesis highlighting is also disabled (as well as other visual aids, if
> > I remember well?). The editor also feels faster because of this, but
> > navigating parentheses becomes slightly more tedious without it.
> >
> > And that's exactly the parenthesis problem.  For a language as
> > parenthesis-heavy as Scheme or Lisp, you need a
> > parenthesis-oriented editor.  DrRacket does this very well bu
> > shading the background (but apparently not all the time).  Emacs
> > does it too, in principle, but isn't reaally great at it.
> >
> 
> Not to minimize your experience but I'm speaking up simply as a
> counterpoint:  I haven't had this issue, even without Racket's equivalence
> between () [] and {}.
> 
> Also is there a programming editor that *won't* do parenthesis matching?

Evidently the Racket editor whan debugging is disabled, if  
understand Dexter Lagan correctly.

-- hendrik

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/20200430190125.4eibezfdyp3dcuds%40topoi.pooq.com.

Re: [racket-users] Reducing parentheses without language damage.

[David Storrs]

On Thu, Apr 30, 2020 at 11:16 AM Hendrik Boom 
wrote:

> On Thu, Apr 30, 2020 at 09:36:15AM +0200, Dexter Lagan wrote:
> >   There’s one thing I noticed: if debugging is disabled, then
> parenthesis highlighting is also disabled (as well as other visual aids, if
> I remember well?). The editor also feels faster because of this, but
> navigating parentheses becomes slightly more tedious without it.
>
> And that's exactly the parenthesis problem.  For a language as
> parenthesis-heavy as Scheme or Lisp, you need a
> parenthesis-oriented editor.  DrRacket does this very well bu
> shading the background (but apparently not all the time).  Emacs
> does it too, in principle, but isn't reaally great at it.
>

Not to minimize your experience but I'm speaking up simply as a
counterpoint:  I haven't had this issue, even without Racket's equivalence
between () [] and {}.

Also is there a programming editor that *won't* do parenthesis matching?

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAE8gKof3QdacuH1XoK8QftQnpVfFYWUuon0-Z%2B7oLq3JiPgx-g%40mail.gmail.com.