[racket-users] Re: PSA: alexis/collection is dead, long live data/collection

[brendan]

Great! As an aside, do you know if there are any plans to integrate generics 
(or, ideally, multiple dispatch) more tightly in later versions of Racket?

-- 
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] Display Animated GIFs

[Lehi Toskin]

Hi, I'm trying to figure out the best way to display an animated gif inside a 
canvas. I had attempted this before, but the only way I could figure out how to 
display the animation was by picking apart the gif, frame by frame, and then 
displaying the animation by a loop inside the canvas' paint-callback. I looked 
through the Racket Users archives and I found this thread 
https://groups.google.com/forum/#!searchin/racket-users/gif/racket-users/k2mfykyAaWY/CHUlu1cB9BUJ
 where it talks about how there aren't any plans to support animated gifs, 
though there may be in the future.

That thread was from 5 years ago. Is this still the case? I'd very much prefer 
a more native way of displaying animation in gifs than the very painful hack I 
made a few months ago (not to mention I took apart the gif in GIMP before 
turning to Racket for the animation itself).

-- 
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] "Is Sound Gradual Typing Dead?"

[Matthias Felleisen]

> On Dec 4, 2015, at 5:06 PM, Matthew Butterick  wrote:
> 
> Under Betteridge's Law, I was expecting that a paper so titled [1] would 
> conclude that the answer is no. But it does ultimately assert that "In the 
> context of current implementation technology, sound gradual typing is dead." 
> (With a silver lining that some new research questions have been discovered.)
> 
> What is the upshot for those of us whose Racketeering is more in the 
> practical rather than research realm? On its face, this paper seems to tell 
> me "don't use TR." Is that accurate? Is there a category of practical 
> programs that TR remains suitable for? 
> 
> I ask this as one of the guinea pigs studied in the paper [2]. I originally 
> picked up TR because I was curious whether it would be suitable for a project 
> where performance is a key consideration. Instead, TR slowed it down. Though 
> I was relieved to learn that my bad programming was not entirely the culprit, 
> now I feel bad about helping kill TR.



Matthew, 

thanks for bringing up this title/result. As the author of this title (and the 
somewhat sharper edges in the prose),  I owe the mailing list a general 
response. 

The title/paper are set up in this way to get the research community engaged. 
Typed Racket is the first and longest research development project in the 
gradual typing context (though the paper that Sam and I published did not use  
this phrase originally, which was coined in a parallel paper within a month of 
our design pub).  For most of the time since 2006, a fair number of efforts in 
this direction have focused on plain theory or moved toward optional unsound 
typing (you may say Int -> Int but I mean Int -> Real, too bad for you). In 
particular 

  nobody had any idea of how to measure whether a GT language would support the 
imagined gradual conversion of untyped programs into mostly typed ones. 

It is my opinion that semi-practical research questions such as this one call 
for a systematic evaluation, and I wanted to use the title/paper game to wake 
up the selection committee at POPL (our flagship conference in the research 
area). Well it did and the paper will appear there. 

— MAIN RESULT: The main result is really a method for measuring the 
“gradualness” of a GT language. We measure every possible way of tackling the 
conversion of an UNtyped program into a TYPED one for multi-module programs. 
The expectation is that (1) the top and the bottom should have approximately 
the same performance and (2) ideally the points (of partially converted 
programs) in between should perform well enough to be deliverable or at least 
useful. 

— COLLATERAL RESULT: As is, the evaluation method reveals that TR satisfies (1) 
but not (2). So if you use TR as intended — gradually convert a multi-module 
program into a partially typed one — you are extremely likely to experience 
serious performance problems. 

To the Racket/Typed Racket community, this collateral result is not a disaster. 
Instead it sets a research agenda, namely, to get TR to satisfy (2) 
linguistically (that is, as a language) or via IDE support that helps 
programmers identify and eliminate particularly bad trouble points in partially 
typed programs. 

Like everything in our language world, TR is a serious research effort meaning 
we are committed to invest a lot of energy and time into its realization. We 
will report progress as we make it and you’re likely to experience it before we 
say much about it, 

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

Re: [racket-users] PSA: alexis/collection is dead, long live data/collection

[George Neuner]

On 12/6/2015 11:07 PM, Alexis King wrote:

More generally, I’m not sure multiple dispatch is needed, though it can be a 
neat tool at times. I think part of the problem is that multiple dispatch is 
both hard to reason about and slow to implement in a dynamically-typed 
language. It’s unclear what to use to dispatch on given that values do not have 
“types”.


I would disagree that multiple dispatch isn't needed.  The Visitor 
pattern is used fairly frequently in real programs and it is just a 
overly complex, error-prone way of doing double dispatch.  Trying to 
handle more than 2 dimensions of dispatch using Visitor involves 
considerable pain.


Obviously CLOS combines multiple dispatch with latent typing, so that is 
one place to look for solutions.  How to do it most efficiently is a 
fair question.  Various Lisps have used tables and sorting trees for 
multimethod dispatch.  I think most implementations have settled on 
using tables now, but my understanding is that this was more to reduce 
compiler complexity than a determination that tables are more efficient 
in most cases.


It is true that dispatch on 3 or more arguments is rarely needed - I 
read somewhere that in Lisp, dispatch on 2 arguments accounts for 95+% 
of all multimethod use.  But when it is needed, faking it on top of 
single dispatch is a royal PITA.


YMMV,
George

--
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] PSA: alexis/collection is dead, long live data/collection

[Alexis King]

The honest answer to your question is that I don’t know (though I’d also be 
interested to hear the answer). Obviously, I’d like to see generic APIs given 
more thought, but they are currently somewhat slow due to how dispatch is 
performed. I don’t think that’s a reason to design APIs in a certain way, but 
it is a practical consideration. I’m guessing that can be optimized, though, 
and I’d be curious to see how generics fare on Pycket.

More generally, I’m not sure multiple dispatch is needed, though it can be a 
neat tool at times. I think part of the problem is that multiple dispatch is 
both hard to reason about and slow to implement in a dynamically-typed 
language. It’s unclear what to use to dispatch on given that values do not have 
“types”. Clojure has multimethods, which could certainly be ported to Racket, 
but it is of note that Clojure protocols are single dispatch and are much 
faster. This is arguably because they leverage features of the JVM rather than 
possessing an inherent speed difference, but that is a much larger discussion.

Generics are already used in a few places, such as Racket dicts, sets, and 
“sequences”, but I certainly think it would be nice if more functions were 
overloadable. At the same time, sometimes that can just be confusing rather 
than helpful. I think that collections are an obvious place where generic APIs 
just make sense, but I’d be open to hearing suggestions for other parts of 
Racket to be “genericized”.

> On Dec 6, 2015, at 10:49, brendan  wrote:
> 
> Great! As an aside, do you know if there are any plans to integrate generics 
> (or, ideally, multiple dispatch) more tightly in later versions of Racket?
> 
> -- 
> 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.