<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	>
<channel>
	<title>Comments on: LISP conditions and role-based security models</title>
	<atom:link href="http://blog.amber.org/2005/08/06/lisp-conditions-and-role-based-security-models/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.amber.org/2005/08/06/lisp-conditions-and-role-based-security-models/</link>
	<description>Thoughts of a minor lunatic</description>
	<pubDate>Wed, 07 Jan 2009 08:23:01 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Patrick Logan</title>
		<link>http://blog.amber.org/2005/08/06/lisp-conditions-and-role-based-security-models/comment-page-1/#comment-2569</link>
		<dc:creator>Patrick Logan</dc:creator>
		<pubDate>Thu, 25 Aug 2005 18:13:37 +0000</pubDate>
		<guid isPermaLink="false">http://blog.amber.org/?p=1747#comment-2569</guid>
		<description>It gets a lot better than that. See...

http://mumble.net/~jar/pubs/secureos/</description>
		<content:encoded><![CDATA[<p>It gets a lot better than that. See&#8230;</p>
<p><a href="http://mumble.net/~jar/pubs/secureos/" rel="nofollow">http://mumble.net/~jar/pubs/secureos/</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: petrilli</title>
		<link>http://blog.amber.org/2005/08/06/lisp-conditions-and-role-based-security-models/comment-page-1/#comment-2458</link>
		<dc:creator>petrilli</dc:creator>
		<pubDate>Sun, 07 Aug 2005 13:11:37 +0000</pubDate>
		<guid isPermaLink="false">http://blog.amber.org/?p=1747#comment-2458</guid>
		<description>Actually this would work totally differently.  Basically, when you get to a specific point where you need to make a decision, you raise a signal and "something" above you in the call stack can make the decision of whether to proceed or abort -- without unwinding the call stack. 

You could certainly do it trivially in Lisp with @:before@ functions.</description>
		<content:encoded><![CDATA[<p>Actually this would work totally differently.  Basically, when you get to a specific point where you need to make a decision, you raise a signal and &#8220;something&#8221; above you in the call stack can make the decision of whether to proceed or abort&#8212;without unwinding the call stack. </p>
<p>You could certainly do it trivially in Lisp with <code>:before</code> functions.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ian Bicking</title>
		<link>http://blog.amber.org/2005/08/06/lisp-conditions-and-role-based-security-models/comment-page-1/#comment-2456</link>
		<dc:creator>Ian Bicking</dc:creator>
		<pubDate>Sun, 07 Aug 2005 05:49:28 +0000</pubDate>
		<guid isPermaLink="false">http://blog.amber.org/?p=1747#comment-2456</guid>
		<description>Just, you know, if you wanted to make it more relevent, I think PEAK's generic functions might provide the same thing.  That is, you can monkey-patch any function to be generic, then specialize it with functions that provide security constraints (and call next_method).  Anyway, I think that's kind of what you are talking about here.</description>
		<content:encoded><![CDATA[<p>Just, you know, if you wanted to make it more relevent, I think PEAK&#8217;s generic functions might provide the same thing.  That is, you can monkey-patch any function to be generic, then specialize it with functions that provide security constraints (and call next_method).  Anyway, I think that&#8217;s kind of what you are talking about here.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
