[racket-users] Re: get-file-list filter

2017-02-20 Thread Alex Harsanyi 
On Tuesday, February 21, 2017 at 11:52:49 AM UTC+8, Lehi Toskin wrote:
> In `get-file-list`  there is a filter argument that can be passed to the 
> function such that when going through a directory it'll only list directories 
> and those files in the filter (separated by a semicolon). This can get rather 
> unruly when the filter is rather large. At current count, I have a filter of 
> 14 different file extensions accounting for spelling or case (e.g. 
> "*.jpg;*.jpeg;*.JPG;*.JPEG"). Is there a way to do this more 
> programmatically? I don't mean using a procedure to create the string, but 
> that instead of a string it'd be, say, a predicate.
> 
> In various GUI programs, the selection would be simply "All Images" or "Any" 
> without specifying exactly what list of file extensions it's filtering. I 
> suppose that behavior itself is fine, which would mean hiding the file 
> extensions from the filter choice and only showing the name of the filter.

The documentation for get-file-list (well, actually get-file) suggests that it 
uses a platform specific dialog box.  On windows platforms, I suspect  that 
would be GetOpenFileName which accepts filter string in the same format as 
required by get-file-list.  It is likely that the filter is passed directly to 
the windows function and as such, it has to be a string.

This was just a long way of saying that you cannot have a predicate for the 
filter, at least not while using the platform specific "File Open" dialog boxes.

However, the documentation does have an example for a shorted pattern for JPEG 
files: "*.jp*g"

Best regards,
Alex.

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

[racket-users] get-file-list filter

2017-02-20 Thread Lehi Toskin 
In `get-file-list`  there is a filter argument that can be passed to the 
function such that when going through a directory it'll only list directories 
and those files in the filter (separated by a semicolon). This can get rather 
unruly when the filter is rather large. At current count, I have a filter of 14 
different file extensions accounting for spelling or case (e.g. 
"*.jpg;*.jpeg;*.JPG;*.JPEG"). Is there a way to do this more programmatically? 
I don't mean using a procedure to create the string, but that instead of a 
string it'd be, say, a predicate.

In various GUI programs, the selection would be simply "All Images" or "Any" 
without specifying exactly what list of file extensions it's filtering. I 
suppose that behavior itself is fine, which would mean hiding the file 
extensions from the filter choice and only showing the name of the filter.

-- 
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] Programming paradigms

2017-02-20 Thread Rusi Mody 
On Thursday, February 16, 2017 at 9:46:53 PM UTC+5:30, David K. Storrs wrote:
> I find PP to be a useful tool for thinking about programming, but not 
> terribly significant in everyday use -- my code will typically end up as a 
> mixture of functional, declarative, procedural, and OO.  The fact that Racket 
> makes it easy to mix all of these is one of its many appeals.

If you had said aspects I would have agreed
Appeal?? Not so sure
Take python
One can (as a user) use a facility f(x,y) or x.f(y)
And so as a programmer this choice exists: Which form of f should I provide?
Sure this choice exists but are there not more important choices for a student 
(especially a beginner) to grapple with?

More trivially (no I am not being facetious):
def f(x): return x

and

def g(x): print x

SEEM to be the same
And its an unnecessary time waster for teachers to have to tell students to
prefer the first over the second — hard given all the zillions of 
print "Hello World"
in existence

See also Paradox of Choice: https://en.wikipedia.org/wiki/The_Paradox_of_Choice
[Ironically a wikipedia link]

And thanks Matthias for the Sriram paper and book

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

[racket-users] Re: Can raco distribute produce a single executable?

2017-02-20 Thread Alex Harsanyi 
On Tuesday, February 21, 2017 at 3:12:50 AM UTC+8, lu wrote:
> Hi all, I have this little toy project[1] to help me learn the language. I 
> would like to produce a single portable executable that can be executed 
> without reliance on racket installation. `raco distribute` does produce a 
> "package" folder. But for small utility tool like this, I would prefer a 
> simple standalone executable file rather than a folder, so I can just drop it 
> into a directory on `PATH` on the target machine and run it.

I don't think this is possible.  You have two options: create the distribution 
(which you already did), or just install Racket and run the program from source 
(on windows you can write a batch file to run the program using racket).

This situation is no different than in other languages such as Python, where 
you would have to install the Python distribution to be able to run small 
programs.

Best Regards,
Alex.

-- 
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] intensional equality and unit tests

2017-02-20 Thread Matthias Felleisen 

> On Feb 20, 2017, at 2:27 PM, Sam Tobin-Hochstadt  wrote:
> 
> Maybe that's true, but I haven't wanted to do that in my Racket code
> using either `check-expect` in class or `check-equal` in Rackunit (or
> at least, not enough to define a new abstraction for it). Have you
> tried making a testing framework to accommodate this better?


I have wanted this, and have done this, many times. But I will say that it 
doesn’t come that easy in Racket either. 

-- 
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] Can raco distribute produce a single executable?

2017-02-20 Thread lu 
On Monday, February 20, 2017 at 11:24:50 AM UTC-8, Shu-Hung You wrote:
> Sorry, I saw that you're already using raco exe and raco distribute.
> So is the problem related to some DLL issue on Windows?
> 
> Best,
> Shu-Hung
> 
> On Mon, Feb 20, 2017 at 1:19 PM, Shu-Hung You
>  wrote:
> > https://docs.racket-lang.org/raco/exe.html
> > Is raco exe in this page what you want? Just type
> >
> >> raco exe q.rkt
> >
> > And this command will produce a single executable. Now we can now run
> >
> >> ./q
> > q: expects 1  on the command line, given 0 arguments
> >
> > Best,
> > Shu-Hung
> >
> > On Mon, Feb 20, 2017 at 1:12 PM, lu  wrote:
> >> Hi all, I have this little toy project[1] to help me learn the language. I 
> >> would like to produce a single portable executable that can be executed 
> >> without reliance on racket installation. `raco distribute` does produce a 
> >> "package" folder. But for small utility tool like this, I would prefer a 
> >> simple standalone executable file rather than a folder, so I can just drop 
> >> it into a directory on `PATH` on the target machine and run it.
> >>
> >> For the start I'm looking at solving this problem for Windows 
> >> specifically, but am also interested in a solution on other systems.
> >>
> >> Thanks!
> >>
> >>
> >> [1]: https://github.com/kflu/q
> >>
> >> --
> >> 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.

No, there's nothing wrong with DLL issue on Windows specifically. It's the way 
how `raco exe` is designed to work.

The executable produced with `raco exe` is not portable to another machine of 
the same OS without Racket installed. More specifically, if you look at the 
distribution `raco distribute` produce, it includes essential dependencies for 
running the application, e.g., the GC lib `libracket3m_a1zjsw.dll`. If you run 
the executable from another machine where Racket isn't installed, you get (at 
least) an error saying that `libracket3m_a1zjsw.dll` cannot be found.

In fact, I'm wondering if `raco distribute` or `raco exe` is flexible enough to 
produce a statically linked executable where all the necessary dlls are 
incorporated.


C:\USERS\LU\WORK\RACK\Q
|   q.exe
|
\---lib
|   libiconv-2.dll
|   libracket3m_a1zjsw.dll
|   longdouble.dll
|
\---plt
\---q
+---collects
\---exts
\---ert
+---r0
|   dh4096.pem
|
\---r1
libeay32.dll
ssleay32.dll

-- 
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] intensional equality and unit tests

2017-02-20 Thread Sam Tobin-Hochstadt 
On Mon, Feb 20, 2017 at 2:23 PM, 'John Clements' via Racket Users
 wrote:
>
>> On Feb 20, 2017, at 11:06, Sam Tobin-Hochstadt  wrote:
>>
>> I don't think `check-expect` is doing something that's
>> module-relative. For example, this program:
>>
>> #lang racket
>> (require test-engine/racket-tests)
>> (struct x (a))
>> (check-expect (x 1) (x 1))
>> (run-tests)
>> (display-results)
>>
>> fails its test. `equal?` in Racket checks structural equality in a
>> deep way, which is indeed a feature not found in Java and Python, but
>> I don't think it's any different than overriding .equals() everywhere
>> in Java to perform structural traversal.
>
> I agree; my only point is that those writing unit tests probably want to 
> define (or have defined) two separate notions of equality; one for use in 
> tests, and one for use by clients. And that testing frameworks should 
> accommodate/encourage this.

Maybe that's true, but I haven't wanted to do that in my Racket code
using either `check-expect` in class or `check-equal` in Rackunit (or
at least, not enough to define a new abstraction for it). Have you
tried making a testing framework to accommodate this better?

Sam

>
> John
>
>>
>> Sam
>>
>> On Mon, Feb 20, 2017 at 1:53 PM, 'John Clements' via Racket Users
>>  wrote:
>>>
 On Feb 19, 2017, at 14:40, Matthias Felleisen  wrote:


> On Feb 18, 2017, at 11:12 PM, 'John Clements' via Racket Users 
>  wrote:
>
> (cc:ak)
>
> Okay, this sounds just crushingly obvious now that I say it, but 
> honestly, I don’t think it’s occurred to me:
>
> One reason that equality is such a nightmare in Java and Python (which 
> turns out to be JUST AS BAD), is that those of us that actually want to 
> write unit test cases want *intensional* equality, not extensional 
> equality—but not pointer-based equality.
>
> I just came across a nice example while working on code for first-year 
> students (thanks, Aaron!).
>
> Specifically, imagine an “array” class that contains a backing array and 
> a length, where the backing array might be arbitrarily longer than the 
> length:
>
> (struct arr (vec len))
>
> So, for instance, an array with two elements in it might be represented 
> as either
>
> (arr (vector “apple" “horse” #f #f #f) 2)
>
> or as
>
> (arr (vector “apple” “horse” #f) 2)
>
> —they both represent the array of length 2 that has “apple” as the first 
> element, and “horse” as the second.
>
> If I’m providing this library to be used by others, I probably want 
> extensional equality; I don’t want users of my library to be able to 
> distinguish between the two. However, if I’m writing unit tests for my 
> library, I definitely *do* want to be able to distinguish between the 
> two, for instance in checking the behavior of arrays that fill up and 
> need to be resized. Moreover, pointer-based equality—the == of Java, and 
> the `is` of Python (IIUC)—is also largely useless for unit tests.
>
> It’s probably not terribly controversial to suggest that neither Python 
> nor Java were designed with unit testing in mind. Accordingly, I 
> shouldn’t be surprised to discover that they don’t provide a natural 
> notion of equality that fits well with unit tests.
>
> So, I have three questions:
>
> 1) Is there an existing term for what I would call “functional 
> extensional equality”—that is, Racket’s ‘equal?’ ?
> 2) Does what I wrote make sense?
> 3) Has this been written down somewhere else, as part of a larger work?


 John,

 what you point out is that extensional equality depends on the point of 
 view. In your specific example, ‘arr’ from inside the module — 
 specifically for non-exported functions — equal? must take into account 
 the full vector. For a client module, equality is a notion of projection 
 (elimination of array fields). In particular, I would expect your module 
 to declare the structure opaque so that equal? does not inspect the full 
 array. Additionally, I would expect you to export a function called 
 arr-equal? so that clients can determine whether two instances are 
 extensionally equal from their perspective (which is apparently needed in 
 your context).

 If you were in a typed functional world, I’d use a sealed structure for 
 the module or at least an existential type so that the outside world 
 cannot inspect arr’s vec filed. This shows that equality is a 
 type-dependent notion — just as Reynolds said it.

 In a typed OO world such as Java, you’d override .equal, which is public 
 and thus accessible. But for internal, private comparisons, you’d have to 
 step

Re: [racket-users] Can raco distribute produce a single executable?

2017-02-20 Thread Shu-Hung You 
Sorry, I saw that you're already using raco exe and raco distribute.
So is the problem related to some DLL issue on Windows?

Best,
Shu-Hung

On Mon, Feb 20, 2017 at 1:19 PM, Shu-Hung You
 wrote:
> https://docs.racket-lang.org/raco/exe.html
> Is raco exe in this page what you want? Just type
>
>> raco exe q.rkt
>
> And this command will produce a single executable. Now we can now run
>
>> ./q
> q: expects 1  on the command line, given 0 arguments
>
> Best,
> Shu-Hung
>
> On Mon, Feb 20, 2017 at 1:12 PM, lu  wrote:
>> Hi all, I have this little toy project[1] to help me learn the language. I 
>> would like to produce a single portable executable that can be executed 
>> without reliance on racket installation. `raco distribute` does produce a 
>> "package" folder. But for small utility tool like this, I would prefer a 
>> simple standalone executable file rather than a folder, so I can just drop 
>> it into a directory on `PATH` on the target machine and run it.
>>
>> For the start I'm looking at solving this problem for Windows specifically, 
>> but am also interested in a solution on other systems.
>>
>> Thanks!
>>
>>
>> [1]: https://github.com/kflu/q
>>
>> --
>> 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] intensional equality and unit tests

2017-02-20 Thread 'John Clements' via Racket Users 

> On Feb 20, 2017, at 11:06, Sam Tobin-Hochstadt  wrote:
> 
> I don't think `check-expect` is doing something that's
> module-relative. For example, this program:
> 
> #lang racket
> (require test-engine/racket-tests)
> (struct x (a))
> (check-expect (x 1) (x 1))
> (run-tests)
> (display-results)
> 
> fails its test. `equal?` in Racket checks structural equality in a
> deep way, which is indeed a feature not found in Java and Python, but
> I don't think it's any different than overriding .equals() everywhere
> in Java to perform structural traversal.

I agree; my only point is that those writing unit tests probably want to define 
(or have defined) two separate notions of equality; one for use in tests, and 
one for use by clients. And that testing frameworks should 
accommodate/encourage this.

John

> 
> Sam
> 
> On Mon, Feb 20, 2017 at 1:53 PM, 'John Clements' via Racket Users
>  wrote:
>> 
>>> On Feb 19, 2017, at 14:40, Matthias Felleisen  wrote:
>>> 
>>> 
 On Feb 18, 2017, at 11:12 PM, 'John Clements' via Racket Users 
  wrote:
 
 (cc:ak)
 
 Okay, this sounds just crushingly obvious now that I say it, but honestly, 
 I don’t think it’s occurred to me:
 
 One reason that equality is such a nightmare in Java and Python (which 
 turns out to be JUST AS BAD), is that those of us that actually want to 
 write unit test cases want *intensional* equality, not extensional 
 equality—but not pointer-based equality.
 
 I just came across a nice example while working on code for first-year 
 students (thanks, Aaron!).
 
 Specifically, imagine an “array” class that contains a backing array and a 
 length, where the backing array might be arbitrarily longer than the 
 length:
 
 (struct arr (vec len))
 
 So, for instance, an array with two elements in it might be represented as 
 either
 
 (arr (vector “apple" “horse” #f #f #f) 2)
 
 or as
 
 (arr (vector “apple” “horse” #f) 2)
 
 —they both represent the array of length 2 that has “apple” as the first 
 element, and “horse” as the second.
 
 If I’m providing this library to be used by others, I probably want 
 extensional equality; I don’t want users of my library to be able to 
 distinguish between the two. However, if I’m writing unit tests for my 
 library, I definitely *do* want to be able to distinguish between the two, 
 for instance in checking the behavior of arrays that fill up and need to 
 be resized. Moreover, pointer-based equality—the == of Java, and the `is` 
 of Python (IIUC)—is also largely useless for unit tests.
 
 It’s probably not terribly controversial to suggest that neither Python 
 nor Java were designed with unit testing in mind. Accordingly, I shouldn’t 
 be surprised to discover that they don’t provide a natural notion of 
 equality that fits well with unit tests.
 
 So, I have three questions:
 
 1) Is there an existing term for what I would call “functional extensional 
 equality”—that is, Racket’s ‘equal?’ ?
 2) Does what I wrote make sense?
 3) Has this been written down somewhere else, as part of a larger work?
>>> 
>>> 
>>> John,
>>> 
>>> what you point out is that extensional equality depends on the point of 
>>> view. In your specific example, ‘arr’ from inside the module — specifically 
>>> for non-exported functions — equal? must take into account the full vector. 
>>> For a client module, equality is a notion of projection (elimination of 
>>> array fields). In particular, I would expect your module to declare the 
>>> structure opaque so that equal? does not inspect the full array. 
>>> Additionally, I would expect you to export a function called arr-equal? so 
>>> that clients can determine whether two instances are extensionally equal 
>>> from their perspective (which is apparently needed in your context).
>>> 
>>> If you were in a typed functional world, I’d use a sealed structure for the 
>>> module or at least an existential type so that the outside world cannot 
>>> inspect arr’s vec filed. This shows that equality is a type-dependent 
>>> notion — just as Reynolds said it.
>>> 
>>> In a typed OO world such as Java, you’d override .equal, which is public 
>>> and thus accessible. But for internal, private comparisons, you’d have to 
>>> step outside of Java’s equality predicate and use a method that inspects 
>>> the full vec field. Here this is relatively easy because you are dealing 
>>> with just two slots.
>>> 
>>> In any case, I doubt equal? helps you here. Did I misunderstand anything?
>> 
>> 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

Re: [racket-users] intensional equality and unit tests

2017-02-20 Thread 'John Clements' via Racket Users 

> On Feb 20, 2017, at 11:02, Matthias Felleisen  wrote:
> 
> 
>> On Feb 20, 2017, at 1:53 PM, John Clements  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.

Re: [racket-users] Can raco distribute produce a single executable?

2017-02-20 Thread Shu-Hung You 
https://docs.racket-lang.org/raco/exe.html
Is raco exe in this page what you want? Just type

> raco exe q.rkt

And this command will produce a single executable. Now we can now run

> ./q
q: expects 1  on the command line, given 0 arguments

Best,
Shu-Hung

On Mon, Feb 20, 2017 at 1:12 PM, lu  wrote:
> Hi all, I have this little toy project[1] to help me learn the language. I 
> would like to produce a single portable executable that can be executed 
> without reliance on racket installation. `raco distribute` does produce a 
> "package" folder. But for small utility tool like this, I would prefer a 
> simple standalone executable file rather than a folder, so I can just drop it 
> into a directory on `PATH` on the target machine and run it.
>
> For the start I'm looking at solving this problem for Windows specifically, 
> but am also interested in a solution on other systems.
>
> Thanks!
>
>
> [1]: https://github.com/kflu/q
>
> --
> 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.

[racket-users] Can raco distribute produce a single executable?

2017-02-20 Thread lu 
Hi all, I have this little toy project[1] to help me learn the language. I 
would like to produce a single portable executable that can be executed without 
reliance on racket installation. `raco distribute` does produce a "package" 
folder. But for small utility tool like this, I would prefer a simple 
standalone executable file rather than a folder, so I can just drop it into a 
directory on `PATH` on the target machine and run it.

For the start I'm looking at solving this problem for Windows specifically, but 
am also interested in a solution on other systems.

Thanks!


[1]: https://github.com/kflu/q

-- 
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] intensional equality and unit tests

2017-02-20 Thread Matthias Felleisen 

> On Feb 20, 2017, at 1:53 PM, John Clements  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. 

-- 
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] intensional equality and unit tests

2017-02-20 Thread 'John Clements' via Racket Users 

> On Feb 19, 2017, at 14:40, Matthias Felleisen  wrote:
> 
> 
>> On Feb 18, 2017, at 11:12 PM, 'John Clements' via Racket Users 
>>  wrote:
>> 
>> (cc:ak)
>> 
>> Okay, this sounds just crushingly obvious now that I say it, but honestly, I 
>> don’t think it’s occurred to me: 
>> 
>> One reason that equality is such a nightmare in Java and Python (which turns 
>> out to be JUST AS BAD), is that those of us that actually want to write unit 
>> test cases want *intensional* equality, not extensional equality—but not 
>> pointer-based equality.
>> 
>> I just came across a nice example while working on code for first-year 
>> students (thanks, Aaron!).
>> 
>> Specifically, imagine an “array” class that contains a backing array and a 
>> length, where the backing array might be arbitrarily longer than the length:
>> 
>> (struct arr (vec len))
>> 
>> So, for instance, an array with two elements in it might be represented as 
>> either
>> 
>> (arr (vector “apple" “horse” #f #f #f) 2)
>> 
>> or as
>> 
>> (arr (vector “apple” “horse” #f) 2)
>> 
>> —they both represent the array of length 2 that has “apple” as the first 
>> element, and “horse” as the second.
>> 
>> If I’m providing this library to be used by others, I probably want 
>> extensional equality; I don’t want users of my library to be able to 
>> distinguish between the two. However, if I’m writing unit tests for my 
>> library, I definitely *do* want to be able to distinguish between the two, 
>> for instance in checking the behavior of arrays that fill up and need to be 
>> resized. Moreover, pointer-based equality—the == of Java, and the `is` of 
>> Python (IIUC)—is also largely useless for unit tests.
>> 
>> It’s probably not terribly controversial to suggest that neither Python nor 
>> Java were designed with unit testing in mind. Accordingly, I shouldn’t be 
>> surprised to discover that they don’t provide a natural notion of equality 
>> that fits well with unit tests.
>> 
>> So, I have three questions:
>> 
>> 1) Is there an existing term for what I would call “functional extensional 
>> equality”—that is, Racket’s ‘equal?’ ?
>> 2) Does what I wrote make sense?
>> 3) Has this been written down somewhere else, as part of a larger work?
> 
> 
> John, 
> 
> what you point out is that extensional equality depends on the point of view. 
> In your specific example, ‘arr’ from inside the module — specifically for 
> non-exported functions — equal? must take into account the full vector. For a 
> client module, equality is a notion of projection (elimination of array 
> fields). In particular, I would expect your module to declare the structure 
> opaque so that equal? does not inspect the full array. Additionally, I would 
> expect you to export a function called arr-equal? so that clients can 
> determine whether two instances are extensionally equal from their 
> perspective (which is apparently needed in your context). 
> 
> If you were in a typed functional world, I’d use a sealed structure for the 
> module or at least an existential type so that the outside world cannot 
> inspect arr’s vec filed. This shows that equality is a type-dependent notion 
> — just as Reynolds said it. 
> 
> In a typed OO world such as Java, you’d override .equal, which is public and 
> thus accessible. But for internal, private comparisons, you’d have to step 
> outside of Java’s equality predicate and use a method that inspects the full 
> vec field. Here this is relatively easy because you are dealing with just two 
> slots. 
> 
> In any case, I doubt equal? helps you here. Did I misunderstand anything? 

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

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.