Re: [racket-users] Why is there a space in the path to the Racket application on MacOSX?

[Philip McGrath]

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

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

Re: [racket-users] Why is there a space in the path to the Racket application on MacOSX?

[Stephen Smith]

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 

Re: [racket-users] Why is there a space in the path to the Racket application on MacOSX?

[Stephen Smith]

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.

Re: [racket-users] Why is there a space in the path to the Racket application on MacOSX?

[Matthias Felleisen]

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

Re: [racket-users] Why is there a space in the path to the Racket application on MacOSX?

[Matthew Flatt]

At Sat, 31 Mar 2018 06:45:29 -0400, Philip McGrath wrote:
> My current approach is to put a file containing "/Applications/Racket
> v6.12/bin" in /etc/paths.d, which adds it to the default PATH for all users.

I recommend that approach, because it's simple, reliable, and easy to
adjust when you're ready to switch to a new version. Note that you
don't have to perform any quoting in the content of the file in
"/etc/paths.d".

We've experimented with an installer package that creates
"/etc/paths.d/racket" as it installs Racket into "/Applications/Racket
vX". But since the installer's only benefit is creating "/etc/paths.d",
and since the installer takes away a user's ability to choose where
Racket is installed, we've never switched the main distribution to that
mode.

FWIW, Racket used to be called "PLT Scheme", with a space in its name
--- so there was no question back then whether the folder in
"Applications" should have a space in its name when following Mac
conventions. And we kept following the numbering style for "Racket"
folders, because it still looks right to have a space.

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

[Philip McGrath]

My current approach is to put a file containing "/Applications/Racket
v6.12/bin" in /etc/paths.d, which adds it to the default PATH for all users.

Personally, I'm command-line-oriented enough that I try to avoid spaces and
special characters in file names I'm likely to work with from the command
line, but:

   1. I believe Apple has some guideline encouraging file names to use
   spaces, capital letters, etc. rather than underscores and other workarounds.
   2. If you are writing a shell script, there are so many special
   characters that can cause problems that you really do have to properly
   quote your paths (or write the script in Racket instead, which is happy to
   deal with arbitrary characters in paths).


-Philip

On Sat, Mar 31, 2018 at 6:22 AM, Geoffrey Knauth  wrote:

> Every time I download a new version of Racket, I put it in:
> /Applications/Racket/
> The first thing I do is replace the space in the name with a hyphen.
> On the more comand-liney side of things, I put
> /usr/local/racket/latest/bin in my PATH.
> Currently I have:
>
> $ which racket
> /usr/local/racket/latest/bin/racket
> $ ls -l /usr/local/racket
> lrwxr-xr-x ... Jan 27 09:08 Racket-v6.12@ -> /Applications/Racket/Racket-
> v6.12
> lrwxr-xr-x ... Jan 27 09:08 Racket-v6.12.0.3@ ->
> /Applications/Racket/Racket-v6.12.0.3
> lrwxr-xr-x ... Mar 27 10:58 Racket-v6.90.0.23@ ->
> /Applications/Racket/Racket-v6.90.0.23
> lrwxr-xr-x ... Mar 27 10:55 latest@ -> Racket-v6.90.0.23
>
>
> On Thursday, March 29, 2018 at 4:20:02 PM UTC-4, David K. Storrs wrote:
>>
>> Second the desire for this not to be the case.  Personally, my
>> solution is just to rename the folder after installing it.  I am
>> currently working with binaries from
>> /Applications/Racket_v6.11/bin/...
>>
> --
> 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.

Re: [racket-users] Why is there a space in the path to the Racket application on MacOSX?

[Geoffrey Knauth]

Every time I download a new version of Racket, I put it in:  
/Applications/Racket/
The first thing I do is replace the space in the name with a hyphen.
On the more comand-liney side of things, I put /usr/local/racket/latest/bin 
in my PATH.
Currently I have:

$ which racket
/usr/local/racket/latest/bin/racket
$ ls -l /usr/local/racket
lrwxr-xr-x ... Jan 27 09:08 Racket-v6.12@ -> 
/Applications/Racket/Racket-v6.12
lrwxr-xr-x ... Jan 27 09:08 Racket-v6.12.0.3@ -> 
/Applications/Racket/Racket-v6.12.0.3
lrwxr-xr-x ... Mar 27 10:58 Racket-v6.90.0.23@ -> 
/Applications/Racket/Racket-v6.90.0.23
lrwxr-xr-x ... Mar 27 10:55 latest@ -> Racket-v6.90.0.23


On Thursday, March 29, 2018 at 4:20:02 PM UTC-4, David K. Storrs wrote:
>
> Second the desire for this not to be the case.  Personally, my 
> solution is just to rename the folder after installing it.  I am 
> currently working with binaries from 
> /Applications/Racket_v6.11/bin/... 
>

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

[Norman Gray]

Greetings.

On 30 Mar 2018, at 15:44, David Storrs wrote:

On Thu, Mar 29, 2018 at 5:54 PM, HiPhish  
wrote:


I think you are trying to solve the wrong problem. If people want to 
use a
command-line tool they should know how to use the command line first. 
They


[...]



I look at it the other way:  there are clear benefits to NOT having
names containing characters that need to be quoted, so any use of such
characters has an opportunity cost.  What benefit does the space
provide that outweighs that opportunity cost?


I think the main benefit is simply that it looks nice.

OSX ^W macOS is primarily [1] designed for GUI users.  The Finder has no 
problem with files containing spaces, or other bash-annoying characters 
such as various brackets, dollar-signs and ampersands.  I can name a 
file 'A $/€/£ conversions (2017)' and not think twice about it.  
Spaces in the Racket installation locations represent a mild 
inconvenience only to the minority of users (including me) who use the 
command line more than the Finder, and we, to a first approximation, 
don't count.


If I find such a name inconvenient, then I can either find the tab key 
on my keyboard, or add a symlink somewhere convenient (as suggested 
above, and what I actually do), or else learn to love the bit of the 
bash manual about quoting arguments (which one should do anyway, when 
writing half-way-careful scripts).


Catering to command-line users in this way, and naming 
A-and-B_USD-EUR-GPB_conversions-2017 is frankly ugly, significantly less 
readable, unintelligibly obscure for anyone who doesn't have 
bash-expansion intuitions, and is still something I'd use the tab 
character to complete when typing.


Best wishes,

Norman


[1] ...for some value of 'primarily' which might not survive close 
examination


--
Norman Gray  :  https://nxg.me.uk

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