> On Feb 20, 2017, at 11:02, Matthias Felleisen <matth...@ccs.neu.edu> wrote:
> 
> 
>> On Feb 20, 2017, at 1:53 PM, John Clements <cleme...@brinckerhoff.org> wrote:
>> 
>> No, I don’t think you missed anything, but from the standpoint of those 
>> teaching early classes in either Java or Python (a standpoint that I 
>> understand you are generally and mercifully not compelled to adopt),
> 
> 
> Yes. As a you know well, I firmly believe that such courses should be taught 
> with teaching languages that are best suited for beginners. No of-the-rack 
> language is good enough for the job. One of the things we should show 
> students is that existing languages are bad (in many different regards). It’s 
> the second course that should make students chafe against the (low) moral 
> compromises of existing languages (Java, Python), because we owe them an 
> introduction to the baddities of the real world. (Is this a bad neologism?) 
> 
> In this spirit . . . 
> 
> 
>> it seems that there’s a missing piece in unit testing frameworks: namely, 
>> the default check-expect form in these languages should not be one that 
>> refers to the notion of outside-of-module-extensional equality, but rather 
>> one that refers to inside-of-module-extensional equality, as check-expect 
>> does. I’d be tempted to call this notion of equality “testing equality,” but 
>> I’ve been called out before on my barbarous neologisms. (Not sure this one 
>> would be considered barbarous, at any rate.) Additionally, students should 
>> probably not be required to implement this notion of equality by hand. 
>> Sounds like a nice three-page position paper, probably not good enough for 
>> ITICSE, maybe SIGSCE (sigh).
> 
> 
> Did Viera Proulx’s testing framework and its reliance on reflection solve the 
> problem for Java? Given that both languages do come with reflection 
> capabilities (this makes me want to include #%app and #%module-begin in ISL 
> so we can discuss good language interposition strategies), the question is 
> 
>       can you mimic Racket’s approach to inside-testing and 
> outside-observation? 
> 
> Then you can turn your 3-pager into a real paper. Or someone has already done 
> it. 

Well, thank you for reminding me of Viera’s framework. Reflection seems like 
the Wrong Way to implement this, if you have the option of using macros. Are 
Java’s macros still not up to this task?

Also, when you refer to Racket’s approach to inside-testing and 
outside-observation, are you referring to the combination of equal? and the 
ability to provide an externally-visible equality relation? Or are you 
referring to inspectors?

Related: I feel as though five years ago, this code evaluated to #t:

(define-struct foo (a b))

(equal? (make-foo 3 4)
        (make-foo 3 4)) 

… which, I suppose, only goes to show that I don’t understand Racket’s notion 
of equality well either.

John

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

Reply via email to