Re: [Visionaries] SilverScheme and the end of DG-Scheme

[Peter Minten]

Norbert Bollow wrote:

> Peter Minten <address@hidden> wrote:
>
>
> > after careful consideration I've decided to take DG-Scheme out of
> > the DotGNU context and rename it to SilverScheme. The reason is that
> > I don't want SilverScheme to be as webservice focussed as for
> > example C#, rather I want it to be math and metadata focussed,
> > experimenting with some new techniques (like a very high amount of
> > introspection). Obviously this goal makes SilverScheme fall outside
> > of the DotGNU project
>
>
> Hmm... as much as I hate so say so, I tend to agree.  If a
> project doesn't have any strong ties to webservices or to
> C# or to IL then it doesn't fit into DotGNU.
>
> On the other hand, just a day ago or so someone showed up in
> #dotgnu asking whther DotGNU has a Scheme-like language.  I feel
> strongly that DotGNU should have one.  This doesn't need to be a
> new one - an existing established language will do fine if we
> can plug its interpreter into DGEE similar to how we do with the
> python bytecode itnerpreter, or alternatively the language could
> be compiled to say Parrot.  DotGNU definately should support
> parrot as an alternative to IL... btw how feasible is it to
> compile a Scheme-like language to Parrot?

DotGNU certainly needs a LISP. One of the big differences between Scheme and
Common LISP is the stronger sense of security (constants, etc) in Common LISP.
Scheme should be compilable to Parrot, it's simple enough. Common LISP can
probably also be compiled to Parrot.

> > I do understand the concerns of the opponents of introspection
> > however, if you apply introspection to an existing language then all
> > the programs written in that language become theoretically a target
> > for a GPL circumvention attack.
>
>
> I don't see how introspection (in the sense in which the term is
> used e.g. in Patrick K. O'Brien's "Guide to Python introspection"
> http://www-106.ibm.com/developerworks/linux/library/l-pyint.html )
> weakens the GPL ?  

It doesn't. Introspection itself isn't dangerous. The result of introspection in
logic language (RDF statements) can be dangerous. For a more complete
explanation see below.

> > I don't want to create a controversy about the controversial
> > aspects of introspection
>
>
> If there's something dangerous about introspection in general
> (and not just a problem with mdupont's so-called "introspector"
> patches to gcc which RMS doesn't like) then I think we should not
> be afraid of controversy but rather discuss the issues openly.

There is a certain danger in introspection, which is not in the actual act of
introspecting. Rather introspecting as mdupont is doing it produces statements
that you can feed into a proof engine. You can use the proof engine to create
new statements build upon the old statements. Even though the statements
produced by the introspector are logically (dunno about legally) derivate works
of the input the inferred statements don't need to be. In theory one could use
this technique to rebuild a program from introspection data about it without
using the actual introspection data in the rebuild program. This would obviously
cause a threat to copyright. At least this is how I understand it :-).

It's all just a matter of the fact that drawing conclusions based on information
can't be considered copying that information (or otherwise we would have a
massive copyright violation problem in schools :-).

> > I consider introspection a logical and inevitable thing. I also
> > consider introspection an advancement of computer science. If
> > introspection allows a proprietary company to circumvent the GPL
> > on my code than that's bad luck for me.
>
>
> I don't think that anything is inevitable... but I think that new
> technologies which increase flexibility should be endorsed by the
> Free Software movement.  Even when it is the case that such
> technologies weaken copyleft they also weaken the mechanisms that
> proprietary software uses to lock users in.

There is a big difference between the proprietary industry and us, they can use
EULA's preventing reverse engineering, we can't.

Greetings,

Peter