[racket-users] Re: Is this a TR bug?

[Sam Tobin-Hochstadt]

No, this isn't a bug. The problem is the cast _from_ `Any`, which
means we can't know what kind of value we have or how to protect it
more than we do.

This isn't introducing runtime errors into correct programs any more
than this one is:

#lang typed/racket
(: id : (-> String String))
(define (id x) x)
((cast id (-> Boolean Boolean))  #t)

which will also error.

Higher-order contracts are always potentially "time bombs" in this
sense, because they delay checking.

Sam


On Thu, Feb 16, 2017 at 3:15 PM, John Clements
 wrote:
> Here’s a simple program that fails:
>
> #lang typed/racket
>
> (define (obscurinator [x : Any]) : Any
>   x)
>
> (struct PrimV ([f : (Real Real -> Real)]) #:transparent)
>
> (define dangerval : PrimV
>   (cast (obscurinator (PrimV +))
> PrimV))
>
> ((PrimV-f dangerval) 3 4)
>
> It type-checks fine, but it produces this error in 6.8.0.2--2017-01-19(-/f) 
> [3m].:
>
> contract violation
>   Attempted to use a higher-order value passed as `Any` in untyped code: 
> #
>   in: Any
>   contract from: typed-world
>   blaming: cast
>(assuming the contract is correct)
>   at: unsaved-editor:9.2
>
> Basically, the ‘cast’ to a higher-order value type creates a time bomb that 
> blows up when called. Is this a bug?
>
> More generally, how do we feel about a type system that appears to introduce 
> run-time errors into otherwise correct programs? I think it might be nicer 
> just to prevent casts to higher-order types than to introduce this kind of 
> time bomb (pardon the excessively pejorative term). Apologies if I’m 
> misunderstanding this. Or maybe this is a fixable bug in TR?
>
> At a minimum, explaining it to a class of Java programmers is going to be 
> interesting.
>
> 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.

[racket-users] Is this a TR bug?

['John Clements' via Racket Users]

Here’s a simple program that fails:

#lang typed/racket

(define (obscurinator [x : Any]) : Any
  x)

(struct PrimV ([f : (Real Real -> Real)]) #:transparent)

(define dangerval : PrimV
  (cast (obscurinator (PrimV +))
PrimV))

((PrimV-f dangerval) 3 4)

It type-checks fine, but it produces this error in 6.8.0.2--2017-01-19(-/f) 
[3m].:

contract violation
  Attempted to use a higher-order value passed as `Any` in untyped code: 
#
  in: Any
  contract from: typed-world
  blaming: cast
   (assuming the contract is correct)
  at: unsaved-editor:9.2

Basically, the ‘cast’ to a higher-order value type creates a time bomb that 
blows up when called. Is this a bug? 

More generally, how do we feel about a type system that appears to introduce 
run-time errors into otherwise correct programs? I think it might be nicer just 
to prevent casts to higher-order types than to introduce this kind of time bomb 
(pardon the excessively pejorative term). Apologies if I’m misunderstanding 
this. Or maybe this is a fixable bug in TR?

At a minimum, explaining it to a class of Java programmers is going to be 
interesting.

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.

Re: [racket-users] make-directory race condition fix?

[Neil Van Dyke]

Dan Liebgold wrote on 02/16/2017 02:33 PM:

How can I rewrite this so that it either eats the exception or is atomic?


I think the difficulty here is that you don't know for certain why a 
`make-directory` failed, so maybe conditionally re-raising the exception 
is the way:



(define (make-directory-if-does-not-exist dir)
  (or (directory-exists? dir)
  (with-handlers ((exn:fail:filesystem?
   (lambda (exn)
 (if (directory-exists? dir)
 ;; make-directory exception, but directory 
exists

 ;; now, so assume all is OK.
 (void)
 ;; make-directory exception, but directory 
does

 ;; NOT exist, so re-raise the exception.
 (raise exn)
(make-directory dir


(make-directory-if-does-not-exist "/tmp/my-dir")


BTW, the first `directory-exists?` call is not functionally necessary, 
but (since the exact low-level behavior is unspecified) a general rule 
of thumb is that it's gentler to do read first, when that might preclude 
having to do a write.  And you only do the second `directory-exists?` if 
you already had to do a likely more expensive `make-directory`.


--
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] make-directory race condition fix?

[David Storrs]

On Thu, Feb 16, 2017 at 2:33 PM, Dan Liebgold 
wrote:

> Hi -
>
> I have a few racket process running on Windows that need to each ensure
> the same directory structure exists. I have code like this:
>
> (unless (directory-exists? dir)
>   (make-directory dir))
>
> Well, since they're running in parallel occasionally they race and try to
> make the directory after another has done so, resulting in an exception.
>
> How can I rewrite this so that it either eats the exception or is atomic?
>
> Thanks,
> Dan
>

Will this do?


(with-handlers ((exn:fail? (lambda (e) #t)))
(make-directory "bar"))

It doesn't do the 'directory-exists?' check and it will eat the exceptions.




>
> --
> 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] make-directory race condition fix?

[Dan Liebgold]

Hi -

I have a few racket process running on Windows that need to each ensure the 
same directory structure exists. I have code like this:

(unless (directory-exists? dir)
  (make-directory dir))

Well, since they're running in parallel occasionally they race and try to make 
the directory after another has done so, resulting in an exception.

How can I rewrite this so that it either eats the exception or is atomic?

Thanks,
Dan

-- 
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] Providing a seed to random number generators (and thence to distributions)

[Matthias Felleisen]

http://docs.racket-lang.org/reference/generic-numbers.html?q=random%20see#%28def._%28%28quote._~23~25kernel%29._random-seed%29%29



> On Feb 16, 2017, at 1:25 PM, Steve Byan's Lists  
> wrote:
> 
> In some tests I'm writing, it would be helpful to have the math-lib random 
> number generator (and distributions built upon it) return a deterministic 
> sequence. I didn't see anything in the documentation, but perhaps I 
> overlooked something. Is there a way to set a seed for a random number 
> generator?
> 
> Best regards,
> -Steve
> 
> --  
> Steve Byan
> steveb...@me.com
> Littleton, MA
> 
> 
> 
> -- 
> 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] Oregon PL Summer School 2017: call for participation

[Amal Ahmed]

We are pleased to announce the program for the 16th annual Oregon Programming 
Languages Summer School (OPLSS) to be held from June 26th to July 8th, 2017 at 
the University of Oregon in Eugene. The registration deadline is April 1st, 
2017.

Full information on registration and scholarships can be found here:

http://www.cs.uoregon.edu/Activities/summerschool


This year's program is titled: A Spectrum of Types.  The speakers and topics 
include:

Amal Ahmed -- Correct and Secure Compilation for Multi-Language Software
Northeastern University

Edwin Brady -- Dependent Types in the Idris Programming Language
University of St. Andrews

Ron Garcia -- Gradual Typing
University of British Columbia

Robert Harper -- Programming Languages Background
Carnegie Mellon University 

Neel Krishnaswami -- Dependent Types and Linearity
University of Cambridge

Dan Licata -- Programming Languages Background
Wesleyan University

Frank Pfenning -- Substructural Type Systems and Concurrent Programming
Carnegie Mellon University

Sam Tobin-Hochstadt -- Contracts and Gradual Types
Indiana University

David Van Horn -- Redex, Abstract Machines, and Abstract Interpretation
University of Maryland

The school has a long and successful tradition (sponsored by the NSF, ACM 
SIGPLAN, and industry). It covers current research in the theory and practice 
of programming languages.  Material is presented at a tutorial level that will 
help graduate students and researchers from academia or industry understand the 
critical issues and open problems confronting the field. Prerequisites are an 
elementary knowledge of logic and mathematics, as covered in undergraduate 
classes on discrete mathematics, and some knowledge of programming languages at 
the level of an undergraduate survey course. 

A *new feature* this year is the option for students to attend a Review session 
from June 23rd to 25th -- the three days before the summer school officially 
begins. The review will cover operational semantics, type systems, and basic 
proof techniques, and will help graduate and especially undergraduate students 
who have not had a previous course in this material prepare for the main part 
of the school. Please contact the organizers if you have questions about 
whether the review will be helpful given your background.

We hope you can join us for this excellent program!

Amal Ahmed
Dan Licata
Zena Ariola

-- 
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 supported by Racket (according to wikipedia)

[Matthias Felleisen]

The world of text books for undergraduate PL classes changed radically in the 
1980s with the introduction of Kamin’s book and Friedman & Wand’s EOPL. One of 
the final bricks in this wall to fence of “paradigm” teaching is SK’s PLAI. 
Instead of paradigms, these books emphasized the idea of interpretation and 
everything that goes with it (type checking, gc, transformations on 
interpreters (cps, sps), and many more language concepts). The DSL movement of 
the last 10 years has also bought into this. 

This is not to say that the stone-aged “paradigmers” don’t write books anymore 
or that the people don’t teach this stuff anymore. But no self-respecting 
research university does. Instead they hire a well-trained PL guy and move away 
from this nonsense. 

— Matthias








> On Feb 16, 2017, at 6:18 AM, Stephen De Gabrielle  
> wrote:
> 
>  I've edited both the paradigms and comparison pages to emphasise and add 
> criticisms citing the paper.
> 
> While I don't consider  Wikipedia either a safe  or reliable source for 
> study, it is nevertheless used widely. I would suggest in this context it is 
> a marketing tool -  just take a look at the language which supports all 
> paradigms.  I don't think that simply removing Racket is helpful.
> 
> It would be helpful if there were more sources that supported the criticism 
> both of classifying languages in this way, and as a teaching methodology.  If 
> you are  aware of any please let me know and I will at them. 
> 
> Kind regards 
> 
> Stephen
> On Sat, 11 Feb 2017 at 14:30, Matthias Felleisen  wrote:
> 
>> On Feb 11, 2017, at 8:31 AM, Greg Trzeciak  wrote:
>> 
>> I have stumbled upon the following wiki page:
>> https://en.wikipedia.org/wiki/Comparison_of_multi-paradigm_programming_languages
>> 
>> Supported paradigms:
>> ---
>> Language: Racket
>> Num­ber of Para­digms: 6 
>> Con­cur­rent: No
>> Con­straints: No
>> Data­flow: No
>> De­clar­at­ive: No
>> Dis­trib­uted: No
>> Func­tion­al: Yes
>> Meta­pro­gram­ming: Yes
>> Gen­er­ic: No
>> Im­per­at­ive: Yes
>> Lo­gic: Yes
>> Re­flec­tion: Yes
>> Ob­ject-ori­ented: Yes
>> Pipe­lines: No
>> Visu­al: No
>> Rule-based: No
>> Oth­er para­digms: No (not listed paradigms can be mentioned here)
>> 
>> According to the same page eg. Julia supports 17 paradigms.
>> 
>> Not being an expert in Racket I can see the article sells Racket short. How 
>> really this table should look like in regards to Racket?
> 
> 
> Racket should be removed from the list. 
> 
>  
> http://cs.brown.edu/~sk/Publications/Papers/Published/sk-teach-pl-post-linnaean/
> 
>  Programming language ‘‘paradigms’’ are a moribund and tedious legacy of a 
> bygone age. 
>  Modern language designers pay them no respect, so why do our courses 
> slavishly adhere 
>  to them? This paper argues that we should abandon this method of teaching 
> languages, 
>  offers an alternative, reconciles an important split in programming language 
> education, 
>  and describes a textbook that explores these matters.
>  
>  (Shriram’s dissertation on linguistic reuse inspired Racket’s modular system 
> of languages.)
> 
> If you have time to edit the wikipage, please do so. Thanks — Matthias
> 
> 
> -- 
> 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.
> -- 
> Kind regards,
> Stephen
> --

-- 
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 supported by Racket (according to wikipedia)

[Luis Sanjuán]

On Sunday, February 12, 2017 at 11:19:06 PM UTC+1, Matthias Felleisen wrote:
> > On Feb 12, 2017, at 4:55 PM, Greg Trzeciak  wrote:
> > 
> > On Sunday, February 12, 2017 at 10:35:45 PM UTC+1, Matthias Felleisen wrote:
> >> Thanks. I assume you have seen my old web page with Don Q as my image :-) 
> > 
> > Believe it or not... I haven't which makes the analogy even more fitting =)
> > 
> > To make sure I didn't simply have it in my subconsciousness I even checked 
> > wayback machine:
> > https://web.archive.org/web/20100823072635/http://www.ccs.neu.edu/home/matthias/
> > 
> > That was the last time you used it - at that time I didn't even know of 
> > existence of Racket!
> 
> 
> Yes :-) I am now convinced some of my work can make it … (well, I actually 
> wanted to move to a different picture and did not find the right-sized Don Q 
> picture).


I can't resist to mention -) You have lots of beautiful drawings of everything 
in "Don Quijote" from classic editions in this page:

http://www.qbi2005.com/Default.aspx

[Use rights are specified here: http://www.qbi2005.com/wfrmAyuda.aspx]

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