Matthias, thank you very much for taking the time to carefully read the whole thing and for your thoughtful suggestions. Most, if not all of them, put on the foreground my own doubts and misgivings.
On Saturday, April 20, 2019 at 8:19:31 PM UTC+2, Matthias Felleisen wrote: > > > > > On Apr 18, 2019, at 12:08 PM, Luis Sanjuán <luisj....@gmail.com > <javascript:>> wrote: > > > > The last month or so we all read some interesting posts about the > convenience of examples or docs to facilitate the transition from other > languages to Racket (from Python to Racket, from R to Racket, ...). Then I > thought about another non-Racket languages that no one mention, if I recall > well, for which such examples would be more than helpful, *SL languages ;) > > > > Of course, The Realm is there, but more examples would be beneficial, I > guess. I have written something along these lines on my blog: > > > > > https://los-pajaros-de-hogano.blogspot.com/2019/04/from-htdp-to-racket-isbn-extraction-in.html > > > > > It might be full of inaccuracies or even errors. So comments, fixes, or > suggestions are welcomed. > > > > > Luis, this is great. Thank you for the effort. > > Here are some suggestions on how I’d re-order some of the material: > > 0. Importing all of racketbase and racket/string and racket/file first is > questionable. I would create a teachpack > > htdp2racket > > that includes the functions that are needed for writing such excerpts of > realistic programs. I’d be happy to collaborate on this and include the > teachpack with 2htdp. racket/file requirement can be easily replaced with your read-file (2htdp/batch-io) As for racket/string, all the functions needed, if not in their full generality, at least to the extent required by the task, can be defined in ISL, and replaced with Racket string functions in a later step. Regexes pose a more demanding challenge. I really thought of it, and even tried to some extent other alternatives too: (a) Begin with a solution to HtDP ex. 476 (fsm-match) and extend it to deal with quantifiers. Maybe this reduced regex support would be enough for the task. The problem with this is that this adds heavy burden to the task. (b) Tackle the problem assuming that each ISBN appears in its own line, as the standard specifies. Under this assumption it is possible to devise this strategy: 1. Read words per line. 2. Join consecutive words consisting of ISBN letters (digits or 'X'). 3. Remove separators from the result. 4. Validate each word. I think that this should work for the problem without the need of regexes. >From there on regexes could be introduced as another way of solving the task in Racket, or I could stick to the initial strategy and present it in Racket, using regexes sparingly if needed. What do you think about these alternatives? Anyway, a teachpack is another option. I really appreciate your offer of making it possible :-) > > > 1. I’d switch to #lang htdp/isl+ first. Your code should pose no problems > for this #lang. (It isn’t production ready yet). > > 2. Still in ISL+, I would add the 2htdp/abstraction teachpack to simplify > the ISLcode first. I think its suport of for and match fits. > > I did so in a prior draft. I can return to that, and show full-fledged Racket 'for' later. > 3. A re-factoring of code must have the support of a test suite. There are > three ways to go about this: > > (a) import rackunit into ISL+ > (b) import racket-tests/test-engine into the racket/base program > and run (test) at the bottom > (c) rewrite the tests into rackunit + submdoule. > > I’d go with (b) and do an optional last step to show people how to write > idiomatic rackunit tests. > > Definitely fair complaint. Exposition order shouldn't affect basic program design principles. > 4. I would not use define/contract for this transition sequence. See > elsewhere for its somewhat complex semantics when it comes to blame > assignment. Instead when you use contracts, it might be a good time to > split the module into two parts: > > — the main functions > — the helpers and the large number of constant definitions plus > contracts (yes export the contracts from here if you can keep things > opaque) > > You could first show how to move code into a submodule with its own > contract-out plus a single require, then move the submodule into a file. > (That’s how I proceed and it should be a DrRacket refactoring operation.) > > I'm aware of define/contract caveats (Guide 7.9.2). Splitting things into two modules looks indeed the soundest solution here. > > 5. Years ago, I observed a PhD in our lab using point-free style in > Racket. He came from Haskell of course. I tried it. I got close to saying > negative things about it in the style guide. > > That was a Haskellian whim, and I'm going to correct it. Actually, function composition and curried functions are introduced somewhere else, when they are really needed (functions taking functions as arguments). > I am a bit disappointed that the code didn't shrink during the > transformation but I didn’t spot immediate big gains, even with some small > style guide things fixed. > > Again, thank you very much and please keep posting — Matthias > > I want the result to be completely valid in terms of Racket good practices and idiomatic code. So feel free to change that result as needed. My ultimate hope is to encourage everyone, particularly all of you who know Racket much better than I do, to add more sample problems and fill the gap between HtDP languages and Racket. Racket should be, in my view, the language of choice for HtDP students to make real-world programs. Why not Racket instead of Python, Java, JS, ....? -- 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. For more options, visit https://groups.google.com/d/optout.
