Re: [racket-users] Why is there a space in the path to the Racket application on MacOSX?
Philip, you're right, a DSL doesn't have to mean a restricted language (like BSL). I completely missed that point in my last response to this thread. For some reason BSL got in my head and I incorrectly equated that concept with the embedded DSL approach suggested by Matthias as I was writing my response. That clearly wasn't what Matthias was suggesting, and he even mentioned the natural backdoor. Thanks for clarifying this for me, it was actually very helpful. Call it a momentary brain malfunction on my part. On Sun, Apr 1, 2018 at 10:51 PM, Philip McGrath wrote: > One way the student languages from HtDP are different from most Racket > DSLs and langs is that, in the service of regularity and nice error > messages, they take away many convenient and powerful features of the full > Racket language. There is not really an "escape hatch" into full Racket, > other than importing libraries. > > In contrast, most Racket language extensions either simply add new > language constructs to racket/base—think of the contract system, or the > class-based object system—or provide forms very similar to the racket/base > form, but with some refinement: #lang web-server transforms modules to make > continuations serializable at interaction points, or Typed Racket adds > syntax for specifying types. So starting your readers with a DSL doesn't > have to mean that they have a heavily-restricted language overall (or you > could be really ambitious and provide both a (require railroad) library and > a #lang railroad/beginner). > > My first experience with Racket was through HtDP, which I loved, but, > while I understand the good reasons for the teaching languages (especially > the great error messages for beginners), I also have mixed feelings about > them. For students like me who already had some (imperative, > non-parenthesized) coding experience, there was a lot of complaining about > conveniences of other languages that seemed to be missing from *SL (e.g. I > believe BSL doesn't even have a mechanism for giving temporary names to > values). When I tell other people who've been through HtDP that Racket is > now my language of choice, I often get reactions like "Why would you want > to use that for a real project?" and have to explain that Racket is not the > language we learned in class. I think the text of the second edition may do > a better job at making that distinction: we mostly used the first edition > with little bits of the second, and certainly it was more confusing when > everything was just called "Scheme." > > -Philip > > On Mon, Apr 2, 2018 at 1:30 AM, Stephen Smith > wrote: > >> Railroad-simulation language, absolutely! One of the key reasons that >> Racket is on the top of the list. But what I didn't think of was to have >> the reader use the DSL first. I was initially planning to develop the DSL >> as a later part of the book - doing it the hard way perhaps. >> >> That has always been the one thing I wasn't crazy about with htdp, >> starting with the Beginning Student language, but that's just me >> personally. I understand the reasons for the approach. I look at it as, "I >> don't want training wheels - let me take the real thing for a ride!", and >> deal with the consequences later - an >> I-wanna-know-what's-under-the-hood-right-now >> type of guy. For that reason, I never considered something like that for my >> book, but the more I think of it now, it kind of makes a lot of sense for >> my audience? I've always looked at it from an experienced programmer's >> point of view - which doesn't necessarily fit best here. >> >> Thanks Matthias for giving me this suggestion to think about. I might >> have a lot more work to do to get started using that approach, but in the >> long run, as you say, it might get them more interested in the programming >> part. Much appreciated food for thought. >> >> >> >> On Sunday, April 1, 2018 at 8:23:32 PM UTC-4, Matthias Felleisen wrote: >>> >>> >>> On Apr 1, 2018, at 12:57 PM, Stephen Smith >>> wrote: >>> >>> my (book) project is for model railroad hobbyists (many if not most who >>> have never programmed before). >>> >>> >>> >>> Have you considered the development of a railroad-simulation language >>> within Racket that fits your domain? If you can provide people with a >>> language that fits their problem area, they might be more interested in >>> learning more about programming per se. Since embedded DSLs usually have a >>> natural backdoor, this might be an approach that works well. >>> >>> In my current “hack your own language” course, some kids have gone a >>> step further. They are interested in music theory. So they implemented a >>> language for specifying languages in which students can then create >>> compositions of choral music and the composition is statically checked >>> before they even turn it in. The teacher can create a language per weekly >>> homework and teh students get to see the progression. At the same time, >>> there are several ways to di
Re: [racket-users] Re: Smalltalk (Was: Why is there a space in the path to the Racket application on MacOSX?)
Geoffrey Knauth wrote on 04/01/2018 11:53 PM: I don't see why there couldn't be a Racket Machine. People could live in it the way people live in Emacs and get so much done and have their ice cream too. BTW, if someone wants the novelty of a kind of mock-up of booting into a Racket Machine, you can rig up your own Debian Live distro to boot a stripped-down GNU/Linux that launches your Racket process. (I have done this before, which is why there's a scary Racket package for repartitioning your hard disk, "http://www.neilvandyke.org/racket/parted/";.) User experience-wise, you might wind up with an environment that builds upon DrRacket, to incorporate elements of the more dynamic environments of Lisp machines, Smalltalk, and Emacs. Of course, a Racket Machine might also eventually have an operating system kernel or hardware architecture that was designed for its needs. In the interim, Debian Live lets you pretend that you do. -- 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.
[racket-users] Re: Smalltalk (Was: Why is there a space in the path to the Racket application on MacOSX?)
On Sunday, April 1, 2018 at 9:53:45 PM UTC-4, Neil Van Dyke wrote: > > A bonus of reading old Smalltalk-80 stuff is that you get exposed to a > bit of some of the best and most optimistic visionary thinking about > information technology, when people had grand ideas for how computers > could elevate everyone (spoilers: it wasn't about a couple billionaire > 'social' dotcom founders seizing power over everyone, and CS students > weren't thinking like startup MBAs). > Amen to that. For fun I'd love to see Alan Kay play with DrRacket, then pick his brain. I run into clumps of Smalltalk people in unexpected places, such as at SIGGRAPH. For your Smalltalk-in-Racket implementation idea, the key is how you start out the project. If it starts right, it can grow naturally. Smalltalk and the Lisp Machine had some similarities. I don't see why there couldn't be a Racket Machine. People could live in it the way people live in Emacs and get so much done and have their ice cream too. -- 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.
[racket-users] Smalltalk (Was: Why is there a space in the path to the Racket application on MacOSX?)
Geoffrey Knauth wrote on 04/01/2018 01:05 PM: On Sunday, April 1, 2018 at 12:57:46 PM UTC-4, Stephen Smith wrote: It's been a long tough road as to which implementation language to choose for it. I'm down to two now after much experimenting - Racket of course, and Smalltalk. Now you have me wondering which is harder, implementing Smalltalk in Racket, or the other way around. Implementing the Smalltalk-80 language alone in Racket seems pretty easy, and could be a really fun hobby project. You can make it non-easy by going for performance optimizations, while keeping it fully dynamic. But, remember, we used to run Smalltalk on hardware that's very slow compared to today, so you might be pleasantly surprised with the performance of an unoptimized implementation for traditional Smalltalk-80 applications. The Smalltalk-80 GUI environment would be fun to write from scratch, or you could look for an open source implementation atop Smalltalk GUI primitives, and implement those primitives atop Racket GUI. You might want to go retro chic, and not use Racket GUI widgets (pop-up menus, lists, text, scrollbars, etc.), except perhaps for the top-level windows. Once you have your standard Smalltalk-80 browsers, you can then build upon it with non-standard, like "http://www.neilvandyke.org/smalltalk-chg/";. A program in `#lang smalltalk` could boot the environment, and then you're no longer dealing with `#lang`, but with live Smalltalk objects, created and manipulated through environment browsers. A bonus of reading old Smalltalk-80 stuff is that you get exposed to a bit of some of the best and most optimistic visionary thinking about information technology, when people had grand ideas for how computers could elevate everyone (spoilers: it wasn't about a couple billionaire 'social' dotcom founders seizing power over everyone, and CS students weren't thinking like startup MBAs). -- 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.
Re: [racket-users] Why is there a space in the path to the Racket application on MacOSX?
Railroad-simulation language, absolutely! One of the key reasons that Racket is on the top of the list. But what I didn't think of was to have the reader use the DSL first. I was initially planning to develop the DSL as a later part of the book - doing it the hard way perhaps. That has always been the one thing I wasn't crazy about with htdp, starting with the Beginning Student language, but that's just me personally. I understand the reasons for the approach. I look at it as, "I don't want training wheels - let me take the real thing for a ride!", and deal with the consequences later - an I-wanna-know-what's-under-the-hood-right-now type of guy. For that reason, I never considered something like that for my book, but the more I think of it now, it kind of makes a lot of sense for my audience? I've always looked at it from an experienced programmer's point of view - which doesn't necessarily fit best here. Thanks Matthias for giving me this suggestion to think about. I might have a lot more work to do to get started using that approach, but in the long run, as you say, it might get them more interested in the programming part. Much appreciated food for thought. On Sunday, April 1, 2018 at 8:23:32 PM UTC-4, Matthias Felleisen wrote: > > > On Apr 1, 2018, at 12:57 PM, Stephen Smith > wrote: > > my (book) project is for model railroad hobbyists (many if not most who > have never programmed before). > > > > Have you considered the development of a railroad-simulation language > within Racket that fits your domain? If you can provide people with a > language that fits their problem area, they might be more interested in > learning more about programming per se. Since embedded DSLs usually have a > natural backdoor, this might be an approach that works well. > > In my current “hack your own language” course, some kids have gone a step > further. They are interested in music theory. So they implemented a > language for specifying languages in which students can then create > compositions of choral music and the composition is statically checked > before they even turn it in. The teacher can create a language per weekly > homework and teh students get to see the progression. At the same time, > there are several ways to dive into Racket from each level. > > — Matthias > > -- 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.
[racket-users] Re: Why is there a space in the path to the Racket application on MacOSX?
Hmm, you've got me thinking more now - maybe leave the command-line until later. I certainly don't want to scare them off in the first chapter. I'm so used to installing packages via raco I didn't even think of using DrRacket. On Sunday, April 1, 2018 at 7:18:33 PM UTC-4, HiPhish wrote: > > I don't know where you are going with your book, but are you sure forcing > people to use the command-line interface is a good idea? Racket can be > fully used through the GUI (even managing packages can be done through > DrRacket). I agree with explaining both DrRacket and raco, but why can't > users just pick the one they are more comfortable with and ignore the other > (and maybe come back later to it)? > > I think the biggest problem is that so many people have very low computer > literacy. You will never see a book or web tutorial explaining concepts > like clicking, right-clicking, drag&drop or double-clicking because those > are so essential to using a computer. However, few people know how to use > the CLI, even though it allows you to automate and combine things in a way > a GUI cannot. You don't even have to be a programmer to find the CLI useful. > > On Sunday, April 1, 2018 at 6:57:46 PM UTC+2, Stephen Smith wrote: >> >> 2. @HiPhish: "Users should learn the command-line first". Although I >> agree with this in almost any other context, my book is for people who have >> never programmed before. So they will be learning the command-line and GUI >> at the same time (they have no choice in the matter ;-). In my opinion >> though, raco is an essential command line tool to teach new Racketeers so >> at least in my case the GUI alone will not suffice. And my book is not >> really a "Racket" book per se - Racket is just a tool to achieve the end >> goal. Which probably requires further explanation ... >> > -- 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.
[racket-users] Re: Why is there a space in the path to the Racket application on MacOSX?
You've gone above my pay-grade. :-) On Sunday, April 1, 2018 at 1:05:17 PM UTC-4, Geoffrey Knauth wrote: > > On Sunday, April 1, 2018 at 12:57:46 PM UTC-4, Stephen Smith wrote: >> >> It's been a long tough road as to which implementation language to choose >> for it. I'm down to two now after much experimenting - Racket of course, >> and Smalltalk. >> > > Now you have me wondering which is harder, implementing Smalltalk in > Racket, or the other way around. > -- 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.
Re: [racket-users] Why is there a space in the path to the Racket application on MacOSX?
> On Apr 1, 2018, at 12:57 PM, Stephen Smith wrote: > > my (book) project is for model railroad hobbyists (many if not most who have > never programmed before). Have you considered the development of a railroad-simulation language within Racket that fits your domain? If you can provide people with a language that fits their problem area, they might be more interested in learning more about programming per se. Since embedded DSLs usually have a natural backdoor, this might be an approach that works well. In my current “hack your own language” course, some kids have gone a step further. They are interested in music theory. So they implemented a language for specifying languages in which students can then create compositions of choral music and the composition is statically checked before they even turn it in. The teacher can create a language per weekly homework and teh students get to see the progression. At the same time, there are several ways to dive into Racket from each level. — Matthias -- 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.
[racket-users] Re: Why is there a space in the path to the Racket application on MacOSX?
I don't know where you are going with your book, but are you sure forcing people to use the command-line interface is a good idea? Racket can be fully used through the GUI (even managing packages can be done through DrRacket). I agree with explaining both DrRacket and raco, but why can't users just pick the one they are more comfortable with and ignore the other (and maybe come back later to it)? I think the biggest problem is that so many people have very low computer literacy. You will never see a book or web tutorial explaining concepts like clicking, right-clicking, drag&drop or double-clicking because those are so essential to using a computer. However, few people know how to use the CLI, even though it allows you to automate and combine things in a way a GUI cannot. You don't even have to be a programmer to find the CLI useful. On Sunday, April 1, 2018 at 6:57:46 PM UTC+2, Stephen Smith wrote: > > 2. @HiPhish: "Users should learn the command-line first". Although I agree > with this in almost any other context, my book is for people who have never > programmed before. So they will be learning the command-line and GUI at the > same time (they have no choice in the matter ;-). In my opinion though, > raco is an essential command line tool to teach new Racketeers so at least > in my case the GUI alone will not suffice. And my book is not really a > "Racket" book per se - Racket is just a tool to achieve the end goal. Which > probably requires further explanation ... > -- 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.
[racket-users] Re: Why is there a space in the path to the Racket application on MacOSX?
On Sunday, April 1, 2018 at 12:57:46 PM UTC-4, Stephen Smith wrote: > > It's been a long tough road as to which implementation language to choose > for it. I'm down to two now after much experimenting - Racket of course, > and Smalltalk. > Now you have me wondering which is harder, implementing Smalltalk in Racket, or the other way around. -- 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.
[racket-users] Re: Why is there a space in the path to the Racket application on MacOSX?
Lots of good advice and opinions here. Thanks everyone. I'll try to respond to all of them in some way ... 1. @David K. Storrs and @Eric Eide: Renaming the folder. This works for sure but _my_ preference is to use a symlink (as Eric also mentioned) as it doesn't touch the original folder layout. On a Mac I simply use 'ln -s /Applications/Racket\ v6.12/ /usr/local/racket' and then add '/usr/local/racket/bin' to my path (via one of the .bash* files or /etc/paths for a system-wide setting). /Applications/Racket as a symlink also works. This is the approach I will likely take in the book as I believe that maintaining the original folder layout is a good practice to teach newcomers (and that's what symlinks were invented for, right? :-). Though for experienced users, renaming the folder is certainly just as effective as you'll probably know how to handle problems that can arise from taking that approach. 2. @HiPhish: "Users should learn the command-line first". Although I agree with this in almost any other context, my book is for people who have never programmed before. So they will be learning the command-line and GUI at the same time (they have no choice in the matter ;-). In my opinion though, raco is an essential command line tool to teach new Racketeers so at least in my case the GUI alone will not suffice. And my book is not really a "Racket" book per se - Racket is just a tool to achieve the end goal. Which probably requires further explanation ... 3. @Matthew Butterick: my (book) project is for model railroad hobbyists (many if not most who have never programmed before). I want to teach them to build a computer-based model railroad. I'm currently helping to maintain www.railwayoperationsimulator.com (a C++ project) which is a signalling simulator. I stumbled on that project while looking for ideas on how to model track and decided to hang around for awhile :-). My book will focus on a couple of different types of simulation though. I've had the project in the works for several years now. I've only just recently had the opportunity to work on it in any serious capacity. It's been a long tough road as to which implementation language to choose for it. I'm down to two now after much experimenting - Racket of course, and Smalltalk. Heavily inspired by htdp and I've just started to look at Beautiful Racket. Former contenders were C++ (wxWidgets), Rust, Ada, Eiffel, Tcl/Tk and Pascal (using FreePascal and Lazarus). I've taken the approach to writing the first chapter in both Racket and Squeak Smalltalk. I'll post those up when they are complete, and see what kind of response I get from potential readers as to which language is more likely to work best. If I get ambitious enough I may try to write two books simultaneously though I'm sure most would discourage me from doing that (and rightfully so). I just find both approaches have so many advantages - it's very difficult to choose just one. Cheers, Stephen Smith. On Thursday, March 29, 2018 at 3:51:07 PM UTC-4, Stephen Smith wrote: > > Authoring a new Racket book (targeting all platforms and non-programmers) > and having to tell users to quote paths with spaces to be able to use the > command-line tools seems distracting and an unnecessary complexity to > impose on them. > > Reference this post: > https://groups.google.com/d/msg/racket-users/2-ASoQ03x9Q/AXQyV4MTx0EJ by > Matthew Johnson. > > From a *nix perspective, it just seems like 'bad practice' to have folder > names with spaces? Though, devil's advocate, I get that underscores or > combined words can be unsightly, especially on a Mac where there are > hard-core design people to contend with (I can hear them now, "It doesn't > look nice in Finder" :-) but for Mac apps that have command-line tools it > seems more common to not have spaces in the folder name leading to a bin > folder. > > Is there a particular reason why Racket uses a space in its folder name? > > Cheers, > 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. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Simple loop control
Take at look at Racket's `for' loops. They are very flexible. The reference: http://docs.racket-lang.org/reference/for.html?q=for#%28form._%28%28lib._racket%2Fprivate%2Fbase..rkt%29._for%29%29 The guide with examples: http://docs.racket-lang.org/guide/for.html On Sun, Apr 1, 2018 at 10:14 AM, 若草春男 wrote: > Hi, everyone. > > I want to write loops simpler. > > > (do ([i 1 (add1 i)]) ([= i 10]) (display i)) > 123456789 > > (for-each (lambda (i) (display i)) (range 1 10)) > 123456789 > > In Common Lisp, I like the extended loop like "for" of C-language. > > [3]> (loop for i from 1 below 10 do (print i)) > > 1 > 2 > 3 > 4 > 5 > 6 > 7 > 8 > 9 > NIL > > Please tell me the best solution. > > Haruo > > -- > 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. > -- 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.
[racket-users] Simple loop control
Hi, everyone. I want to write loops simpler. > (do ([i 1 (add1 i)]) ([= i 10]) (display i)) 123456789 > (for-each (lambda (i) (display i)) (range 1 10)) 123456789 In Common Lisp, I like the extended loop like "for" of C-language. [3]> (loop for i from 1 below 10 do (print i)) 1 2 3 4 5 6 7 8 9 NIL Please tell me the best solution. Haruo -- 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.
[racket-users] Re: Implementation of threading macros
Thanks for your advice, Alex. I'll be used to require point-free package. -- 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.