Re: [racket-users] Re: The case, and a proposal, for elegant syntax in #lang racket2

[Gustavo Massaccesi]

 [I remember an old discussion about this, but I can't find the message.]
For small number of clauses, case is expanded to a bunch of if. When there
are more than ¿12? it may be use a hash table or binary search. It has a
few tricks:

https://github.com/racket/racket/blob/master/racket/collects/racket/private/case.rkt

Gustavo

On Thu, Aug 22, 2019 at 3:38 PM George Neuner  wrote:

>
> On 8/21/2019 3:25 PM, Jon Zeppieri wrote:
> > Racket's `case` is an implementation of this approach:
> > http://scheme2006.cs.uchicago.edu/07-clinger.pdf
> >
> > It is not significantly complicated by `else`. And that approach was
> > created in the context of Scheme, which leaves the return value
> > unspecified when none of the tests are successful. That seems like it
> > should offer more opportunities for optimization, but I don't think
> > this approach is any less efficient when the unsuccessful result is
> > specified as # (as it is in Racket) than when it is not.
> >
> > - Jon
>
> Thanks for the pointer!
>
> 'case' in Scheme is an interesting challenge for compilation because it
> can involve dispatching on multiple types, each having its own
> comparison ordering.  I would hope that Racket leverages generic table
> searches where possible - depending on the use, generating a complete
> static dispatch routine everywhere can result in explosive growth of the
> code.  [Not that I've seen this happen, but I haven't had occasion to
> experiment in Racket with extremely large or complicated 'case'
> constructs.]
>
> 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/a8dd208d-dd3f-a2a7-3d20-3c1027932ac9%40comcast.net
> .
>

-- 
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/CAPaha9PvohKnSZwsnF8gn8hOKejQMpCCVWVPiNmZuQOjO2Odzw%40mail.gmail.com.

Re: [racket-users] Re: The case, and a proposal, for elegant syntax in #lang racket2

[George Neuner]

On 8/21/2019 3:25 PM, Jon Zeppieri wrote:

Racket's `case` is an implementation of this approach:
http://scheme2006.cs.uchicago.edu/07-clinger.pdf

It is not significantly complicated by `else`. And that approach was
created in the context of Scheme, which leaves the return value
unspecified when none of the tests are successful. That seems like it
should offer more opportunities for optimization, but I don't think
this approach is any less efficient when the unsuccessful result is
specified as # (as it is in Racket) than when it is not.

- Jon


Thanks for the pointer!

'case' in Scheme is an interesting challenge for compilation because it 
can involve dispatching on multiple types, each having its own 
comparison ordering.  I would hope that Racket leverages generic table 
searches where possible - depending on the use, generating a complete 
static dispatch routine everywhere can result in explosive growth of the 
code.  [Not that I've seen this happen, but I haven't had occasion to 
experiment in Racket with extremely large or complicated 'case'  
constructs.]


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/a8dd208d-dd3f-a2a7-3d20-3c1027932ac9%40comcast.net.

Re: [racket-users] Re: The case, and a proposal, for elegant syntax in #lang racket2

[Jon Zeppieri]

On Wed, Aug 21, 2019 at 2:43 PM George Neuner  wrote:
>
>
> On 8/21/2019 1:13 PM, Gustavo Massaccesi wrote:
> > The expander in racket adds something equivalent to
> > [else (void)]
> > if there is no else clause. (Try an example with the Macro Stepper.)
> > So an explicit else clause would not change the speed of the programs.
> >
> > In some cases the compiler can prove that the else part is not
> > necessary and drop it, Also, I think that the compiler in RacketCS can
> > notice that it has no side effects and also drop it if the result is
> > ignored (but I'm not 100% sure).
>
> Yes.  But in most cases, it is impossible to prove that the 'else' is
> unnecessary.

Yes, but this is why `else` doesn't slow anything down. Unless the
compiler can prove that it's unnecessary, an `else` clause going to be
there whether you write it explicitly or not, which is exactly what
Gustavo wrote above.


> And as I mentioned in my reply to Hendrick, 'cond' is
> pretty simple, but an 'else' - implicit or explicit - can screw up
> optimizing tests in a 'case'.
>

Racket's `case` is an implementation of this approach:
http://scheme2006.cs.uchicago.edu/07-clinger.pdf

It is not significantly complicated by `else`. And that approach was
created in the context of Scheme, which leaves the return value
unspecified when none of the tests are successful. That seems like it
should offer more opportunities for optimization, but I don't think
this approach is any less efficient when the unsuccessful result is
specified as # (as it is in Racket) than when it is not.

- Jon

-- 
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/CAKfDxxxCMFHoC1%2B14VosKdeqOeg-dKc%2B3_nH-hjMf2JWjfxXOA%40mail.gmail.com.

Re: [racket-users] Re: The case, and a proposal, for elegant syntax in #lang racket2

[Chris Stephenson]

Yes this year we put a lot of effort into reducing any kind of change 
between the two halves of the course, even changes of approach independent 
of language

This worked well for students. the first 5 days or so was a slightly 
enhanced version of Bootstrapworld Algebra. 

However, we wanted more on logical operators and on symbolic values, so we 
expanded the exercise a that has a butterfly trying to stay out of danger 
in a garden to include well in the middle of the garden. So the butterfly 
has to stay within the garden and outside the well. Then the size of the 
garden and the size and position of the well become variables...  This was 
a good preparation for the second half in which students designed a game 
from the ground up using 2htdp/universe.

Our "killer app" was to introduce vector arithmetic the moment we had 
structs. We did the math and the programming together and built a set of 
vector arithmetic functions /vector addition subtraction, vector/scalar 
multiplication, dot product, magnitude)

Then.. we introduced an object struct that had an imgae and three vectors - 
location, velocity acceleration. Once the students have developed functions 
to move and draw thewse objects they have a very powerful and simple tool 
in their hands.

Updating an object is like this

location, velocity, acceleration -> location+velocity, 
velocity+acceleration, acceleration  (all vector arithmetic, of course)

We introduced structs for the first time on Sunday morning. By Monday 
evening they had objects moving in parabolic arcs on the screen under the 
effect of "gravity"

This created a "wow" effect and students were then able to produce quite 
impressive games by the end of the course on Saturday sfternoon.

The "wow" effect is really important...It gave students confidence.

I am not sure how easy this would have been in another language 
environment. the 2htdp/universe framework and the design recipe certainly 
were very important.

By the end of the 2 weeks even the most stalwart previous programmers had 
been converted to the benefits of the design recipe. Ad most of the newbies 
had produced quite sophisticated games far from the standard form provided 
for them in the first 5 days.

Of the difficulties we faced with students, syntax errors were the most 
common, missing else clauses and errors associated with implicit begin end 
were the most intractable.

Our students face the additional difficulty that all error message are in a 
foreign language (English) that many of them do not know well, some know 
hardly at all 

The only language trick we did was to use a  macro for struct definition so 
that every struct automatically had an inspector and so structs printed out 
nicely and EXAMPLE (ie check-expect) worked for structs. Except we called 
it ÖRNEK (which is example in Turkish) 

CS


On Wednesday, August 21, 2019 at 9:20:14 PM UTC+3, cwebber wrote:
>
> Chris Stephenson writes: 
>
> > Parantheses and learners - experience with 14-18 year olds 
> > 
> > I have just finished giving a two week intensive course to 14-18 year 
> olds 
> > at the Mathematics Village near Ephesus in Turkey 
>
> Very interesting email all around! 
>
> > (a) A change of syntax between the two halves had proved confusing for 
> > students 
>
> You actually touched on something that has been at the back of my mind 
> for a while.  Else where in this discussion: 
>
> Matthew Flatt writes: 
>
> > At Sat, 20 Jul 2019 18:07:40 -0400, Christopher Lemmer Webber wrote: 
>
> >>  - Are people happy?  Is this meeting their needs?  Get community 
> input. 
> >>At this point, if the community is happy enough, and if it appears 
> >>that *newcomers* (including in the educational space) are happy 
> >>enough, now we can focus on switching the core Racket system over 
> >>to ~Honu-as-the-basis. 
> > 
> > I agree that the process would have to be something like that. 
> > 
> > I'm skeptical of starting with teaching languages in the sense of BSL, 
> > ISL, and ASL. That sets up some different problems --- ones that Pyret 
> > has directly addressed/explored. (Obviously, we should pay attention to 
> > Pyret.) 
>
> I've been thinking about this, and I think that it's hard enough *for 
> me* to jump between different syntaxes.  If there was a switch to ~Honu 
> as being the default, it really should be ~Honu everywhere... not ~Honu 
> in one place and Pyret like syntax in the other (or vice versa).  That 
> kind of context switch is really hard. 
>
> In my experience, the most empowering thing for students is "being able 
> to write programs that do cool things".  If we use different syntaxes, I 
> think this will feel like the worlds between a "beginner's language" and 
> the "main world of Racket" will feel like too much of a jump... I know 
> *I* get intimidated by a shift in syntax, and I'm sure that for 
> students, it's even harder. 
>
> Gerald Sussman explained Python's success, and the reason for the 

Re: [racket-users] Re: The case, and a proposal, for elegant syntax in #lang racket2

[George Neuner]

On 8/21/2019 1:13 PM, Gustavo Massaccesi wrote:

The expander in racket adds something equivalent to
    [else (void)]
if there is no else clause. (Try an example with the Macro Stepper.) 
So an explicit else clause would not change the speed of the programs.


In some cases the compiler can prove that the else part is not 
necessary and drop it, Also, I think that the compiler in RacketCS can 
notice that it has no side effects and also drop it if the result is 
ignored (but I'm not 100% sure).


Yes.  But in most cases, it is impossible to prove that the 'else' is 
unnecessary.  And as I mentioned in my reply to Hendrick, 'cond' is 
pretty simple, but an 'else' - implicit or explicit - can screw up 
optimizing tests in a 'case'.


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/931ae453-8d87-5ee1-f8e1-ab23466a3647%40comcast.net.

Re: [racket-users] Re: The case, and a proposal, for elegant syntax in #lang racket2

[George Neuner]

On 8/21/2019 11:01 AM, Hendrik Boom wrote:

On Wed, Aug 21, 2019 at 10:52:57AM -0400, George Neuner wrote:

> 
> I don't like the idea of compulsory 'else' - for 'cond' or 'case' or

> 'match' or ...
> 
> 'Else' isn't needed if all input cases are covered, but in almost all

> real world uses, the compiler is not able to prove the 'else' is
> unneeded so as to prevent emitting code for it.  And depending on how
> the compiler structures the tests (cond is simple, case less so),
> adding 'else' into the mix may increase execution time as well.

What about treating a missing 'else' as a run-time error if and only
if control gets that far.

That would require code that intends nothing to be done to have an
explicit 'else' saying so.

Except for notation, this would seem to meet your demands for semantic
expressibility.


Not at all.  Obviously, I'm not a beginner:  when I choose to leave out 
'else', it is not a mistake - I intend that nothing should happen if no 
explicit case was matched.  An implicit runtime error would represent 
completely different semantics ... well defined maybe, but completely 
different nonetheless.


More importantly, the code generation consequences exist regardless of 
whether the 'else' is explicit or implicit:  it requires extra tests 
which may affect the overall structuring and performance of the [set of] 
tests.  As I alluded to above, 'cond' wouldn't be affected very much 
because it compiles quite straightforwardly into a series of 'if's' that 
correspond directly to the source.  However 'case' is a different matter.


I admit that I haven't looked to see how Racket compiles 'case' ... and 
there are many possible variations due to the flexibility of the 
construct.  However, I have some non-Scheme-related experience with 
compiler implementation, and in general, 'case' presents many more 
opportunities wrt 'cond' to generate better optimized, out-of-order (wrt 
the source) testing.  Requiring an implicit 'else' introduces 
considerable extra complexity, and may (not necessarily will, but may) 
hamper generating an optimal test sequence for the explicit cases.



This is something that may become more apparent with the switch to 
RacketCS because the Chez compiler does much more optimization and 
produces native code.  From a compiler implementor's view, the surface 
syntax of the language largely is irrelevant - it impacts introspection 
and metaprogramming, but quite a lot of syntax related stuff has little 
or no effect on generated code.  However, some of the things that have 
been mentioned (at various times) have very real consequences for 
generated code: things like automatic currying, 'statement' vs 
'expression', arbitrary numbers of return values, implicit 'else', 
generic stream access to (raw) collections, generic port access to 
strings, N-dimension arrays vs vectors of vectors, incremental typing, 
etc.  It's the features themselves which affect the generated code that 
I worry about much more than what syntax is used.



That said, I *like* the Lispy syntax.  I do think there are some 
opportunities to reduce the number of parentheses needed, but the 
consistent prefix nature of S-exprs is - I think - what makes Racket 
(and Scheme and Lisp) *easier* to learn than many other languages. 
Remembering all the operator precedences in infix languages is a PITA.


I dislike in some FPLs remembering that I *must* use parentheses in 
certain cases, while in other cases they are optional (or even 
disallowed).  I loathe significant whitespace (indentation) as in Python 
- counting spaces is just as stupid as counting parentheses [and yes, a 
decent editor can address either problem, but jeez ... even Fortran 
dropped its indentation requirements decades ago].


I don't think "popularity" is a very good reason to change language 
syntax - but as long as S-expr Racket remains a viable, completely 
*supported*, language, then I don't have a problem with development of a 
parallel infix version.


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/1ebfcd3b-80da-1abf-9dff-e2a3dec62f20%40comcast.net.

Re: [racket-users] Re: The case, and a proposal, for elegant syntax in #lang racket2

[Christopher Lemmer Webber]

Christopher Lemmer Webber writes:

> Gerald Sussman explained Python's success, and the reason for the switch
> from Scheme and SICP to a Python based curriculum, as being because
> Python had for whatever reason libraries that allowed students to be
> able to lego together examples very quickly.  I've made the case that
> Racket is the Python of lisps... even if we aren't continuing to have a
> lispy syntax by default, we should realize that this is a strength we
> don't want to lose.  If there's a syntax gulf between the restricted
> student languages and the "main" language, we'll diminish that value
> we're providing to newcomers.

More on that:

  
https://cemerick.com/2009/03/24/why-mit-now-uses-python-instead-of-scheme-for-its-undergraduate-cs-program/

Though I also saw him explain this in a talk, I forget which one, maybe
it was:

  https://vimeo.com/151465912

... but I don't have time to review again.

-- 
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/87y2zmwf6v.fsf%40dustycloud.org.

Re: [racket-users] Re: The case, and a proposal, for elegant syntax in #lang racket2

[Christopher Lemmer Webber]

Chris Stephenson writes:

> Parantheses and learners - experience with 14-18 year olds
>
> I have just finished giving a two week intensive course to 14-18 year olds
> at the Mathematics Village near Ephesus in Turkey

Very interesting email all around!

> (a) A change of syntax between the two halves had proved confusing for
> students

You actually touched on something that has been at the back of my mind
for a while.  Else where in this discussion:

Matthew Flatt writes:

> At Sat, 20 Jul 2019 18:07:40 -0400, Christopher Lemmer Webber wrote:

>>  - Are people happy?  Is this meeting their needs?  Get community input.
>>At this point, if the community is happy enough, and if it appears
>>that *newcomers* (including in the educational space) are happy
>>enough, now we can focus on switching the core Racket system over
>>to ~Honu-as-the-basis.
>
> I agree that the process would have to be something like that.
>
> I'm skeptical of starting with teaching languages in the sense of BSL,
> ISL, and ASL. That sets up some different problems --- ones that Pyret
> has directly addressed/explored. (Obviously, we should pay attention to
> Pyret.)

I've been thinking about this, and I think that it's hard enough *for
me* to jump between different syntaxes.  If there was a switch to ~Honu
as being the default, it really should be ~Honu everywhere... not ~Honu
in one place and Pyret like syntax in the other (or vice versa).  That
kind of context switch is really hard.

In my experience, the most empowering thing for students is "being able
to write programs that do cool things".  If we use different syntaxes, I
think this will feel like the worlds between a "beginner's language" and
the "main world of Racket" will feel like too much of a jump... I know
*I* get intimidated by a shift in syntax, and I'm sure that for
students, it's even harder.

Gerald Sussman explained Python's success, and the reason for the switch
from Scheme and SICP to a Python based curriculum, as being because
Python had for whatever reason libraries that allowed students to be
able to lego together examples very quickly.  I've made the case that
Racket is the Python of lisps... even if we aren't continuing to have a
lispy syntax by default, we should realize that this is a strength we
don't want to lose.  If there's a syntax gulf between the restricted
student languages and the "main" language, we'll diminish that value
we're providing to newcomers.

-- 
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/87zhk2wfc5.fsf%40dustycloud.org.

Re: [racket-users] Re: The case, and a proposal, for elegant syntax in #lang racket2

[Gustavo Massaccesi]

The expander in racket adds something equivalent to
[else (void)]
if there is no else clause. (Try an example with the Macro Stepper.) So an
explicit else clause would not change the speed of the programs.

In some cases the compiler can prove that the else part is not necessary
and drop it, Also, I think that the compiler in RacketCS can notice that it
has no side effects and also drop it if the result is ignored (but I'm not
100% sure).

Gustavo

-- 
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/CAPaha9OsXr%3DYxKxPFcKC-sCK-JuATDWR4b6NpxHooVsirj6aQw%40mail.gmail.com.

Re: [racket-users] Re: The case, and a proposal, for elegant syntax in #lang racket2

[Shriram Krishnamurthi]

I agree that struct-copy is almost essential. That's why it's baked into
the syntax of Pyret (where we're very sparing in what we provide syntactic
surface to). It might be better to just import struct-copy and leave the
language-level intact, in the future (if not create a language level that
reflects this).

On Wed, Aug 21, 2019 at 8:21 AM Chris Stephenson 
wrote:

> Hi Shriram
>
> Nice to hear from you!
>
> In a course for 14-18 year olds where we are rigorously enforcing the
> design recipe, the overwhelming majority of errors are, indeed, syntax
> errors. (Except for missiing-else conds, of course)
>
> So that was what I meant. Pyret syntax errors are reported confusingly.
> Infix just messes things up. And in my view prefix does not present a
> problem for students
>
> Conversion: Indeed we did find an old version of Reactive in Racket, by
> which time we had already translated the newer Pyret version into Turkish
> and also introduced some experience based changes of our own. So what we
> had in our hands had diverged in several ways from the old Racket version.
> So we were merging the changes we had made and also translating the Turkish
> langauge documentation from Pyret to Racket.
>
> I understand the critcisms for using lang racket rather than advanced
> student in the second week , after using beginner in the first.   Given
> that advanced student also accepts else-less conds (the worst source of
> hard-to-find errors) and we wanted to use the new Racket struct syntax (and
> struct-copy which can make HtDP universe code much shorter) we were pushed
> in that direction. I dont think we paid any other penalty for using lang
> racket. If we had had struct and struct-copy in advanced student, we would
> have used it. I am sure that is something we could have solved ourselves
> ... but time...
>
> Thanks for your views.
>
>
> Chris
>
>
>
>
> On Wednesday, August 21, 2019 at 2:38:55 PM UTC+3, sk wrote:
>>
>>
>>> Pyret was a pain. Error messages were not clear and the whole change
 confused students.

>>>
>>> Can you elaborate more on this? My personal experience with Pyret is
>>> that it has an exceptionally good error message, except when an internal
>>> error occurs (which should not happen).
>>>
>>
>> IMO, Pyret's *parse* errors are terrible. To some extent they are an
>> unavoidable consequence of infix, but it doesn't matter: parse errors just
>> suck, even for me, even today, even as one of the three longest-running
>> Pyret programmers.
>>
>> The run-time errors are (again IMO) much better than Racket's.
>>
>> Chris, FYI, Bootstrap:Reactive *was* in Racket to begin with, so there
>> may not have been a need to "convert" it…
>>
>> Shriram
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Racket Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/racket-users/ewWuCvbe93k/unsubscribe.
> To unsubscribe from this group and all its topics, 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/bae23873-6837-415c-97ff-d7c0879873ad%40googlegroups.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/CAJUf2yRmHLWccb_TWW0WTcgsEFEK%2BNwn7aK7i49yAD0QfB74ZQ%40mail.gmail.com.

Re: [racket-users] Re: The case, and a proposal, for elegant syntax in #lang racket2

[Hendrik Boom]

On Wed, Aug 21, 2019 at 10:52:57AM -0400, George Neuner wrote:

> 
> I don't like the idea of compulsory 'else' - for 'cond' or 'case' or
> 'match' or ...
> 
> 'Else' isn't needed if all input cases are covered, but in almost all
> real world uses, the compiler is not able to prove the 'else' is
> unneeded so as to prevent emitting code for it.  And depending on how
> the compiler structures the tests (cond is simple, case less so),
> adding 'else' into the mix may increase execution time as well.

What about treating a missing 'else' as a run-time error if and only 
if control gets that far.

That would require code that intends nothing to be done to have an 
explicit 'else' saying so.

Except for notation, this would seem to meet your demands for semantic 
expressibility.

-- 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/20190821150121.u46ng3uogxxg5v6s%40topoi.pooq.com.

Re: [racket-users] Re: The case, and a proposal, for elegant syntax in #lang racket2

[Hendrik Boom]

On Wed, Aug 21, 2019 at 02:55:46AM -0700, Chris Stephenson wrote:
> Parantheses and learners - experience with 14-18 year olds
...
...
> 
> Do we have parenthesis problems?
> 
> Yes. Worse for students with previous programming experience. We solved 
> them by educating our students in the clues given by drRacket - colouring 
> matching parenthesis. But the most useful trick we taught is to select the 
> whole function and use tab to autoformat it. This immediately makes 
> parenthesis errors obvious. Make of that what you will. Does that mean that 
> an indentation based format would be better? I am not sure.

There are three things here:

 * The notation the language uses for nesting
 * The visual appearance of the code
 * The intentions of the programmer

The problem exists when these conflict.

The solution exists when the programmer can see that his intentions to 
not match the code.

Autoformatting the function accomplishes this by making the appearance 
match the language's notation.  Especially if it's easy to do.
Letting the editor signal mismatches between indentation and semantics 
is also effective.
Colouring the brackets helps for bracket clusters within a line.

Hand-indenting (as in Python) also accomplishes this, but is more work.

But an additional effective technique is to enable notation for 
tail-nesting parentheses, so there are fewer physical parentheses to 
match up.

e.g. (a b ; c d ; e f) for (a b (c d (e d)))

Or 
( a b
; c d
; e f)

but Racket would need another character than ';' for this.  Are there 
any left?

-- 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/20190821145714.e6ipvxvppvkxn3y3%40topoi.pooq.com.

Re: [racket-users] Re: The case, and a proposal, for elegant syntax in #lang racket2

[Chris Stephenson]

Hi Shriram

Nice to hear from you!

In a course for 14-18 year olds where we are rigorously enforcing the 
design recipe, the overwhelming majority of errors are, indeed, syntax 
errors. (Except for missiing-else conds, of course)

So that was what I meant. Pyret syntax errors are reported confusingly. 
Infix just messes things up. And in my view prefix does not present a 
problem for students

Conversion: Indeed we did find an old version of Reactive in Racket, by 
which time we had already translated the newer Pyret version into Turkish 
and also introduced some experience based changes of our own. So what we 
had in our hands had diverged in several ways from the old Racket version. 
So we were merging the changes we had made and also translating the Turkish 
langauge documentation from Pyret to Racket.  

I understand the critcisms for using lang racket rather than advanced 
student in the second week , after using beginner in the first.   Given 
that advanced student also accepts else-less conds (the worst source of 
hard-to-find errors) and we wanted to use the new Racket struct syntax (and 
struct-copy which can make HtDP universe code much shorter) we were pushed 
in that direction. I dont think we paid any other penalty for using lang 
racket. If we had had struct and struct-copy in advanced student, we would 
have used it. I am sure that is something we could have solved ourselves 
... but time...

Thanks for your views. 


Chris




On Wednesday, August 21, 2019 at 2:38:55 PM UTC+3, sk wrote:
>
>
>> Pyret was a pain. Error messages were not clear and the whole change 
>>> confused students.
>>>
>>
>> Can you elaborate more on this? My personal experience with Pyret is that 
>> it has an exceptionally good error message, except when an internal 
>> error occurs (which should not happen).
>>
>
> IMO, Pyret's *parse* errors are terrible. To some extent they are an 
> unavoidable consequence of infix, but it doesn't matter: parse errors just 
> suck, even for me, even today, even as one of the three longest-running 
> Pyret programmers. 
>
> The run-time errors are (again IMO) much better than Racket's.
>
> Chris, FYI, Bootstrap:Reactive *was* in Racket to begin with, so there 
> may not have been a need to "convert" it…
>
> Shriram
>

-- 
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/bae23873-6837-415c-97ff-d7c0879873ad%40googlegroups.com.

Re: [racket-users] Re: The case, and a proposal, for elegant syntax in #lang racket2

[Shriram Krishnamurthi]

>
>
> Pyret was a pain. Error messages were not clear and the whole change
>> confused students.
>>
>
> Can you elaborate more on this? My personal experience with Pyret is that
> it has an exceptionally good error message, except when an internal
> error occurs (which should not happen).
>

IMO, Pyret's *parse* errors are terrible. To some extent they are an
unavoidable consequence of infix, but it doesn't matter: parse errors just
suck, even for me, even today, even as one of the three longest-running
Pyret programmers.

The run-time errors are (again IMO) much better than Racket's.

Chris, FYI, Bootstrap:Reactive *was* in Racket to begin with, so there may
not have been a need to "convert" it…

Shriram

-- 
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/CAJUf2ySks8FFn6X9vuce_61dsnO6JbmGQetJXQ3ATGv5V5imjA%40mail.gmail.com.

Re: [racket-users] Re: The case, and a proposal, for elegant syntax in #lang racket2

[Sorawee Porncharoenwase]

Pyret was a pain. Error messages were not clear and the whole change
> confused students.
>

Can you elaborate more on this? My personal experience with Pyret is that
it has an exceptionally good error message, except when an internal
error occurs (which should not happen).

Two language features caused us trouble, being the cause of impenetrable
> bugs in student code:
>

>
(a) Implicit begin .. end in function body. I have been writing Scheme for
> 20 years, and I **didn't know this existed**, always writing begin .. end
> in the very rare cases it was needed.
>

> Beginner Student (imho correctly) treats this as an error. I would be
> happy if advanced Racket also treated it as an error. You can end up with
> bizarre results if it is allowed and you don't notice what you have done.
> It allows, encourages even, paranthesis errors.
>

Well, why do your students use `#lang racket` rather than student languages?

And in my opinion, imposing students' programming environment constraints
to professional programming environment is probably not a good idea. There
are people who use `#lang racket` in imperative style. Forcing them to
write `begin` everywhere will just cause a hassle.

Pyret has this feature, by the way.


> (b)  Conds allowed without else. Even beginner student allows this. It
> causes bugs. In htdp/universe you can end up with a void universe or a void
> somewhere in univers. the error emerges a long distance in space and time
> from the code that causes it. Make else clauses compulsory.
>

A lot of people agree with you. Here's a (pre-) RFC on the issue:
https://github.com/racket/racket2-rfcs/issues/39

-- 
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/CADcuegtY-G1Xbe34Hs7fD4Yj36%2BOX86rKVVWi%3DgLnUx54eUT6A%40mail.gmail.com.

Re: [racket-users] Re: The case, and a proposal, for elegant syntax in #lang racket2

[Chris Stephenson]

Parantheses and learners - experience with 14-18 year olds

I have just finished giving a two week intensive course to 14-18 year olds 
at the Mathematics Village near Ephesus in Turkey

The course is based on Bootstrapworld Algebra and Reactive. Internet is 
very poor in the village, so we cannot use the web based WeScheme versiosn 
of the course(s).

We have converted  the Pyret language of the Reactive course to Racket for 
two reasons:

(a) A change of syntax between the two halves had proved confusing for 
students

(b) We don't have an offline Pyret, we had found online to be unusable in 
ptractice with our flaky internet connections and setting up a local server 
just looked to be too much work.

So we have a variety of experience with our 14-18 year olds, Beginners 
Language Racket, Pyret, #lang racket with structs.

Do we have parenthesis problems?

Yes. Worse for students with previous programming experience. We solved 
them by educating our students in the clues given by drRacket - colouring 
matching parenthesis. But the most useful trick we taught is to select the 
whole function and use tab to autoformat it. This immediately makes 
parenthesis errors obvious. Make of that what you will. Does that mean that 
an indentation based format would be better? I am not sure.

We certainly did *not* see any benefit from giving the second week in 
indentation based Pyret, as we did three years ago. Pyret was a pain. Error 
messages were not clear and the whole change confused students. Including 
students who had used Python, because the syntax looked familiar but the 
underlying language was different - being functional.

Other problems?

Two language features caused us trouble, being the cause of impenetrable 
bugs in student code:

(a) Implicit begin .. end in function body. I have been writing Scheme for 
20 years, and I **didn't know this existed**, always writing begin .. end 
in the very rare cases it was needed.

Beginner Student (imho correctly) treats this as an error. I would be happy 
if advanced Racket also treated it as an error. You can end up with bizarre 
results if it is allowed and you don't notice what you have done. It 
allows, encourages even, paranthesis errors. 

(b)  Conds allowed without else. Even beginner student allows this. It 
causes bugs. In htdp/universe you can end up with a void universe or a void 
somewhere in univers. the error emerges a long distance in space and time 
from the code that causes it. Make else clauses compulsory.

That's my two cents worth. 

  

On Saturday, August 17, 2019 at 9:11:57 PM UTC+3, Dario Maiocchi wrote:
>
> HI all, 
>
> I would personally be unhappy if in racketlang2 we would remove the  (). I 
> don't think they represent a real issue. 
>
> Just to share my personal experience a professional programmer. I learned 
> clojure  like 7 months ago and now I'm learning racketlang and  I never 
> felt the () as a barrier.
>
> best
>
> Am Freitag, 26. Juli 2019 03:42:14 UTC+2 schrieb Greg Hendershott:
>>
>> > I've taught the exact same material at the start of a 3rd year CS PL 
>> > course, and the students there didn't find the syntax as easy as one 
>> would 
>> > hope for students with that much CS “experience”. In fact, 
>> unsurprisingly, 
>> > many find the syntax as hard as expected for having trained on very 
>> > different syntaxes (especially when they are unclear about the 
>> semantics 
>> > that were attached to those syntaxes). Although the switch to teaching 
>> the 
>> > start of the course with literally the same materials, with the 
>> students 
>> > knowing that, seems to have reduced resistance substantially 
>> (presumably 
>> > they don't want to be seen as complaining about something 1st year 
>> > humantities students are fine with). 
>>
>> This makes me wonder if some experienced programmers dislike simple 
>> syntax, not just because it is unfamiliar to them, but also because it 
>> is too simple to serve as an effective in-group filter. If humanities 
>> students are comfortable, we must raise the barrier to entry. ;) 
>>
>>
>> p.s. I just now stumbled across the Iron Ring obtained from the Ritual 
>> of the Calling of an Engineer. Probably everyone has heard of this 
>> except me, but if anyone hasn't: 
>>
>>   https://en.wikipedia.org/wiki/Ritual_of_the_Calling_of_an_Engineer 
>>
>

-- 
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/614d8a6a-78d4-468f-8941-c93d4b060efe%40googlegroups.com.

Re: [racket-users] Re: The case, and a proposal, for elegant syntax in #lang racket2

[Dario Maiocchi]

HI all, 

I would personally be unhappy if in racketlang2 we would remove the  (). I 
don't think they represent a real issue. 

Just to share my personal experience a professional programmer. I learned 
clojure  like 7 months ago and now I'm learning racketlang and  I never 
felt the () as a barrier.

best

Am Freitag, 26. Juli 2019 03:42:14 UTC+2 schrieb Greg Hendershott:
>
> > I've taught the exact same material at the start of a 3rd year CS PL 
> > course, and the students there didn't find the syntax as easy as one 
> would 
> > hope for students with that much CS “experience”. In fact, 
> unsurprisingly, 
> > many find the syntax as hard as expected for having trained on very 
> > different syntaxes (especially when they are unclear about the semantics 
> > that were attached to those syntaxes). Although the switch to teaching 
> the 
> > start of the course with literally the same materials, with the students 
> > knowing that, seems to have reduced resistance substantially (presumably 
> > they don't want to be seen as complaining about something 1st year 
> > humantities students are fine with). 
>
> This makes me wonder if some experienced programmers dislike simple 
> syntax, not just because it is unfamiliar to them, but also because it 
> is too simple to serve as an effective in-group filter. If humanities 
> students are comfortable, we must raise the barrier to entry. ;) 
>
>
> p.s. I just now stumbled across the Iron Ring obtained from the Ritual 
> of the Calling of an Engineer. Probably everyone has heard of this 
> except me, but if anyone hasn't: 
>
>   https://en.wikipedia.org/wiki/Ritual_of_the_Calling_of_an_Engineer 
>

-- 
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/f7776433-d445-45cc-9da1-87ae29943806%40googlegroups.com.

Re: [racket-users] Re: The case, and a proposal, for elegant syntax in #lang racket2

[Hendrik Boom]

On Thu, Jul 25, 2019 at 09:42:10PM -0400, Greg Hendershott wrote:
> 
> This makes me wonder if some experienced programmers dislike simple
> syntax, not just because it is unfamiliar to them, but also because it
> is too simple to serve as an effective in-group filter. If humanities
> students are comfortable, we must raise the barrier to entry. ;)

the real question is, "What is simple syntax?"
or, "Who or what finds it simple?"

Human beings find natural language really simple to use.

Computer programs find natural language really hard, and like recursion 
and parentheses.

Natural languages use a wide variety of syntaactic forms and even have 
practical limits on nesting depth.

-- 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/20190726201907.bydp3sasavgfkk2z%40topoi.pooq.com.

Re: [racket-users] Re: The case, and a proposal, for elegant syntax in #lang racket2

[Greg Hendershott]

> I've taught the exact same material at the start of a 3rd year CS PL
> course, and the students there didn't find the syntax as easy as one would
> hope for students with that much CS “experience”. In fact, unsurprisingly,
> many find the syntax as hard as expected for having trained on very
> different syntaxes (especially when they are unclear about the semantics
> that were attached to those syntaxes). Although the switch to teaching the
> start of the course with literally the same materials, with the students
> knowing that, seems to have reduced resistance substantially (presumably
> they don't want to be seen as complaining about something 1st year
> humantities students are fine with).

This makes me wonder if some experienced programmers dislike simple
syntax, not just because it is unfamiliar to them, but also because it
is too simple to serve as an effective in-group filter. If humanities
students are comfortable, we must raise the barrier to entry. ;)


p.s. I just now stumbled across the Iron Ring obtained from the Ritual
of the Calling of an Engineer. Probably everyone has heard of this
except me, but if anyone hasn't:

  https://en.wikipedia.org/wiki/Ritual_of_the_Calling_of_an_Engineer

-- 
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/87a7d1mv0t.fsf%40greghendershott.com.

Re: [racket-users] Re: The case, and a proposal, for elegant syntax in #lang racket2

[Alexander Shopov]

To whoever will implement a new syntax forRacket, may I give the following
resources. I really hope they are widely known and I am just stating the
obvious common knowledge.

There have been previous attempts of using an alternative syntax:
 * M-expresisons - dating to the original McCarthy Lisp paper
http://www-formal.stanford.edu/jmc/recursive.pdf,
https://en.wikipedia.org/wiki/M-expression#cite_note-3
 * I-expressions - https://srfi.schemers.org/srfi-49/srfi-49.html

On a semi related note: I would also recomment this recent (2017) lecture
by Guy Steele: It's Time for a New Old Language
https://www.youtube.com/watch?v=dCuZkaaou0Q on the most popular programming
language in computer science (definitely not Scheme as it has no compiler,
interpreter or specification)

Kind regards:
al_shopov



На ср, 24.07.2019 г. в 22:47 ч. Hendrik Boom 
написа:

> On Wed, Jul 24, 2019 at 08:06:18AM -0700, Will Jukes wrote:
> >- On the other hand, parenthesized syntax is a natural way of
> conveying
> >the difference between statements and expressions, and that's lost in
> >moving away from parenthesized syntax, so there's some trade-off
> there.
>
> Is there a difference between statements and expressions?  Other than
> statements returning a data type that takes no space to represent?
>
> -- 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/20190724204753.dwvr6ji5nzbfd7jr%40topoi.pooq.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/CAP6f5M%3Dnc41vLTqT9z-Rz%2B2AZgLrMfZNfLHUhJg6ta9o_fyfAw%40mail.gmail.com.

Re: [racket-users] Re: The case, and a proposal, for elegant syntax in #lang racket2

[Hendrik Boom]

On Wed, Jul 24, 2019 at 08:06:18AM -0700, Will Jukes wrote:
>- On the other hand, parenthesized syntax is a natural way of conveying 
>the difference between statements and expressions, and that's lost in 
>moving away from parenthesized syntax, so there's some trade-off there.

Is there a difference between statements and expressions?  Other than 
statements returning a data type that takes no space to represent?

-- 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/20190724204753.dwvr6ji5nzbfd7jr%40topoi.pooq.com.

Re: [racket-users] Re: The case, and a proposal, for elegant syntax in #lang racket2

[gfb]

On Wednesday, July 24, 2019 at 1:40:25 PM UTC-4, sk wrote:
>
> To riff on Will's message:
>
> In the Bootstrap:Algebra 
>  materials, we use 
> Racket syntax because it's a powerful pedagogic device. Recently, for 
> various reasons, we've ported this over to another language called Pyret 
> (while also maintaining the Racket version; it hasn't been deprecated). 
>
> Pyret has an almost-traditional infix syntax. It turns out infix is 
> actually much worse for the concepts we try to teach in that curriculum. Of 
> course it can be done, but the irregularity of infix — which is barely 
> noticed or even appreciated in some contexts — is a real headache there. We 
> have to work against it, rather than it working for us.
>
> So, especially in education:
>
> (a) the subtleties of syntax are manifold and sometimes unexpected
>
> (b) there's an enduring value to our (beloved) syntax, so it'll never go 
> away (-:
>
> Shriram
>

In our CS1 for humanities and social science the parenthetical syntax has 
not only not been a problem, it really appears far easier/better. As sk and 
other bootstrappers and htdpers have known for a long time, unless one 
focuses on already familiar numerical algebraic expressions, irregularity 
is a hindrance.

I've taught the exact same material at the start of a 3rd year CS PL 
course, and the students there didn't find the syntax as easy as one would 
hope for students with that much CS “experience”. In fact, unsurprisingly, 
many find the syntax as hard as expected for having trained on very 
different syntaxes (especially when they are unclear about the semantics 
that were attached to those syntaxes). Although the switch to teaching the 
start of the course with literally the same materials, with the students 
knowing that, seems to have reduced resistance substantially (presumably 
they don't want to be seen as complaining about something 1st year 
humantities students are fine with).

-- 
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/e615518f-4f81-4fae-bed1-2a221ebddc66%40googlegroups.com.

Re: [racket-users] Re: The case, and a proposal, for elegant syntax in #lang racket2

[Shriram Krishnamurthi]

To riff on Will's message:

In the Bootstrap:Algebra
 materials,
we use Racket syntax because it's a powerful pedagogic device. Recently,
for various reasons, we've ported this over to another language called
Pyret (while also maintaining the Racket version; it hasn't been
deprecated).

Pyret has an almost-traditional infix syntax. It turns out infix is
actually much worse for the concepts we try to teach in that curriculum. Of
course it can be done, but the irregularity of infix — which is barely
noticed or even appreciated in some contexts — is a real headache there. We
have to work against it, rather than it working for us.

So, especially in education:

(a) the subtleties of syntax are manifold and sometimes unexpected

(b) there's an enduring value to our (beloved) syntax, so it'll never go
away (-:

Shriram

-- 
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/CAJUf2yStc3nWr6rra5OBoEMkXq7xRccocBccmUBzpXX_NiT4gQ%40mail.gmail.com.

Re: [racket-users] Re: The case, and a proposal, for elegant syntax in #lang racket2

[Christopher Lemmer Webber]

Hendrik Boom writes:

> On Wed, Jul 17, 2019 at 04:52:37PM -0700, Maria Gabriela Guimarães wrote:
>>
>> Does Racket wants to be popular in the industry? Then Racket must focus on
>> being a language-oriented programming ecosystem on a popular VM, like the
>> ErlangVM, the JVM, and the WebAssemblyVM. This means to stop working on the
>> RacketVM, if there's such a thing, and to start moving Racket's
>> language-oriented programming features into these popular VMs.
>
> There may be performance advantages to the Racket VM, so I wouldn't
> stop developing it.  But adding those other popular VMs may well be a
> win.
>
> -- hendrik

The work that Matthew Flatt is doing on Racket-on-Chez should be opening
up the possibility of running Racket on multiple other foundations, is
my understanding from conversations in the past.  So I don't think we
need to pivot, since opening up the possibility for this is already on
track.

-- 
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/87d0i814yk.fsf%40dustycloud.org.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: The case, and a proposal, for elegant syntax in #lang racket2

[Hendrik Boom]

On Wed, Jul 17, 2019 at 04:52:37PM -0700, Maria Gabriela Guimarães wrote:
> 
> Does Racket wants to be popular in the industry? Then Racket must focus on 
> being a language-oriented programming ecosystem on a popular VM, like the 
> ErlangVM, the JVM, and the WebAssemblyVM. This means to stop working on the 
> RacketVM, if there's such a thing, and to start moving Racket's 
> language-oriented programming features into these popular VMs.

There may be performance advantages to the Racket VM, so I wouldn't 
stop developing it.  But adding those other popular VMs may well be a 
win. 

-- 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/20190718015018.6zanhroooyzwxffq%40topoi.pooq.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: The case, and a proposal, for elegant syntax in #lang racket2

[Shriram Krishnamurthi]

P4P is also very much "current", as far as I'm concerned. (In fact, I'm 
quite likely about to use it in a new setting.) Pyret is a parallel branch 
effort. 

Pyret is "let's just go all out and design a new syntax". Specifically, I 
was tired of dealing with people who wouldn't read *How to Design Programs* 
because 
of the syntax, and wanted to be able to communicate its ideas to them. We 
realized that a new syntax could go a long ways. It has. But I still dream 
in parentheses. (-:

P4P, in contrast, was my attempt at an answer to "how far can we go with 
Racket's existing mechanisms?"

Indeed, the original P4P is flawed in that it seems to take Racket as the 
base language. In retrospect, this isn't what I meant. I meant for P4P to 
be a *syntax* that *layers* atop *whatever* underlying (semantic) language 
you want, as a different *reader*. It wasn't really implemented that way, 
but should have been/should be. Then you could use any existing Racket 
language with P4P syntax as its surface.

Shriram

On Monday, July 15, 2019 at 2:34:31 PM UTC-4, Neil Van Dyke wrote:
>
> Wesley Kerfoot wrote on 7/15/19 2:28 PM: 
> > Has anyone considered http://shriram.github.io/p4p/ as an alternative? 
>
> This might represent Shriram's current thinking (and is what I was 
> alluding to before): https://www.pyret.org/ 
>
> I'll wait for the official community process to commence, before I get 
> deep in discussion. 
>
>

-- 
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/4af85482-fd61-4173-a878-e61b02ab8776%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: The case, and a proposal, for elegant syntax in #lang racket2

[Hendrik Boom]

On Mon, Jul 15, 2019 at 11:26:06AM -0700, Wesley Kerfoot wrote:
> Has anyone considered http://shriram.github.io/p4p/ as an alternative?
> 
> The idea in a nutshell is to get rid of the implicit `(begin ...)` that 
> many of the forms have, and use that to reduce the number of required 
> parentheses for parsing, and add in some extra syntactic sugar in the form 
> of `:` (colon) to further reduce the need for parens.

Does current Racket already have a meaning for ':'?
Are there any other characters that are still free?

-- 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/20190715210333.k5indts2wovi5hec%40topoi.pooq.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: The case, and a proposal, for elegant syntax in #lang racket2

[Neil Van Dyke]

Wesley Kerfoot wrote on 7/15/19 2:28 PM:

Has anyone considered http://shriram.github.io/p4p/ as an alternative?


This might represent Shriram's current thinking (and is what I was 
alluding to before): https://www.pyret.org/


I'll wait for the official community process to commence, before I get 
deep in discussion.


--
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/173ee913-ebb9-6f48-f758-d58f60938dea%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.