Re: [racket-dev] [plt] Push #28829: master branch updated
On 2014-06-01 17:49:59 -0600, Jay McCarthy wrote: > Based on this commit, I feel like "assert" would be a better name than > "invariant-assertion". FWIW, it may be confusing if both Racket and TR provide an `assert` function (especially if `assert` ends up being part of #lang racket). Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Machinery for eliding contracts
On 2014-06-09 00:19:40 -0700, Eric Dobson wrote: > One issue I see is that we need an unforgeable property that the value > actually came from the typed world so we know that eliding the new > contract is safe. > > Does this seem like a reasonable thing to support/do people see issues with > it? A potentially useful generalization of this that's not just for TR is to avoid duplicate complex check ons values (no types involved), making complicated contracts more feasible. Imagine a contract that parses a string to see if it is a valid IP address, for example. Would this only work for higher-order/behavioral values/types though? (i.e., not my IP example) Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] 2htdp/image Feature Suggestion
On 2014-06-22 20:27:21 -0700, Kevin Forchione wrote: >Thanks! Is there any documentation or guide on which *styles* to prefer in >writing Racket code? I find myself scratching my head at times in these >matters! In recent Racket distributions and online docs there's now a style manual: http://docs.racket-lang.org/style/index.html Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28936: master branch updated
On 2014-06-26 07:30:40 -0400, Sam Tobin-Hochstadt wrote: >Can we make this error message a little more informative? People find this >confusing. Sure, did you have something in mind? Something like this? Type Checker: cannot apply a function with no known arities; Function `f` had type Procedure which cannot be applied Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] FOOL 2014 Call for Papers
Call For Papers 21th International Workshop on Foundations of Object-Oriented Languages (FOOL 2014) A Workshop of SPLASH (OOPSLA) 2014 Portland, Oregon, United States. http://homepages.ecs.vuw.ac.nz/~servetto/Fool2014/ Important dates: - August 15, 2014 Abstract submission - August 23, 2014 Full paper submission - September 26, 2014 Notification - October 10, 2014 Paper due for informal proceedings - October 20-24, 2014 Workshop (the day is still to be decided) The search for sound principles for object-oriented languages has given rise to much work during the past two decades, leading to a better understanding of the key concepts of object-oriented languages and to important developments in type theory, semantics, program verification, and program development. Submissions for this event are invited in the general area of foundations of object-oriented languages. Topics of interest include language semantics, type systems, type modifiers, memory models, program verification, object capabilities, formal calculi, concurrent and distributed languages, database languages, and language-based security issues. Papers are welcome to include formal descriptions and proofs, but these are not required; the key consideration is that papers should present novel and valuable ideas or experiences. The main focus in selecting workshop contributions will be the intrinsic interest and timeliness of the work, so authors are encouraged to submit polished descriptions of work in progress as well as papers describing completed projects. We solicit submissions on original research not previously published or currently submitted for publication elsewhere. The program chair should be informed of any related submissions; see the ACM SIGPLAN Republication Policy. Submissions should be PDF in standard SIGPLAN 10pt conference format for a US-letter size page. While submissions can be up to 12 pages, shorter papers describing promising preliminary work are also encouraged. Papers must be submitted electronically via EasyChair. ***NEW: Future of Object-Oriented Foundations session at FOOL 2014*** Over the past 20 years, research presented at FOOL has lead to a more solid understanding of the foundations of today's object-oriented programming languages. At the same time, new object-oriented languages and concepts are constantly being proposed, and there remain core topics that have not yet been fully explored. This year at FOOL 2014, we will hold a special session on the Future of Object-Oriented Foundations (FOOF). For this session, we solicit short papers as well as brief position statements regarding future research in object-oriented foundations: - A short paper will have the same format as regular submissions to FOOL, and will be reviewed in a similar way, but will be limited to 4 pages. - A position statement includes a title, authors, and 2-3 paragraphs of text summarizing the position. These will be lightly evaluated to ensure the position is of interest to the community. Authors of short papers will be given short presentation slots to present them in the FOOF session. One author of each position statement will be invited to participate in an panel related to the position statement's topic. Possible topics include, but are not limited to: brands, tags, and pattern matching; module systems and modularity; protocols, typestate, and sessions; ownership, permissions, and immutability; concurrent and distributed object models; OO logics and reasoning; and gradual/hybrid types and verification. An informal proceedings will be made publicly available on the web page. However, presentation at FOOL does not count as prior publication, and many of the results presented at FOOL have later been published at ECOOP, OOPSLA, POPL, and other main conferences. Program Committee Ferruccio Damiani (University of Turin) Sophia Drossopoulou (Imperial College London) Truong Anh Hoang (Vietnam National University Hanoi) Hidehiko Masuhara (Tokyo Institute of Technology) Rosemary Monahan (National University of Ireland, Maynooth) Alex Potanin (Victoria University of Wellington) Sukyoung Ryu (Korea Advanced Institute of Science and Technology) Marco Servetto (Victoria University of Wellington) Asumu Takikawa (Northeastern University) Thomas Wies (New York Univeristy) Tobias Wrigstad (Uppsala University) Elena Zucca (University of Genova) -- Organizers Marco Servetto (PC Chair) (Victoria University of Wellington) James Noble (Victoria University of Wellington) Jonathan Aldrich (Carnegie Mellon University ) - Steering Committee Jeremy Siek (Indiana University Bloomington) John Boyland (University of Wisconsin-Milwaukee) Atsushi Igarashi (Kyoto University) Shriram Krishnamurthi (Brown University) James Noble (Victoria
[racket-dev] flatten-begin
Hi all, I was wondering what people think about a potential API addition to the `syntax/flatten-begin` library. Something like `flatten-begin*` (or a less terrible name) that would recursively flatten `begin` expressions like the `flatten` function does for plain lists. i.e., (flatten-begin* #'(begin (begin 1 2) 3 4)) => (list #'1 #'2 #'3 #'4) as opposed to (flatten-begin #'(begin (begin 1 2) 3 4)) => (list #'(begin 1 2) #'3 #'4) Would that be useful? I keep finding myself writing functions like this. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] flatten-begin
On 2014-07-17 22:17:18 -0500, Robby Findler wrote: >Why doesn't flatten-begin already do this? I'm not sure. I was hoping someone else could tell me. :) Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] flatten-begin
On 2014-07-18 09:52:26 -0500, Robby Findler wrote: > Unless someone knows why it is a bad idea, how about adding a #:all? > argument that flattens all the way down? > > I don't see many uses of flatten-begin in our tree, but the one in > compatibility/package sure looks like it could use the #:all? > argument. Ditto the one in TR (in class-prims.rkt). And I'm pretty > sure that replacing the hand-rolled loops in drracket for doing this > (they predate that library) would use the #:all? argument if they were > rewritten. This sounds like a nice solution and it would be fine for my use-case too. Anyone have any reasons against? (otherwise I can make the change) Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] flatten-begin
On 2014-07-19 23:12:51 -0400, Asumu Takikawa wrote: > This sounds like a nice solution and it would be fine for my use-case > too. Anyone have any reasons against? (otherwise I can make the change) I just realized that `flatten-begin` actually doesn't care if the form starts with a `begin`. In other words, the following evalutes like this: (flatten-begin #'(a 1 2)) => (list #'2 #'3) In which case the behavior of #:all? becomes a bit weird since it would care about the head being a `begin` (otherwise it would collapse too manay things). Maybe the recursive flattener should be a different function after all? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Pre-Release Checklist for v6.1
On 2014-07-21 16:14:27 -0400, Vincent St-Amour wrote: > Sam, Asumu, Eric: what's new for this release? This came up on IRC the other day. I think Eric was saying the main changes were inference speedups, support for contracted functions, and better keyword support. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Problem with Values type constructor
On 2014-07-23 20:20:56 +0100, Antonio Menezes Leitao wrote: >Although the typed racket documentation mentions Values as a type >constructor, it does not work: > >[...] > >Am I missing something? Nope, this is just a bug. Thanks for the report. I've pushed a fix to git. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Release Announcement for v6.1
On 2014-07-28 14:33:07 -0400, Ryan Culpepper wrote: > asumu: > - removed mzlib/class100 (5711e900) > - classes and TR (various) I don't have anything in particular for classes. For TR, we should add Stephen's contribution of async-channel support: * Typed Racket now supports asynchronous channels using the `typed/racket/async-channel' library. I also added a new syntax for asymmetric filters. Is that worth including? (and the filter syntax is now documented) Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Release Announcement for v6.1
On 2014-08-01 13:54:15 -0400, Asumu Takikawa wrote: > On 2014-07-28 14:33:07 -0400, Ryan Culpepper wrote: > > asumu: > > - removed mzlib/class100 (5711e900) Whoops, sorry, we should actually put in a blurb about class100 though. * As noted in the v5.3.2 release, the `mzlib/class100` library is deprecated. The library has now been removed from the distribution. Use `racket/class` instead. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] SGC as default
On 2014-08-12 05:16:21 +0100, Matthew Flatt wrote: > If you have an existing build in a repo checkout, then `make` is likely > to fail, because the makefile dependencies are not precise enough to > deal with the switch. You can discard your old build directory, or it > might work to simply delete > > /racket/libmzgc.a The build didn't work for me in an existing checkout, so I tried making a fresh one and still got this failure: make xsrc/precomp.h make[7]: Entering directory '/home/asumu/plt/racket-fresh/racket/src/build/racket/gc2' env XFORM_PRECOMP=yes ../racketcgc -G /home/asumu/plt/racket-fresh/build/config -cqu ../../../racket/gc2/xform.rkt --setup . --cpp "gcc -E -I./.. -I../../../racket/gc2/../include -pthread -DUSE_SENORA_GC " --keep-lines -o xsrc/precomp.h ../../../racket/gc2/precomp.c Segmentation fault Makefile:202: recipe for target 'xsrc/precomp.h' failed make[7]: *** [xsrc/precomp.h] Error 139 Anything I should try to debug this? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] SGC as default
On 2014-08-12 06:06:51 +0100, Matthew Flatt wrote: > What platform are you using? > > I imagine that running `./racketcgc` within the "racket" subdirectory > of your build directory will similarly crash. Can you get any > information from running `gdb racketcgc`? This is on Linux. Running the built executable immediately produces a segfault. Here's a backtrace from gdb: (gdb) bt #0 0x005e78db in free_managed (s=s@entry=0x0) at ../../../racket/sgc/sgc.c:1535 #1 0x005e7f63 in GC_add_roots (start=start@entry=0x881b70 , end=end@entry=0x881b79 ) at ../../../racket/sgc/sgc.c:1657 #2 0x00576f9a in scheme_register_static (ptr=ptr@entry=0x881b70 , size=size@entry=8) at ../../../racket/src/salloc.c:720 #3 0x0045b87f in scheme_set_collects_path (p=p@entry=0x77f701a0) at ../../../racket/src/file.c:6841 #4 0x00436673 in run_from_cmd_line (mk_basic_env=, cont_run=0x435a10 , _argv=, argc=0) at ../../racket/cmdline.inc:1444 #5 main_after_stack (data=data@entry=0x7fffdc30) at ../../racket/main.c:450 #6 0x0057694d in do_main_stack_setup (data=0x7fffdc30, _main=0x435a80 , no_auto_statics=1) at ../../../racket/src/salloc.c:198 #7 scheme_main_stack_setup (no_auto_statics=no_auto_statics@entry=1, _main=_main@entry=0x435a80 , data=data@entry=0x7fffdc30) at ../../../racket/src/salloc.c:310 #8 0x004346ee in main_after_dlls (argv=, argc=) at ../../racket/main.c:381 #9 main (argc=, argv=) at ../../racket/main.c:341 Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Racket build crashes on CGC mode
Hi all, I've found a reproducible crash while building Racket using the CGC mode on my Linux machine: $ ../configure --enable-cgcdefault --enable-sgc $ make && make install [... output ...] raco setup: 2 making: /file While receiving message from parallel-do worker 0 UNKNOWN::98: read: bad syntax `#<' Makefile:178: recipe for target 'install-cgc' failed make[1]: *** [install-cgc] Error 1 make[1]: Leaving directory '/home/asumu/plt/racket-sgc/racket/src/build' Makefile:86: recipe for target 'install' failed make: *** [install] Error 2 $ WORKER SEND MESSAGE ERROR: error writing to stream port system error: Broken pipe; errno=32 WORKER SEND MESSAGE ERROR: error writing to stream port system error: Broken pipe; errno=32 WORKER SEND MESSAGE ERROR: error writing to stream port system error: Broken pipe; errno=32 WORKER SEND MESSAGE ERROR: error writing to stream port system error: Broken pipe; errno=32 (I don't actually need to use CGC, but I was just curious to see what would happen) Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #29355: master branch updated
On 2014-10-10 07:29:47 -0400, Neil Toronto wrote: > Does this mean most instances of GUI classes can now cross the contract > boundary? Not quite, because the algorithm to create the mutually recursive contracts is currently baad. Like use all of your memory and terminate in 5 years bad. I have a somewhat better way to do this in a pull request, but I just discovered yesterday that the new framework types that Phil has added (yay!) are also challenging to translate to contracts. In particular, I was getting zo files that are 460MB or so of contracts. I got it down to about 64MB, but it still takes 5 minutes to compile that file. I have an idea for how to get this down to a reasonable number, but it requires changing the class type representation so I still need some time to hack on it. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Proposed addition of #:where clause to the match library
Hi Michael,
On 2014-10-24 17:55:24 +, Michael Bernstein wrote:
>Proposed Racket version (based on the Erlang example)
>uses #:where keyword:
>(define/match (insert X lst)
> [{ X '() } (list X)]
> [{ X (cons H T) } #:where (<= X H) (list* X H T)]
> [{ X (cons H T) } (cons H (insert X T))])
>(define (insertion-sort lst)
> (foldl insert '() lst))
You can write this as:
(define/match (insert X lst)
[{ X '() } (list X)]
[{ X (cons H T) } #:when (<= X H) (list* X H T)]
[{ X (cons H T) } (cons H (insert X T))])
(define (insertion-sort lst)
(foldl insert '() lst))
Note that #:where is replaced by #:when. I believe this works in Racket
v6.0 and later.
Cheers,
Asumu
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #29450: master branch updated
On 2014-10-28 12:05:12 -0400, sa...@racket-lang.org wrote: > | Avoid requires of contracts when they're not used. > | > | This changes when various libraries that provide contract > | support to possible contracted bindings to declare when > | those bindings are needed. Is there some unit test we can write that will check to make sure these requires are not included when they're not used? (I ask because there are some refactorings of contract generation I'd like to merge eventually and I don't want to break the improvement you've made here) Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #29452: master branch updated
On 2014-10-28 17:58:49 -0400, as...@racket-lang.org wrote: > 64bc7d4 Asumu Takikawa 2014-10-28 17:41 > : > | Send thunks to check-syntax for type tooltips > | > | This avoids the cost of computing the printed types > | to some degree. It still does have overhead (~5%) over > | not computing anything related to tooltips because of > | the cost of traversing the type table and computing > | tooltip locations. Actually I may have mismeasured this and I think the overhead may be lower or non-significant. I'll just wait for DrDr to run on a few pushes and see how the test graphs look. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Expansion size vs. zo file size
Hi all, I'm currently trying to improve Typed Racket's contract generation. I have a change which improves time/memory usage and also the size of the expanded code. The trouble is that despite the decrease in the size of the expanded code, the resulting zo files are actually *larger*. I found this unintuitive. Is there anything I can do to get the bytecode compiler to help me out here? Here are the numbers: with change without change matrix.rkt expansion | 264K | 524K -- matrix.rkt zo file | 1036K | 820K If you'd like to try to reproduce this, the branch I'm operating on is here: https://github.com/takikawa/racket/tree/tr-experimentation-2 I got the expansion size with: raco expand matrix.rkt > matrix-expansion du matrix-expansion and just `du compiled/matrix_rkt.zo` for zo file size. This is for "matrix.rkt" in the math library. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Expansion size vs. zo file size
On 2014-11-11 17:25:37 -0500, Asumu Takikawa wrote: > I found this unintuitive. Is there anything I can do to get the bytecode > compiler to help me out here? FWIW, I also tried looking at the optimizer logs in both cases to see if there was much difference. Grepping for "inlining" shows counts of 75 vs. 47 for compiling matrix.rkt (post/pre change and ignoring the inlining that goes on for modules like '#%util). So maybe this is just a time/space tradeoff that I can't do much about. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] DrDr & the split repository
On 2014-12-05 07:14:40 -0500, Jay McCarthy wrote: > Instead, Matthew changed "raco test" (which is how DrDr tests > programs) to support all these options. They can be test on a > per-directory or per-file basis. The documentation for this is here: I tried to set this for a test I am responsible for, but it didn't seem to work. I've probably just made a mistake somewhere, so can someone sanity check this for me? DrDr is complaining to me about this file: http://drdr.racket-lang.org/29616/pkgs/racket-test/tests/generic/benchmark.rkt but I thought I set the timeout/randomness for that file here: https://github.com/plt/racket/blob/1e5ec02262e588512d225f4212badf4ce36b40d7/pkgs/racket-test/tests/generic/info.rkt Thanks, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket/typed-racket] 3e45f2: Adjust TR test package dependencies
On 2014-12-16 13:26:38 -0800, Asumu Takikawa wrote: > Branch: refs/heads/master > Home: https://github.com/racket/typed-racket > Commit: 3e45f258bed22d16b1f7ab1cac701d20c5f57e06 > > https://github.com/racket/typed-racket/commit/3e45f258bed22d16b1f7ab1cac701d20c5f57e06 > Author: Asumu Takikawa > Date: 2014-12-16 (Tue, 16 Dec 2014) > > Changed paths: > M typed-racket-test/info.rkt > > Log Message: > --- > Adjust TR test package dependencies I made this change to satisfy the package dependency checker, but it seemed like the dependency should've been detected prior to Vincent's recent commit (that reduced a level of nesting). Is it possible that the dependency checker was failing to detect some dependencies? Here's a concrete example. This file: https://github.com/racket/typed-racket/blob/76effbb4235c3be26659430733ab1efb5aadaf18/typed-racket-test/tests/typed-racket/random-real.rkt clearly depends on the `unstable/flonum` library in a different package. Prior to commit 134f793, the package system didn't complain that this dependency wasn't listed. After the commit, the package system suddenly started complaining. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] raco pkg update --clone and git URL config
Hi all, I've been trying to adjust to the new package-split workflow now and I've bumped into a small usability problem and I wanted to see if anyone else has encountered this or if my config is just broken somehow. On a fresh build of Racket, if I do the following: raco pkg update --clone typed-racket it will install TR from github and reinstall. An excerpt from the config for that git repo looks like this: [remote "origin"] url = git://github.com/racket/typed-racket/ The problem is that this URL is not as useful as it could be because github won't let you push to it (at least I can't seem to). The corresponding SSH URL "g...@github.com:racket/typed-racket.git" lets me push. Is this something other people have encountered or is there some git config that I should fix on my end? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket/typed-racket] 3e45f2: Adjust TR test package dependencies
On 2014-12-17 08:22:33 -0700, Matthew Flatt wrote: > Commit 134f793 moved files out of a directory named "tests". By > default, a directory named "tests" is treated specially by the > dependency checker, reflecting that the directory name is treated > specially for the creation of "binary" and "binary library" variants of > a package: Unless the "info.rkt" file says otherwise, anything in > "tests" is treated as "build-time" code, and so the directory's content > creates build dependencies, not general dependencies. > > That's why it was sufficient to list "unstable-flonum-lib" in > `build-deps` before commit 134f793, and why "unstable-flonum-lib" had > to be moved to `deps` afterward. Thanks Matthew, that clears it up. Is this documented anywhere in the pkg docs? I looked in section 5 of the package docs which says that "tests" folders are pruned for binary packages, but I'm not sure if that implies that the dependency checker treats it as "build-time" code. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] syntax-local-lift-require is useless wrt submodules
On 2015-01-11 23:29:28 -0800, Alexis King wrote: >This is a real problem, since Typed Racket’s require/typed form uses >local-require, which in turn uses syntax-local-lift-require. This means >that require/typed currently cannot require submodules. Interesting, thanks for tracking this down! IIRC Typed Racket switched to using `local-require` in order to support uses of `require/typed` in the REPL/top-level. (as the comment on https://github.com/racket/typed-racket/blob/master/typed-racket-lib/typed-racket/utils/require-contract.rkt#L57 notes) So one possible solution is to switch back to using `require` but also overhaul how TR handles the REPL to avoid these issues. (for the REPL, local expanding everything at once doesn't work well because an early definition in a `begin` has to be registered before later clauses are typechecked) Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Typed Racket does not play nice with submodules
On 2015-01-13 03:05:30 -0800, Alexis King wrote: >Also, Asumu, a related problem: are there any issues with changing >local-require back to require that would break anything else? Or can you >possibly implement that change in TR with no issues? I initially thought there would be (hence my previous e-mail), but actually it seems to work. Originally TR switched to using local-require to get require/typed working in the REPL/top-level, but it seems that other changes since then (I think commit a4a2ccacc3f896) made that unnecessary. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Announcing Soft Contract Verification tool
On 2015-01-14 19:11:59 -0500, David Van Horn wrote: > If you have questions, comments, bugs, or any other feedback, let us > know, or just file bug reports on the GitHub source code. Nice tool! I like the web interface too. I was confused by this interaction though. Clicking verify on this: (module fact racket (define (factorial x) (if (zero? x) 1 (* x (factorial (sub1 x) (provide (contract-out [factorial (-> (>=/c 0) (>=/c 0))]))) gives me: Contract violation: 'fact' violates '>='. Value 0.105 violates predicate real? An example module that breaks it: (module user racket (require (submod ".." fact)) (factorial 0.105)) (Verification takes 0.05s) but the value 0.105 shouldn't violate the predicate real? I think. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Announcing Soft Contract Verification tool
On 2015-01-15 14:13:02 -0500, Asumu Takikawa wrote: > Contract violation: 'fact' violates '>='. > Value > 0.105 > violates predicate > real? > An example module that breaks it: > (module user racket (require (submod ".." fact)) (factorial 0.105)) > (Verification takes 0.05s) Hmm, actually I should've looked at this more carefully. Is this a case where the tool is telling me that the function is non-terminating on this input? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Behavioral subtyping for editor<%> and its implementing classes
Hi all, While writing contracts for classes in racket/gui, I noticed that the implementations of text% and pasteboard% do not act as behavioral subtypes of editor<%>, which both classes implement. In particular, consider the do-copy method from editor<%>. Its contract looks like this: (send an-editor do-copy) → void? http://pre.racket-lang.org/docs/html/gui/editor___.html?q=do-copy#(meth._(((lib._mred/main..rkt)._editor~3c~25~3e)._do-copy)) However, the implementations have the following contracts: (send a-text do-copy start end time extend?) → void? http://pre.racket-lang.org/docs/html/gui/text_.html?q=do-copy#(meth._(((lib._mred/main..rkt)._text~25)._do-copy)) and (send a-pasteboard do-copy time extend?) → void? http://pre.racket-lang.org/docs/html/gui/pasteboard_.html?q=do-copy#(meth._(((lib._mred/main..rkt)._pasteboard~25)._do-copy)) That is, do-copy in editor<%> has no mandatory arguments, do-copy in text% has four mandatory arguments, and do-copy in pasteboard% has two mandatory arguments. Thus, the do-copy methods in text% and pasteboard% do not implement the editor<%> interface (in the behavioral subtyping sense) nor do they implement a common interface despite claiming to. There are several other examples of this issue in the same classes. (see do-paste, paste-x-selection, etc.) Is there a design rationale for this? Is this method not meant to implement a common interface? Cheers, Asumu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] SSLv2 in collects
Apparently SSLv2 is considered dangerous and some Linux distributions have started shipping OpenSSL libraries with SSLv2 removed. (e.g. Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589706) Since collects/openssl/mzssl.rkt depends on SSLv2 (presumably for legacy support?), this seems to cause a build failure on Debian testing and newer using the system libraries. Is there any reason to keep SSLv2 around or can this be removed? Cheers, Asumu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] SSLv2 in collects
On 2011-04-25 14:54:18 -0300, David Bremner wrote: > Yeah, this is a problem for the official Debian builds as well. > > Would it be enough just to hack out all of the mentions of > SSLv2_(client|server)_method? Has anyone tried? The latest commit changes the openssl module to fail gracefully at runtime when SSLv2 can't be found instead of failing to build. This should work on Debian too (tested on wheezy). Cheers, Asumu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Inline caching (was Re: my '312' this semester, how we compare to others)
On 2011-05-04 18:49:13 -0400, Tony Garnock-Jones wrote: > The attached (highly experimental) patch seems to improve the > performance of normal sends (in the case of a cache hit) by roughly > 100% - 150%. The difference between this mere factor of two > improvement and the factor of six-through-ten I was seeing earlier > is, I speculate, related to object-ref taking a lot of time. > > Interestingly, the performance of (send something message) is, with > this patch, seemingly roughly en par with the performance of > generics captured using generic and invoked using send-generic. > > I haven't yet tried running a full racket system with this patch > applied. I wonder if it makes a difference to the interactive > performance of DrRacket? Wow, impressive! I've been benchmarking with the DrRacket interactive tests already for contracts, so I can run my test driver and get some numbers for that. Cheers, Asumu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Non-negative real predicate?
Hi all, I've seen some locations in the docs where a currently imaginary predicate is used as a contract. e.g. the sleep function has a nonnegative-number? contract The same contract is often expressed as (and/c real? (not/c negative?)) in many locations. e.g. the get-extent method for snip%, methods for editor<%>, text%, etc. It seems like the imaginary contract should be replaced with an actual one. Should it be replaced by the combinator expression above in the docs or can a predicate be made for this [somewhat common] case? Cheers, Asumu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Non-negative real predicate?
On 2011-06-10 13:11:51 -0700, Matthew Flatt wrote: > I'm more in favor of using `(and/c real? (not/c negative?))'. Stevie just pointed out that the following contract is equivalent and shorter: (>=/c 0) so I'll go with that. Cheers, Asumu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Roogle?
A few of us in the lab today were discussing how the Haskell community has this nice tool called Hoogle (http://www.haskell.org/hoogle) that lets you search Haskell docs by type. Is it at all feasible to supplement Racket's doc search to display contracts and/or search by contract? (or type for TR) Does something like that exist? Cheers, Asumu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Roogle?
On 2011-08-05 00:08:03 -0400, Eli Barzilay wrote: > Are there any *practical* uses for that thing? It could be useful if you have an idea of the name of the thing you're looking for and then want to narrow it down by type. Or you know you want a higher order function that works on a list but don't know where it is (so you look up "(a -> b) -> [a]"). The first example on Hoogle for that search is in GHC.Exts so if that's what you wanted it would be harder to find by browsing. That said, I'm not a heavy Hoogle user so I don't know. > That won't be hard in itself, but the real problem is huge blocks of > text in the results which would make it much less useful. I think this would be a more useful feature than the searching. Maybe it could display optionally or truncated if it's too long. Another nice thing Hoogle does is search Hackage, but I think that's been discussed here before (and probably depends on how packages end up?). Cheers, Asumu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] online check syntax: now disabled by default
On 2011-09-16 14:49:12 -0500, Casey Klein wrote: > On Thu, Sep 15, 2011 at 8:13 PM, Robby Findler > wrote: > > Yes, certainly! Core files (or just stack traces) are useful, I expect. > > > > I've been seeing a freeze roughly once a day. DrRacket gets > permanently stuck with the OS X rainbow pinwheel as the cursor, and > SIGKILLs won't kill it. I have to hard reboot. FWIW, I've had segfaults on Linux recently as well so it's not just OS X. Cheers, Asumu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Missing pregexp syntax in Racket
On 2011-11-29 15:43:27 -0500, Matthias Felleisen wrote: > > So, any volunteers? > I added this to the list of intro projects on GitHub, so if anyone wants to take this up, please put it up on GitHub/PLaneT and update the page: https://github.com/plt/racket/wiki/Intro-Projects Cheers, Asumu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Racket home page proposal
Hi all, Currently, the Racket home page is really nice, but it leaves a significant amount of vertical space unused that could be used to communicate information. How would people feel about adding more content "below the fold" on the website? To be more concrete about this, here's a mockup I made: http://www.ccs.neu.edu/home/asumu/racket-home/ (should look fine on Firefox, Opera, and Chrome at least) Notably, it contains a twitter feed for @racketlang and entries from the blog. These might help to give the first impression that we're an active community. Cheers, Asumu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket home page proposal
On 2011-12-20 08:02:15 -0500, Matthias Felleisen wrote: > I do NOT like pages that have text below my laptop screen 'fold'. > My eyes do glaze over. And I am off the page quickly. Taking some feedback into account, here's a second mockup: http://www.ccs.neu.edu/home/asumu/racket-home-3/ It leaves all the content "above the fold" but fits in more by using a fluid 12-column based layout (credit to http://cssgrid.net/). If you resize the browser window it will re-align the layout. The extra content in the space is a twitter/blog feed in the mockup, but it could be something else as well. Cheers, Asumu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] "bookmarks" in drracket?
On 2012-02-03 12:06:16 -0500, Stephen Chang wrote: > Any ideas on what the graphical representation should look like? > Should it be a popup window? Or a side bar? I like the idea of a breadcrumb UI (maybe at the bottom like PLaneT?): http://en.wikipedia.org/wiki/Breadcrumb_(navigation) Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] collections with no one responsible
On 2012-02-03 18:32:46 -0500, Sam Tobin-Hochstadt wrote: > As well as: > - gui-builder > No one has made significant changes (other than collection-wide > cleanups) to guibuilder in more than 6 years, except Asumu. Asumu, do > you want to take this on? AFAIK, this doesn't even ship with the standard Racket distribution. It probably makes more sense to remove it unless anyone actually uses it. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Abstract classes
Hi all, Stevie and I have been hacking on an addition to the class system that would allow classes to be made abstract. Abstract classes are already used in the codebase, so the idea here is to make this a language feature rather than a pattern. e.g., the private editor% class that implements the editor<%> interface and is a superclass of text% and pasteboard% contains many methods defined with the body (void) that aren't meant to be called. We have an implementation on github here: https://github.com/takikawa/abstract-methods Currently, abstract methods can be defined with a new class clause: (abstract m) that defines `m` as an abstract method. A class with at least one abstract method is an abstract class. Abstract methods are concretized using the `define/override` form. The idea is to be compatible with how people currently implement abstract methods as a design pattern (i.e., dummy method and an override). This means that we could even go back and change existing classes, e.g., in the GUI libraries, to use the abstract form without breaking compatibility with existing clients. There are several design questions that we're still pondering: * Should abstract classes be instantiatable or not? If so, abstract methods would only fail when they are called. If not, `new` will fail on an abstract class. Currently our implementation disallows instantiation of abstract classes. * What should the syntax of the abstract clause be? Matthias had the idea of specifying a method header to communicate intent, e.g. (abstract [m x y z]) for a method `m` that takes arguments `x`, `y`, and `z`. This gets complicated if we support the full range of argument options for a `define/public` (e.g., keywords). Any thoughts or suggestions? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Abstract classes
On 2012-02-07 12:01:10 -0600, Robby Findler wrote: > I'd say to try this position and go around in the codebase looking for > abstract classes to see if it works with what we have. That's a good idea. I can look into that. > One other abstract classe in the framework come to mind: the > frame:editor-mixin produces abstract classes. Creating abstract classes at runtime is a neat use-case. > What would you do with this information if you had it? We could either just let it be a hint for the programmer or actually check that concrete implementations match the signature. I think Matthias had the former in mind, but either way is an option if we had this. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Abstract classes
On 2012-02-07 12:17:18 -0600, Robby Findler wrote: > That seems like an interesting thing to explore, but it is in a > subtyping, not subclassing direction and probably is violated > somewhere in our codebase. Overall, it seems to point to a larger > redesign of the class system. That makes sense. > Also, I don't see too much value in the former if it is just a hint. > Seems useful to have that information in the documentation, tho. I definitely agree that a defabstract (or equiv.) form for documentation would be useful. It may be more useful to go this route rather than relying on the code to signify the intent of a method. *** Incidentally, I went through and replaced all of the methods that just call (void) in editor% with abstract methods as an experiment. Only three abstract methods failed to be concretized (and thus text% failed to instantiate): on-focus, set-snip-data, and on-paint. Of these, on-focus and on-paint were actually supposed to be implemented as (void) so that subclasses of text% or pasteboard% can rely on a protocol of calling super from the overriding method. set-snip-data, however, was only overridden in pasteboard%, suggesting the (void) implementation should actually be pushed into text% from editor%. There was another problem though: many methods in text% and pasteboard% were implemented to call super or call the inherited (void) implementation. These had concrete implementations, but would error when they tried to call the abstract supermethod. That still left around 63 methods that could be made abstract safely (well, at least 'safe' meaning DrRacket runs). Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket logo
On 2012-02-08 19:18:47 -0600, Robby Findler wrote: > John Clements and Neil Toronto have put together a new Racket logo > that I've just put on the DrRacket splash screen. See what you think. Very nice work! I think it will take some getting used to, but I like how energetic it is. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] web pages
On 2012-02-11 13:19:11 -0500, Matthias Felleisen wrote: > Asumu, did you drop the ball on your new web page design or is still in the > works? -- Matthias I haven't had time to work on it since my last e-mail, though I did discuss some ideas with Sam. I don't think I will be able to find much time to work on it anytime soon. There was some discussion in the last thread about improving front-page content (without a re-design), e.g., reconsidering the motto. Maybe that could be done in the short-term. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] new logo
On 2012-02-11 13:23:46 -0500, Matthias Felleisen wrote: > Have you guys considered a small change that makes the 'r' more > lambda-ish? Maybe an 'r' in different scripts can be considered? For example, an R rotunda: http://en.wikipedia.org/wiki/R_rotunda Or perhaps a script capital R: ℛ (if that unicode shows up) Both look more like lambdas than a lowercase Latin 'r'. (OTOH: you might lose the pun for most viewers) Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Google Summer of Code
On 2012-02-14 09:58:12 -0800, John Clements wrote: > I sent an e-mail to Asumu about a week ago that sneakily tried to get him to > take responsibility, and it sounds like he might be on it. If not, I'll take > the lead. Asumu? I'm still up for it. The application process starts on the 27th but we should do some preparation for it. First of all though, are people interested in this? If we're accepted, any students we get are paired up with mentors, so we'll need some people to volunteer for that. Probably not too many though. The mentor's responsibility is to get their student up to speed with the codebase/language & community, check up on progress (once or more a week), and formally evaluate the student. Other things we'd need: * an ideas list (the github page should do, with some modifications) * organization admin (I could do this, or anyone else more appropriate) and backup admin. * people willing to review student applications Also, the mentoring org. receives $500 per student who passes final evaluations so an IRS W-9 form is needed for tax purposes. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24346: master branch updated
On 2012-02-25 17:27:31 -0600, Robby Findler wrote: > I'm now going to be using it in DrRacket to do a better job with picts > in the REPL. Inspired by this talk[1] by any chance? I was thinking today that it'd be really neat if there were on-the-fly pict viewing somehow (not necessarily in DrRacket itself, but a tool maybe?). :) [1]: http://vimeo.com/36579366 Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] submodules
This sounds great! I haven't tried it out yet, but here are some preliminary comments. On 2012-03-07 10:14:35 -0700, Matthew Flatt wrote: > Submodules declared with `module' are declared locally while expanding > a module body, which means that the submodules can be `require'd > afterward by the enclosing module. This ordering means, however, that > the submodule cannot `require' the enclosing module. > > [...] > > The `module*' form is like `module', but it can be used only for > submodules, and it defers the submodule's expansion until after the > enclosing module is otherwise expanded. As a result, a submodule using > `module*' can `require' its enclosing module, while the enclosing > module cannot require the submodule. It seems to me that `module*` maybe actually be the common case for submodules because most of the time I would expect that you want to use the bindings of the enclosing module. This seems true for unit tests, driver modules, documentation (requiring for-template), and so on. Would it make sense to swap the `module` and `module*` forms? *** Another aspect of the syntax that I foresee being annoying is that each module nesting adds an additional indentation level. On the other hand, I don't see any good alternative for this. I only bring this up because this was problematic enough in the past to invent the #lang shorthand. Maybe a pattern that could avoid this is to have something like #lang racket/main #:main "driver.rkt" #:tests "tests.rkt" which would bring in the given modules (in the filesystem) as submodules. That way you could define submodules separately but still package them together in order to follow any protocols for documentation or unit testing that come about with submodules. Is that implementable with submodules? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Changes to `git push`
I just saw that the git project is considering changing the default behavior of the `git push` command and are taking feedback on the potential change. In case anyone is interested, here is the call for feedback: https://lwn.net/Articles/487131/ Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] request for triangle in slideshow/pict
On 2012-03-22 15:26:55 -0400, Stephen Chang wrote: > Would anyone find it useful to have a triangle primitive in > slideshow/pict? How easy would it be to add one? I told Stephen about this, but a generally useful thing is to have a procedure (and corresponding macro) that can build a pict out of a dc-path%. That lets you draw triangles and many other things easily. I've defined such a macro here (the `path` macro): https://github.com/takikawa/pict-utils/blob/master/pict.rkt and here is an example use (look for `path`, draws a pie slice): https://github.com/takikawa/pict-utils/blob/master/pict-test.rkt Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Class contracts: opaque or transparent?
Hi all, Recently I have been adding class contracts to parts of the GUI system. In tandem, I've also added a new feature to `class/c` that allows a contract to be opaque, which means that the contract requires that *all* public methods & fields in the contracted class are themselves contracted. This raises a question: should the contracts that are applied in our core libraries be opaque or transparent (status quo)? Note: this is a question about coding practice rather than language defaults. `class/c` will continue to be default transparent. The main benefit that I see for class contracts being opaque: * Enforces contract coverage: if a new public method/field is added to the implementation, the class contract will force the implementor to add a corresponding method/field contract (or at least specify its existence). You could also see this with a less strict connotation as helping you figure out your contract coverage. Possible counter-arguments: * Composability: opaque class contracts are not composable since each one requires the entire specification. This shouldn't be a problem since the individual class/c clauses can be composed/reused (e.g., ->m contracts). * Do we want contracts on all methods & fields? Any thoughts? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Class contracts: opaque or transparent?
On 2012-04-27 13:17:36 -0500, Robby Findler wrote: > Specifically, it seems like I can add the contract > (unconstrained-domain-> any) to each method to get it to be opaque > without actually contributing anything of value. > > [...] > > Or is there something else going on there that I'm missing? The primary reason that I added opaque contracts is that they are needed for Typed Racket's eventual class/object support. A secondary reason is for enforcing contract coverage. You're right though: you could get around this by writing a loose contract or by only specifying the name.[1] The intention is that the contract error would encourage people to write useful contracts (my mistake for saying "force"---it doesn't quite do that) rather than just bypass it. [1]: e.g., (class/c #:opaque m) will allow (class object% (super-new) (define/public (m) ...)) Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Class contracts: opaque or transparent?
On 2012-04-27 13:37:02 -0500, Robby Findler wrote: > I think that maybe I still misunderstand? Specifically, if I put an > opaque object contract on a value and the contract does not mention > 'm', then (send ... m) will be a runtime error The opaque class contract wouldn't produce an error on (send ... m) but instead when the contract is applied to the class. It's just a first-order check that makes sure that "the set of contracted members" = "the set of class members" > So, if that's the difference, then what would be the difference of > making the class/c contracts for the GUI transparent? If all methods have contracts, there is no difference at all. But suppose that someone adds a new method and they forget to add a corresponding contract. Opaque would then raise an error, transparent would not. Sorry if I'm being unclear. Let me know if that clears it up. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Class contracts: opaque or transparent?
On 2012-04-27 17:44:06 -0400, Matthias Felleisen wrote: > [[If you mentioned this issue in my office yesterday, I failed to catch it.]] I remembered/thought it as I was composing the e-mail. > In the old world, I could write contracts such as > > (and/c (class/cc ...) (class/c ...)) > > and that was *really convenient*. Are you saying I can > no longer do so? You can write that, but the following isn't very useful: (and/c (class/c #:opaque [m (->m number? number?)]) (class/c #:opaque [n (->m number? number?)])) Since the two class contracts both reject classes that the other would accept (unless `and/c` somehow merged the first-order checks of the two rather than checking both separately). It works if the two contracts mention exactly the same members. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Getting Started & install instructions
Hi all, I've long thought that the Getting Started page in the documentation is too sparse, so I discussed with Ryan and added some more content to it. The intent is to try to answer some frequent questions that beginners ask (e.g., "do I want the `racket` or the `drracket` executable?"). Ideally, I'd like to link to platform-specific installation instructions for Racket, but I couldn't find any on the Racket home page. Do we have a page that we can link to for this purpose? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Getting Started & install instructions
On 2012-05-01 16:04:18 -0400, Eli Barzilay wrote: > 1. No. The download page does try to detect your platform and put the >relevant download(s) first, but I don't think that even for this >use case the decision should be made automatically based on that >guess. What I was getting at is that there are no installation instructions linked from the Download page. What I mean is something like these: * http://www.ruby-lang.org/en/downloads/ "Three ways of installing Ruby" * http://typesafe.com/stack/download "Installing the TypeSafe stack"A * http://www.perl.org/get.html "Operating System information" * http://hackage.haskell.org/platform/ see "After downloading" for each I didn't write anything like this in the Getting Started page because it seems like it'd make more sense to put it on the Download page and link to it. I'll look at your prose feedback and push more commits in a bit. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Generics and data structures
Hi all, Racket currently provides several generic extensible data structure APIs such as dictionaries, sequences, streams, and so on. Unfortunately, each data structure currently has its own extension API, but no consistent convention exists: some APIs use lists of methods, some use vectors, etc. Furthermore, these APIs are usually rather low-level (e.g., dependent on ordering in the method table). Vincent and I have been working on a unified user-friendly extension interface based on unstable/generics by Eli and Jay (which we have moved to collects/generics). We have a prototype that implements our proposed interface for prop:dict and prop:ordered-dict with complete backwards compatibility with their respective extension APIs. That is, we have modified racket/dict and data/ordered-dict to use generics. The code is on github here: https://github.com/takikawa/racket/tree/generics We would like to get feedback on what we have so far and if nobody has any objections, we would like to push what we currently have to master. Ideally, we would provide similar interfaces for the other generic APIs in the tree, such as streams and sequences. However, the existing APIs rely on different representations for method tables from the one used by unstable/generics, specifically a vector of methods. This makes backwards compatibility complicated and we're not sure how to proceed. Some specific examples: * `prop:sequence`: Instead of a vector of methods, this struct property takes a procedure which takes a struct instance and produces a sequence (not a vector of methods). * `prop:equal+hash-code` uses a list of methods instead of a vector. * `prop:dict/contract` is given both a method vector and a vector of sub-contracts that are used to assemble the method contracts. The generics library currently uses a single vector. To apply our proposal to these cases, we could change these struct properties to use the generics library's preferred representation. However, this would break backwards compatibility with code that currently uses these struct properties, which makes this a non-starter. Does anyone have any suggestions on how to proceed without breaking backwards compatibility? Streams present a slightly different issue. `prop:stream` already represents its methods with a vector. However, it is used heavily in the implementation of racket/base, so we cannot re-write it to use generics (which depends on racket/base). Assuming we can't restructure racket/private/for to break the circular dependency, another solution would be to allow the generics library to create a generic interface attached to an existing struct property[1], given the struct property accessor. That would require exposing the struct property accessor from the internals of racket/base. Would that be an acceptable solution? [1]: currently, the generics library needs to be the one defining the struct property. Any thoughts or suggestions? Cheers, Asumu & Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Generics and data structures
On 2012-05-09 19:01:10 -0400, Neil Van Dyke wrote: > When you say "dictionaries, sequences,", are you including the > Racket types hash, vector, and list? Yes, the changes we made to racket/dict will work with hashes, vectors, and a-lists in the same way it did before. The only difference is when you define your own dictionaries using struct properties. > If so, would current performance for those Racket types be affected? > And does this have implications for what optimizations the compiler > would likely make in the foreseeable future? There should not be any performance impact for the base types. The racket/dict functions will not dispatch to generic methods unless the given object does not match any of the supported base types. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Generics and data structures
On 2012-05-09 18:02:04 -0600, Ryan Culpepper wrote: > See the 'supers' argument to 'make-struct-type-property'. > > Create 'real-prop:sequence' that takes a vector (compatible with > generics library). > > Define 'prop:sequence' as a backwards compatibility property that > takes an old-style implementation and transforms it into the > new-style implementation vector. 'prop:dict/contract' plays the same > trick, IIRC. Thanks! That seems like it will work nicely. It turns out that over dinner, after sending out the e-mail, Vincent and I came up with a similar solution. It's nice to know that this pattern is already supported by struct properties. It should even work with sequences, which we thought were difficult. You just need to create a vector of methods that just apply the normal sequence functions to the sequence created by `make-do-sequence`. We will try to implement this tomorrow. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Abort behavior different in DrRacket & Racket
Hi all, In the Guide entry on control[1], there's a section detailing prompts and abort. Here's an example from that section: > (define (escape v) (abort-current-continuation (default-continuation-prompt-tag) (lambda () v))) > (+ 1 (+ 1 (+ 1 (+ 1 (+ 1 (+ 1 (escape 0))) If you run this in the command-line REPL, it'll produce 0 as the Guide claims. However, if you run it in DrRacket, it will not return. It turns out that the abort handler for DrRacket is just: (lambda args (void)) while the abort handler for Racket is this: (lambda results (for-each (current-print) results)) Was this intentional or should both REPLs behave the same way for aborts? [1]: http://pre.racket-lang.org/docs/html/guide/prompt.html Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] syntax/syntax proposal
Hi all, Recently I was using the `stx-car` function from `syntax/stx`. At some point, I had called it on a non-syntax pair and the error message came from `car`, which is used inside the implementation of `stx-car`. I thought it would be nice to add contracts in `syntax/stx` for better error messages, but it turns out that the contract library depends on it and so it's impossible to do without introducing cycles. So I would like to propose a `syntax/syntax` library with the following: * provides `syntax/stx` functions with contracts attached (caveat: core libraries like `racket/contract` would still use `syntax/stx`) * for consistency with the rest of the language, `stx-car` and friends would be renamed to use the `syntax-` prefix instead of `stx-`. * the name of the library is also consistent with the rest of the language. This could replace `syntax/stx` for most users and provide both better error messages and identifiers that follow standard Racket naming convention. I've attached a patch that implements this. Any comments? Cheers, Asumu >From f480e8511c6f162e6a35d06861fb5dcd5a3bfb7a Mon Sep 17 00:00:00 2001 From: Asumu Takikawa Date: Fri, 15 Jun 2012 15:00:20 -0400 Subject: [PATCH] Add syntax/syntax library (aliases for syntax/stx functions with contracts) --- collects/syntax/syntax.rkt | 24 1 file changed, 24 insertions(+) create mode 100644 collects/syntax/syntax.rkt diff --git a/collects/syntax/syntax.rkt b/collects/syntax/syntax.rkt new file mode 100644 index 000..73261b7 --- /dev/null +++ b/collects/syntax/syntax.rkt @@ -0,0 +1,24 @@ +#lang racket/base + +;; syntax utilities + +(require + racket/contract/base + (rename-in syntax/stx +[stx-null? syntax-null?] +[stx-pair? syntax-pair?] +[stx-list? syntax-list?] +[stx-car syntax-car] +[stx-cdr syntax-cdr] +[stx->list syntax->list] +[stx-map syntax-map])) + +(provide/contract + [syntax-null? (-> any/c boolean?)] + [syntax-pair? (-> any/c boolean?)] + [syntax-list? (-> any/c boolean?)] + [syntax-car (-> syntax-pair? any)] + [syntax-cdr (-> syntax-pair? any)] + [syntax->list (-> syntax-list? (or/c list? #f))] + [syntax-map (->* (procedure?) #:rest syntax-list? any)] + [module-or-top-identifier=? (-> identifier? identifier? boolean?)]) \ No newline at end of file -- 1.7.10 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] syntax/syntax proposal
On 2012-06-15 15:12:05 -0400, Asumu Takikawa wrote: > I've attached a patch that implements this. Any comments? Just realized after I sent it that I'd change two things in the patch: * `syntax-null?`, `syntax-pair?`, `syntax-list?` would be defined using `procedure-rename` to get better contract error messages. * the `#:rest` contract is wrong, it'd really be `(listof syntax-list?)` And of course there'd be documentation in the final version too. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] syntax/syntax proposal
On 2012-06-15 15:09:15 -0600, Ryan Culpepper wrote: > The 'stx-*' functions work on values that aren't syntax objects, so > renaming them to 'syntax-*' would be misleading. Is that really so misleading though? There is already precedent for functions which take arguments not exactly matching their prefix. `list-ref` works on non-`list?` things, for example. Other examples include `syntax-local-module-exports`, `syntax-local-make-delta-introducer`, `syntax-local-module-required-identifiers`, and so on. > 'syntax->list' already exists and means something different from > 'stx->list'. This could be `syntax-list->list` instead maybe. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] syntax/syntax proposal
On 2012-06-15 17:39:27 -0400, Matthias Felleisen wrote: > Sounds like this should be documented and possibly even contracted. The contracts I wrote in the patch do reflect this via the `stx-pair?` predicate, FYI. By the way, the definition of a syntax pair in the documentation is this: A syntax pair is a pair containing a syntax object as its first element, and either the empty list, a syntax pair, or a syntax object as its second element. I may just be confused, but doesn't this conflict with the documented behavior of the `stx-pair?` predicate? Returns #t if v is either a pair or a syntax object representing a pair (see syntax pair). Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24750: master branch updated
On 2012-06-21 13:03:18 -0400, Eli Barzilay wrote: > Nice. How about adding a big "deprecated" to the class100 docs, and > make a note to remove it in a year? That trick is neat, but would it be a problem to just remove it now? Tony had the idea that we could just put it on PLaneT and tell people to change their `require`s if they really need it. Or we could put it up on github and tell people in the docs to `raco link` it to look like mzlib/class100. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24906: master branch updated
On 2012-06-25 20:35:21 -0400, as...@racket-lang.org wrote: > | racket/generics: add contract combinator > | > | The generics library now generates a `name/c` macro > | for a generic interface `name`. The combinator can be > | used to contract instances (or constructors) of a > | generic interface across standard contract boundaries. To add a bit more context, the purpose of this feature is to allow contracts to be applied to generic interfaces like how `prop:dict/contract` does for dictionaries. It's more flexible because it allows contracts to be added for any interface (without any additional properties) and allows contracts to be added at different places. e.g., you could export `make-prime-dict` and `make-dict` constructors with different contracts. If nobody minds, I may go ahead and convert uses of `prop:dict/contract` to use `dict/c` and export the latter from `racket/dict`. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24906: master branch updated
On 2012-06-25 20:15:49 -0500, Robby Findler wrote: > This is not directly related to your particular commit, but if I make > a make-prime-dict, does apply a contract at that point (using > 'contract')? If so, who are the parties that get blamed? The short answer is: the generated contract can be applied, for example, in the range of a constructor and the blame is from whatever contract boundary it was applied at. Longer: I'll explain by way of example. Suppose you define a generic interface: (define-generics simple-dict (dict-refsimple-dict key [default]) (dict-setsimple-dict key val) (dict-remove simple-dict key)) then you define an implementation of it (perhaps in a different module): (define-struct some-dict (v) #:methods gen:simple-dict [...]) then you can provide a constructor from that implementing module that contracts the resulting instance: (provide/contract [make-int-dict (-> key-value-list? (simple-dict/c [dict-ref (->* (simple-dict? symbol?) (any/c) integer?)] [dict-set (-> simple-dict? symbol? integer? simple-dict?)] [dict-remove (-> simple-dict? symbol? simple-dict?)]))])) You could also provide the same constructor under a different contract (with a subset of the operations if you want): (provide/contract [make-prime-dict (-> key-value-list-of-primes? (simple-dict/c [dict-set (-> simple-dict? symbol? prime? simple-dict?)]))])) Instances made with these constructors will have the appropriate checks when you use `dict-set` on them. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24906: master branch updated
On 2012-06-25 21:28:52 -0400, Asumu Takikawa wrote: > (provide/contract >[make-int-dict > (-> key-value-list? > (simple-dict/c > [dict-ref (->* (simple-dict? symbol?) (any/c) integer?)] > [dict-set (-> simple-dict? symbol? integer? simple-dict?)] > [dict-remove (-> simple-dict? symbol? simple-dict?)]))])) Addendum: something you might imagine wanting for a dictionary is a contract that looks like the following instead: (simple-dict/c #:params (key/c value/c) ; <-- [dict-ref (->* (simple-dict? key/c) (any/c) value/c?)] [dict-set (-> simple-dict? key/c value/c simple-dict?)] [dict-remove (-> simple-dict? key/c simple-dict?)]))])) taking after similar language constructs like type classes where you can parameterize the entire family of operations over the types. I experimented with this idea (where `key/c` and `value/c` are turned into parameteric contracts), but it turns out to be incompatible with our design. For example, there is no way for the dict contract above to apply to the constructor of the data structure (since that isn't an operation in the interface). Thus, the initial elements you provide to the constructor can't be looked up with `dict-ref` with the above parametric contract (the argument key is made opaque with `key/c` and won't be equal to any of the existing keys). My conclusion for now is that it's not obvious how to best handle contract parameterization over a data structure interface and that it requires more thought. Let me know if anyone has any ideas. :) Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24906: master branch updated
On 2012-06-25 21:19:33 -0500, Robby Findler wrote: > What do you mean by "made opaque by key/c"? The prototype I wrote would bind the parameters provided in the `#:params` argument to contracts produced by `new-∀/c`. If `key/c` is one of the parameters, then `dict-ref` with a key argument wraps it in an opaque struct. The constructor isn't part of the interface (and can't be in the current implementation of `define-generics`), so the initial keys in the dictionaries aren't wrapped in opaque structs, causing lookups of the initial keys to fail. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24906: master branch updated
On 2012-06-25 20:17:33 -0600, Ryan Culpepper wrote: > IIUC from your later message, you've implemented the generics > analogue of object/c (per-instance contract), whereas > prop:dict/contract is closer to class/c (per-type contract). It's a > little fuzzy because prop:dict/contract hacks in per-instance > contracts too in a kind of ad hoc way. That's a good point. The better analogy might be interface contracts vs. class/c. With generics, it is easy to control all points that an instance is created since constructors are just procedures. With classes, you can't get away with that since the instantiation forms are macros. The difference/advantage you might get with a per-type contract for generics is that you get a more interface-like blame story, as with interface contracts. Coverage isn't as much of an issue since you can just contract all constructors. Unfortunately, it's also not clear how to implement interface-like contracts for generics. Since the generics forms don't control the constructors, it's not obvious how to instantiate the blame at the construction site. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Bitwise operators
On 2012-06-19 17:54:48 -0400, Harry Spier wrote: > 2. Why the names arithmetic-shift and integer-length instead of > bitwise-shift and bitwise-length ? Late reply, but here's a reason: SRFI-33[1] and SRFI-60[2] already use these names. Although it looks like Racket's `arithmetic-shift` name predates SRFI-33 (and was more or less tradition among Schemes). It also differentiates from a `logical-shift`, should one ever be defined. Apparently `integer-length` was also the traditional name by the time the SRFIs rolled around. [1]: http://srfi.schemers.org/srfi-33/srfi-33.txt [2]: http://srfi.schemers.org/srfi-60/srfi-60.html Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Proposal for a "no-argument"
On 2012-07-01 09:27:00 -0400, Eli Barzilay wrote: > A more robust way to do that, which has become idiomatic in Racket is > to use (gensym). (And as a sidenote, in other implementations there > are various similar eq-based hacks.) IMO, this is an attempt to > improve on the #f case by guaranteeing a unique value, but at its core > it's still a similar hack. The gensym thing is used in parts of the GUI code for initialization arguments, e.g.: (class* mred% (area<%>) (init mk-wx get-wx-pan get-outer-wx-pan mismatches prnt [min-width no-val] [min-height no-val] [stretchable-width no-val] [stretchable-height no-val]) ...) Where `no-val` has been defined with a gensym. So it'd be nice to have the distinguished `no-argument` for these cases too. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket] "Insert Pict Box" menu item not found in DrRacket
On 2012-07-08 15:47:27 +0800, Grecks Grecks wrote: >Hi, I post an issue on github 2 month before. >[1]https://github.com/plt/racket/issues/101 For devs: while fixing this, I noticed that the code that used to implement this menu item is still around (along with string constants) but are unused. Should I remove that code while I'm at it? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket] "Insert Pict Box" menu item not found in DrRacket
On 2012-07-10 07:20:59 -0500, Robby Findler wrote: > Which string constants specifically were you planning to remove? I > should probably check that they aren't used on planet. The `slideshow-insert-pict-box` constant doesn't appear to be used. There are also `slideshow-hide-picts, `slideshow-show-picts, `slideshow-cannot-show-picts` as well---I'm not sure whether these are removable or not (I see they're used for a pict-snip%'s popup menu but I can't seem to trigger that menu in DrRacket). Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Deprecating collects
Hi all, Recently, we've made some progress on getting rid of parts of our legacy codebase (e.g., mzlib/class100). Since a release is coming up, that is an opportunity to do more cleanup. Vincent and I have been brainstorming what other collections could be set on a 1-year deprecation & removal notice. Here is a list of potential collections to deprecate with accompanying rationales. Some of these may still be useful and worth keeping around; we may have missed some of their use cases. This is just a first stab at it: - combinator-parser This library only has .txt documentaiton and looks bitrotted. There are no users of this collection as far as we know and it's unlikely to gain any (due to lack of documentation). - test-box-recovery A library for compatibility with the pre-v360 DrScheme format - tex2page Undocumented and it's unclear how it's related to Racket - defmacro in mzlib mzlib in general, but this one in particular because it is highly misleading for newcomers (who think it's a blessed macro facility). Has no real users in the core codebase (there are two requires in benchmarks but no uses) - mzlib Most of this library has been superceded and the rest should probably either be moved elsewhere (e.g., mzlib/control) or removed. - mzscheme This is a superceded, legacy language Some of these collections may have users outside of the codebase, but they are likely running on older versions of Racket anyway. Some of these collections could be turned into PLaneT packages instead. Any thoughts? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Deprecating collects
> - Original Message - > I agree that these should never be removed. I would not mind if they > were marked in some way as "these are here for legacy reasons. New > code should use XYZ" with specific pointers and helpful advice. Okay, we will just add the deprecation notices to the documentation (using the same notice that `htdp/image` and `mzlib/class100` use) but otherwise won't touch `mzlib` and `mzscheme`. There are also some libraries that are still in `mzlib` (with pointers from `racket`) such as `unit` and `control`, so we will go ahead and move these to `racket` and leave pointers in `mzlib` (but legacy code should still work) unless anyone has any objections. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket-bug] all/12861: promise/c does not maintain equality
(sending this e-mail to dev since it's not directly related to promise/c) On 2012-07-10 22:13:58 -0500, Robby Findler wrote: > Note that this means the guard on there is now going to be gone (as it > is meaningless since impersonators can arbitrarily change it). This is something that has confused me about impersonators on struct type property accessors. It seems like there is a use case for having an impersonatable property that still has a guard. For example, suppose the property and its accessor are defined and retained local to some module (for example, to store a generic method access table). This means that nobody outside of the module can impersonate the property through the accessor. Assuming your module itself upholds whatever invariants you expect of the property guard, it's not going to be arbitrarily violated. For example, with generics it might be desirable to have optional polymorphic contracts applied to methods in the method table. Since polymorphic contracts are impersonator contracts, the proxy on the method table property itself must be an impersonator. However, this impersonation doesn't violate the invariants of the method table property guard, which just ensures that the user provided valid methods for the method table. Maybe I'm missing something obvious though? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket-bug] all/12861: promise/c does not maintain equality
On 2012-07-11 11:33:39 -0500, Robby Findler wrote: > If you're limiting access, could you provide a function-based > interface that wrapped the impersonating procedures to add the checks > instead of using a guard? I'm not sure this would work because the user interface for inserting the data into the property is via the #:property or #:methods arguments in the `struct` form. The guard seems to be the only way to add any checking there (without wrapping or modifying `struct`). Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Deprecating collects
On 2012-07-10 13:39:37 -0600, Matthew Flatt wrote: > > - combinator-parser [...] > > - test-box-recovery [...] > > - tex2page [...] > > These seem fine with me, because I think they have no current users. > > We've had enough versions with the test-box recovery tool that if > someone really needs it, they can run an older version to get to the > new version. Okay, it sounds like the consensus is that it is okay to get rid of these three packages (if they are at least available elsewhere). If nobody objects, I plan to do the following in the next 2 days: - Remove the three packages from the core distribution (We can't deprecate combinator-parser or tex2page in documentation because neither has Scribble docs. We could just deprecate test-box-recovery in docs and put it on a 1-year counter if anyone would prefer that instead) - Put combinator-parser and tex2page on PLaneT. (It might make less sense to make test-box-recovery a PLaneT package, since it might be easier for users who would need this to just use an older DrRacket. Any opinions on this?) Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] contracts not okay?
On 2012-07-12 19:38:44 -0400, Matthias Felleisen wrote: > > | I updated and noticed that this was now failing because interface > > | contracts are not check structurally (any more?). I don't think this is a case of checking structurally or not. It is not valid, for example, for the following behavioral subtyping to hold: (-> number? boolean?) <: (-> number? [number?] boolean?) since the former cannot be used in contexts that expect to apply the optional argument (using imaginary contract notation where [...] means optional). You might want this to be okay in the other direction (though interface contracts will currently not allow it). > > | Should I change the documentation or is > > | this a bad backwards incompatibility with the older versions? I don't have an opinion on this since I'm not too familiar with gl-context<%>s. I wrote the contract based on the documentation. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] contracts not okay?
On 2012-07-12 20:19:34 -0400, Jay McCarthy wrote: > First, the interface wasn't even being associated with the class. This > was the source of my structural/not comment. Ah, I see. This interface was actually defined with `class->interface` before and I forgot to update the class to use the new separately defined interface. My bad. > Second, the interface contract (based on the documentation) was wrong > because the documentation is wrong. None of the implementation > actually take the optional arguments. Okay, my comment was just about this issue, but I think we are on the same page on this. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] `make-struct-type-property` and impersonators
Hi all, I mentioned an issue I had with struct type properties & impersonators in the promise/c thread, but I figured I should explain this in more detail. Currently, `make-struct-type-property` takes an optional argument which is the "guard" for the property. This guard is a procedure that checks the value coming from *users* of a property (via the `struct` form and #:property keyword). This is useful so that the implementor of a struct type property can rely on this guard invariant for whatever internal processing is needed. However, the guard can also be the 'can-impersonate symbol. In this case, there is no guard procedure and the struct type property accessor (the procedure actually used to obtain the stored value) can be impersonated. i.e., only one of these two are allowed: (define-values (prop:widget widget? prop:widget-accessor) (make-struct-type-property 'widget valid-widget?)) (define-values (prop:widget widget? prop:widget-accessor) (make-struct-type-property 'widget 'can-impersonate)) but not both. The issue is that there is a use case for having *both* impersonation of the accessor and a guard. The reason is that there are two interactions involved in a property: one interaction between the property implementor and the struct type creator, who provides the initial value using the `struct` form, and another interaction involving the client who accesses the property value in an existing structure instance. e.g., (struct a-widget (...) #:property prop:widget some-widget) ; guarded by `valid-widget?` vs. (prop:widget-accessor w) ; not guarded, could be redirected ; by some impersonator The guard protects the property implementor in the former interaction, whereas the client is the one that is affected by any impersonation of the property. Since these two interactions aren't necessarily related, it's still useful to guard the property even if the property can be arbitrarily impersonated. One example where I needed this is to attach impersonator contracts (i.e., polymorphic contracts) to a method table in the generics implementation. The table is stored in a struct property and needs to be impersonatable for contracting. However, I don't want to introduce additional code that duplicates the sanity checking that the guard would guarantee for the initial methods provided by the implementor of an *instance* of a generic interface. *** That was my summary of the problem. I propose to change the API a bit to make it more flexible: `make-struct-type-property` would take a keyword #:can-impersonate which will control impersonation entirely orthogonal to the guard argument (which would now be either #f or a procedure). I think this API would cover more of the possible use cases than what is currently available. One way to summarize the use of the guard is that with non-impersonatable properties, it is making a guarantee about what it is in the property. With impersonatable properties, it can only make a guarantee about the *initial* value of the property. The latter can still be useful though. Any thoughts? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Official PLaneT account?
Hi all, I heard rumours that there was once an official PLT PLaneT account intended for packages maintained by the dev team. Does anyone know if it exists and how to go about getting access to it? I was thinking that it'd be more appropriate to put the 'parser-combinator' and 'tex2page' packages under such an account rather than under mine. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Coroutines (mzlib/thread)
Hi all, I've been moving some libraries from mzlib to more appropriate places recently. I was meaning to move `mzlib/thread` to `racket/coroutine`, but had some questions about its API. It appears that the coroutines from `mzlib/thread` don't actually provide a built-in way to yield the computation to another coroutine. Instead, the coroutine is run with either a timeout or an event that suspends the computation and returns to the caller. Is this a useful coroutine API? It seems that to encode the typical `yield` construct you need to set up your own protocol with, say, a channel to trigger a context switch and then do scheduling manually. If we're going to bother providing it as a `racket` library, should we try to improve the API? NB: the only use I could find in the code base was in framework/private/color.rkt. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Coroutines (mzlib/thread)
On 2012-07-20 21:48:38 -0400, Matthias Felleisen wrote: > We can build it for real. Both interfaces have separate uses and > should be kept separate. -- Matthias My first thought was that these could be provided by the same interface, but let me see if I understand what you're saying. The issue with providing both options, is that if you provide an `yield` operator to implicit co-routines, you take away the ability to place all control of yielding from the controller. So couldn't we provide a version of `coroutine-run` that takes a #:yield keyword that enables/disables explicit yielding? If #:yield is off, then the `yield` procedure provided to the coroutine would be a no-op. Only the implicit yield condition would trigger a context switch. Otherwise, the procedure would yield and run some default scheduler. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] small documentation bug
On 2012-07-25 01:50:19 -0400, D Herring wrote: > I think that is incorrect. The Racket Reference says # is the > result only when the body is not evaluated. Thanks for the report! This was recently fixed in the pre-release version and will be in the docs for the next release. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Release Announcement for v5.3
On 2012-07-25 13:26:53 -0400, Ryan Culpepper wrote: > - add contracts to interfaces (6f4ad1de) "Interfaces from the racket/class library now allow contracts to be specified for methods. Instances of classes that implement such contracted interfaces will be protected by these contracts." > - generics (518bf0fd) > - contracts for generics (552d6de9) "The new racket/generic library allows the definition of generic functions, which will dispatch to methods added to a structure type. Methods can be added to structure types using the new #:methods keyword." > - prompt/c, continuation-mark-key/c (de5c756d, 095d47fc) "Contracts can now be applied to continuation prompt tags or continuation mark keys, which will respectively guard the use of control operators or access to data stored in continuation marks. > - abstract methods (06091079) "The class form now supports declaring a method abstract. An abstract method prevents a class from being instantiated unless it is overriden." > - mzlib deprecation notices (e4141077) "The mzlib/class100 library has been deprecated and will be removed in the first release after June 21, 2013" (the rest of the deprecation notices are just for documentation since we don't have any plans to remove them) > - class/c changes (3eb963f6) > - class contracts for racket/draw, racket/snip (30311058, 2e1d59f7) These are probably not worth including. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #25091: master branch updated
On 2012-07-26 20:07:16 -0400, ro...@racket-lang.org wrote: > 9356e8e Robby Findler 2012-07-26 18:58 > : > | try out Asumu's suggestion, namely if there is a keyboard event, > | then hide the definitions/interactions labels for a while (2 > | seconds currently). also, when the 2 seconds expires, fade back > | in instead of just appearing immediately > : Thanks, I like it. :) Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Release Announcement for v5.3
On 2012-07-26 19:06:38 -0500, Robby Findler wrote: > How about something like this: > > - the contract library has better support for interfaces, generics, > prompts, continuation-marks, and structs > > and then put those bullets, plus a bullet for struct/dc into the > racket HISTORY file (if they're not already there). That's fine with me. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Release Announcement for v5.3, second draft
On 2012-08-01 09:44:13 -0400, Sam Tobin-Hochstadt wrote: > > * The `tex2page' and `combinator-parser' libraries have been moved > > from the Racket distribution to PLaneT. > > This should include the URLs to the planet packages, and perhaps the > `require` lines. For convenience: http://planet.racket-lang.org/display.ss?package=combinator-parser.plt&owner=plt http://planet.racket-lang.org/display.ss?package=tex2page.plt&owner=plt (require (planet plt/tex2page)) (require (planet plt/combinator-parser)) Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #25179: master branch updated
This is really great. I especially like how you can "lock" the docs into place. One thing I was confused by is how to activate it. It appears to activate when I type an identifier standalone. For example, when typing this into the definitions window, it shows up ($ is the cursor): call-with-continuation-prompt$ However, this doesn't work: (call-with-continuation-prompt$ but the latter seems more useful, because I'm more likely to type the identifier in operator position. It does show up if I complete the expression and then put my cursor over it, like this: (call-with-continuation-prompt$ (lambda () (+ 1 2))) Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #25244: master branch updated
On 2012-08-21 12:45:03 -0400, as...@racket-lang.org wrote: > | This enables the use of polymorphic contracts with generic > | interfaces and their instances. > If you're curious how this can be used, I have an example up as a Gist that I've also checked in as a test: https://gist.github.com/3292447 It reminds me of type classes since the generic functions themselves are protected by polymorphic contracts (like how type class definitions usually consist of polymorphic operations) and you can specify more specific contracts for the instances of the interface (like instantiating a type class at some type). One caveat is that this doesn't work easily for generic functions that might also dispatch to non-struct datatypes (e.g., dictionaries with built-in hashes). You have to write more complicated contracts to handle these. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] #:forall for contract-out
Hi all, Is there any reason that the #:forall, #:∀ clause (dual to #:exists, #:∃) doesn't exist for contract-out? If it's just that nobody has written it, I've attached a patch that implements it. If there aren't any design issues anyone has in mind, I'll push it once I write tests and docs. Cheers, Asumu >From 39c7f488736dc842e6989c5088930e7b049142b5 Mon Sep 17 00:00:00 2001 From: Asumu Takikawa Date: Tue, 21 Aug 2012 14:46:13 -0400 Subject: [PATCH] =?UTF-8?q?Add=20#:forall,=20#:=E2=88=80=20to=20contract-out?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- collects/racket/contract/private/provide.rkt | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/collects/racket/contract/private/provide.rkt b/collects/racket/contract/private/provide.rkt index 5e92549..735a603 100644 --- a/collects/racket/contract/private/provide.rkt +++ b/collects/racket/contract/private/provide.rkt @@ -169,7 +169,8 @@ ;; compare raw identifiers for `struct' and `rename' just like provide does (syntax-case* clause (struct rename) (λ (x y) (eq? (syntax-e x) (syntax-e y))) [exists - (or (eq? '#:exists (syntax-e #'exists)) (eq? '#:∃ (syntax-e #'exists))) + (or (eq? '#:exists (syntax-e #'exists)) (eq? '#:∃ (syntax-e #'exists)) + (eq? '#:forall (syntax-e #'exists)) (eq? '#:∀ (syntax-e #'exists))) (cond [(null? (cdr clauses)) (raise-syntax-error who @@ -184,7 +185,7 @@ (if just-check-errors? (loop (cddr clauses) exists-binders) (with-syntax ([(x-gen) (generate-temporaries #'(x))]) - (cons (code-for-one-exists-id #'x #'x-gen) + (cons (code-for-one-poly-id #'x #'x-gen #'exists) (loop (cddr clauses) (add-a-binder #'x #'x-gen exists-binders)] [(x ...) @@ -192,7 +193,7 @@ (if just-check-errors? (loop (cddr clauses) exists-binders) (with-syntax ([(x-gen ...) (generate-temporaries #'(x ...))]) - (append (map code-for-one-exists-id + (append (map code-for-one-poly-id (syntax->list #'(x ...)) (syntax->list #'(x-gen ...))) (loop (cddr clauses) @@ -678,9 +679,11 @@ field-contract-id void? - ;; code-for-one-exists-id : syntax -> syntax - (define (code-for-one-exists-id x x-gen) - #`(define #,x-gen (new-∃/c '#,x))) + ;; code-for-one-poly-id : syntax -> syntax + (define (code-for-one-poly-id x x-gen poly) + (if (or (eq? '#:exists (syntax-e poly)) (eq? '#:∃ (syntax-e poly))) + #`(define #,x-gen (new-∃/c '#,x)) + #`(define #,x-gen (new-∀/c '#,x (define (add-exists-binders stx exists-binders) (if (null? exists-binders) -- 1.7.10.4 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #25179: master branch updated
On 2012-08-12 15:42:09 -0500, Robby Findler wrote: > But unlike other information from check syntax, it is activated by the > position of the insertion point, not the mouse position. I'm not sure > if this is the right call, but I thought it worth trying out. After using this for a bit, I've found it really useful for when I can't remember the argument order of a procedure. I think it's possible that it'd be more useful if it activated based on mouse position and faded out when the mouse cursor is off the identifier. Especially since you don't get the info as you're typing anyway (only after you have a valid expression). Right now you also have to make an extra click and then hover over the blue thing (unless it's locked, but then it never goes away even if you move the insertion point). Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] stream confusion
On 2012-08-22 14:04:36 -0700, Martin Neal wrote: >*Maybe a problem with generics? Thanks, that was a good insight. I'm pretty sure this is a problem with the addition of generics. The `stream-map` function uses the wrong bindings (the ones generated by the generics system) rather than the compatibility layer we provide to clients of the library. I'll look into fixing this. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
