Re: [racket-users] typed racket backend/ir & gpu computing
To clarify: neither my work nor Stephen's would allow you to re-use Typed Racket's typechecking or inference. Rather, we're working to make it easy to implement new eDSLs with custom type systems and intermediate representations while remaining macro-extensible. A few projects that have been inspiring to me on how to deal with some of the challenges of compiling high-level, functional languages for GPU computing are: - Harlan, Eric Holk's PhD project. It addresses high-level approaches to memory management and portability of first-class functions between CPU and GPU. (https://pqdtopen.proquest.com/doc/1810156180.html?FMT=ABS, https://github.com/eholk/harlan) - Accelerate, which embeds GPU programs written in a functional programming style in Haskell. (http://www.acceleratehs.org/) - BraidGL, which uses multi-stage programming and cross-phase persistent values to mediate the interaction between GPU and CPU code. (https://www.cs.cornell.edu/~asampson/media/papers/braid-oopsla2017-preprint.pdf) Having any of these ideas integrated with Racket's macros would be really exciting. I expect to have some of my tools stable enough to be usable by folks other than myself in the next month or so. If you're interested in building something and trying out an alpha, definitely send me an email. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[racket-users] Re: test suite for hygienic expander?
You might also find the redex model and examples from the scope sets paper useful: http://www.cs.utah.edu/plt/popl16/ On Monday, August 6, 2018 at 5:18:47 PM UTC-4, michael.ballantyne wrote: > > As far as I'm aware, the new expander was tested initially on the simple > cases in: > > https://github.com/racket/racket/blob/master/racket/src/expander/demo.rkt > > The `racket-tests-core` tests here: > https://github.com/racket/racket/tree/master/pkgs/racket-test-core/tests/racket > > particularly `stx.rktl`, `macro.rktl`, and perhaps `module.rktl`. > > and by simply attempting to expand `racket/base`, `racket`, the rest of > the standard library, and ultimately every package on the package server. > > I'm not sure many of these would make easy smoke tests for a hygienic > expander proposal, as many are quite specific to racket's syntax, > libraries, and choice of fancy expander APIs. > > > > On Monday, August 6, 2018 at 4:32:08 PM UTC-4, Mitchell Wand wrote: >> >> Is there a test suite for the macro expander? I assume that you must >> have one, but it would save me some effort if somebody can tell me where it >> is. >> >> I'm interested in finding out if you have good corner cases for testing a >> proposal for a hygienic expander. >> >> --Mitch >> >> -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[racket-users] Re: test suite for hygienic expander?
As far as I'm aware, the new expander was tested initially on the simple cases in: https://github.com/racket/racket/blob/master/racket/src/expander/demo.rkt The `racket-tests-core` tests here: https://github.com/racket/racket/tree/master/pkgs/racket-test-core/tests/racket particularly `stx.rktl`, `macro.rktl`, and perhaps `module.rktl`. and by simply attempting to expand `racket/base`, `racket`, the rest of the standard library, and ultimately every package on the package server. I'm not sure many of these would make easy smoke tests for a hygienic expander proposal, as many are quite specific to racket's syntax, libraries, and choice of fancy expander APIs. On Monday, August 6, 2018 at 4:32:08 PM UTC-4, Mitchell Wand wrote: > > Is there a test suite for the macro expander? I assume that you must have > one, but it would save me some effort if somebody can tell me where it is. > > I'm interested in finding out if you have good corner cases for testing a > proposal for a hygienic expander. > > --Mitch > > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] internal-definition-context-binding-identifiers & macro scopes
It's true that `internal-definition-context-binding-identifier` is unusual in not applying `syntax-local-introduce` to the identifiers it returns, but that doesn't capture the whole problem. Let's imagine we made things consistent by mapping `syntax-local-introduce` over the returned names. Let's also, though, bind an identifier that has an extra scope that should make it distinct from the `var` we look up: #lang racket (define-for-syntax (sanity-check var) (define ctx (syntax-local-make-definition-context)) (syntax-local-bind-syntaxes (list ((make-syntax-introducer) var)) #f ctx) (cond ; should be non-#f; we just bound it! [(member (internal-definition-context-introduce ctx var) (map syntax-local-introduce (internal-definition-context-binding-identifiers ctx)) free-identifier=?) 'ok] [else (error "failed check")])) (define-syntax (m1 stx) #`'#,(sanity-check #'test)) (m1) We find that they're `free-identifier=?`, even though we added the extra scope to the binder! The problem here is that neither `(internal-definition-context-introduce ctx var)` or the identifiers in `(map syntax-local-introduce (internal-definition-context-binding-identifiers ctx))` now have the introduction scope, because we've removed it to match the "negative space" within the macro where syntax without an introduction scope should be considered introduced, rather than the "postive space" outside of the macro where the introduction scope means it the syntax was introduced. So when `free-identifier=?` resolves each of the two references, it finds them both unbound. And unbound references with the same symbol are `free-identifier=?`. To get the right answer, you need to ask `free-identifier=?` of identifiers in "positive space". In this case you should write: (member (syntax-local-introduce (internal-definition-context-introduce ctx var)) (internal-definition-context-binding-identifiers ctx) free-identifier=?) On Tuesday, July 24, 2018 at 8:32:56 AM UTC-4, Matthew Flatt wrote: > > At Tue, 24 Jul 2018 00:47:19 -0700 (PDT), Milo Turner wrote: > > Hello Racketeers. > > > > I'm having trouble understanding why this free-identifier=? check is > > failing: [...] > > > > This suggests that internal definition contexts are aware of the macro > > introduction scope in some way. The documentation doesn't mention this > sort > > of thing, so I'm wondering if there is some explanation I'm missing? > > I think it's a documentation issue, or perhaps a design issue with > `internal-definition-context-binding-identifiers`. > > Various operations implicitly use `syntax-local-introduce`, and I have > never been clear on when/where that needs to be specified. For example, > `local-expand` implicitly uses `syntax-local-introduce` on its > argument, because that's going back out of the current macro in a > sense, and it uses `syntax-local-introduce` again on the result. The > implicit uses of `syntax-local-introduce` make things "just work", and > so the uses are normally not mentioned in the documentation. > > Occasionally, however, there's a mismatch. In this case, > `syntax-local-bind-syntaxes` implicitly uses `syntax-local-introduce` > on its argument, but `internal-definition-context-binding-identifiers` > doesn't use `syntax-local-introduce` on its result. I think that's the > mismatch you're seeing. > > Overall, the documentation should be improved/corrected to mention the > implicit `syntax-local-introduce`s, and then exceptions like > `internal-definition-context-binding-identifiers` can be highlighted. > > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[racket-users] Re: On Richard P. Gabriel’s “The Structure of a Programming Language Revolution”
The idea of systems vs languages from that article felt important to me, too, though I'm not sure I understand it exactly the same as Gabriel does. I look back at programming environments like Smalltalk-80 and the Symbolics lisp machine with a bit of envy. They had features that relied on the tight integration between the language and the programming environment: * Smalltalk's fix-and-continue debugging, which let you create a missing method or change a broken call without restarting execution. * In Symbolics, you could select any GUI element and find out which code was drawing it * Also in Symbolics, REPL results were retained as objects you could select and use as arguments in subsequent REPL interactions. Autocomplete would suggest REPL results of the appropriate type. My impression is that Gabriel is right that languages won out over complete systems as the objects of academic study, or at least that the subjects split as the field specialized. Research on "integrated" development environments is now bolted on after the language and standard library already exist, and maybe by somebody in "software engineering" rather than "programming languages". I think the split leads to bad programming environments. Designing the language and environment together enables things like Elm's delightful time-traveling debugger (http://elm-lang.org/blog/the-perfect-bug-report). Racket's community definitely pays attention to the complete programming system more than many other folks in academic PL do, via lots of work in DrRacket and other things like Scribble. The consequences of the paradigm shift from systems to languages still feel present, though. On Wednesday, April 18, 2018 at 2:40:26 PM UTC-4, Alexis King wrote: > > Hello all, > > I have a rather different sort of question to ask about from my usual > fare. A month or two ago, I read an essay written by Richard P. Gabriel > and published at Onward! 2012 called “The Structure of a Programming > Language Revolution”. The essay itself is available here to those > interested in reading it: > > http://dreamsongs.com/Files/Incommensurability.pdf > > The essay covers a number of things, from CLOS and Smalltalk to the > concept of incommensurability, but one of the things I found most > intriguing was this thesis: > > > The real paradigm shift? Systems versus languages. Before 1990, a > > person interested in programming could work comfortably both in > > programming languages and in programming systems, but not so easily > > after. To tell the truth, I never even noticed the different words — > > language versus system — never attached any significance to the word > > choice until this exploration. I used the phrases interchangeably for > > many years: Programming System / Programming Language. > > Gabriel goes onto elaborate on the difference between so-called “systems > thinking” and “language thinking”. From his perspective, Common Lisp > sits squarely in the “systems” camp, and Scheme in the “language” camp. > He makes the claim that the amount of effort Common Lisp dedicates to > things like redefinition to support a running system are the effect of > systems thinking, which has more or less fallen out of favor in the > academic community in recent decades. > > This got me thinking about Racket, since much of Racket sits firmly in > the language thinking camp. Racket focuses on the language being a > single source of truth, on soundness, on syntactic properties and formal > semantics. It discourages things like long-running systems and dynamic > reflection. On the other hand, Racket is clearly made up of many systems > in addition to its many languages: the macro system, the > chaperone/impersonator system, and the namespace system all come to > mind. (On the other hand, perhaps the line is much blurrier than Gabriel > would have one believe: do contracts really belong cleanly to either > philosophy?) > > Since then, I’ve wondered what thoughts other Racketeers would have in > response to Gabriel’s essay. The ability to have a live, dynamic system > akin to Common Lisp’s images is a useful feature, but it certainly > requires “systems thinking”, and it is unsatisfying from a “language > thinking” point of view. To pose a question to those who have been doing > this longer than me, do you think this proposed philosophical binary > really makes sense? Does Racket really fit in more closely with one or > the other? Philosophically, does Racket reject things like CLOS and > redefinition/long-running images just because they don’t work in the > edge cases, or is there some bigger picture here that I’m not seeing? > > Thanks in advance for your thoughts, > Alexis > > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com.
[racket-users] Quasisyntax bug?
The expression: (quasisyntax (quote-syntax quasisyntax)) seems to result in an infinite loop. Does anyone know if that's a bug, or expected behavior? Thanks! -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[racket-users] Copying a (preferably sandboxed) evaluator with all state
Is there a way to make a deep copy of the state of a sandbox evaluator, such that I could start up another evaluator from the same state? I'm imagining a collaborative programming environment where users could fork the state of a REPL with all it's definitions, computed values, etc and begin an independent interaction from that state, while the original REPL session continued. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Re: [racket] Unsafe version of require/typed?
To offer another speculative solution, perhaps there could be a variant of Typed Racket structs that are opaque to untyped Racket. If only Typed Racket code is capable of constructing these objects, the types of their contents needn't be checked as they pass between typed and untyped code. On Friday, May 1, 2015 at 10:08:07 AM UTC-6, Neil Toronto wrote: > Submit a bug report, because that number is obviously false. (Or you've > misunderstood how to use it, in which case the documentation probably > needs work. :D) > > The problem is that first-order polymorphic contracts are O(n) in the > size of the data. See my other, much, much longer reply to Matthias. > > It's a shame, because TR is such a nice language to write data > structures in. > > Neil ⊥ > > On 05/01/2015 12:00 PM, Michael Ballantyne wrote: > > I'm delighted to offer both. Here's a particularly pathological test case: > > > > https://github.com/michaelballantyne/typed-racket-performance > > > > Using a typed/racket/no-check variant of the tr-pfds package makes my > > untyped code run 1275x faster. The feature-profile tool reports that > > in the TR variant "Contracts account(s) for 0.49% of total running > > time", but I'm not sure I believe it. > > > > On Fri, May 1, 2015 at 6:02 AM, Matthias Felleisen > > wrote: > >> > >> What I'd much prefer at the moment over speculative solutions are reports > >> of actual performance bottlenecks. -- Matthias > >> > >> > >> > >> > >> > >> On May 1, 2015, at 1:09 AM, michael.ballantyne wrote: > >> > >>> I've started using Typed Racket several times recently only to flip the > >>> switch to #lang typed/racket/no-check or remove types entirely. Something > >>> like Vincent suggests with an option to write with types and have them > >>> checked but turn off the type-driven optimizer and skip contract checking > >>> at typed/untyped boundaries would be fantastic. > >>> > >>> Having the option to flip this switch either from the code doing the > >>> requiring or at package installation time seems important, regardless of > >>> whether the author of the typed code wrote with that in mind. When I > >>> wanted to use the tr-pfds package from untyped code I had to modify it to > >>> use #lang typed/racket/no-check because the performance hit of contract > >>> checks was massive. > >>> > >>> A raco option to compile and install a package without Typed Racket > >>> optimizations or contracts might be another piece of the solution. > >>> > >>> > >>> On Monday, March 23, 2015 at 1:23:12 PM UTC-6, Robby Findler wrote: > >>>> Just to be sure we are on the same page, my comments were in the > >>>> context of push back that came for reasons that are unclear to me, but > >>>> I think had something to do with the thought that we shouldn't > >>>> compromise the type system. My comments were meant to be in that > >>>> context, trying to point out what the real value of a type system is; > >>>> that is, to give a judgment we can use as a basis for design decisions > >>>> here. > >>>> > >>>> As for smothering: the cost of contracts is "observable enough" (you > >>>> know what I mean) that we cannot just ignore it, as I'm sure you > >>>> agree. And since we do not have an acceptable solution we should > >>>> explore generalizing our support for unsafe operations that we already > >>>> have. It seems to fit very naturally to think of parallel libraries, > >>>> the safe and the unsafe version. > >>>> > >>>> I also like Vincent's idea about coupling the optimizer to the > >>>> contracts as a point worth pragmatic exploration. We shouldn't kid > >>>> ourselves, however, it is still unsafe and programs that turn it on > >>>> can behave in arbitrarily weird ways (when an error is skipped over). > >>>> > >>>> Robby > >>>> > >>>> > >>>> On Mon, Mar 23, 2015 at 2:12 PM, Matthias Felleisen > >>>> wrote: > >>>>> > >>>>> On Mar 20, 2015, at 5:10 PM, Robby Findler > >>>>> wrote: > >>>>> > >>>>>> Well, that's
[racket-users] Re: [racket] Unsafe version of require/typed?
I've started using Typed Racket several times recently only to flip the switch to #lang typed/racket/no-check or remove types entirely. Something like Vincent suggests with an option to write with types and have them checked but turn off the type-driven optimizer and skip contract checking at typed/untyped boundaries would be fantastic. Having the option to flip this switch either from the code doing the requiring or at package installation time seems important, regardless of whether the author of the typed code wrote with that in mind. When I wanted to use the tr-pfds package from untyped code I had to modify it to use #lang typed/racket/no-check because the performance hit of contract checks was massive. A raco option to compile and install a package without Typed Racket optimizations or contracts might be another piece of the solution. On Monday, March 23, 2015 at 1:23:12 PM UTC-6, Robby Findler wrote: > Just to be sure we are on the same page, my comments were in the > context of push back that came for reasons that are unclear to me, but > I think had something to do with the thought that we shouldn't > compromise the type system. My comments were meant to be in that > context, trying to point out what the real value of a type system is; > that is, to give a judgment we can use as a basis for design decisions > here. > > As for smothering: the cost of contracts is "observable enough" (you > know what I mean) that we cannot just ignore it, as I'm sure you > agree. And since we do not have an acceptable solution we should > explore generalizing our support for unsafe operations that we already > have. It seems to fit very naturally to think of parallel libraries, > the safe and the unsafe version. > > I also like Vincent's idea about coupling the optimizer to the > contracts as a point worth pragmatic exploration. We shouldn't kid > ourselves, however, it is still unsafe and programs that turn it on > can behave in arbitrarily weird ways (when an error is skipped over). > > Robby > > > On Mon, Mar 23, 2015 at 2:12 PM, Matthias Felleisen > wrote: > > > > On Mar 20, 2015, at 5:10 PM, Robby Findler > > wrote: > > > >> Well, that's already the case if you use the FFI (which lots and lots > >> of Racket programs do). > >> > >> Fundamentally the typechecker is a tool that programmers can choose to > >> use to make their programs better. It should not try to be more than > >> that. > > > > > > I think these statements paint an image in broad brushstrokes that > > some people appreciate properly and some don't. > > > > Yes, ffi/unsafe makes Racket programs unsafe. They may introduce > > causes for segfaults beyond the Racket engine itself. That's not > > a good thing but ffi/unsafe suggests this problem by its name and > > I think we try to stick this to a layer where we know it's potentially > > problematic. > > > > Otherwise the goal is to smother the unsafety of the existing software > > infrastructure. If we don't have such a minimal goal, why bother with > > Racket (at least from a research perspective)? > > > > ;; -- > > > > On Mar 23, 2015, at 1:37 PM, Vincent St-Amour wrote: > > > >> Then there's the possibility of turning off the optimizer (makes most > >> sense for the `#lang` design), which would compromise by avoiding > >> contracts, but remain as safe as `#lang racket`. There's already a way > >> to turn off the optimizer (`#:no-optimize`), so that may be redundant. > > > > > > This is an acceptable and pragmatic alternative. It gives the programmer > > some of the advantages of types (checking, documentation, hooks for tools). > > And it does not lower the level of safety that Racket aims for. > > > > On a more general note: It also exposes the Reynolds insight that types > > are an inherent part of the meaning (static). As such, compiling uses of > > first in > > > > (: f (-> [List X Y Z] X)) > > > > to not check the listness of the argument is intrinsic to __compilation__, > > not __optimization__. I think the strict use of this guideline would > > establish > > another point in our language spectrum. > > > > > > -- Matthias > > > > > > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
