[racket-users] Re: Error when I try to use slideshow?

[Alex Harsanyi]

This may or may not work for them, but ask the user to open the 
"viewer.rkt" file in their racket installation (it should be in C:\Program 
Files\Racket\share\pkgs\slideshow-lib\slideshow) and comment out the 
`set-icon` call around line 1512.   That is, comment out the following 
block:

(let* ([bm slideshow-bm]
   [mbm slideshow-mbm])
  (when (send bm ok?)
(send f set-icon bm (and (send mbm ok?) mbm) 'both)))

This is the line in GitHub:

https://github.com/racket/slideshow/blob/c61c80de63cf7b2197d67c078bdc9133823c0030/slideshow-lib/slideshow/viewer.rkt#L1509

---

Others may come up with better workarounds, but this looks to me like a 
problem with the Racket GUI library.  Slideshow fails on my home PC but 
works on my work PC, both Windows 10 but different build numbers.  The 
problem is that the windows CreateIconIndirect API call is passed an 
invalid parameter (this is what code 87 means).  Not sure what the invalid 
parameter is (or why it is invalid), but it is probably either the bitmap 
or the mask.

Alex.

On Thursday, August 22, 2019 at 11:40:45 AM UTC+8, Stephen De Gabrielle 
wrote:
>
> Hi
>
> I’m trying to help a user who is getting an error when trying to run 
> slideshow:
>
> I typed "#lang slideshow" into DrRacket and got the following error:
>
> CreateIconIndirect: call failed (87)
>
> Interactions disabled: slideshow does not support a REPL (no 
> #%top-interaction)
>
> They have two computers - slideshow works on a newer pc(win 10) but fails 
> on one that has been upgraded from windows 7 to 10. I can’t determine any 
> other difference.
>
>
> Any ideas how I can help this user ?
>
>
>
> https://www.reddit.com/r/Racket/comments/ct95b0/error_when_i_try_to_use_slideshow/?utm_source=share_medium=ios_app
>
>
> 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/d3ec8c4f-6c58-45be-962e-14776d53c32c%40googlegroups.com.

[racket-users] Error when I try to use slideshow?

[Stephen De Gabrielle]

Hi

I’m trying to help a user who is getting an error when trying to run slideshow:
> I typed "#lang slideshow" into DrRacket and got the following error:
> 
> CreateIconIndirect: call failed (87)
> 
> Interactions disabled: slideshow does not support a REPL (no 
> #%top-interaction)
> 
They have two computers - slideshow works on a newer pc(win 10) but fails on 
one that has been upgraded from windows 7 to 10. I can’t determine any other 
difference.

Any ideas how I can help this user ?

https://www.reddit.com/r/Racket/comments/ct95b0/error_when_i_try_to_use_slideshow/?utm_source=share_medium=ios_app


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/2F881EB1-7080-4EC3-86B2-5F4A5681BD0B%40gmail.com.

Re: [racket-users] Seeking good benchmark code for immutable hash and hash set usage

[Ben Greenman]

A few of the GTP benchmarks [1] use immutable hashes. Here's a link
with the ones that look most interesting:

http://ccs.neu.edu/home/types/tmp/gtp-hash.tar.gz


And here's a small (untyped) program that uses code from the tr-pfds
library to make a trie:

http://ccs.neu.edu/home/types/tmp/trie.tar.gz


Redex and the graph library might be good places to look for other
examples. I know graph uses lots of hashes internally, and I bet Redex
does too.

[1] https://github.com/bennn/gtp-benchmarks

On 8/14/19, Jon Zeppieri  wrote:
> Hello Racketeers,
>
> I'm looking for examples of code that would make good benchmarks for
> evaluating the performance of immutable hashes.
>
> Some background:
> Immutable hashes used to be implemented in Racket as red-black trees.
> That was changed to hash array mapped tries (HAMTs) a number of years
> back. In Racket CS, the current implementation is a Patricia trie.
> That choice was based largely on the fact that it performed
> significantly faster on the hash demo benchmarks[1] that any of the
> HAMT variants I tested against. In particular, the write performance
> of the HAMTs seemed especially poor.
>
> However, on some real-world code[2] I recently had occasion to test, a
> HAMT consistently performs better than the Patricia trie, _especially_
> on writes, which makes me think I put entirely too much weight on the
> hash demo benchmark.
>
> So I'm looking for more realistic cases to use for benchmarking. If
> you have a Racket application or library that makes heavy use of
> immutable hashes or hash sets (from the racket/set module), please let
> me know.
>
> Thanks,
> Jon
>
> [1] https://github.com/racket/racket/blob/master/racket/src/cs/demo/hash.ss
> I also tried to use the expander demo as a benchmark, but the timings
> weren't significantly different with different hash implementations.
>
> [2] https://github.com/racket/racket/pull/2766#issuecomment-520173585
> Well, it's a lot closer to real-world code than the hash demo.
>
> --
> 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/CAKfDxxwjPcWewzo2X5uXGH06Ud1hjURNuKFW59duXrZq4-7tWQ%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/CAFUu9R4dwNWS28MyApTYUkiQ-%2BhV%3DuWPBAF77xMV-wNsDMduLw%40mail.gmail.com.

Re: [racket-users] is there a list of racket relevant papers/thesis/posters/etc.?

[Neil Van Dyke]

AFAIK, the publication list is currently split up between the different 
universities.  If you scroll to the "PLT Research" section of either of 
the two below (near-identical?) pages, you can click through to the 
different research groups:


https://www.racket-lang.org/team.html
https://www.racket-lang.org/plt.html

If I may please humbly offer one suggestion: before making a centralized 
official-looking publications list, get buy-in from all the researchers, 
and make sure it's representative of how the researchers want to portray 
their work, and that it will be kept up-to-date in practice.


(Racket actually got ripped on by another professor, a couple weeks ago, 
who held up as evidence the paucity of items in one of the Racket wiki 
pages on github, which might've been incomplete.  A publication list 
seems even more important to get right, than most things.)



--
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/3f04d1f9-ea35-a059-949b-87d2cd4a718c%40neilvandyke.org.

[racket-users] is there a list of racket relevant papers/thesis/posters/etc.?

[Stephen De Gabrielle]

Hi Racketeers,

I know some of the documentation refers to papers[*], but I'm wondering if
there is a centralised list.

I don't want to duplicate effort, but if there isn't, I'll try add one to
the wiki.

Kind regards,

Stephen

[*]
https://docs.racket-lang.org/reference/doc-bibliography.html (many without
links)
typed racket papers by STH
honu paper
control paper by MF

-- 
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-Lj23AAmoKHJpieeTinKZm_PHpo-my5PwTL%2BLd6sGjx_g%40mail.gmail.com.

[racket-users] handin-server: writing a first checker

['Wayne Harris' via Racket Users]

I haven't been able to write a first checker.  I'm always getting

  map: all lists must have same size

in the server's log.

The submission always shows this in the log file:

[16|2019-08-21T21:12:35] connect from 191.35.15.190
[16|2019-08-21T21:12:39] running 12KB (123MB 133MB)
[16|2019-08-21T21:12:39] login: (wharr...@protonmail.com)
[16|2019-08-21T21:12:39] assignment for (wharr...@protonmail.com): assignment-1
[16|2019-08-21T21:12:40] timeout-control: reset
[16|2019-08-21T21:12:40] checking assignment-1 for (wharr...@protonmail.com)
[16|2019-08-21T21:12:42] running 37KB (123MB 133MB)
[16|2019-08-21T21:12:46] running 37KB (123MB 133MB)
[16|2019-08-21T21:12:49] running 39KB (123MB 133MB)
[16|2019-08-21T21:12:52] ERROR: map: all lists must have same size
[16|2019-08-21T21:12:52]   first list length: 3
[16|2019-08-21T21:12:52]   other list length: 1
[16|2019-08-21T21:12:52]   procedure: #

It also pops up the message error message to the student in DrRacket.

Any ideas what's causing this?

Taking the typical checker from the documentation, I started with:

(module checker handin-server/checker
  (check: :language  '(special intermediate)
(!procedure Fahrenheit->Celsius 1)
(!test (Fahrenheit->Celsius  32)   0)
(!test (Fahrenheit->Celsius 212) 100)
(!test (Fahrenheit->Celsius  -4) -20)))

My student code in DrRacket is set to intermediate language and the
code is:

(define (Fahrenheit->Celsius x)
  (* 5/9 (- x 32)))

(check-expect (Fahrenheit->Celsius 32) 0)

Here's my server configuration:

$ cat config.rktd
 ((active-dirs ("assignment-1"))
  (allow-web-upload #t)
  (allow-new-users #t)
  (master-password "4c96f8324e3ba54a99e78249b95daa30"))
$

$ cat users.rktd
(
 (wharr...@protonmail.com ("4c96f8324e3ba54a99e78249b95daa30" "Wayne Harris"))
)
$

$ cat assignment-1/checker.rkt
(module checker handin-server/checker
  (check: :language  '(special intermediate)
(!procedure Fahrenheit->Celsius 1)
(!test (Fahrenheit->Celsius  32)   0)
(!test (Fahrenheit->Celsius 212) 100)
(!test (Fahrenheit->Celsius  -4) -20)))
$

-- 
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/Le2v4fuorTS76ru-EzIcXTxB9t0I3wyV56qTFtRFY8cErV3l4mIJVUsi-s9qSlv7Q_2PVix-prxqDh5noOcmrlm3yyeB7gdBx02fwaUICW8%3D%40protonmail.com.

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] Racket News - Issue 14

[Annaia Berry]

the SSL cert seems to have expired the other day.

On Wed, Aug 21, 2019 at 8:37 PM Stephen Foster 
wrote:

> My browser is telling me that the SSL certificate for racket-news.com is
> invalid.
> Is it just me?
>
> On Monday, August 19, 2019 at 7:54:54 AM UTC-7, Stephen De Gabrielle wrote:
>>
>> Thank you Paulo!
>> Another awesome issue of Racket News.
>>
>> S.
>>
>>
>>
>>
>> On Fri, Aug 16, 2019 at 9:49 PM Paulo Matos  wrote:
>>
>>> Racket News issue 14 is here.
>>> https://racket-news.com/2019/08/racket-news-issue-14.html
>>>
>>> Enjoy!
>>>
>>> --
>>> Paulo Matos
>>>
>>> --
>>> 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...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/racket-users/05377b52-dc75-09ce-97b6-5c9734bbaec3%40linki.tools
>>> .
>>>
>> --
> 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/9586f6ed-f0b3-4889-abf7-77e3a436537e%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/CA%2BHVF0AQhOm1s1avkK%3DqO4vQqgx6VyRDZh8XymTUKqVYqZ6%3DxQ%40mail.gmail.com.

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] does handin-server really need racket/gui/base?

['Wayne Harris' via Racket Users]

On Monday, August 19, 2019 10:40 PM, John Clements  
wrote:

> I’m not looking at the code here, but I believe the issue here is that the 
> handin-server receives user code in a serialized-could-contain-images-format 
> that can’t be decoded properly without importing the gui libraries.

That makes sense.

> It seems not implausible to me that you could special-case all-text 
> submissions to build a handin-server that doesn’t require the gui pieces.

That'd be an interesting addition to handin-server.  I'd love to contribute 
that, but I need to see if I can understand enough to make it.  Thanks for the 
idea!

> BUT,
>
> I’m here to tell you that I also run the handin server on a headless UNIX 
> system (currently Debian 9) with no problems.
>
> Specifically, I use tigervnc to create an x session, then connect to it 
> remotely (using a local vnc client) and start the handin server with an 
> active X connection.
>
> Let me know if you need more clues on this setup; there are a whole bunch of 
> things that can go wrong.

Thanks a lot!  I did make it: I installed Xming on my Windows system and used 
PuTTY's X11-configuration.  The server ran fine!  (Now I'm free to study how to 
implement a checker!)  Thanks for your help!

-- 
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/FgpfMl4f7STt9TrXMSVMGIggf3c9PgLQB2k9HEm-6uEBUzlCYcRwUKPdr71pnBPRhLW07rVERtA7uWXQePv0r5mM6EzaofLb70OUN-7kxLc%3D%40protonmail.com.

Re: [racket-users] Racket News - Issue 14

[Stephen Foster]

My browser is telling me that the SSL certificate for racket-news.com is 
invalid.
Is it just me?

On Monday, August 19, 2019 at 7:54:54 AM UTC-7, Stephen De Gabrielle wrote:
>
> Thank you Paulo! 
> Another awesome issue of Racket News.
>
> S.
>
>
>  
>
> On Fri, Aug 16, 2019 at 9:49 PM Paulo Matos  wrote:
>
>> Racket News issue 14 is here.
>> https://racket-news.com/2019/08/racket-news-issue-14.html
>>
>> Enjoy!
>>
>> -- 
>> Paulo Matos
>>
>> -- 
>> 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...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/racket-users/05377b52-dc75-09ce-97b6-5c9734bbaec3%40linki.tools
>> .
>>
>

-- 
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/9586f6ed-f0b3-4889-abf7-77e3a436537e%40googlegroups.com.

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.

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

[George Neuner]

On Wed, 21 Aug 2019 03:48:29 -0700, Sorawee Porncharoenwase
 wrote:

> On Wed, 21 Aug 2019 02:55:46 -0700 (PDT), Chris Stephenson 
>  wrote:

>> (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


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.


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/esjqledhdohgt3eogv6s9sjvfibml0dgkf%404ax.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.

[racket-users] Re: [standard-fish] Summer competiton 2019

[Stephen De Gabrielle]

I'd forgotten about Planet Cute - another valid way to enter.


[image: Post image] 

2htdp/planetcute image

try this:

https://docs.racket-lang.org/teachpack/2htdpPlanet_Cute_Images.html

#lang racket
(require 2htdp/image 2htdp/planetcute)
;The 2htdp/planetcute library contains the Planet Cute art by Daniel Cook
(Lostgarden.com).
;
;The images are designed to be overlaid with each other to build scenes for
use in games. Here is an example image taken from the Planet Cute website.
; stack : non-empty-list-of-images -> image
; stacks 'imgs' on each other, separated by 40 pixels
(define (stack imgs)
  (cond
[(empty? (rest imgs)) (first imgs)]
[else (overlay/xy (first imgs)
  0 40
  (stack (rest imgs)))]))
(beside/align
   "bottom"
   (stack (list wall-block-tall stone-block))
   (stack (list character-cat-girl
stone-block stone-block
stone-block stone-block))
   water-block
   (stack (list grass-block dirt-block))
   (stack (list grass-block dirt-block dirt-block)))



On Wed, Aug 21, 2019 at 6:19 PM Stephen De Gabrielle <
spdegabrie...@gmail.com> wrote:

> Only 10 days left!
>
> Get your entries in!
>
>
> https://github.com/standard-fish/summer-competititon-2019/blob/master/README.md
>
>
> On Wed, 31 Jul 2019 at 04:28, Stephen De Gabrielle <
> spdegabrie...@gmail.com> wrote:
>
>> *Subject: [standard-fish] Summer competiton 2019*
>> *'Summer standard fish competition 2019'*
>> [image: image]
>> Competition: Make an image with Racket this summer! Win stickers!
>>
>> Rules:
>> * you can make images any way you like. I suggest *pict *or *htdp2e/image,
>> but you can use whatever you like!*
>> * Images can be of anything.  Images do not have to be of fish. There is
>> no advantage in fish images.
>> * You can enter as many times as you like.
>>
>> It is easy to enter - just post your entry on racket-users, either by
>> email or via google groups, with the prefix '[standard-fish]' just like
>> this email.
>>
>> Please remember to put [standard-fish] at the begining of the email
>> subject line so I can easily identfy your entry.
>>
>> You can paste your code onto the the end of your message, or inlcude a
>> link to a GitLab or GitHub repository/file,  a GitHub Gist, or anything
>> else appropriate.
>> - I don't recommend using attachments on the mailing list/google groups.
>>
>> What will you win? I'll send Racket stickers
>>  to the top 10 winners!
>>
>> Closing date: 1 September 2019 judging will take place in the first two
>> weeks of September, and winners will be announced 14 September. (I'm away
>> for most of August so I look forward to seeing your creations on my return)
>>
>> Note: Not an official Racket competition. I am not a member of the Racket
>> team, nor am I doing this on their behalf. I am covering the cost of the
>> stickers and postage.
>>
>> Any questions: email me at spdegabrielle at gmail dot com
>>
>> Have a good summer holidays!
>>
>> Stephen
>>
>> ---
>>
>> Need help getting started?
>>
>>- Quick: An Introduction to Racket with Pictures
>>
>>- Pict: Functional Pictures
>>
>>-  2htdp/image
>>
>>- https://github.com/standard-fish/paper-doll - provided by Matthew
>>Flatt: *'In case it's of interest, enclosed is some code extracted
>>from one of my talks. Start by running "demo.rkt". Someone might be
>>interested to play with it or turn it into something better. Since there 
>> is
>>no documentation, that someone would have to read the code to extract the
>>various acceptable values for arguments. The most obvious direction for
>>improvement is that choices like hair style and color should have been
>>separated into different arguments."*
>>
>> Having trouble? - ask a question on racket-users. You can also try
>> stack-overflow and reddit but YMMV.
>>
>>  standard-fish
>> 
>> [image: image]
>>
>>
>> --
> 
>

-- 
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-ePRPVTzPF5Jiq5QJVB3u-R2xSR90MHr3_ouMR%2B8cug%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] rel-string module path suffix not added automatically?

[Štěpán Němec]

[resending to the list; I originally posted via Gmane but the
mail-to-news direction doesn't seem to work, sorry for the
duplication/confusion]

On Wed, 21 Aug 2019 06:39:42 +0200
Matthew Flatt wrote:

> It looks to me like the Guide documentation is wrong there. A ".rkt"
> suffix is added for an identifier-form path, like `racket/base`, but
> not for a relative-path string like "../file".

Thank you for the clarification! I hope someone can correct the
documentation (I would submit a patch same as I'm going to do with some
trivial typos I stumbled upon, but here perhaps some more sophisticated
action is required).

-- 
Štěpán

-- 
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/8736hukgpp.fsf%40gmail.com.

[racket-users] Re: [standard-fish] Summer competiton 2019

[Stephen De Gabrielle]

Only 10 days left!

Get your entries in!

https://github.com/standard-fish/summer-competititon-2019/blob/master/README.md


On Wed, 31 Jul 2019 at 04:28, Stephen De Gabrielle 
wrote:

> *Subject: [standard-fish] Summer competiton 2019*
> *'Summer standard fish competition 2019'*
> [image: image]
> Competition: Make an image with Racket this summer! Win stickers!
>
> Rules:
> * you can make images any way you like. I suggest *pict *or *htdp2e/image,
> but you can use whatever you like!*
> * Images can be of anything.  Images do not have to be of fish. There is
> no advantage in fish images.
> * You can enter as many times as you like.
>
> It is easy to enter - just post your entry on racket-users, either by
> email or via google groups, with the prefix '[standard-fish]' just like
> this email.
>
> Please remember to put [standard-fish] at the begining of the email
> subject line so I can easily identfy your entry.
>
> You can paste your code onto the the end of your message, or inlcude a
> link to a GitLab or GitHub repository/file,  a GitHub Gist, or anything
> else appropriate.
> - I don't recommend using attachments on the mailing list/google groups.
>
> What will you win? I'll send Racket stickers
>  to the top 10 winners!
>
> Closing date: 1 September 2019 judging will take place in the first two
> weeks of September, and winners will be announced 14 September. (I'm away
> for most of August so I look forward to seeing your creations on my return)
>
> Note: Not an official Racket competition. I am not a member of the Racket
> team, nor am I doing this on their behalf. I am covering the cost of the
> stickers and postage.
>
> Any questions: email me at spdegabrielle at gmail dot com
>
> Have a good summer holidays!
>
> Stephen
>
> ---
>
> Need help getting started?
>
>- Quick: An Introduction to Racket with Pictures
>
>- Pict: Functional Pictures
>
>-  2htdp/image 
>- https://github.com/standard-fish/paper-doll - provided by Matthew
>Flatt: *'In case it's of interest, enclosed is some code extracted
>from one of my talks. Start by running "demo.rkt". Someone might be
>interested to play with it or turn it into something better. Since there is
>no documentation, that someone would have to read the code to extract the
>various acceptable values for arguments. The most obvious direction for
>improvement is that choices like hair style and color should have been
>separated into different arguments."*
>
> Having trouble? - ask a question on racket-users. You can also try
> stack-overflow and reddit but YMMV.
>
>  standard-fish
> 
> [image: image]
>
>
> --


-- 
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-%2B5dhmpyupwo0ktqivBRgShbe2jR8BFdmn5Qwvj_2L1%3DQ%40mail.gmail.com.

Re: [racket-users] Splicing the result of one macro into another

[Sorawee Porncharoenwase]

>
> I appreciate all of the Racket documentation, but I think there is a need
>> for a much better presentation of the material in a graduated way.
>>
>
I think what you are saying is, there should be more Racket Guide content,
and I think everyone agrees on that...


> you seem to have an excellent grasp of macros.
>

Well, not really. There are a lot of stuff I don't know!


> How did you acquire your knowledge of macros?
>

Mostly from reading tutorials and public code:
- https://www.greghendershott.com/fear-of-macros/
- https://www.hashcollision.org/brainfudge/
- https://docs.racket-lang.org/guide/macros.html
- https://docs.racket-lang.org/syntax/stxparse.html
- https://beautifulracket.com
- https://docs.racket-lang.org/syntax-parse-example/

I also attended Racket School in 2017, though as I understand the topic of
macro was focused less compared to later years -- if you attended Racket
school in recent years, you probably got the knowledge more than I did.

For more advanced topics, I learned a lot from Alexis's blog posts (
https://lexi-lambda.github.io). Ultimately there are papers and reports
like http://www.cs.utah.edu/plt/scope-sets/ which is a lot harder to read
but would be rewarding once you understand it.

Mailing list and Slack are very helpful to me, but the answers are very
easy to get lost (including this very thread, perhaps).

> --
> 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/0a39a0c4-bde5-4207-9abd-63b9d1ceec07%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/CADcuegst8MGdZ7LbF1a%3DEppZ5kTaKcnwibfRXTb7Od6cKqfmRA%40mail.gmail.com.