Konrad Hinsen writes: > Hi Chris, >
Hi Konrad, > While I understand the general goal you are aiming at, it isn't quite > clear to me who you are trying to protect against who. There's a wide > spectrum of people involved, ranging from language designers via library > developers and application developers to end users. Who is going to > define your capabilities? Who is supposed to be protected by them? And > who is the potential villain whose evil doings need to be checked for? > > Your example doesn't help much with this, as playing a game of solitaire > from the Racket REPL is not a relevant real-life scenario. The typical > solitaire player is an end-user who double-clicks an application and > wouldn't understand the implications of granting access to a single > window. Of course I don't expect someone to launch solitaire from the REPL, and indeed there are UX considerations once we move from the REPL to actual program launch. There *are* paradigms for that that have been developed, and intuitive behaviors such as drag and drop compose nicely with a capability discipline. However, I am talking to language people about how we give authority to parts of our programs, so something that works at the REPL can help us think more at this level of abstraction, aside from the other ones :) -- 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/87o91vqu4u.fsf%40dustycloud.org. For more options, visit https://groups.google.com/d/optout.
