[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Peter Minten
Subject: Re: [Visionaries] SilverScheme and the end of DG-Scheme
Date: Mon, 25 Aug 2003 19:06:01 +0200
User-agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.4) Gecko/20030529

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" )
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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]