[plt-scheme] what happens to python language supoort?
On Oct 26, 2007, at 11:14 AM, Stephen De Gabrielle wrote:
> The paper describes supporting python by implementing a python
> interpreter to get access to the full range of tools offered by the
> DrScheme IDE.
Porting Python to DrScheme was a scientific experiment with two
distinct goals:
1. We have started to think of DrScheme as Dr[X], with an
intentionally chosen parametric notation. In the long run, we wish to
plug in languages and inherit as many tools as possible. As you can
tell, it is relatively easy to prototype languages with mzscheme;
even Eli can do that and he likes doing it so much, he produces one
per week in the course he teaches for us.
What is truly challenging is adapting CheckSyntax, Analyze, Debug,
and Step semi-automatically to these languages so that students and
programmers get access to these 'semantic' tools. [CheckSyntax
corresponds to alpha reduction, Analyze to abstract interpretation
with an abstraction projection, Debug and Step to beta reduction.]
In the meantime, we have concluded to focus on parenthetical
languages until we improve our understanding of languages with 'ugly
syntax.'
2. As for the specific Aanlyze tool, we wanted to test the hypothesis
that Meunier's static debugger would apply to a scripting language,
such as Python. The SD uses a set-based analysis that tracks the flow
of values thru the program via the generation and solution of set-[in]
equations. After a superficial study of Python, I had the mistaken
impression that it was a simple and clean language, in the spirit of
Scheme, and that a "macro-based translation" would 'lift' the
analysis results (in raw form) to the Python level.
We had evidence that this would work from our Algol 60 embedding.
Matthew had used the syntax system to implement Algol 60 and to embed
it into drscheme. Meunier's analysis worked without any additional
ado and produced quite sensible results. For example, for an Algol
procedure that has two int arguments one by-name and one by-value
procedure P(x,y);
value x;
integer x, y;
begin ... end
the analysis would _automatically_ derive results such as these:
x : {1,2,3}
y : (-> number)
if P was applied to such inputs. Note how the by-name y argument has
a THUNK signature and the by-value x argument is a value set. (This
is not completely accurate.)
;; ---
The first experiment failed because it was premature from our
perspective. The second experiment failed due to Python's 'dirty
nature'. It lacks any abstraction barriers and the best you can do is
to pretend they exist and hope that your analysis doesn't lie too
much. I don't want to work with such beasts.
-- Matthias
> Is there any reason why you could not use the native python on your
> machine (say via the process.ss library), and use the standard
> python debugging tools?
>
> or does the 'choose language' dialog require a native plt
> implementation?
>
> Just interested,
>
> Stephen
>
>
> On 10/20/07, Jakub Piotr Cłapa <jpc at pld-linux.org> wrote: naruto
> canada wrote:
> > hi
> >
> > what happens to python language supoort?
> > Is is dropped or withdrawn?
> >
> > http://www.python.org/pycon/dc2004/papers/25/
> > I can't find "configure" option for python in plt-371
>
> Check this thread: http://thread.gmane.org/gmane.lisp.scheme.plt/
> 19138/
>
> --
> regards,
> Jakub Piotr Cłapa
> _________________________________________________
> For list-related administrative tasks:
> http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
>
>
> --
> Cheers,
>
> Stephen
>
>
>
> --
> Stephen De Gabrielle
> s.degabrielle at ucl.ac.uk
> Telephone +44 (0)20 7679 5242 (x45242)
> Mobile 079 851 890 45
> http://www.uclic.ucl.ac.uk/annb/MaSI.html
> University College London Interaction Centre
> Remax House - 31/32 Alfred Place
> London - WC1E 7DP
> _________________________________________________
> For list-related administrative tasks:
> http://list.cs.brown.edu/mailman/listinfo/plt-scheme