I just pushed a commit that updates the error messages of the teaching
languages. With this update, *SL now agrees with the rules of the error
message
composition guidelines we sent last month.
If you try the *SL languages from the git repository, you will now see that
the
error messages restrain
At Wed, 6 Jul 2011 05:59:30 -0400, Guillaume Marceau wrote:
> [3]There is a layout problem in my new documentation I need help with.
> I
> tried to abstract the common text between the documentation of the
> different levels.
It's possible that the HtDP languages should be differe
On Wed, Jul 6, 2011 at 9:14 AM, Matthew Flatt wrote:
> In the case of the HtDP languages, was the choice to duplicate all the
> text deliberate, or was it a side-effect of some other change?
Yes, this was a deliberate move away from the no-duplication style
used in the professional documentation,
At Wed, 6 Jul 2011 09:36:35 -0400, Guillaume Marceau wrote:
> On Wed, Jul 6, 2011 at 9:14 AM, Matthew Flatt wrote:
> > In the case of the HtDP languages, was the choice to duplicate all the
> > text deliberate, or was it a side-effect of some other change?
>
> Yes, this was a deliberate move away
Why is it pedagogical to repeat information in the
ISL documentation that the BSL documentation already
presented?
-- Matthias
On Jul 6, 2011, at 9:36 AM, Guillaume Marceau wrote:
> On Wed, Jul 6, 2011 at 9:14 AM, Matthew Flatt wrote:
>> In the case of the HtDP languages, was the choice
If you read the documentation as a textbook when you start
programming, I can see wanting to see something that says "cond is the
same as before". But, if you read the documentation as a reference
when you have a problem it is frustrating to chase through a few links
to get the "real" documentation
If it is a click away and if the idea is that students got to B because they
went thru A?
I admit that there are instructors who use only ISL+ or ASL. But should we
accommodate the special ones or the ones that use the language hierarchy as
intended?
On Jul 6, 2011, at 5:51 PM, Jay McCa
A click away can be one too many. Students have enough difficulty
finding documentation as it is. The reference for ISL cond should
include all the necessary details of ISL cond. How about we have a
note saying that ISL cond is the same as ASL cond, then write it all
out anyway. And presumably
On Jul 6, 2011, at 7:11 PM, Carl Eastlund wrote:
> A click away can be one too many. Students have enough difficulty
> finding documentation as it is. The reference for ISL cond should
> include all the necessary details of ISL cond. How about we have a
> note saying that ISL cond is the same
On Wed, Jul 6, 2011 at 7:11 PM, Carl Eastlund wrote:
> A click away can be one too many. Students have enough difficulty
> finding documentation as it is.
Yes...
On Wed, Jul 6, 2011 at 5:51 PM, Jay McCarthy wrote:
> But, if you read the documentation as a reference
> when you have a problem i
Jay McCarthy writes:
> If you read the documentation as a textbook when you start
> programming, I can see wanting to see something that says "cond is the
> same as before". But, if you read the documentation as a reference
> when you have a problem it is frustrating to chase through a few links
25 minutes ago, Michael Sperber wrote:
> For the record, I fully agree with Guillaume. I was puzzling over
> the exact same issue when I was doing the docs for the DMdA teaching
> languages, came out with the exact same reasoning as Guillaume, and
> ran against the exact same problem (as Eli may r
Eli Barzilay writes:
> 25 minutes ago, Michael Sperber wrote:
>> For the record, I fully agree with Guillaume. I was puzzling over
>> the exact same issue when I was doing the docs for the DMdA teaching
>> languages, came out with the exact same reasoning as Guillaume, and
>> ran against the ex
Four minutes ago, Michael Sperber wrote:
> Eli Barzilay writes:
> > It's just code, so you do have direct support.
>
> Yeah, well, except you run into trouble almost immediately because
> that code contains references, and Scribble is sensitive to all
> kinds of side conditions involving referenc
Eli Barzilay writes:
>> Yeah, well, except you run into trouble almost immediately because
>> that code contains references, and Scribble is sensitive to all
>> kinds of side conditions involving references.
I'm talking about the references to identifiers, and sections.
Guillaume and I want pur
9 minutes ago, Michael Sperber wrote:
>
> Eli Barzilay writes:
>
> >> At the time, you proposed a complicated macro to work around the
> >> ensuing problems.
>
> No, it was you. This must have been in 2009.
Now I'm even more curious. Pointer?
--
((lambda (x) (x x)) (lambda (x) (x
On Thu, Jul 7, 2011 at 2:48 AM, Michael Sperber wrote:
>
> Eli Barzilay writes:
>
>>> Yeah, well, except you run into trouble almost immediately because
>>> that code contains references, and Scribble is sensitive to all
>>> kinds of side conditions involving references.
>
> I'm talking about the
On 07/06/2011 03:59 AM, Guillaume Marceau wrote:
[...]
[2]If you are the author of a teachpack, please update your error
messages
to match this new style. You can follow the error message completion
guidelines, which are now in the main documentation under the "How to
D
Robby Findler writes:
> On Thu, Jul 7, 2011 at 2:48 AM, Michael Sperber
> wrote:
>>
>> Eli Barzilay writes:
>>
Yeah, well, except you run into trouble almost immediately because
that code contains references, and Scribble is sensitive to all
kinds of side conditions involving r
I've clarified with Mike the problem, and that email. For reference,
that email had a macro that had some complication in that it
implemented a raw `include' with scribble syntax -- but putting the
code inside a scribble file makes that unnecessary.
So there are two problems: the first is that he
On Jul 7, 2011, at 5:31 AM, Ryan Culpepper wrote:
> On 07/06/2011 03:59 AM, Guillaume Marceau wrote:
>>
>> [...]
>>
>> [2]If you are the author of a teachpack, please update your error
>> messages
>> to match this new style. You can follow the error message completion
>> guideli
Two minutes ago, Matthias Felleisen wrote:
>
> I clarified personally but for 'dev' in general. There should be
> three sets of docs:
>
> 1. HtDP teachpacks --- for students
>
> 2. How to Design HtDP Teachpack -- for teachers courageous enough to
>implement teachpacks
I love the pun (and th
>>> I'm talking about the references to identifiers, and sections.
>>> Guillaume and I want pure, verbatim duplication of a piece of
>>> documentation.
>>
>> Is the issue is that you want the links in one copy of the docs to go
>> to one place and the links in another copy to go in another place an
On Thu, Jul 7, 2011 at 11:49 AM, Guillaume Marceau wrote:
I'm talking about the references to identifiers, and sections.
Guillaume and I want pure, verbatim duplication of a piece of
documentation.
>>>
>>> Is the issue is that you want the links in one copy of the docs to go
>>> to
At Wed, 6 Jul 2011 05:59:30 -0400, Guillaume Marceau wrote:
> [3]There is a layout problem in my new documentation I need help with.
> I
> tried to abstract the common text between the documentation of the
> different levels. Possibly because I didn't do it correctly, the macro
> I
> Fix pushed.
Thanks.
> Some remaining issues:
>
> * ISL's "Syntax" section lists syntax that was already in B+SL.
>
> * ASL incorrectly specifies >= 1 arguments required for functions and
> function calls (i.e., functions and call are not common syntax at
> that point).
>
> * The order o
At Sat, 9 Jul 2011 01:59:31 -0400, Guillaume Marceau wrote:
> > * Expanding `expr' to `expression' means that the grammar tables don't
> > fit in the available width. (Is `expr' as an abbreviation confusing
> > to students?)
>
> In general, yes, abbreviations are a big speed bump for students
On Thu, Jul 7, 2011 at 12:44 PM, Matthew Flatt wrote:
> * ASL incorrectly specifies >= 1 arguments required for functions and
> function calls (i.e., functions and call are not common syntax at
> that point).
>
Stephen pointed out that function calls in BSL can invoke functions of
zero argume
I'd much prefer eliminating such function calls.
On Jul 11, 2011, at 6:28 PM, Guillaume Marceau wrote:
> On Thu, Jul 7, 2011 at 12:44 PM, Matthew Flatt wrote:
>> * ASL incorrectly specifies >= 1 arguments required for functions and
>> function calls (i.e., functions and call are not common
On Mon, Jul 11, 2011 at 6:32 PM, Matthias Felleisen
wrote:
> I'd much prefer eliminating such function calls.
Do you want them out in this release?
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Whoa, whoa there. They're there for a reason. I can't remember why,
but I am pretty certain I have actually used such a function. Please
don't go around chopping and changing the language a few days before
the deadline.
On Mon, Jul 11, 2011 at 7:21 PM, Guillaume Marceau wrote:
> On Mon, Jul 11
Yes, they're useful for 'teachpacks' like the Kiva teachpack...
(https://github.com/nadeemabdulhamid/Kiva-Teachpack)
On Mon, Jul 11, 2011 at 7:28 PM, Shriram Krishnamurthi
wrote:
> Whoa, whoa there. They're there for a reason. I can't remember why,
> but I am pretty certain I have actually use
It's way too late for this release but I consider this a wart
On Jul 11, 2011, at 7:21 PM, Guillaume Marceau wrote:
> On Mon, Jul 11, 2011 at 6:32 PM, Matthias Felleisen
> wrote:
>> I'd much prefer eliminating such function calls.
>
> Do you want them out in this release?
_
On Jul 11, 2011, at 6:32 PM, Matthias Felleisen wrote:
I'd much prefer eliminating such function calls.
What harm do they do? You can't call any library function with the
wrong number of arguments, and you can't define a zero-argument
function. The only way this affects a BSL student is
Precisely.
On Tue, Jul 12, 2011 at 6:10 AM, Stephen Bloch wrote:
>
> On Jul 11, 2011, at 6:32 PM, Matthias Felleisen wrote:
>
> I'd much prefer eliminating such function calls.
>
> What harm do they do? You can't call any library function with the wrong
> number of arguments, and you can't defin
At Mon, 11 Jul 2011 18:28:56 -0400, Guillaume Marceau wrote:
> On Thu, Jul 7, 2011 at 12:44 PM, Matthew Flatt wrote:
> > * ASL incorrectly specifies >= 1 arguments required for functions and
> > function calls (i.e., functions and call are not common syntax at
> > that point).
> >
>
> Stephen
I am with your initial thoughts.
I find this inconsistency disturbing.
I also wish to use BSL as a language that is isomorphic to the kind of
mathematics that students see in middle school and high school. (I think of
structs as generalized Cartesian points, i.e., something comprehensible in
On Thu, Jul 7, 2011 at 12:44 PM, Matthew Flatt wrote:
> * All contracts for primitives print as lists.
I traced this down to the change from (require scheme/pretty) to
(require racket/pretty).
I don't understand how that's causing the bug, but reverting to
(require scheme/pretty) fixes things.
In racket/pretty, pretty-print is like print and pretty-write is like
write. In scheme/pretty, pretty-print is like write.
So probably the better change is to stick with racket/pretty and use
pretty-write instead of pretty-print.
Robby
On Wed, Jul 13, 2011 at 9:57 PM, Guillaume Marceau wrote:
>
On Thu, Jul 14, 2011 at 12:00 AM, Robby Findler
wrote:
> In racket/pretty, pretty-print is like print and pretty-write is like
> write. In scheme/pretty, pretty-print is like write.
>
> So probably the better change is to stick with racket/pretty and use
> pretty-write instead of pretty-print.
Do
10 hours ago, Guillaume Marceau wrote:
> On Thu, Jul 14, 2011 at 12:00 AM, Robby Findler
> wrote:
> > In racket/pretty, pretty-print is like print and pretty-write is
> > like write. In scheme/pretty, pretty-print is like write.
> >
> > So probably the better change is to stick with racket/pretty
Are the SIGNATURES in the beginner funs definitions and elsewhere
fed to Mike's signature checker? If so, we need to roll back a commit
I made for a small change to atan and that Eli just rolled over to the
release.
If not, it's okay.
On Jul 13, 2011, at 11:57 PM, Guillaume Marceau wrote:
5 minutes ago, Matthias Felleisen wrote:
>
> Are the SIGNATURES in the beginner funs definitions and elsewhere
> fed to Mike's signature checker? If so, we need to roll back a
> commit I made for a small change to atan and that Eli just rolled
> over to the release.
>
> If not, it's okay.
The c
Matthias Felleisen writes:
> Are the SIGNATURES in the beginner funs definitions and elsewhere
> fed to Mike's signature checker? If so, we need to roll back a commit
> I made for a small change to atan and that Eli just rolled over to the
> release.
You mean those in the documentation? No.
On Sat, Jul 9, 2011 at 10:17 AM, Matthew Flatt wrote:
> I see that `case' is the only one in a blue box that doesn't fit, but I
> meant the grammar at the start of each language section. It doesn't fit
> for any of the languages on my machines (i.e., some line extends
> further than the beige bar
45 matches
Mail list logo
