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
sbl...@adelphi.edu


_________________________________________________
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/users

Reply via email to