Securing and taming an existing language

--===============3534327712650181742==
Content-Type: multipart/alternative; boundary=bcaec53d5507326472050fc5bfbc

--bcaec53d5507326472050fc5bfbc
Content-Type: text/plain; charset=UTF-8

Hopefully this is the right list for this question or set of questions ...

I help maintain the Dylan language, http://opendylan.org/.  It is similar
to Scheme, but with a CLOS-style object system, and was originally designed
by various Common Lisp folks at Apple, CMU and Harlequin in the early 1990s.

I'm interested in seeing what we could do to become friendly to object
capabilities.

I've following along with E over the last 17 years off and on and some of
the other efforts. I've read the slides for
http://dynamic-languages-symposium.org/dls-07/program/media/MarkMiller_2007_TradeoffsInRetrofittingSecurityAnExperienceReport_Dls.pdf
... I've also skimmed the paper on taming Pict

I'm curious if there's a good place to start reading for how to:

1) subset a language to remove ambient authority
2) tame unprincipled libraries

I realize that these are big, complicated tasks, but I'd like to evaluate
whether or not this is a feasible direction for Dylan to move in.

Along with the usual issues, Dylan has another interesting complication in
that it is using the CLOS model of OO which is very different from that of
Java, Smalltalk and C++. In the CLOS model, multiple dispatch is used and
the methods (generic functions) don't "belong" to objects or classes. (It
isn't really a message-passing OO.)

Has there been any consideration of that sort of object system and model in
the past with respect to object capabilities?

Cheers,

 - Bruce

--bcaec53d5507326472050fc5bfbc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hopefully this is the right list for this question or set =
of questions ...<div><br></div><div>I help maintain the Dylan language, <a =
href=3D"http://opendylan.org/">http://opendylan.org/</a>.=C2=A0 It is simil=
ar to Scheme, but with a CLOS-style object system, and was originally desig=
ned by various Common Lisp folks at Apple, CMU and Harlequin in the early 1=
990s.</div><div><br></div><div>I&#39;m interested in seeing what we could d=
o to become friendly to object capabilities.</div><div><br></div><div>I&#39=
;ve following along with E over the last 17 years off and on and some of th=
e other efforts. I&#39;ve read the slides for=C2=A0<a href=3D"http://dynami=
c-languages-symposium.org/dls-07/program/media/MarkMiller_2007_TradeoffsInR=
etrofittingSecurityAnExperienceReport_Dls.pdf">http://dynamic-languages-sym=
posium.org/dls-07/program/media/MarkMiller_2007_TradeoffsInRetrofittingSecu=
rityAnExperienceReport_Dls.pdf</a> ... I&#39;ve also skimmed the paper on t=
aming Pict</div><div><br></div><div>I&#39;m curious if there&#39;s a good p=
lace to start reading for how to:</div><div><br></div><div>1) subset a lang=
uage to remove ambient authority</div><div>2) tame unprincipled libraries</=
div><div><br></div><div>I realize that these are big, complicated tasks, bu=
t I&#39;d like to evaluate whether or not this is a feasible direction for =
Dylan to move in.</div><div><br></div><div>Along with the usual issues, Dyl=
an has another interesting complication in that it is using the CLOS model =
of OO which is very different from that of Java, Smalltalk and C++. In the =
CLOS model, multiple dispatch is used and the methods (generic functions) d=
on&#39;t &quot;belong&quot; to objects or classes. (It isn&#39;t really a m=
essage-passing OO.)</div><div><br></div><div>Has there been any considerati=
on of that sort of object system and model in the past with respect to obje=
ct capabilities?</div><div><br></div><div>Cheers,</div><div><br></div><div>=
=C2=A0- Bruce</div><div><br></div></div>

--bcaec53d5507326472050fc5bfbc--

--===============3534327712650181742==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
e-lang mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/e-lang

--===============3534327712650181742==--