[racket] #lang

From: Jos Koot (jos.koot at telefonica.net)
Date: Sun May 15 11:44:24 EDT 2011

Racket is not a language, it is a collection of languages (MHO) I am very
pleased with the #lang or #!... line on top of my modules. I must admit that
I run all of my programs under control of DrRacket, although I don't have
much problems running my programs by means of Gracket.exe nor by making
executables (which may, of course, require the correct mode of making the
executable) I think we have to accept that Racket is not Scheme (It does
include R6RS, but I prefer #lang racket, which no longer is a small
language, but still can be used as though it were a small language)

> -----Original Message-----
> From: users-bounces at racket-lang.org 
> [mailto:users-bounces at racket-lang.org] On Behalf Of Stephen Bloch
> Sent: 15 May 2011 15:36
> To: Racket Users
> Subject: Re: [racket] #lang
> Eli writes:
> >> I'd rather have my
> >> students' files start with
> >> #lang bsl
> >> or 
> >> #lang isll
> >> or something, as long as my students don't need to SEE that.
> > 
> > -1.
> I presume the part you don't like is "my students don't need 
> to SEE that"?
> I'm not suggesting that the choice of language should be 
> invisible and inaccessible, only that the #lang syntax should 
> be invisible much (if not all) of the time.
> For example, there might be a display near the top of the 
> DrRacket window saying at all times what language we're in, 
> without the word "#lang".  If you want to change it, you 
> click on that display and type in a new language choice, 
> still without the word "#lang".  If it's not recognized, you 
> get an immediate error message.  The language choice menu, if 
> it still exists, would be just a shortcut for filling in one 
> of several guaranteed-to-exist languages.  You NEVER see the 
> #lang line in the Definitions pane.
> >> Could we have a menu option in DrRacket to hide or show the #lang
> >> line (perhaps in a separate pane)?
> > 
> > -1.
> > 
> > As Shriram said, this is similar to how the language choice 
> is encoded
> > in current teaching language files, and it leads to bad surprises --
> > weird errors if you do add a `#lang' in the part that you do see
> That's a simple syntax error: "#lang blah" isn't legal syntax 
> inside a module, in any language that I know of.  One could 
> give it a clear, informative error message:  in racket, "You 
> have two #lang lines in the same source file," and in 
> DrRacket, something like "You've already specified the 
> language in the language display at the top of the window".
> However, people are much less likely to put a "#lang" into 
> the part that they do see if they've never seen the word 
> "#lang", as would be true of DrRacket-using students.  Those 
> that use a vanilla text editor can clearly see that they've 
> got two of them.
> > surprises when you edit the file outside of DrRacket
> See above.
> > , and confusions when you copy-paste the code and send it 
> to someone else.
> Yes, copy-and-paste is a problem.  If you copy-and-paste from 
> one DrRacket window into another, they both presumably have 
> (hidden) #lang lines, so things should be clear (either 
> they're in the same language and everything works, or they're 
> explicitly in different languages and you deserve what you 
> get).  If you copy-and-paste from DrRacket into a text file 
> and then use that text file in racket or DrRacket, DrRacket 
> will have to use its default language (see below).
> >> For the benefit of beginning students, I'd like to keep 
> the language
> >> selection menu, but its effect would be to alter the (hidden) #lang
> >> line.
> > 
> > IME, the language dialog is currently a major source of 
> confusion.  It
> > tempts people to choose languages that they shouldn't choose
> I'm not wedded to it myself, but I think it can be clearer 
> and more transparent than it is now.  I'm suggesting getting 
> rid of "Use the language declared in the source", because 
> that would ALWAYS be true.  The menu, if it continues to 
> exist, would be just shortcuts to some suggested languages.  
> And if everything on this menu can also be invoked from 
> #lang, that list could be trimmed down to only the ones used 
> by significant numbers of beginners: say, the HtDP and 
> DeinProgramm teaching languages and racket.
> The one UI drawback to this proposal (that I see) is that if 
> one is currently in a language that isn't on the menu, 
> nothing in the menu would be checked.  One could switch from 
> it to a "standard" language using the menu but wouldn't be 
> able to get back using the menu; you'd need to click the 
> language display and type in the language name.  However, 
> this would only affect people already using a language that's 
> not in the menu, which means they must have used the manual 
> override before, and they should be able to use it again.
> > BTW, to put these negatives in more perspective -- a *lot* 
> of work has
> > been put to make the `#lang' lines very simple -- easy to remember,
> > and easy to write.  So I view removing them from the user's explicit
> > reach and instead leaving it for some gui to generate as something
> > that goes against the whole idea of `#lang'.
> Shriram writes:
> > If you really wanted to accommodate all comers,
> > 
> > - no #lang => language is BSL
> > - all other languages need their own #lang line
> Yes, that makes some sense.  Philosophically, one would 
> rather have the default language be racket -- I can imagine 
> the howls of protest from somebody like Elliott who starts up 
> racket or DrRacket, types in the first example from some 
> non-HtDP Scheme book, and gets an error message because it's 
> not in BSL.  But as a teacher, I'd want BSL to be extremely 
> easy to get to.
> > (Of course I'm glossing over the #lang bsl =/= BSL from 
> menu, which is
> > a real annoyance.)
> How much difference is there?  Can we fix it?
> Stephen Bloch
> sbloch at adelphi.edu
> _________________________________________________
>   For list-related administrative tasks:
>   http://lists.racket-lang.org/listinfo/users

Posted on the users mailing list.