Re: [racket-users] Racket2 and syntax
Well! While I am sure that everyone at RacketCon has already discussed this to death, and I’m sure there has been plenty of support to counterbalance the tomato-throwing, let me be the first to say something positive on the mailing list so the optics from here aren’t so gloomy: I find this idea extremely exciting. :) It’s a surprise, for sure, but I will not be doing any panicking. I don’t have any significant commentary right now, given how vague and open-ended the direction still is, but I am excited by the idea of continuing the Honu line of research. I, too, don’t mind parentheses, but after straddling the Haskell and Racket communities for a few years, I’ll happily defend the readability advantages of a more irregular syntax. I keep coming back to Racket because nothing lets me extend the language like Racket does, but if I could get that kind of flexibility and robustness without s-expressions? It sounds hard to achieve, but if Racket can pull it off (and I am confident Racket can do it as well as anyone), I doubt I would do much looking back. If anything, the one thing I’m disappointed about is that I could not be at RacketCon this year, as it seems like it’s been a bad one to miss, but it’s been fun to follow everything as best as I can from the sidelines. Many thanks to everyone who’s had a part in the organizing, speaking, recording, and streaming! I look forward to seeing where this goes. Alexis > On Jul 14, 2019, at 21:29, Matthew Flatt wrote: > > tl;dr DON'T PANIC > > At RacketCon today, after summarizing the state of work on Racket CS, I > recommended that we next explore the possibly of changing to an > infix-oriented syntax in "Racket2". > > You can find the recording here: > > https://www.youtube.com/watch?v=dnz6y5U0tFs > > Start at 32:27 for the part about what Racket2 could be. > > I'll produce a text version of the rationale soon. For now, I'd like to > offer a few clarifications: > > * There is no specific proposal for a new syntax, yet. Our next step > will be creating a process to explore a possible new syntax. > > * The talk does include some initial constraints that might guide the > choice of a syntax. Even that meta level (i.e., the set of > constraints) remains subject to a community process. > > * `#lang racket` is not going away and will always have its current > parenthesis-oriented syntax. In the same way that Racket still > supports `#lang scheme` and `#lang mzscheme` and even `(module >mzscheme )` and even top-level programs, the Racket > compiler and runtime system will always support `#lang racket` > programs. We believe that Racket's `#lang`-based ecosystem makes it > uniquely positioned for trying new language variants while > preserving and building on our past investments. > > * Any new syntax must specifically preserve Racket-style > language-oriented programming, which means everything from defining > simple pattern-based macros to building whole new `#lang`s with a > smooth path in between. Again, our current macro technology must be > an enabler for a new surface syntax, not a casualty. > > As I hope comes across in the talk, I like the current Racket syntax > --- and how could I not, after 24 years of helping to define it? --- > and I am aware of many potential technical and social pitfalls that > this kind of shift could create. Still, in addition to keeping the core > Racket implementation running, I feel obliged to recommend changes that > I think would be good for the Racket language and community. We've been > lining up some technical solutions for a while. I don't know where the > community discussion will lead, but I'm pretty sure it's time to start > the conversation. > > Whether or not we eventually decide on a different syntax, the design > of Racket2 will require community input and participation. If you want > to know more about how we're thinking about that process, see the > keynote by Aaron Turon: > > https://www.youtube.com/watch?v=xSjk2PdQm5k > > (We'll have professionally edited videos of all talks available soon.) > > Thanks, > Matthew -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/E3D28E85-DB14-4734-B18E-5DFAF6CD9AB0%40gmail.com. For more options, visit https://groups.google.com/d/optout.
[racket-users] recursion schemes
Hi, I recently became interested in recursion schemes, and I noticed that almost all implementations are in typed languages. I understand the advantage of having an implementation using recursion at the type level, but why is it that there are so few material in untyped languages? For instance, would a recursion schemes racket lib be useful or is there something I am missing? I noticed that there is no such lib, currently. Thanks, Raoul -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/6c54e287-8b50-40cf-8ef2-5309de572728%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[racket-users] Racket2 and syntax
tl;dr DON'T PANIC At RacketCon today, after summarizing the state of work on Racket CS, I recommended that we next explore the possibly of changing to an infix-oriented syntax in "Racket2". You can find the recording here: https://www.youtube.com/watch?v=dnz6y5U0tFs Start at 32:27 for the part about what Racket2 could be. I'll produce a text version of the rationale soon. For now, I'd like to offer a few clarifications: * There is no specific proposal for a new syntax, yet. Our next step will be creating a process to explore a possible new syntax. * The talk does include some initial constraints that might guide the choice of a syntax. Even that meta level (i.e., the set of constraints) remains subject to a community process. * `#lang racket` is not going away and will always have its current parenthesis-oriented syntax. In the same way that Racket still supports `#lang scheme` and `#lang mzscheme` and even `(module mzscheme )` and even top-level programs, the Racket compiler and runtime system will always support `#lang racket` programs. We believe that Racket's `#lang`-based ecosystem makes it uniquely positioned for trying new language variants while preserving and building on our past investments. * Any new syntax must specifically preserve Racket-style language-oriented programming, which means everything from defining simple pattern-based macros to building whole new `#lang`s with a smooth path in between. Again, our current macro technology must be an enabler for a new surface syntax, not a casualty. As I hope comes across in the talk, I like the current Racket syntax --- and how could I not, after 24 years of helping to define it? --- and I am aware of many potential technical and social pitfalls that this kind of shift could create. Still, in addition to keeping the core Racket implementation running, I feel obliged to recommend changes that I think would be good for the Racket language and community. We've been lining up some technical solutions for a while. I don't know where the community discussion will lead, but I'm pretty sure it's time to start the conversation. Whether or not we eventually decide on a different syntax, the design of Racket2 will require community input and participation. If you want to know more about how we're thinking about that process, see the keynote by Aaron Turon: https://www.youtube.com/watch?v=xSjk2PdQm5k (We'll have professionally edited videos of all talks available soon.) Thanks, Matthew -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/5d2be52a.1c69fb81.f77b6.e393SMTPIN_ADDED_MISSING%40gmr-mx.google.com. For more options, visit https://groups.google.com/d/optout.
[racket-users] Re: The case, and a proposal, for elegant syntax in #lang racket2
Not willing to enter the discussion I feel incompetent about, just for a
sake of completeness I will mention another previous attempt that wasn't
mentioned before (alternative to sweet/wisp):
http://breuleux.net/blog/liso.html
On Sunday, July 14, 2019 at 7:44:30 PM UTC+2, cwebber wrote:
>
> The context of this email is the proposal by Matthew Flatt that we move
> to an easier-to-accept surface syntax for #lang racket2.
>
> Matthew Flatt has heard more than enough from me of concern about this
> proposal. But I should indicate that I'm highly sympathetic to the
> goal. I would like to lay out the following observations:
>
> - The challenge with s-expressions is largely in anxiety with something
>that looks extremely alien. I suspect there's more fear from
>instructors than students in encountering a lisp syntax; my
>experience is that introducing someone who doesn't know differently
>to a parenthetical syntax isn't scary for them, and they tend to like
>it. But people who have *started out* with experience in a non-lispy
>language tend to find it scary.
>
> - Nonetheless, assumptions that various math operators should be infix
>is understandable because that's what people see today.
>
> - I am indeed very for growth in the community, though my main interest
>in growth is in seeing a wider diversity of participants than just
>raw numbers. Obviously other peoples' mileage may vary.
>
> - We are at serious risk in this pivot of losing some key things:
>
>- Many communities I have been in that have undertaken such a large
> pivot to increase popularity expend enormous energy in the move to
> the new thing, and in that process, the project actually collapses.
> What I'm trying to say is that a pivot is a gamble; we should
> calculate our odds carefully. (Indeed, the first thing I thought
> when I heard that this might happen was, did I make a mistake in
> shifting my work to Racket? It is unlikely I would have come to
> Racket if there wasn't an equivalent amount of elegance.)
>
>- I'm not sure if I could have understood Racket Week with a syntax
> that didn't have the elegance of s-expressions. This is not to say
> that *no* syntax can have that level of elegance where things can
> be so clear, however.
>
> IIRC Matthew's proposal for "#lang racket2" was something like the
> following:
>
> a) function(args ...) should work.
> b) infix is necessary for math, such as 3 + 4
> c) parentheses should be possible for grouping
>
> The weird thing about the last one being that this is already kind of
> true in s-expressions, but by ~default this also results in application.
>
> Let me add one more suggested design goal:
>
> - the new syntax should must not be significantly less elegant than
>s-expressions.
>
> Is there a way to achieve this? I actually think the best path forward
> is to have a surface syntax that actually maps completely to
> s-expressions, which is in fact universal that it can work with *any*
> s-expression syntax.
>
> I would suggest starting with Wisp as the basis for examining this:
>
> https://dustycloud.org/blog/wisp-lisp-alternative/
> https://srfi.schemers.org/srfi-119/srfi-119.html
>
> Sweet-expressions may also be an alternative to explore. However, I
> think Wisp is a more elegant base; it can transform *any* wisp code into
> s-exp code. Not discussed in my blogpost about Wisp is that it also
> supports infix via {3 + 4}. So ok, now we have that. And we can still
> group:
>
> {3 + {8 + 4}}
>
> So that's points b) and c), but we don't have a) yet. Could we add it?
>
> I think we can extend wisp with one thing and get everything we want: if
> you have func(arg1 arg2 arg3) where the parenthesis comes *immediately*
> after the symbol, that is rewritten to (func arg1 arg2 arg3). I will
> call this version ~Wisp.
>
> With all this, observe the following code rewritten from Scheme to ~Wisp:
>
> (define (rgb-maker mk)
> (lambda (sz)
> (vc-append (colorize (mk sz) "red")
> (colorize (mk sz) "green")
> (colorize (mk sz) "blue"
>
> define rgb-maker(mk)
> lambda(sz)
> vc-append(colorize(mk(sz) "red")
> colorize(mk(sz) "green")
> colorize(mk(sz) "blue"))
>
> Here is another chunk of code, taken from HTdP2:
>
> (and (or (= (string-length "hello world")
> (string->number "11"))
>(string=? "hello world" "good morning"))
>(>= (+ (string-length "hello world") 60) 80))
>
> To:
>
> and(or({string-length("hello world") = string->number("11")}
> string=?("hello world" "good morning"))
> {{(string-length "hello world") + 60} >= 80})
>
> And in fact the latter can transform itself *directly* into the former.
> And the former technically is also still valid Wisp:
Re: [racket-users] Building "#lang dungeon"
ra...@airmail.cc writes: > There is http://shill.seas.harvard.edu/ it runs on freebsd. Yes, it's a good source of inspiration. However it's really meant for shell scripting and isn't quite a good fit for the case I need, which is for more general racket programming. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/87r26sqp8x.fsf%40dustycloud.org. For more options, visit https://groups.google.com/d/optout.
[racket-users] Re: The case, and a proposal, for elegant syntax in #lang racket2
>
> (Indeed, the first thing I thought
> when I heard that this might happen was, did I make a mistake in
> shifting my work to Racket? It is unlikely I would have come to
> Racket if there wasn't an equivalent amount of elegance.)
>
I want to briefly echo this sentiment. I've been casually learning Racket
for several months (and greatly enjoying it), which was preceded by several
months of reading and thinking about which programming language to learn
next (my background is as a biologist that uses R and NetLogo). When I was
listening to the livestream this morning, I had a moment of panic that
maybe I had made the wrong choice to learn Racket. Or maybe I jumped on the
Racket train at the wrong time.
Thanks,
Travis
On Sunday, July 14, 2019 at 10:44:30 AM UTC-7, cwebber wrote:
>
> The context of this email is the proposal by Matthew Flatt that we move
> to an easier-to-accept surface syntax for #lang racket2.
>
> Matthew Flatt has heard more than enough from me of concern about this
> proposal. But I should indicate that I'm highly sympathetic to the
> goal. I would like to lay out the following observations:
>
> - The challenge with s-expressions is largely in anxiety with something
>that looks extremely alien. I suspect there's more fear from
>instructors than students in encountering a lisp syntax; my
>experience is that introducing someone who doesn't know differently
>to a parenthetical syntax isn't scary for them, and they tend to like
>it. But people who have *started out* with experience in a non-lispy
>language tend to find it scary.
>
> - Nonetheless, assumptions that various math operators should be infix
>is understandable because that's what people see today.
>
> - I am indeed very for growth in the community, though my main interest
>in growth is in seeing a wider diversity of participants than just
>raw numbers. Obviously other peoples' mileage may vary.
>
> - We are at serious risk in this pivot of losing some key things:
>
>- Many communities I have been in that have undertaken such a large
> pivot to increase popularity expend enormous energy in the move to
> the new thing, and in that process, the project actually collapses.
> What I'm trying to say is that a pivot is a gamble; we should
> calculate our odds carefully. (Indeed, the first thing I thought
> when I heard that this might happen was, did I make a mistake in
> shifting my work to Racket? It is unlikely I would have come to
> Racket if there wasn't an equivalent amount of elegance.)
>
>- I'm not sure if I could have understood Racket Week with a syntax
> that didn't have the elegance of s-expressions. This is not to say
> that *no* syntax can have that level of elegance where things can
> be so clear, however.
>
> IIRC Matthew's proposal for "#lang racket2" was something like the
> following:
>
> a) function(args ...) should work.
> b) infix is necessary for math, such as 3 + 4
> c) parentheses should be possible for grouping
>
> The weird thing about the last one being that this is already kind of
> true in s-expressions, but by ~default this also results in application.
>
> Let me add one more suggested design goal:
>
> - the new syntax should must not be significantly less elegant than
>s-expressions.
>
> Is there a way to achieve this? I actually think the best path forward
> is to have a surface syntax that actually maps completely to
> s-expressions, which is in fact universal that it can work with *any*
> s-expression syntax.
>
> I would suggest starting with Wisp as the basis for examining this:
>
> https://dustycloud.org/blog/wisp-lisp-alternative/
> https://srfi.schemers.org/srfi-119/srfi-119.html
>
> Sweet-expressions may also be an alternative to explore. However, I
> think Wisp is a more elegant base; it can transform *any* wisp code into
> s-exp code. Not discussed in my blogpost about Wisp is that it also
> supports infix via {3 + 4}. So ok, now we have that. And we can still
> group:
>
> {3 + {8 + 4}}
>
> So that's points b) and c), but we don't have a) yet. Could we add it?
>
> I think we can extend wisp with one thing and get everything we want: if
> you have func(arg1 arg2 arg3) where the parenthesis comes *immediately*
> after the symbol, that is rewritten to (func arg1 arg2 arg3). I will
> call this version ~Wisp.
>
> With all this, observe the following code rewritten from Scheme to ~Wisp:
>
> (define (rgb-maker mk)
> (lambda (sz)
> (vc-append (colorize (mk sz) "red")
> (colorize (mk sz) "green")
> (colorize (mk sz) "blue"
>
> define rgb-maker(mk)
> lambda(sz)
> vc-append(colorize(mk(sz) "red")
> colorize(mk(sz) "green")
> colorize(mk(sz) "blue"))
>
> Here is another chunk of code, taken
Re: [racket-users] The case, and a proposal, for elegant syntax in #lang racket2
At Sun, 14 Jul 2019 13:44:27 -0400, Christopher Lemmer Webber wrote: > The context of this email is the proposal by Matthew Flatt that we move > to an easier-to-accept surface syntax for #lang racket2. I appreciate your enthusiasm to get started! And I normally appreciate concrete proposals to solve problems. But I think the design-and-exploration task that we have ahead is too big for this mode of operation. Specifically, I don't think we should use the mailing list to broadcast and discuss concrete solutions just now. It's presumably on me to propose the next step, so stay tuned. I won't offer a proposal for a solution or even a proposal for a set of constraints on a solution. Instead, I intend a proposal (informed by Aaron's talk) for the social structure that we use to study the possibilities for Racket2, including but not limited to the question of reader syntax. In other words, while it's tempting to jump into technical discussions, I think we'll need to take this more slowly and formally, making sure that we agree on a set of goals/constraints for a potential new syntax. Just as an example, I would advocate the constraint that function(arg, ...) needs to be the function-call syntax --- with commas --- not just function(arg ...) as you wrote it. My point is not to debate the comma detail here or establish it a priori as a requirement, but only to illustrate the layers of discussion that we'll need to work through. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/5d2b9451.1c69fb81.da89e.58f4SMTPIN_ADDED_MISSING%40gmr-mx.google.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Building "#lang dungeon"
There is http://shill.seas.harvard.edu/ it runs on freebsd. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/81c4e9b5c1a6a74f27bcbfab528d7d61%40airmail.cc. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Building "#lang dungeon"
Hi Dionna, thanks for your reply! I gave a response to you IRL that I think I hadn't conveyed here which is that there's a reason I'm taking the lambda-approach to capabilities (which is explicit) vs an ambient/dynamic approach of continuation marks. One reason is that the work I'm trying to build can have references that cross machines (Goblin[oid] has preliminary support for this, but it isn't really fully implemented yet); in order for those to work, we can't rely on runtime scope behavior since we also are going to compose with remote capabilities as well, which do not have access to our inner runtime. I hear your concern that this is too much explicit argument passing; the only thing I suppose I can respond with is that this is how previous ocap systems have worked. One thing that helps a lot is that we can compose capabilities by enclosing over them, and often times doing this enclosure can abstract the necessary things we need, but it does indeed result in more argument passing. Dionna Amalie Glaze writes: > Capabilities can be tracked with continuation marks. For a language to > grant a subset of capabilities to a required module, you can do something > like contract-in that will wrap identifiers with a with-continuation-marks > capability restriction. The tricky part becomes how to make all I/O > subsystems etc. actually consult and respect the capabilities that are > marked on the continuation. That will take a really invasive change to the > runtime, or a flawed approach of a wrapper language around #%kernel such > that everything that builds on top of it respects capabilities. > Unfortunately we can't treat existing modules like functors for which we > can replace the underlying #%kernel. > > On Sun, Jul 14, 2019 at 10:25 AM Christopher Lemmer Webber < > cweb...@dustycloud.org> wrote: > >> Every day the threats facing our computing environments are getting >> worse. Recent incidents in both gems and npm have shown modules >> exfiltrating information from developers' machines or production >> servers. It is likely that soon package managers will also be targeted >> to install cryptolockers to attack developers' machines, or worse, >> install backdoors that allow an attacker to perform arbitrary execution. >> How can we make Racket not only a fun and fulfilling development, but >> also a safe one? >> >> Thankfully, Jonathan Rees did the kind work of laying out the recipe for >> dramatically improved safety over two decades ago: >> >> http://mumble.net/~jar/pubs/secureos/secureos.html >> >> It turns out that the lambda calculus already provides the fundamental >> layer of security we need; code can only perform actions it has >> references to. This is called "object capability (ocap) security"; >> a decent (ok, I'm biased) intro to the ideas can be found on this >> podcast episode if you are interested: >> >> >> https://librelounge.org/episodes/episode-13-object-capabilities-with-kate-sills.html >> >> Racket already has most of the pieces in place; we just need to add one >> more thing. Consider and contrast the following scenarios: >> >> Conventional Racket scenario: >> >> ;; Runs a game of solitaire. >> ;; Also has access to your entire filesystem, can secretly exfiltrate >> ;; data or install backdoors, etc etc. >> (solitaire) >> >> A more desirable scenario: >> >> ;; Runs a game of solitaire. >> ;; *Only* has access to a stream of input when the window is active, >> ;; the ability to draw to a *specific* window on the screen, the >> ;; ability to read/write from a single file on disk, the save file. >> (solitaire get-input >> display-graphics-to-window >> save-file-access) >> >> Now the amount of damage that solitiare can perform is significantly >> curtailed. It can perhaps display images we would not like to see >> or write nonsense to its save file, but it cannot do anything else. >> (We could also put limits in the save-file-access procedure on how >> large of a file it is allowed to write, if we were worried about that.) >> >> The key idea here is that authority flows through the system the same >> way that data naturally flows through a program. You simply don't have >> more access than what you allowed to flow through. >> >> So what is necessary to make Racket ocap-secure? The primary problem is >> the assumption of "require", that any module can "reach out" and gain >> access to anything it likes, be it network access or file access or etc. >> >> What I would like instead is to allow modules to be "granted" access. >> The idea is in fact the same as with the solitaire-as-procedure solution >> above: modules gain access not by reaching out and grabbing whatever >> they want, but by being "handed" access. Imagine your module as one big >> procedure where we pass in access to other modules/values/macros and >> you'll get the idea. >> >> >> >> #+BEGIN_SRC racket >> #lang dungeon >> >> ; passed in, already fully "empowered" >>
Re: [racket-users] Building "#lang dungeon"
Capabilities can be tracked with continuation marks. For a language to grant a subset of capabilities to a required module, you can do something like contract-in that will wrap identifiers with a with-continuation-marks capability restriction. The tricky part becomes how to make all I/O subsystems etc. actually consult and respect the capabilities that are marked on the continuation. That will take a really invasive change to the runtime, or a flawed approach of a wrapper language around #%kernel such that everything that builds on top of it respects capabilities. Unfortunately we can't treat existing modules like functors for which we can replace the underlying #%kernel. On Sun, Jul 14, 2019 at 10:25 AM Christopher Lemmer Webber < cweb...@dustycloud.org> wrote: > Every day the threats facing our computing environments are getting > worse. Recent incidents in both gems and npm have shown modules > exfiltrating information from developers' machines or production > servers. It is likely that soon package managers will also be targeted > to install cryptolockers to attack developers' machines, or worse, > install backdoors that allow an attacker to perform arbitrary execution. > How can we make Racket not only a fun and fulfilling development, but > also a safe one? > > Thankfully, Jonathan Rees did the kind work of laying out the recipe for > dramatically improved safety over two decades ago: > > http://mumble.net/~jar/pubs/secureos/secureos.html > > It turns out that the lambda calculus already provides the fundamental > layer of security we need; code can only perform actions it has > references to. This is called "object capability (ocap) security"; > a decent (ok, I'm biased) intro to the ideas can be found on this > podcast episode if you are interested: > > > https://librelounge.org/episodes/episode-13-object-capabilities-with-kate-sills.html > > Racket already has most of the pieces in place; we just need to add one > more thing. Consider and contrast the following scenarios: > > Conventional Racket scenario: > > ;; Runs a game of solitaire. > ;; Also has access to your entire filesystem, can secretly exfiltrate > ;; data or install backdoors, etc etc. > (solitaire) > > A more desirable scenario: > > ;; Runs a game of solitaire. > ;; *Only* has access to a stream of input when the window is active, > ;; the ability to draw to a *specific* window on the screen, the > ;; ability to read/write from a single file on disk, the save file. > (solitaire get-input > display-graphics-to-window > save-file-access) > > Now the amount of damage that solitiare can perform is significantly > curtailed. It can perhaps display images we would not like to see > or write nonsense to its save file, but it cannot do anything else. > (We could also put limits in the save-file-access procedure on how > large of a file it is allowed to write, if we were worried about that.) > > The key idea here is that authority flows through the system the same > way that data naturally flows through a program. You simply don't have > more access than what you allowed to flow through. > > So what is necessary to make Racket ocap-secure? The primary problem is > the assumption of "require", that any module can "reach out" and gain > access to anything it likes, be it network access or file access or etc. > > What I would like instead is to allow modules to be "granted" access. > The idea is in fact the same as with the solitaire-as-procedure solution > above: modules gain access not by reaching out and grabbing whatever > they want, but by being "handed" access. Imagine your module as one big > procedure where we pass in access to other modules/values/macros and > you'll get the idea. > > > > #+BEGIN_SRC racket > #lang dungeon > > ; passed in, already fully "empowered" > (require match >graphics-tools >keyboard-tools >;; the parent module must trust us a lot, they gave us full >;; filesystem access! >general-file-io >;; solitaire needs picture constructors to generate graphics >(empower solitaire graphics-tools)) > > (provide run-solitaire) > > (define (get-input input-source) > ...) > > (define (display-graphics-to-window ...) > ...) > > (define (make-save-file-access filename) > (match-lambda > [(list 'read) (call-with-input-file filename port->bytes)] > [(list 'write bytes) >(call-with-output-file filename > (lambda (p) > (write-bytes bytes p)) > #:exists 'replace)])) > > > (define (run-solitaire [save-file "~/.racket-solitaire"]) > (solitaire get-input display-graphics-to-window >(make-save-file-access save-file))) > #+END_SRC > > I've handwaved over a couple of things, but this module shouldn't be > afraid that the solitaire procedure that comes from the empowered > solitaire module has access to
Re: [racket-users] The case, and a proposal, for elegant syntax in #lang racket2
I sent this about 5 minutes before Jay announced https://github.com/racket/racket2-rfcs :) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/87tvboqz9b.fsf%40dustycloud.org. For more options, visit https://groups.google.com/d/optout.
[racket-users] The case, and a proposal, for elegant syntax in #lang racket2
The context of this email is the proposal by Matthew Flatt that we move
to an easier-to-accept surface syntax for #lang racket2.
Matthew Flatt has heard more than enough from me of concern about this
proposal. But I should indicate that I'm highly sympathetic to the
goal. I would like to lay out the following observations:
- The challenge with s-expressions is largely in anxiety with something
that looks extremely alien. I suspect there's more fear from
instructors than students in encountering a lisp syntax; my
experience is that introducing someone who doesn't know differently
to a parenthetical syntax isn't scary for them, and they tend to like
it. But people who have *started out* with experience in a non-lispy
language tend to find it scary.
- Nonetheless, assumptions that various math operators should be infix
is understandable because that's what people see today.
- I am indeed very for growth in the community, though my main interest
in growth is in seeing a wider diversity of participants than just
raw numbers. Obviously other peoples' mileage may vary.
- We are at serious risk in this pivot of losing some key things:
- Many communities I have been in that have undertaken such a large
pivot to increase popularity expend enormous energy in the move to
the new thing, and in that process, the project actually collapses.
What I'm trying to say is that a pivot is a gamble; we should
calculate our odds carefully. (Indeed, the first thing I thought
when I heard that this might happen was, did I make a mistake in
shifting my work to Racket? It is unlikely I would have come to
Racket if there wasn't an equivalent amount of elegance.)
- I'm not sure if I could have understood Racket Week with a syntax
that didn't have the elegance of s-expressions. This is not to say
that *no* syntax can have that level of elegance where things can
be so clear, however.
IIRC Matthew's proposal for "#lang racket2" was something like the
following:
a) function(args ...) should work.
b) infix is necessary for math, such as 3 + 4
c) parentheses should be possible for grouping
The weird thing about the last one being that this is already kind of
true in s-expressions, but by ~default this also results in application.
Let me add one more suggested design goal:
- the new syntax should must not be significantly less elegant than
s-expressions.
Is there a way to achieve this? I actually think the best path forward
is to have a surface syntax that actually maps completely to
s-expressions, which is in fact universal that it can work with *any*
s-expression syntax.
I would suggest starting with Wisp as the basis for examining this:
https://dustycloud.org/blog/wisp-lisp-alternative/
https://srfi.schemers.org/srfi-119/srfi-119.html
Sweet-expressions may also be an alternative to explore. However, I
think Wisp is a more elegant base; it can transform *any* wisp code into
s-exp code. Not discussed in my blogpost about Wisp is that it also
supports infix via {3 + 4}. So ok, now we have that. And we can still
group:
{3 + {8 + 4}}
So that's points b) and c), but we don't have a) yet. Could we add it?
I think we can extend wisp with one thing and get everything we want: if
you have func(arg1 arg2 arg3) where the parenthesis comes *immediately*
after the symbol, that is rewritten to (func arg1 arg2 arg3). I will
call this version ~Wisp.
With all this, observe the following code rewritten from Scheme to ~Wisp:
(define (rgb-maker mk)
(lambda (sz)
(vc-append (colorize (mk sz) "red")
(colorize (mk sz) "green")
(colorize (mk sz) "blue"
define rgb-maker(mk)
lambda(sz)
vc-append(colorize(mk(sz) "red")
colorize(mk(sz) "green")
colorize(mk(sz) "blue"))
Here is another chunk of code, taken from HTdP2:
(and (or (= (string-length "hello world")
(string->number "11"))
(string=? "hello world" "good morning"))
(>= (+ (string-length "hello world") 60) 80))
To:
and(or({string-length("hello world") = string->number("11")}
string=?("hello world" "good morning"))
{{(string-length "hello world") + 60} >= 80})
And in fact the latter can transform itself *directly* into the former.
And the former technically is also still valid Wisp: you can embed
s-expressions into it and they still work.
I think this satisfies the requirements that Matthew laid out.
There's another major advantage of this. We can now write languages
that work either like:
#lang s-exp "mylang.rkt"
or:
#lang wisp "mylang.rkt"
The main thing that Wisp is missing right now is editor tooling so that
doing indentation is convenient. But that's more than feasible to add,
imo.
I think this is the best way to move forward without creating
significant divisions, throwing out valuable things we have, or making
[racket-users] Building "#lang dungeon"
Every day the threats facing our computing environments are getting worse. Recent incidents in both gems and npm have shown modules exfiltrating information from developers' machines or production servers. It is likely that soon package managers will also be targeted to install cryptolockers to attack developers' machines, or worse, install backdoors that allow an attacker to perform arbitrary execution. How can we make Racket not only a fun and fulfilling development, but also a safe one? Thankfully, Jonathan Rees did the kind work of laying out the recipe for dramatically improved safety over two decades ago: http://mumble.net/~jar/pubs/secureos/secureos.html It turns out that the lambda calculus already provides the fundamental layer of security we need; code can only perform actions it has references to. This is called "object capability (ocap) security"; a decent (ok, I'm biased) intro to the ideas can be found on this podcast episode if you are interested: https://librelounge.org/episodes/episode-13-object-capabilities-with-kate-sills.html Racket already has most of the pieces in place; we just need to add one more thing. Consider and contrast the following scenarios: Conventional Racket scenario: ;; Runs a game of solitaire. ;; Also has access to your entire filesystem, can secretly exfiltrate ;; data or install backdoors, etc etc. (solitaire) A more desirable scenario: ;; Runs a game of solitaire. ;; *Only* has access to a stream of input when the window is active, ;; the ability to draw to a *specific* window on the screen, the ;; ability to read/write from a single file on disk, the save file. (solitaire get-input display-graphics-to-window save-file-access) Now the amount of damage that solitiare can perform is significantly curtailed. It can perhaps display images we would not like to see or write nonsense to its save file, but it cannot do anything else. (We could also put limits in the save-file-access procedure on how large of a file it is allowed to write, if we were worried about that.) The key idea here is that authority flows through the system the same way that data naturally flows through a program. You simply don't have more access than what you allowed to flow through. So what is necessary to make Racket ocap-secure? The primary problem is the assumption of "require", that any module can "reach out" and gain access to anything it likes, be it network access or file access or etc. What I would like instead is to allow modules to be "granted" access. The idea is in fact the same as with the solitaire-as-procedure solution above: modules gain access not by reaching out and grabbing whatever they want, but by being "handed" access. Imagine your module as one big procedure where we pass in access to other modules/values/macros and you'll get the idea. #+BEGIN_SRC racket #lang dungeon ; passed in, already fully "empowered" (require match graphics-tools keyboard-tools ;; the parent module must trust us a lot, they gave us full ;; filesystem access! general-file-io ;; solitaire needs picture constructors to generate graphics (empower solitaire graphics-tools)) (provide run-solitaire) (define (get-input input-source) ...) (define (display-graphics-to-window ...) ...) (define (make-save-file-access filename) (match-lambda [(list 'read) (call-with-input-file filename port->bytes)] [(list 'write bytes) (call-with-output-file filename (lambda (p) (write-bytes bytes p)) #:exists 'replace)])) (define (run-solitaire [save-file "~/.racket-solitaire"]) (solitaire get-input display-graphics-to-window (make-save-file-access save-file))) #+END_SRC I've handwaved over a couple of things, but this module shouldn't be afraid that the solitaire procedure that comes from the empowered solitaire module has access to dangerous things such as the full filesystem (even though the importer of *this* module trusted it to have full filesystem access), and neither module has network access. I don't know how to build this fully; I know that: - we need code inspectors to prevent evil hygeine-breaking, but good news we have that - I need a way to make *something like require* work, but where the import-er is able to very explicitly pass in which modules are allowed. This seems to mean something *like* controlling the module registry. Note that this also means that the names of the modules being imported aren't from a "global registry" anymore, it's the names that the empowering-module provided. There's an alternative, which is the emaker / frozen realms approach. This approach actually instead gives you an extremely minimal base syntax that *cannot be extended*. No new macros. Instead, the module that is imported wakes up in a cold world of
[racket-users] Summer BOB 2019 2nd Call for Participation (Aug 21, Berlin, early reg until Jul 18)
Summer BOB 2019 Conference “What happens if we simply use what’s best?” August 21, 2019, Berlin co-located with ICFP 2019 http://bobkonf.de/2019-summer/ Program: http://bobkonf.de/2019-summer/program.html Registration: http://bobkonf.de/2019-summer/registration.html Are you interested in technologies beyond the mainstream, that are a pleasure to use, and effective at getting the job done? BOB is the forum for developers, architects and builders to explore and discover the best tools available today for building software. Our goal is for all participants to leave the conference with new ideas to improve development back at the ranch. Summer BOB is a one-time-only event, in the spirit of the spectacular Winter BOB. The International Conference on Functional Programming is coming to town, and Summer BOB will be right in the middle of it, on the last day of ICFP proper, prior to all the workshops. Summer BOB will feature two tracks: one from practitioners, and one from researchers, and foster communication and cross-pollination between these communities. BOB features two tracks of seven talk each: One research track with invited talks, and one track by practitioners, designed to cross-pollinate and inspire. http://bobkonf.de/2019-summer/program.html Topics include distributed programming, testing, linear algebra, functional design patterns, type systems, formal methods, and interactive development. We are committed to diversity: We aim at exploring a wide range of tools in a welcoming and friendly crowd of diverse people. To that end, a number of support options for participants from groups under-represented in tech are available. http://bobkonf.de/2019-summer/registration.html NOTE: The early-bird rates expire on July 18, 2019! -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/y9lzhlgr6na.fsf%40deinprogramm.de. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Advice for porting Interactive Brokers API to Racket
Thanks for the feedback. I will check to see if there's some way to query for capabilities, but I doubt it, given the client code. The client code does most of this version checking in one class, so that seems localized enough and I think it will be straight forward. Maybe if I stumble on a better way to do this, I'll share. Evan On Thursday, July 11, 2019 at 3:09:09 AM UTC-10, Greg Hendershott wrote: > > Some systems provide a way to query for a capability: COM has > QueryInterface, Racket dynamic-require, Emacs fboundp, and so on. When > such a query method is available, you can simply ask for the thing you > need or prefer. If it's available, great. If not, act appropriately: > Fail, or use your own "back fill" that does something similar or is just > a no-op, or whatever is appropriate. > > [IMHO this is more sensible than using version numbers as proxies for > the thing you really care about. Especially lawyerly systems like > so-called semantic versioning. But I digress. :)] > > The Racket flavor is something like the following. Let's say > some/module/path maybe has a new fribble function. If that's not > present, or if indeed that whole module isn't even installed, we want to > use our own our-fribble function as a default: > > (define (our-fribble _x) > 'some-default-value) > > (define fribble > (with-handlers ([exn:fail? (λ _ our-fribble)]) > (dynamic-require 'some/module/path > 'fribble))) > > For example, I use this and also Emacs' fboundp in Racket Mode, to > support various versions of Racket and Emacs, both. > > > I don't know if/how this would help your case. Their API uses the > futzing-with-version-numbers approach. Even so, _maybe_ you'd want to > localize the version number checks in one module, which provides the > functions for your other code to use? The functions will end up being > either the real broker thing, or your own default. > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/54fdaf8b-2233-475e-b6ed-78c8fdeeeabf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
