Last week I decided to do some serious web hacking for money; which is
a novelty for me and kind of fun. Of all the languages widely used
for scripting, Python seemed to me to be the nicest from my point of
view, and has the bonus of being widely supported on a range of
servers. I never really got into Python before, based on my impresson
that it offered little that was conceptually new that wasn't already
in Lisp.
It occurred to me then, I could write the application in Qi and
generate the Python using Python as the object code instead of Lisp.
This was a lot more interesting way of learning Python than chugging
through newbie Python exercises and its been quite instructive. Here
are some lessons I've learnt so far.
1. Python is not novel but it does look pretty.
Yes; I was right, its not new but ...
It is actually a pleasing language to work in and it looks
reassuringly bracket free. Perhaps we should have listened to all the
newbies who complained in the past about 'too many brackets' in Lisp
because all van Rossum has really done is neatly package some old
ideas, but the wrapper looks good.
2. Whitespace in Python is initally a pain but wears off fairly
quickly
This was a culture shock - whitespace/indentation sensitivity - and
working off the web sans textbook, it was difficult at first to figure
out the conventions. Having figured it out and having bullied the
formatter (see post on CLisp below) to behave, my generated Python
seems to work fine.
The formatting conventions actually help readability across Python
programmers by enforcing a common convention. Its an interesting
contrast to CL anarchy, where everybody writes in their own style,
that van Rossum's influence is tangible as BDFL and he seems pretty
benevolent.
3. Lisp is a great object language to compile from or into.
The simple syntax is responsible. Its actually much easier to compile
from Lisp to Python than from Qi to Python - mainly because Python and
Lisp are essentially so similar in design, if not syntax, whereas Qi
introduces higher-level constructions involving patterns for which I
can find no correlate in Python. Hence the chain is
Qi --> Lisp --> Python
Lisp->Python cross-compilers must have been built, but the nice bit
about doing it myself was that Qi-generated Lisp is extremely
mechanical and regular and uses only a small subset of CL and hence
the compiler (Quip - Qi into Python) is correspondingly small.
4. Look ma, no types.
Types were not used in this application. I had the choice, but simply
wanted to build the thing. You may infer all sorts of conclusions
here and will no doubt do so ;). However pattern-directed list
handling was *enormously* useful. I would not want to do this in
Lisp. In short the motto seems to be 'Qi for your metalanguage and
Lisp for the object language'.
5. Cross-compiling Qi II itself is not hard
Qi II is written in itself which means that the CL source code for Qi
can itself be put through Quip. This would give a version of Qi II
that exists in and under Python. Is it worth it? I'm not convinced
because the end result would be a slower Qi with no apparent
advantages I can see (anybody care to argue the case?). However it
would be equally easy, perhaps easier, to cross-compile Qi source into
any other Lisp-like language such as Clojure or NewLisp.
Mark
On Apr 15, 3:52 pm, Mark Tarver <··········@ukonline.co.uk> wrote:
> Qi II is written in itself which means that the CL source code for Qi
> can itself be put through Quip. This would give a version of Qi II
> that exists in and under Python. Is it worth it? I'm not convinced
> because the end result would be a slower Qi with no apparent
> advantages I can see (anybody care to argue the case?). However it
> would be equally easy, perhaps easier, to cross-compile Qi source into
> any other Lisp-like language such as Clojure or NewLisp.
I would strongly recommend cross-compiling Qi to Clojure "object"
code. This would gain for Qi a cross platform GUI, scads of java libs,
presence on google's app engine, etc. This could jump-start Qi
acceptance among the mass of programmers who want java interop, much
as Clojure has done for lisp.
warmest regards,
Ralph
On 16 Apr, 13:00, Slobodan Blazeski <·················@gmail.com>
wrote:
> How do you mean you've compiled to Python? Python is a compiler.
>
> bobi
I mean that Qi can now produce (type secure) Python code as well as
type secure CL. The command is
(quip "<filename here>.qi")
and the resultant Python file is "<filename here>.py. This allows me
to plug in my Qi code into the well-provided Python libraries. My
provider soes not support CL but does support Python.
Eventually we will run the system under Qi/tk and you'll just click on
'File ...' and 'Output to ...' and choose what language you want your
Qi program outputted to - CL, Python, NewLisp, Clojure - even perhaps
C if we bolt on CLiCC.
Mark
On Apr 16, 8:21 am, Mark Tarver <··········@ukonline.co.uk> wrote:
> Eventually we will run the system under Qi/tk
Or under Qi/jfc/swing when you can compile to clojure :^)
On 16 Apr, 13:32, Raffael Cavallaro <················@gmail.com>
wrote:
> On Apr 16, 8:21 am, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > Eventually we will run the system under Qi/tk
>
> Or under Qi/jfc/swing when you can compile to clojure :^)
Yes; the whole GUI thing is a tower of Babel right now.
Garnet (defunct)
Cells
Cello
CLIM
TCL/tk
GTK+
Qt
..........
From: Kenneth Tilton
Subject: Re: compiling (Qi to) Lisp to Python: some observations
Date:
Message-ID: <49e73d51$0$27765$607ed4bc@cv.net>
Mark Tarver wrote:
> On 16 Apr, 13:32, Raffael Cavallaro <················@gmail.com>
> wrote:
>> On Apr 16, 8:21 am, Mark Tarver <··········@ukonline.co.uk> wrote:
>>
>>> Eventually we will run the system under Qi/tk
>> Or under Qi/jfc/swing when you can compile to clojure :^)
>
> Yes; the whole GUI thing is a tower of Babel right now.
>
> Garnet (defunct)
> Cells
> Cello
> CLIM
> TCL/tk
> GTK+
> Qt
> ..........
Why you ol' desktop GUI dinosaur you! How about:
...symbolic-web, weblocks, web-cells, qooxdoo, html/css, jQuery,
javascript....
kt
On Apr 16, 2:21 pm, Mark Tarver <··········@ukonline.co.uk> wrote:
> On 16 Apr, 13:00, Slobodan Blazeski <·················@gmail.com>
> wrote:
>
> > How do you mean you've compiled to Python? Python is a compiler.
>
> > bobi
>
> I mean that Qi can now produce (type secure) Python code as well as
> type secure CL. The command is <snipped>
Just joking :) . Python is a name of the sbcl and cmucl compiler in
cll package default in this newsgroup.
cheers
bobi
On Apr 15, 9:52 pm, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> The simple syntax is responsible. Its actually much easier to compile
> from Lisp to Python than from Qi to Python - mainly because Python and
> Lisp are essentially so similar in design, if not syntax, whereas Qi
> introduces higher-level constructions involving patterns for which I
> can find no correlate in Python. Hence the chain is
>
> Qi --> Lisp --> Python
>
I am curious. Could you provide an example program (say < 10 lines)
a show how the same code looks in the three languages?
On 21 Apr, 16:59, Michele Simionato <·················@gmail.com>
wrote:
> On Apr 15, 9:52 pm, Mark Tarver <··········@ukonline.co.uk> wrote:
>
>
>
> > The simple syntax is responsible. Its actually much easier to compile
> > from Lisp to Python than from Qi to Python - mainly because Python and
> > Lisp are essentially so similar in design, if not syntax, whereas Qi
> > introduces higher-level constructions involving patterns for which I
> > can find no correlate in Python. Hence the chain is
>
> > Qi --> Lisp --> Python
>
> I am curious. Could you provide an example program (say < 10 lines)
> a show how the same code looks in the three languages?
# Python generated from Qi II; 13:57 14/4/2009
def bubble_sort(V197):
return bubble_again_perhaps(bubble(V197),V197)
def bubble(V198):
if null(V198):
return nil
else:
if iscons(V198) and null(tail(V198)):
return V198
else:
if iscons(V198) and iscons(tail(V198)) and greater(head(tail
(V198)),head(V198)):
return (apply(lambda X199: cons(head(X199),bubble(cons(head
(V198),tail(X199)))),unitlist(tail(V198))))
else:
if iscons(V198) and iscons(tail(V198)):
return cons(head(V198),bubble(tail(V198)))
else:
return patterror("bubble")
def bubble_again_perhaps(V204,V205):
if V205 == V204:
return V205
else:
return bubble_sort(V204)
(define bubble_sort
X -> (bubble_again_perhaps (bubble X) X))
(define bubble
[] -> []
[X] -> [X]
[X Y | Z] -> [Y | (bubble [X | Z])] where (> Y X)
[X Y | Z] -> [X | (bubble [Y | Z])])
(define bubble_again_perhaps
X X -> X
X _ -> (bubble_sort X))
Lisp I have to dig out.
Mark
On 15 Apr, 21:52, Mark Tarver <··········@ukonline.co.uk> wrote:
> Last week I decided to do some serious web hacking for money; which is
> a novelty for me and kind of fun. Of all the languages widely used
> for scripting, Python seemed to me to be the nicest from my point of
> view, and has the bonus of being widely supported on a range of
> servers. I never really got into Python before, based on my impresson
> that it offered little that was conceptually new that wasn't already
> in Lisp.
>
> It occurred to me then, I could write the application in Qi and
> generate the Python using Python as the object code instead of Lisp.
> This was a lot more interesting way of learning Python than chugging
> through newbie Python exercises and its been quite instructive. Here
> are some lessons I've learnt so far.
Do you need bounded-space tail calls in Qi?
If so, how do you implement that in Python?
On 23 Apr, 10:49, Vend <······@virgilio.it> wrote:
> On 15 Apr, 21:52, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > Last week I decided to do some serious web hacking for money; which is
> > a novelty for me and kind of fun. Of all the languages widely used
> > for scripting, Python seemed to me to be the nicest from my point of
> > view, and has the bonus of being widely supported on a range of
> > servers. I never really got into Python before, based on my impresson
> > that it offered little that was conceptually new that wasn't already
> > in Lisp.
>
> > It occurred to me then, I could write the application in Qi and
> > generate the Python using Python as the object code instead of Lisp.
> > This was a lot more interesting way of learning Python than chugging
> > through newbie Python exercises and its been quite instructive. Here
> > are some lessons I've learnt so far.
>
> Do you need bounded-space tail calls in Qi?
> If so, how do you implement that in Python?
ANSI Common Lisp, AFAIK, does not require tail call optimisation and
the language standard in FPQi does not require it either. However
individual CL platforms may perform this optimisation. This has come
up in this group before.
http://groups.google.co.uk/group/comp.lang.lisp/browse_frm/thread/d62865297bde3c41?hl=en&tvc=1&q=CL+implemenations+and+tail-call
Python I'm still learning. It looks from my very cursory survey that
Python does not have this feature built in, otherwise the posts I've
read on how to add this feature would seem spurious.
However Qi probably benefits more from tail optimisation than CL or
Python because it eschews iterative constructions which both the other
languages embrace as substitutes for TCO.
I don't know yet how well Python copes with recursion but I'd guess/
hope that its probably fairly decent. There is some discussion on
this point in
http://lambda-the-ultimate.org/node/472#comment-3526
Mark
On 23 Apr, 22:23, Mark Tarver <··········@ukonline.co.uk> wrote:
> On 23 Apr, 10:49, Vend <······@virgilio.it> wrote:
>
>
>
>
>
> > On 15 Apr, 21:52, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > > Last week I decided to do some serious web hacking for money; which is
> > > a novelty for me and kind of fun. Of all the languages widely used
> > > for scripting, Python seemed to me to be the nicest from my point of
> > > view, and has the bonus of being widely supported on a range of
> > > servers. I never really got into Python before, based on my impresson
> > > that it offered little that was conceptually new that wasn't already
> > > in Lisp.
>
> > > It occurred to me then, I could write the application in Qi and
> > > generate the Python using Python as the object code instead of Lisp.
> > > This was a lot more interesting way of learning Python than chugging
> > > through newbie Python exercises and its been quite instructive. Here
> > > are some lessons I've learnt so far.
>
> > Do you need bounded-space tail calls in Qi?
> > If so, how do you implement that in Python?
>
> ANSI Common Lisp, AFAIK, does not require tail call optimisation and
> the language standard in FPQi does not require it either. However
> individual CL platforms may perform this optimisation. This has come
> up in this group before.
>
> http://groups.google.co.uk/group/comp.lang.lisp/browse_frm/thread/d62...
>
> Python I'm still learning. It looks from my very cursory survey that
> Python does not have this feature built in, otherwise the posts I've
> read on how to add this feature would seem spurious.
>
> However Qi probably benefits more from tail optimisation than CL or
> Python because it eschews iterative constructions which both the other
> languages embrace as substitutes for TCO.
>
> I don't know yet how well Python copes with recursion but I'd guess/
> hope that its probably fairly decent. There is some discussion on
> this point in
>
> http://lambda-the-ultimate.org/node/472#comment-3526
>
> Mark- Hide quoted text -
>
> - Show quoted text -
If its a real issue then it should be possible to generate the
iterative Python code from the recursive definition. Hence the result
would be optimised type secure Python code. If Python supports type
declarations then some of the type information that Qi inserts into
its code at higher compiler speed settings would rub off on Python.
In that event it may be that just as Qi II code will often outperform
hand-coded Lisp, it could with enough work, outperfom hand-coded
Python too.
Qi evolved from Lisp but its really jumped from the Lisp family in
many ways. Its clear that it has Borg like properties for
interbreeding with other languages, taking them over and assimilating
their DNA.
I gotta keep off the sci-fi channel. See how it makes you think. ;)
Mark
On 23 Apr, 23:23, Mark Tarver <··········@ukonline.co.uk> wrote:
> On 23 Apr, 10:49, Vend <······@virgilio.it> wrote:
>
>
>
> > On 15 Apr, 21:52, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > > Last week I decided to do some serious web hacking for money; which is
> > > a novelty for me and kind of fun. Of all the languages widely used
> > > for scripting, Python seemed to me to be the nicest from my point of
> > > view, and has the bonus of being widely supported on a range of
> > > servers. I never really got into Python before, based on my impresson
> > > that it offered little that was conceptually new that wasn't already
> > > in Lisp.
>
> > > It occurred to me then, I could write the application in Qi and
> > > generate the Python using Python as the object code instead of Lisp.
> > > This was a lot more interesting way of learning Python than chugging
> > > through newbie Python exercises and its been quite instructive. Here
> > > are some lessons I've learnt so far.
>
> > Do you need bounded-space tail calls in Qi?
> > If so, how do you implement that in Python?
>
> ANSI Common Lisp, AFAIK, does not require tail call optimisation and
> the language standard in FPQi does not require it either. However
> individual CL platforms may perform this optimisation. This has come
> up in this group before.
Yes, but I thought that being more oriented towards functional/logic
programming Qi required bounded-space tail calls.
I was wrong.
On 24 Apr, 00:10, Vend <······@virgilio.it> wrote:
> On 23 Apr, 23:23, Mark Tarver <··········@ukonline.co.uk> wrote:
>
>
>
>
>
> > On 23 Apr, 10:49, Vend <······@virgilio.it> wrote:
>
> > > On 15 Apr, 21:52, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > > > Last week I decided to do some serious web hacking for money; which is
> > > > a novelty for me and kind of fun. Of all the languages widely used
> > > > for scripting, Python seemed to me to be the nicest from my point of
> > > > view, and has the bonus of being widely supported on a range of
> > > > servers. I never really got into Python before, based on my impresson
> > > > that it offered little that was conceptually new that wasn't already
> > > > in Lisp.
>
> > > > It occurred to me then, I could write the application in Qi and
> > > > generate the Python using Python as the object code instead of Lisp.
> > > > This was a lot more interesting way of learning Python than chugging
> > > > through newbie Python exercises and its been quite instructive. Here
> > > > are some lessons I've learnt so far.
>
> > > Do you need bounded-space tail calls in Qi?
> > > If so, how do you implement that in Python?
>
> > ANSI Common Lisp, AFAIK, does not require tail call optimisation and
> > the language standard in FPQi does not require it either. However
> > individual CL platforms may perform this optimisation. This has come
> > up in this group before.
>
> Yes, but I thought that being more oriented towards functional/logic
> programming Qi required bounded-space tail calls.
> I was wrong.- Hide quoted text -
>
> - Show quoted text -
No; you're not wrong. Its just that the language specification -
syntax and semantics of Qi, leaves this question open. Its a question
for the compiler writer. FPQi gives a semantics for FPQi but stops
short of saying how the resulting Lisp/lambda calculus should itself
be compiled. So if you use combinators or graph reduction or
whatever, this does not matter as long as the semantics of the
language is respected.
However, that said, the behaviour of a Qi function should as far as
possible approximate to the semantics as laid down in part III of that
book and questions of physical limitation and storage do not play as
part in that description. Therefore any compiler technique that
abstracts away from the physical limitations of storage and makes the
actual implementation resemble the ideal in the book is to be
encouraged and that includes TCO.
Mark
On 24 Apr, 01:35, Mark Tarver <··········@ukonline.co.uk> wrote:
> On 24 Apr, 00:10, Vend <······@virgilio.it> wrote:
>
>
>
> > On 23 Apr, 23:23, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > > On 23 Apr, 10:49, Vend <······@virgilio.it> wrote:
>
> > > > On 15 Apr, 21:52, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > > > > Last week I decided to do some serious web hacking for money; which is
> > > > > a novelty for me and kind of fun. Of all the languages widely used
> > > > > for scripting, Python seemed to me to be the nicest from my point of
> > > > > view, and has the bonus of being widely supported on a range of
> > > > > servers. I never really got into Python before, based on my impresson
> > > > > that it offered little that was conceptually new that wasn't already
> > > > > in Lisp.
>
> > > > > It occurred to me then, I could write the application in Qi and
> > > > > generate the Python using Python as the object code instead of Lisp.
> > > > > This was a lot more interesting way of learning Python than chugging
> > > > > through newbie Python exercises and its been quite instructive. Here
> > > > > are some lessons I've learnt so far.
>
> > > > Do you need bounded-space tail calls in Qi?
> > > > If so, how do you implement that in Python?
>
> > > ANSI Common Lisp, AFAIK, does not require tail call optimisation and
> > > the language standard in FPQi does not require it either. However
> > > individual CL platforms may perform this optimisation. This has come
> > > up in this group before.
>
> > Yes, but I thought that being more oriented towards functional/logic
> > programming Qi required bounded-space tail calls.
> > I was wrong.- Hide quoted text -
>
> > - Show quoted text -
>
> No; you're not wrong. Its just that the language specification -
> syntax and semantics of Qi, leaves this question open. Its a question
> for the compiler writer. FPQi gives a semantics for FPQi but stops
> short of saying how the resulting Lisp/lambda calculus should itself
> be compiled. So if you use combinators or graph reduction or
> whatever, this does not matter as long as the semantics of the
> language is respected.
Whether tail calls are executed in bounded stack space or not affects
the language semantics.
Unless bounded space tail calls are guaranted by the language
standard, you can't write reliable programs that depend on it, hence
you are forced to use looping constructs, avoid continuation passing
style, etc.
On 24 Apr, 07:04, Vend <······@virgilio.it> wrote:
> On 24 Apr, 01:35, Mark Tarver <··········@ukonline.co.uk> wrote:
>
>
>
>
>
> > On 24 Apr, 00:10, Vend <······@virgilio.it> wrote:
>
> > > On 23 Apr, 23:23, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > > > On 23 Apr, 10:49, Vend <······@virgilio.it> wrote:
>
> > > > > On 15 Apr, 21:52, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > > > > > Last week I decided to do some serious web hacking for money; which is
> > > > > > a novelty for me and kind of fun. Of all the languages widely used
> > > > > > for scripting, Python seemed to me to be the nicest from my point of
> > > > > > view, and has the bonus of being widely supported on a range of
> > > > > > servers. I never really got into Python before, based on my impresson
> > > > > > that it offered little that was conceptually new that wasn't already
> > > > > > in Lisp.
>
> > > > > > It occurred to me then, I could write the application in Qi and
> > > > > > generate the Python using Python as the object code instead of Lisp.
> > > > > > This was a lot more interesting way of learning Python than chugging
> > > > > > through newbie Python exercises and its been quite instructive. Here
> > > > > > are some lessons I've learnt so far.
>
> > > > > Do you need bounded-space tail calls in Qi?
> > > > > If so, how do you implement that in Python?
>
> > > > ANSI Common Lisp, AFAIK, does not require tail call optimisation and
> > > > the language standard in FPQi does not require it either. However
> > > > individual CL platforms may perform this optimisation. This has come
> > > > up in this group before.
>
> > > Yes, but I thought that being more oriented towards functional/logic
> > > programming Qi required bounded-space tail calls.
> > > I was wrong.- Hide quoted text -
>
> > > - Show quoted text -
>
> > No; you're not wrong. Its just that the language specification -
> > syntax and semantics of Qi, leaves this question open. Its a question
> > for the compiler writer. FPQi gives a semantics for FPQi but stops
> > short of saying how the resulting Lisp/lambda calculus should itself
> > be compiled. So if you use combinators or graph reduction or
> > whatever, this does not matter as long as the semantics of the
> > language is respected.
>
> Whether tail calls are executed in bounded stack space or not affects
> the language semantics.
>
> Unless bounded space tail calls are guaranted by the language
> standard, you can't write reliable programs that depend on it, hence
> you are forced to use looping constructs, avoid continuation passing
> style, etc.- Hide quoted text -
>
> - Show quoted text -
Well I would have to draw a distinction between
1. The semantics of a language and
2. The implementation of that semantics on a specific physical
device.
An example of 1. would be http://www.lambdassociates.org/Book/page223.htm
and following. Generally there is no mention of physical storage
requirements etc in such a semantics. This fact is abstracted away,
and it should be, to give a clear math'l model free from the
contingencies of changing machine design.
An actual implementation must be an imperfect approximation of such an
ideal and is subject to physical constraints. Its goodness or
otherwise cannot affect the semantics of the language itself. However
the systems programmer should endeavour to close this gap as far as
possible and for an FPL that includes TCO to make stack size
irrelevant. Generally stuff like this should go into the manual or be
a design requirement at a slightly lower level than the formal
semantics.
For myself I'm hazy about which Lisp platforms offer TCO and which do
not. Franz seem to make it optional. Perhaps other people here will
enlighten me.
Mark
On 24 Apr, 09:43, Mark Tarver <··········@ukonline.co.uk> wrote:
> On 24 Apr, 07:04, Vend <······@virgilio.it> wrote:
>
>
>
> > On 24 Apr, 01:35, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > > On 24 Apr, 00:10, Vend <······@virgilio.it> wrote:
>
> > > > On 23 Apr, 23:23, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > > > > On 23 Apr, 10:49, Vend <······@virgilio.it> wrote:
>
> > > > > > On 15 Apr, 21:52, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > > > > > > Last week I decided to do some serious web hacking for money; which is
> > > > > > > a novelty for me and kind of fun. Of all the languages widely used
> > > > > > > for scripting, Python seemed to me to be the nicest from my point of
> > > > > > > view, and has the bonus of being widely supported on a range of
> > > > > > > servers. I never really got into Python before, based on my impresson
> > > > > > > that it offered little that was conceptually new that wasn't already
> > > > > > > in Lisp.
>
> > > > > > > It occurred to me then, I could write the application in Qi and
> > > > > > > generate the Python using Python as the object code instead of Lisp.
> > > > > > > This was a lot more interesting way of learning Python than chugging
> > > > > > > through newbie Python exercises and its been quite instructive. Here
> > > > > > > are some lessons I've learnt so far.
>
> > > > > > Do you need bounded-space tail calls in Qi?
> > > > > > If so, how do you implement that in Python?
>
> > > > > ANSI Common Lisp, AFAIK, does not require tail call optimisation and
> > > > > the language standard in FPQi does not require it either. However
> > > > > individual CL platforms may perform this optimisation. This has come
> > > > > up in this group before.
>
> > > > Yes, but I thought that being more oriented towards functional/logic
> > > > programming Qi required bounded-space tail calls.
> > > > I was wrong.- Hide quoted text -
>
> > > > - Show quoted text -
>
> > > No; you're not wrong. Its just that the language specification -
> > > syntax and semantics of Qi, leaves this question open. Its a question
> > > for the compiler writer. FPQi gives a semantics for FPQi but stops
> > > short of saying how the resulting Lisp/lambda calculus should itself
> > > be compiled. So if you use combinators or graph reduction or
> > > whatever, this does not matter as long as the semantics of the
> > > language is respected.
>
> > Whether tail calls are executed in bounded stack space or not affects
> > the language semantics.
>
> > Unless bounded space tail calls are guaranted by the language
> > standard, you can't write reliable programs that depend on it, hence
> > you are forced to use looping constructs, avoid continuation passing
> > style, etc.- Hide quoted text -
>
> > - Show quoted text -
>
> Well I would have to draw a distinction between
>
> 1. The semantics of a language and
> 2. The implementation of that semantics on a specific physical
> device.
>
> An example of 1. would behttp://www.lambdassociates.org/Book/page223.htm
> and following. Generally there is no mention of physical storage
> requirements etc in such a semantics. This fact is abstracted away,
> and it should be, to give a clear math'l model free from the
> contingencies of changing machine design.
Finite memory is not a contingency of changing machine design, on the
contrary, Turing machines and lambda calculus are imperfect
mathematical models of physical machines.
You don't have to tie your language specification to any particular
stack size or implementation detail, but you can formulate it in terms
of an abstract machine with an infinite stack. In this model, the
bounded-space tail call requirement can be formalized (I suppose that
equivalent model exist for lambda calculus).
> For myself I'm hazy about which Lisp platforms offer TCO and which do
> not. Franz seem to make it optional. Perhaps other people here will
> enlighten me.
All conforming Scheme implementations have bounded space tail
recursion.
Common Lisp leaves it up to implementations.
On 24 Apr, 10:35, Vend <······@virgilio.it> wrote:
> On 24 Apr, 09:43, Mark Tarver <··········@ukonline.co.uk> wrote:
>
>
>
>
>
> > On 24 Apr, 07:04, Vend <······@virgilio.it> wrote:
>
> > > On 24 Apr, 01:35, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > > > On 24 Apr, 00:10, Vend <······@virgilio.it> wrote:
>
> > > > > On 23 Apr, 23:23, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > > > > > On 23 Apr, 10:49, Vend <······@virgilio.it> wrote:
>
> > > > > > > On 15 Apr, 21:52, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > > > > > > > Last week I decided to do some serious web hacking for money; which is
> > > > > > > > a novelty for me and kind of fun. Of all the languages widely used
> > > > > > > > for scripting, Python seemed to me to be the nicest from my point of
> > > > > > > > view, and has the bonus of being widely supported on a range of
> > > > > > > > servers. I never really got into Python before, based on my impresson
> > > > > > > > that it offered little that was conceptually new that wasn't already
> > > > > > > > in Lisp.
>
> > > > > > > > It occurred to me then, I could write the application in Qi and
> > > > > > > > generate the Python using Python as the object code instead of Lisp.
> > > > > > > > This was a lot more interesting way of learning Python than chugging
> > > > > > > > through newbie Python exercises and its been quite instructive. Here
> > > > > > > > are some lessons I've learnt so far.
>
> > > > > > > Do you need bounded-space tail calls in Qi?
> > > > > > > If so, how do you implement that in Python?
>
> > > > > > ANSI Common Lisp, AFAIK, does not require tail call optimisation and
> > > > > > the language standard in FPQi does not require it either. However
> > > > > > individual CL platforms may perform this optimisation. This has come
> > > > > > up in this group before.
>
> > > > > Yes, but I thought that being more oriented towards functional/logic
> > > > > programming Qi required bounded-space tail calls.
> > > > > I was wrong.- Hide quoted text -
>
> > > > > - Show quoted text -
>
> > > > No; you're not wrong. Its just that the language specification -
> > > > syntax and semantics of Qi, leaves this question open. Its a question
> > > > for the compiler writer. FPQi gives a semantics for FPQi but stops
> > > > short of saying how the resulting Lisp/lambda calculus should itself
> > > > be compiled. So if you use combinators or graph reduction or
> > > > whatever, this does not matter as long as the semantics of the
> > > > language is respected.
>
> > > Whether tail calls are executed in bounded stack space or not affects
> > > the language semantics.
>
> > > Unless bounded space tail calls are guaranted by the language
> > > standard, you can't write reliable programs that depend on it, hence
> > > you are forced to use looping constructs, avoid continuation passing
> > > style, etc.- Hide quoted text -
>
> > > - Show quoted text -
>
> > Well I would have to draw a distinction between
>
> > 1. The semantics of a language and
> > 2. The implementation of that semantics on a specific physical
> > device.
>
> > An example of 1. would behttp://www.lambdassociates.org/Book/page223.htm
> > and following. Generally there is no mention of physical storage
> > requirements etc in such a semantics. This fact is abstracted away,
> > and it should be, to give a clear math'l model free from the
> > contingencies of changing machine design.
>
> Finite memory is not a contingency of changing machine design, on the
> contrary, Turing machines and lambda calculus are imperfect
> mathematical models of physical machines.
>
> You don't have to tie your language specification to any particular
> stack size or implementation detail, but you can formulate it in terms
> of an abstract machine with an infinite stack. In this model, the
> bounded-space tail call requirement can be formalized (I suppose that
> equivalent model exist for lambda calculus).
>
> > For myself I'm hazy about which Lisp platforms offer TCO and which do
> > not. Franz seem to make it optional. Perhaps other people here will
> > enlighten me.
>
> All conforming Scheme implementations have bounded space tail
> recursion.
> Common Lisp leaves it up to implementations.- Hide quoted text -
>
> - Show quoted text -
Well formal semantics for languages is often not pitched that level of
implementation. There is a reason for that, which is that it may
freeze compiler decisions into the definition of the language at in
ways that later come to seem to be premature in view of advances in CS
(e.g. parallel programming). The second reason is that more math'lly
oriented descriptions like the one in FPQi lend themselves to formal
proofs about type integrity (see following chapter) and program
correctness which might be more awkward if conducted at the level of
stacks etc.
Generally I see the formal semantics as the ideal which implementors
try to capture, rather than as the imperfect model of an imperfect
computing device.
Mark
On Apr 24, 3:16 am, Mark Tarver <··········@ukonline.co.uk> wrote:
> On 24 Apr, 10:35, Vend <······@virgilio.it> wrote:
> > Finite memory is not a contingency of changing machine design, on the
> > contrary, Turing machines and lambda calculus are imperfect
> > mathematical models of physical machines.
>
> > You don't have to tie your language specification to any particular
> > stack size or implementation detail, but you can formulate it in terms
> > of an abstract machine with an infinite stack. In this model, the
> > bounded-space tail call requirement can be formalized (I suppose that
> > equivalent model exist for lambda calculus).
> Well formal semantics for languages is often not pitched that level of
> implementation. There is a reason for that, which is that it may
> freeze compiler decisions into the definition of the language at in
> ways that later come to seem to be premature in view of advances in CS
> (e.g. parallel programming). The second reason is that more math'lly
> oriented descriptions like the one in FPQi lend themselves to formal
> proofs about type integrity (see following chapter) and program
> correctness which might be more awkward if conducted at the level of
> stacks etc.
>
> Generally I see the formal semantics as the ideal which implementors
> try to capture, rather than as the imperfect model of an imperfect
> computing device.
Um, I think you've missed Vend's point. There are ways to formalize
this constraint without getting too concrete. Will Clinger has done
some work in this area.
-- Scott
On 24 Apr, 12:16, Mark Tarver <··········@ukonline.co.uk> wrote:
> On 24 Apr, 10:35, Vend <······@virgilio.it> wrote:
>
>
>
> > On 24 Apr, 09:43, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > > On 24 Apr, 07:04, Vend <······@virgilio.it> wrote:
>
> > > > On 24 Apr, 01:35, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > > > > On 24 Apr, 00:10, Vend <······@virgilio.it> wrote:
>
> > > > > > On 23 Apr, 23:23, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > > > > > > On 23 Apr, 10:49, Vend <······@virgilio.it> wrote:
>
> > > > > > > > On 15 Apr, 21:52, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > > > > > > > > Last week I decided to do some serious web hacking for money; which is
> > > > > > > > > a novelty for me and kind of fun. Of all the languages widely used
> > > > > > > > > for scripting, Python seemed to me to be the nicest from my point of
> > > > > > > > > view, and has the bonus of being widely supported on a range of
> > > > > > > > > servers. I never really got into Python before, based on my impresson
> > > > > > > > > that it offered little that was conceptually new that wasn't already
> > > > > > > > > in Lisp.
>
> > > > > > > > > It occurred to me then, I could write the application in Qi and
> > > > > > > > > generate the Python using Python as the object code instead of Lisp.
> > > > > > > > > This was a lot more interesting way of learning Python than chugging
> > > > > > > > > through newbie Python exercises and its been quite instructive. Here
> > > > > > > > > are some lessons I've learnt so far.
>
> > > > > > > > Do you need bounded-space tail calls in Qi?
> > > > > > > > If so, how do you implement that in Python?
>
> > > > > > > ANSI Common Lisp, AFAIK, does not require tail call optimisation and
> > > > > > > the language standard in FPQi does not require it either. However
> > > > > > > individual CL platforms may perform this optimisation. This has come
> > > > > > > up in this group before.
>
> > > > > > Yes, but I thought that being more oriented towards functional/logic
> > > > > > programming Qi required bounded-space tail calls.
> > > > > > I was wrong.- Hide quoted text -
>
> > > > > > - Show quoted text -
>
> > > > > No; you're not wrong. Its just that the language specification -
> > > > > syntax and semantics of Qi, leaves this question open. Its a question
> > > > > for the compiler writer. FPQi gives a semantics for FPQi but stops
> > > > > short of saying how the resulting Lisp/lambda calculus should itself
> > > > > be compiled. So if you use combinators or graph reduction or
> > > > > whatever, this does not matter as long as the semantics of the
> > > > > language is respected.
>
> > > > Whether tail calls are executed in bounded stack space or not affects
> > > > the language semantics.
>
> > > > Unless bounded space tail calls are guaranted by the language
> > > > standard, you can't write reliable programs that depend on it, hence
> > > > you are forced to use looping constructs, avoid continuation passing
> > > > style, etc.- Hide quoted text -
>
> > > > - Show quoted text -
>
> > > Well I would have to draw a distinction between
>
> > > 1. The semantics of a language and
> > > 2. The implementation of that semantics on a specific physical
> > > device.
>
> > > An example of 1. would behttp://www.lambdassociates.org/Book/page223.htm
> > > and following. Generally there is no mention of physical storage
> > > requirements etc in such a semantics. This fact is abstracted away,
> > > and it should be, to give a clear math'l model free from the
> > > contingencies of changing machine design.
>
> > Finite memory is not a contingency of changing machine design, on the
> > contrary, Turing machines and lambda calculus are imperfect
> > mathematical models of physical machines.
>
> > You don't have to tie your language specification to any particular
> > stack size or implementation detail, but you can formulate it in terms
> > of an abstract machine with an infinite stack. In this model, the
> > bounded-space tail call requirement can be formalized (I suppose that
> > equivalent model exist for lambda calculus).
>
> > > For myself I'm hazy about which Lisp platforms offer TCO and which do
> > > not. Franz seem to make it optional. Perhaps other people here will
> > > enlighten me.
>
> > All conforming Scheme implementations have bounded space tail
> > recursion.
> > Common Lisp leaves it up to implementations.- Hide quoted text -
>
> > - Show quoted text -
>
> Well formal semantics for languages is often not pitched that level of
> implementation.
Actually the specifications of many functional languages require
bounded-space tail calls (or tail recursion).
> There is a reason for that, which is that it may
> freeze compiler decisions into the definition of the language at in
> ways that later come to seem to be premature in view of advances in CS
> (e.g. parallel programming).
Bounded-space tail calls are not a compiler detail, it's a quite
abstract constraint on the space complexity of programs.
How implementations satisfy that requirement is usually not specified
by the standard.
For instance, all conforming Scheme implementations support bounded-
space tail calls, many of them implement it using tail call
optimization, some use trampolines and one (Chicken scheme) uses
continuation passing transform and stack garbage collection.
> The second reason is that more math'lly
> oriented descriptions like the one in FPQi lend themselves to formal
> proofs about type integrity (see following chapter) and program
> correctness which might be more awkward if conducted at the level of
> stacks etc.
I don't see why it type checking would become more awkward if resource
utilization was considered.
Assuming that memory is finite could complicate type inference by
introducing special values representing out of memory exceptions (as
Java does, for instance), but you don't have to assume finite memory
in order to specify the bounded-space tail call requirement.
> Generally I see the formal semantics as the ideal which implementors
> try to capture, rather than as the imperfect model of an imperfect
> computing device.
Then you are writing a model for nice mathematical proofs of theory of
computation, not a programming language.
On 24 Apr, 21:12, Vend <······@virgilio.it> wrote:
> Then you are writing a model for nice mathematical proofs of theory of
> computation, not a programming language.
I didn't mean to me harsh, I just wanted to point out that in writing
the specification of your language you should make it precise enough
that it's possible to write programs portable between different
conforming implementations.
On 24 Apr, 20:23, Vend <······@virgilio.it> wrote:
> On 24 Apr, 21:12, Vend <······@virgilio.it> wrote:
>
> > Then you are writing a model for nice mathematical proofs of theory of
> > computation, not a programming language
>
> I didn't mean to me harsh, I just wanted to point out that in writing
> the specification of your language you should make it precise enough
> that it's possible to write programs portable between different
> conforming implementations.
I think you would prefer a semantics for Qi closer to the actual
innards of the computer where issues of TCO would be determined as
part of the language standard. For me, TCO is a corollary of the
principle that limitations of hardware should be eliminated as far as
possible so that the behaviour of the platform corresponds to the
formal model where resource utilisation is a non-issue. So to say Qi
supports TCO as a desideratum is for for me like saying you should not
spit on the floor. It follows from general principles of hygiene.
That said, Qi runs under and is dependent on Lisp, and I have no
formal power to make CL implementors conform to TCO.
On 25 Apr, 01:51, Mark Tarver <··········@ukonline.co.uk> wrote:
> On 24 Apr, 20:23, Vend <······@virgilio.it> wrote:
>
> > On 24 Apr, 21:12, Vend <······@virgilio.it> wrote:
>
> > > Then you are writing a model for nice mathematical proofs of theory of
> > > computation, not a programming language
>
> > I didn't mean to me harsh, I just wanted to point out that in writing
> > the specification of your language you should make it precise enough
> > that it's possible to write programs portable between different
> > conforming implementations.
>
> I think you would prefer a semantics for Qi closer to the actual
> innards of the computer where issues of TCO would be determined as
> part of the language standard.
I think you are confusing bounded-space tail calls with tail call
optimization:
Boundend-space tail calls is a requirement on space complexity of
programs.
Tail call optimization is a compiler or interpreter technique to
satisfy the above requirement.
> For me, TCO is a corollary of the
> principle that limitations of hardware should be eliminated as far as
> possible so that the behaviour of the platform corresponds to the
> formal model where resource utilisation is a non-issue.
Programmers want to reason about complexity of their programs, at
least asymptotically.
If your language, as defined by its standard, doesn't allow that then
it's underspecified, IMHO.
Theory of computational complexity is at least as important as theory
of computation.
> So to say Qi
> supports TCO as a desideratum is for for me like saying you should not
> spit on the floor. It follows from general principles of hygiene.
While leaving space complexity of tail calls implementation dependent
is a valid decision, I think you should take complexity into
consideration in your language specification.
> That said, Qi runs under and is dependent on Lisp, and I have no
> formal power to make CL implementors conform to TCO.
You can't force tail call optimization on Common Lisp implementations,
but you could still implement bounded-space tail calls using programs
transformations.
(For instance, many Scheme implementations targeting Java use
trampolines).
From: Brian Adkins
Subject: Re: compiling (Qi to) Lisp to Python: some observations
Date:
Message-ID: <m2r5zj109o.fsf@gmail.com>
Mark Tarver <··········@ukonline.co.uk> writes:
> On 23 Apr, 10:49, Vend <······@virgilio.it> wrote:
>> [...]
>> Do you need bounded-space tail calls in Qi?
>> If so, how do you implement that in Python?
>
> ANSI Common Lisp, AFAIK, does not require tail call optimisation and
> the language standard in FPQi does not require it either. However
> individual CL platforms may perform this optimisation. This has come
> up in this group before.
>
> http://groups.google.co.uk/group/comp.lang.lisp/browse_frm/thread/d62865297bde3c41?hl=en&tvc=1&q=CL+implemenations+and+tail-call
>
> Python I'm still learning. It looks from my very cursory survey that
> Python does not have this feature built in, otherwise the posts I've
> read on how to add this feature would seem spurious.
Guido just blogged about this yesterday. He stated he does not want
"tail recursion elimination" in Python because it's "unpythonic":
http://neopythonic.blogspot.com/2009/04/tail-recursion-elimination.html
> However Qi probably benefits more from tail optimisation than CL or
> Python because it eschews iterative constructions which both the other
> languages embrace as substitutes for TCO.
>
> I don't know yet how well Python copes with recursion but I'd guess/
> hope that its probably fairly decent. There is some discussion on
> this point in
>
> http://lambda-the-ultimate.org/node/472#comment-3526
>
> Mark
--
Brian Adkins
http://lojic.com/
On Apr 23, 7:19 pm, Brian Adkins <···········@gmail.com> wrote:
> Mark Tarver <··········@ukonline.co.uk> writes:
> > Python I'm still learning. It looks from my very cursory survey that
> > Python does not have this feature built in, otherwise the posts I've
> > read on how to add this feature would seem spurious.
>
> Guido just blogged about this yesterday. He stated he does not want
> "tail recursion elimination" in Python because it's "unpythonic":
>
> http://neopythonic.blogspot.com/2009/04/tail-recursion-elimination.html
He seems to blag about it every once in a while. People bother him
asking for it, he bothers people back. :P
> > I don't know yet how well Python copes with recursion but I'd guess/
> > hope that its probably fairly decent. There is some discussion on
> > this point in
It copes with recursion as /nicely/ as C: with a stack trace when it
reaches its limit.
Guido van Rossum doesn't like recursion, so one should rely on common
iteration builtin syntax, like for or list iterators...
On 23 Apr, 23:45, namekuseijin <············@gmail.com> wrote:
> On Apr 23, 7:19 pm, Brian Adkins <···········@gmail.com> wrote:
>
> > Mark Tarver <··········@ukonline.co.uk> writes:
> > > Python I'm still learning. It looks from my very cursory survey that
> > > Python does not have this feature built in, otherwise the posts I've
> > > read on how to add this feature would seem spurious.
>
> > Guido just blogged about this yesterday. He stated he does not want
> > "tail recursion elimination" in Python because it's "unpythonic":
>
> >http://neopythonic.blogspot.com/2009/04/tail-recursion-elimination.html
>
> He seems to blag about it every once in a while. People bother him
> asking for it, he bothers people back. :P
>
> > > I don't know yet how well Python copes with recursion but I'd guess/
> > > hope that its probably fairly decent. There is some discussion on
> > > this point in
>
> It copes with recursion as /nicely/ as C: with a stack trace when it
> reaches its limit.
>
> Guido van Rossum doesn't like recursion, so one should rely on common
> iteration builtin syntax, like for or list iterators...
Yes; I think his idea is that having recursion as well as iteration
enables you to solve problems in more than one way and this is
contrary to the Python philosophy of 'the one right way'. This
philosophy of uniform formatting and standardisation of style allows
interchangability of programmers. He imposes his style of
programming and that, to some degree, has proved to be a selling point
for Python for managers. Since Python is now more popular than CL,
you have to admit he must have made some good calls. And Python will
recurse to a depth of nearly a 1000 which is good enough for most
applications.
*However I'm not in agreement with him here*. I think if you are
going to have recursion, you might as well make it as efficient as
possible. I mean, its not going to change the language standard to do
a good job on recursion, so why not do it? I also believe that
thinking recursively liberates you as a functional programmer, helping
you think declaratively. Anybody who learns an FPL after C/C++ will
have to get into recursion otherwise you are still holding onto your
old mindset. ML and Haskell pretty much demand it. CL allows you to
escape this which is why a lot of newbie CL programs are not that
good.
In some ways the philosophy of standardisation of style is shared by
Qi and Python. Except that Qi very clearly standardises towards
recursion.
Mark
On Apr 23, 6:19 pm, Brian Adkins <···········@gmail.com> wrote:
> Mark Tarver <··········@ukonline.co.uk> writes:
> > On 23 Apr, 10:49, Vend <······@virgilio.it> wrote:
> >> [...]
> >> Do you need bounded-space tail calls in Qi?
> >> If so, how do you implement that in Python?
>
> > ANSI Common Lisp, AFAIK, does not require tail call optimisation and
> > the language standard in FPQi does not require it either. However
> > individual CL platforms may perform this optimisation. This has come
> > up in this group before.
>
> >http://groups.google.co.uk/group/comp.lang.lisp/browse_frm/thread/d62...
>
> > Python I'm still learning. It looks from my very cursory survey that
> > Python does not have this feature built in, otherwise the posts I've
> > read on how to add this feature would seem spurious.
>
> Guido just blogged about this yesterday. He stated he does not want
> "tail recursion elimination" in Python because it's "unpythonic":
>
> http://neopythonic.blogspot.com/2009/04/tail-recursion-elimination.html
>
> > However Qi probably benefits more from tail optimisation than CL or
> > Python because it eschews iterative constructions which both the other
> > languages embrace as substitutes for TCO.
>
> > I don't know yet how well Python copes with recursion but I'd guess/
> > hope that its probably fairly decent. There is some discussion on
> > this point in
>
> >http://lambda-the-ultimate.org/node/472#comment-3526
>
> > Mark
>
> --
> Brian Adkinshttp://lojic.com/
It's nice to see that Guido continues to be the poster child for BDFL
autocracy, and the irremediable suckage that inevitably entails.
On 15 Apr, 20:52, Mark Tarver <··········@ukonline.co.uk> wrote:
> Last week I decided to do some serious web hacking for money; which is
> a novelty for me and kind of fun. Of all the languages widely used
> for scripting, Python seemed to me to be the nicest from my point of
> view, and has the bonus of being widely supported on a range of
> servers. I never really got into Python before, based on my impresson
> that it offered little that was conceptually new that wasn't already
> in Lisp.
>
> It occurred to me then, I could write the application in Qi and
> generate the Python using Python as the object code instead of Lisp.
> This was a lot more interesting way of learning Python than chugging
> through newbie Python exercises and its been quite instructive. Here
> are some lessons I've learnt so far.
>
> 1. Python is not novel but it does look pretty.
>
> Yes; I was right, its not new but ...
>
> It is actually a pleasing language to work in and it looks
> reassuringly bracket free. Perhaps we should have listened to all the
> newbies who complained in the past about 'too many brackets' in Lisp
> because all van Rossum has really done is neatly package some old
> ideas, but the wrapper looks good.
>
> 2. Whitespace in Python is initally a pain but wears off fairly
> quickly
>
> This was a culture shock - whitespace/indentation sensitivity - and
> working off the web sans textbook, it was difficult at first to figure
> out the conventions. Having figured it out and having bullied the
> formatter (see post on CLisp below) to behave, my generated Python
> seems to work fine.
>
> The formatting conventions actually help readability across Python
> programmers by enforcing a common convention. Its an interesting
> contrast to CL anarchy, where everybody writes in their own style,
> that van Rossum's influence is tangible as BDFL and he seems pretty
> benevolent.
>
> 3. Lisp is a great object language to compile from or into.
>
> The simple syntax is responsible. Its actually much easier to compile
> from Lisp to Python than from Qi to Python - mainly because Python and
> Lisp are essentially so similar in design, if not syntax, whereas Qi
> introduces higher-level constructions involving patterns for which I
> can find no correlate in Python. Hence the chain is
>
> Qi --> Lisp --> Python
>
> Lisp->Python cross-compilers must have been built, but the nice bit
> about doing it myself was that Qi-generated Lisp is extremely
> mechanical and regular and uses only a small subset of CL and hence
> the compiler (Quip - Qi into Python) is correspondingly small.
>
> 4. Look ma, no types.
>
> Types were not used in this application. I had the choice, but simply
> wanted to build the thing. You may infer all sorts of conclusions
> here and will no doubt do so ;). However pattern-directed list
> handling was *enormously* useful. I would not want to do this in
> Lisp. In short the motto seems to be 'Qi for your metalanguage and
> Lisp for the object language'.
>
> 5. Cross-compiling Qi II itself is not hard
>
> Qi II is written in itself which means that the CL source code for Qi
> can itself be put through Quip. This would give a version of Qi II
> that exists in and under Python. Is it worth it? I'm not convinced
> because the end result would be a slower Qi with no apparent
> advantages I can see (anybody care to argue the case?). However it
> would be equally easy, perhaps easier, to cross-compile Qi source into
> any other Lisp-like language such as Clojure or NewLisp.
>
> Mark
I also see that Python's notation for selecting list elements is
different. Am I right in saying that Python gains constant time
access to list elements by index instead of CL linear time access
through CAR/CDR chains?
If so, then I'll optimise Quip to take advantage of this.
BTW is Python the first language to offer this feature?
Mark
From: Brian Adkins
Subject: Re: Lisp vs Python's list accession
Date:
Message-ID: <m2iqku1cuw.fsf@gmail.com>
Mark Tarver <··········@ukonline.co.uk> writes:
> [...]
> I also see that Python's notation for selecting list elements is
> different. Am I right in saying that Python gains constant time
> access to list elements by index instead of CL linear time access
> through CAR/CDR chains?
>
> If so, then I'll optimise Quip to take advantage of this.
>
> BTW is Python the first language to offer this feature?
>
> Mark
I can't tell if you're being facetious or not. Python's "lists" are
actually "flexible arrays".
--
Brian Adkins
http://lojic.com/
On 24 Apr, 12:59, Brian Adkins <···········@gmail.com> wrote:
> Mark Tarver <··········@ukonline.co.uk> writes:
> > [...]
> > I also see that Python's notation for selecting list elements is
> > different. Am I right in saying that Python gains constant time
> > access to list elements by index instead of CL linear time access
> > through CAR/CDR chains?
>
> > If so, then I'll optimise Quip to take advantage of this.
>
> > BTW is Python the first language to offer this feature?
>
> > Mark
>
> I can't tell if you're being facetious or not. Python's "lists" are
> actually "flexible arrays".
>
> --
> Brian Adkinshttp://lojic.com/
Yes; this page says that they are often flexible arrays
http://www.brpreiss.com/books/opus7/html/page82.html
but also says that their representation is implementation dependent.
But are Python lists also indistinguishable from conventional lists
for list processing. This is the crucial point. For example, can I
modify a Python list non-destructively? Can CAR and CDR be thought of
as
def car (x):
return x[0]
def cdr (x):
return x[1:]
Mark
On 24 Apr, 16:02, Mark Tarver <··········@ukonline.co.uk> wrote:
> On 24 Apr, 12:59, Brian Adkins <···········@gmail.com> wrote:
>
>
>
>
>
> > Mark Tarver <··········@ukonline.co.uk> writes:
> > > [...]
> > > I also see that Python's notation for selecting list elements is
> > > different. Am I right in saying that Python gains constant time
> > > access to list elements by index instead of CL linear time access
> > > through CAR/CDR chains?
>
> > > If so, then I'll optimise Quip to take advantage of this.
>
> > > BTW is Python the first language to offer this feature?
>
> > > Mark
>
> > I can't tell if you're being facetious or not. Python's "lists" are
> > actually "flexible arrays".
>
> > --
> > Brian Adkinshttp://lojic.com/
>
> Yes; this page says that they are often flexible arrays
>
> http://www.brpreiss.com/books/opus7/html/page82.html
>
> but also says that their representation is implementation dependent.
> But are Python lists also indistinguishable from conventional lists
> for list processing. This is the crucial point. For example, can I
> modify a Python list non-destructively? Can CAR and CDR be thought of
> as
>
> def car (x):
> return x[0]
>
> def cdr (x):
> return x[1:]
>
> Mark- Hide quoted text -
>
> - Show quoted text -
I'll ask the Python guys this one.
Mark
On 24 Apr, 17:23, Mark Tarver <··········@ukonline.co.uk> wrote:
> On 24 Apr, 16:02, Mark Tarver <··········@ukonline.co.uk> wrote:
>
>
>
> > On 24 Apr, 12:59, Brian Adkins <···········@gmail.com> wrote:
>
> > > Mark Tarver <··········@ukonline.co.uk> writes:
> > > > [...]
> > > > I also see that Python's notation for selecting list elements is
> > > > different. Am I right in saying that Python gains constant time
> > > > access to list elements by index instead of CL linear time access
> > > > through CAR/CDR chains?
>
> > > > If so, then I'll optimise Quip to take advantage of this.
>
> > > > BTW is Python the first language to offer this feature?
>
> > > > Mark
>
> > > I can't tell if you're being facetious or not. Python's "lists" are
> > > actually "flexible arrays".
>
> > > --
> > > Brian Adkinshttp://lojic.com/
>
> > Yes; this page says that they are often flexible arrays
>
> >http://www.brpreiss.com/books/opus7/html/page82.html
>
> > but also says that their representation is implementation dependent.
> > But are Python lists also indistinguishable from conventional lists
> > for list processing. This is the crucial point. For example, can I
> > modify a Python list non-destructively? Can CAR and CDR be thought of
> > as
>
> > def car (x):
> > return x[0]
>
> > def cdr (x):
> > return x[1:]
I think that x[1:] is O(n)
On Apr 24, 11:36 am, Vend <······@virgilio.it> wrote:
>
> I think that x[1:] is O(n)
Sounds like someone should port FSet to Python ... or at least to
Qi :)
-- Scott
Mark Tarver <··········@ukonline.co.uk> writes:
> On 24 Apr, 12:59, Brian Adkins <···········@gmail.com> wrote:
>> Mark Tarver <··········@ukonline.co.uk> writes:
>> > [...]
>> > I also see that Python's notation for selecting list elements is
>> > different. �Am I right in saying that Python gains constant time
>> > access to list elements by index instead of CL linear time access
>> > through CAR/CDR chains?
>>
>> > If so, then I'll optimise Quip to take advantage of this.
>>
>> > BTW is Python the first language to offer this feature?
>>
>> > Mark
>>
>> I can't tell if you're being facetious or not. Python's "lists" are
>> actually "flexible arrays".
>>
>> --
>> Brian Adkinshttp://lojic.com/
>
> Yes; this page says that they are often flexible arrays
>
> http://www.brpreiss.com/books/opus7/html/page82.html
>
> but also says that their representation is implementation dependent.
> But are Python lists also indistinguishable from conventional lists
> for list processing. This is the crucial point. For example, can I
> modify a Python list non-destructively? Can CAR and CDR be thought of
> as
>
> def car (x):
> return x[0]
>
> def cdr (x):
> return x[1:]
If you don't care about the time and space complexities, yes, somewhat.
Notice that you cannot have a cons equivalent to lisp cons.
Assuming that Python arrays behave like Ruby arrays, here is what you
get in Ruby (I don't know Python):
(def car(x)
(return x[0])
end)
(def cdr (x)
(return x[1..-1])
end)
(def cons(a d)
(return ([a]+d))
end)
(u = (cons 1,(cons 2,(cons 3,[])))) --> [1, 2, 3]
(v = (cons :v,u)) --> [:v, 1, 2, 3]
(w = (cons :w,u)) --> [:w, 1, 2, 3]
((cdr v) == (cdr w)) --> true
# but:
(v[2] = -1)
((cdr v) == (cdr w)) --> false
contrarily to lisp which shares the structure and returns true:
(let* ((u (cons 1 (cons 2 (cons 3 nil))))
(v (cons :v u))
(w (cons :w u)))
(values (eq (cdr v) (cdr w))
(setf (elt v 2) -1)
(eq (cdr v) (cdr w))))
--> T ;
-1 ;
T
--
__Pascal Bourguignon__
Mark Tarver <··········@ukonline.co.uk> writes:
> I also see that Python's notation for selecting list elements is
> different. Am I right in saying that Python gains constant time
> access to list elements by index instead of CL linear time access
> through CAR/CDR chains?
>
> If so, then I'll optimise Quip to take advantage of this.
>
> BTW is Python the first language to offer this feature?
No, Lisp offered this feature first. Well, I wonder why I bother,
LISP INVENTED ALL THE FEATURES FIRST! LISP IS MORE THAN 50 YEARS OLD!
(defun |O(1)LIST| (&rest args) (apply (function vector) args))
(elt (|O(1)LIST| 'a 'b 'c 'd) 1) ; O(1)
(let ((list (|O(1)LIST| 'a 'b 'c 'd)))
(dotimes (i (length list)) ; O(n)
(print (elt list i)))) ; O(1)
--
__Pascal Bourguignon__
On 24 Apr, 13:06, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Mark Tarver <··········@ukonline.co.uk> writes:
> > I also see that Python's notation for selecting list elements is
> > different. Am I right in saying that Python gains constant time
> > access to list elements by index instead of CL linear time access
> > through CAR/CDR chains?
>
> > If so, then I'll optimise Quip to take advantage of this.
>
> > BTW is Python the first language to offer this feature?
>
> No, Lisp offered this feature first. Well, I wonder why I bother,
> LISP INVENTED ALL THE FEATURES FIRST! LISP IS MORE THAN 50 YEARS OLD!
>
> (defun |O(1)LIST| (&rest args) (apply (function vector) args))
>
> (elt (|O(1)LIST| 'a 'b 'c 'd) 1) ; O(1)
>
> (let ((list (|O(1)LIST| 'a 'b 'c 'd)))
> (dotimes (i (length list)) ; O(n)
> (print (elt list i)))) ; O(1)
>
> --
> __Pascal Bourguignon__
Hum, what you've done is copy the contents of a list into a fresh
vector and then indexed into that vector to get constant time access.
That's fine as far as it goes and its neatly done; though its not
quite the same as having bread-and-butter constant time access built
into every list you handle. The default I've seen is exactly as
described here
QUOTE
A list is a sequence of elements, but it is not a single primitive
object; it is made of cons cells, one cell per element. Finding the
nth element requires looking through n cons cells, so elements farther
from the beginning of the list take longer to access. But it is
possible to add elements to the list, or remove elements.
UNQUOTE
http://www.chemie.fu-berlin.de/chemnet/use/info/elisp/elisp_7.html
Given their use of flexible vectors the benefits of constant time list
access in Python will be probably be counterbalanced by overheads
elsewhere in copying, but ....
given thats the way they've sliced it, it seems wise to eliminate my
CAR/CDR chains in favour of [n]X.
Mark
Mark Tarver ha escrito:
> On 24 Apr, 13:06, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
> > Mark Tarver <··········@ukonline.co.uk> writes:
> > > I also see that Python's notation for selecting list elements is
> > > different. Am I right in saying that Python gains constant time
> > > access to list elements by index instead of CL linear time access
> > > through CAR/CDR chains?
> >
> > > If so, then I'll optimise Quip to take advantage of this.
> >
> > > BTW is Python the first language to offer this feature?
> >
> > No, Lisp offered this feature first. Well, I wonder why I bother,
> > LISP INVENTED ALL THE FEATURES FIRST! LISP IS MORE THAN 50 YEARS OLD!
> >
> > (defun |O(1)LIST| (&rest args) (apply (function vector) args))
> >
> > (elt (|O(1)LIST| 'a 'b 'c 'd) 1) ; O(1)
> >
> > (let ((list (|O(1)LIST| 'a 'b 'c 'd)))
> > (dotimes (i (length list)) ; O(n)
> > (print (elt list i)))) ; O(1)
> >
> > --
> > __Pascal Bourguignon__
>
> Hum, what you've done is copy the contents of a list into a fresh
> vector and then indexed into that vector to get constant time access.
> That's fine as far as it goes and its neatly done; though its not
> quite the same as having bread-and-butter constant time access built
> into every list you handle. The default I've seen is exactly as
> described here
>
> QUOTE
> A list is a sequence of elements, but it is not a single primitive
> object; it is made of cons cells, one cell per element. Finding the
> nth element requires looking through n cons cells, so elements farther
> from the beginning of the list take longer to access. But it is
> possible to add elements to the list, or remove elements.
> UNQUOTE
>
> http://www.chemie.fu-berlin.de/chemnet/use/info/elisp/elisp_7.html
>
> Given their use of flexible vectors the benefits of constant time list
> access in Python will be probably be counterbalanced by overheads
> elsewhere in copying, but ....
>
> given thats the way they've sliced it, it seems wise to eliminate my
> CAR/CDR chains in favour of [n]X.
>
> Mark
About python List and alternative implementation:
http://www.python.org/dev/peps/pep-3128/
On 24 Apr, 17:43, camposdeviento <·············@gmail.com> wrote:
> Mark Tarver ha escrito:
>
>
>
>
>
> > On 24 Apr, 13:06, ····@informatimago.com (Pascal J. Bourguignon)
> > wrote:
> > > Mark Tarver <··········@ukonline.co.uk> writes:
> > > > I also see that Python's notation for selecting list elements is
> > > > different. Am I right in saying that Python gains constant time
> > > > access to list elements by index instead of CL linear time access
> > > > through CAR/CDR chains?
>
> > > > If so, then I'll optimise Quip to take advantage of this.
>
> > > > BTW is Python the first language to offer this feature?
>
> > > No, Lisp offered this feature first. Well, I wonder why I bother,
> > > LISP INVENTED ALL THE FEATURES FIRST! LISP IS MORE THAN 50 YEARS OLD!
>
> > > (defun |O(1)LIST| (&rest args) (apply (function vector) args))
>
> > > (elt (|O(1)LIST| 'a 'b 'c 'd) 1) ; O(1)
>
> > > (let ((list (|O(1)LIST| 'a 'b 'c 'd)))
> > > (dotimes (i (length list)) ; O(n)
> > > (print (elt list i)))) ; O(1)
>
> > > --
> > > __Pascal Bourguignon__
>
> > Hum, what you've done is copy the contents of a list into a fresh
> > vector and then indexed into that vector to get constant time access.
> > That's fine as far as it goes and its neatly done; though its not
> > quite the same as having bread-and-butter constant time access built
> > into every list you handle. The default I've seen is exactly as
> > described here
>
> > QUOTE
> > A list is a sequence of elements, but it is not a single primitive
> > object; it is made of cons cells, one cell per element. Finding the
> > nth element requires looking through n cons cells, so elements farther
> > from the beginning of the list take longer to access. But it is
> > possible to add elements to the list, or remove elements.
> > UNQUOTE
>
> >http://www.chemie.fu-berlin.de/chemnet/use/info/elisp/elisp_7.html
>
> > Given their use of flexible vectors the benefits of constant time list
> > access in Python will be probably be counterbalanced by overheads
> > elsewhere in copying, but ....
>
> > given thats the way they've sliced it, it seems wise to eliminate my
> > CAR/CDR chains in favour of [n]X.
>
> > Mark
>
> About python List and alternative implementation:
>
> http://www.python.org/dev/peps/pep-3128/- Hide quoted text -
>
> - Show quoted text -
This constant time list access in Python is actually quite important
for Quip. In Qi, the compiler optimisations focussed on 3 areas.
1. Optimising CAR/CDR chains to stop repeated list traversal (speed =
1).
2. Factorising overlapping patterns to prevent repeated tests.
3. Inserting type declarations and using type specific equality
tests.
Of these 1. seems irrelevant. so that in fact it is better to direct
Quip to set the Qi compiler to speed = 0 (lowest optimisation) and
work off less optimised code. I'm not certain how well code at level
3 can be translated to Python since it uses GOTOs and THE type
declarations. At any rate I'll pitch it low at first.
Thanks for all the info here and Pascal's code. Very interesting to
learn how other languages approach these things.
Mark
Mark Tarver <··········@ukonline.co.uk> writes:
> I also see that Python's notation for selecting list elements is
> different. Am I right in saying that Python gains constant time
> access to list elements by index instead of CL linear time access
> through CAR/CDR chains?
Yes. Python calls them lists, but they're really more like adjustable
vectors with fill pointers. Python's `list' performance sucks if you
try to prepend elements.
> If so, then I'll optimise Quip to take advantage of this.
Sounds good.
> BTW is Python the first language to offer this feature?
No: far from it. Perl talks about lists and arrays in the same breath
so often it's hard to work out what it thinks the difference is[1], and
its arrays are at least as flexible as Python's, and provides efficient
prepending and appending.
Icon (a fascinating language I really ought to use more often) provides
very vector-like `lists', though the reference implementation actually
uses a doubly-linked list of vectory chunks.
[1] The answer appears to be that a `list' is a bunch of values on the
interpreter's stack, between SP and MARK (and is therefore not first
class), whereas an `array' is a proper first-class[2] value
consisting of a sequence of such values.
[2] Well, almost. Points for effort, anyway.
-- [mdw]
> Yes. Python calls them lists, but they're really more like adjustable
> vectors with fill pointers. Python's `list' performance sucks if you
> try to prepend elements.
Yes; I can see how that would be.
Mark
Definitely, none of them are worthy the name Lisp Processing. ;)
Mark Wooding escreveu:
> Yes. Python calls them lists, but they're really more like adjustable
> vectors with fill pointers. Python's `list' performance sucks if you
> try to prepend elements.
Why would anyone want to do that? The default in Python is append.
Prepanding as in Lisp is only useful as a stack, most other uses for
it means getting elements in reverse order.
--
a game sig: http://tinyurl.com/d3rxz9
namekuseijin <············@gmail.com> writes:
> Definitely, none of them are worthy the name Lisp Processing. ;)
>
> Mark Wooding escreveu:
> > Yes. Python calls them lists, but they're really more like adjustable
> > vectors with fill pointers. Python's `list' performance sucks if you
> > try to prepend elements.
>
> Why would anyone want to do that? The default in Python is append.
>
> Prepanding as in Lisp is only useful as a stack, most other uses for
> it means getting elements in reverse order.
Well, stacks are often useful.
So is having a constant-time list addition.
I would expect that in Python, the append would not be guaranteed
constant time, since there would be a need to periodically move the
entire vector into a newer, larger contiguous block of memory.
At least in lisp, you have the choice among various data structures so
that you can get the run-time behavior you want:
lists (conses). Efficient pre-pend, efficient insertion, efficient
traversal in order. Slow random access. Slow append.
vectors (standard). Efficient random access, efficient traversal in
any order, no ability to increase size.
vectors (extensible) Efficient random access, generally efficient
append, efficient traversal in any order, occasional slowdowns to
copy when appending. Inefficient prepend or insertion.
Of these, the latter are most like the Python lists, so if there is a
comparison it should be between those data structures, not the ones with
the most similar names.
--
Thomas A. Russ, USC/Information Sciences Institute
namekuseijin <············@gmail.com> writes:
> Mark Wooding escreveu:
> > Yes. Python calls them lists, but they're really more like adjustable
> > vectors with fill pointers. Python's `list' performance sucks if you
> > try to prepend elements.
>
> Why would anyone want to do that? The default in Python is append.
Look up `deque' in any half-decent book on algorithms. Indeed, even a
simple queue requires insertion at one end and removal from the other,
and Python's lists suck at removal from the front too.
Besides, I'm well aware that few people would want to prepend items to
Python's lists. For one thing, the performance sucks. ;-) I do believe
that it'd be worth hacking Python's list implementation to allow
efficient insertion and removal at both ends, though.
But my main point is that this is a telling difference between Python's
`lists' and a Lisp-style linked list. The former suck at prepending
items; the latter suck at random access and (if you don't have a tail
pointer maintained by hand) appending. Neither is better than the
other. It's nice that CL provides both, really...
-- [mdw]
On Sat, 25 Apr 2009 23:29:20 +0100, Mark Wooding wrote:
> namekuseijin <············@gmail.com> writes:
>
>> Mark Wooding escreveu:
>> > Yes. Python calls them lists, but they're really more like
>> > adjustable vectors with fill pointers. Python's `list' performance
>> > sucks if you try to prepend elements.
>>
>> Why would anyone want to do that? The default in Python is append.
>
> Look up `deque' in any half-decent book on algorithms. Indeed, even a
> simple queue requires insertion at one end and removal from the other,
> and Python's lists suck at removal from the front too.
>
> Besides, I'm well aware that few people would want to prepend items to
> Python's lists. For one thing, the performance sucks. ;-) I do believe
> that it'd be worth hacking Python's list implementation to allow
> efficient insertion and removal at both ends, though.
>
> But my main point is that this is a telling difference between Python's
> `lists' and a Lisp-style linked list. The former suck at prepending
> items; the latter suck at random access and (if you don't have a tail
> pointer maintained by hand) appending. Neither is better than the
> other. It's nice that CL provides both, really...
And CL provides built-in hashtables, so by using integers as keys, you
can easily implement a sequence type which is really great at both
prepending and appending, and provids fast access.
Or if you want something functional, look at FSet, etc.
By the way, what is the purpose of the Qi->Python compiler? Proof of
concept ("see if we can do it"), or do you have something else in
mind?
Tamas
On Apr 25, 3:55 pm, Tamas K Papp <······@gmail.com> wrote:
>
> Or if you want something functional, look at FSet, etc.
I think FSet's seq type deserves more consideration than it gets.
Yes, random access takes O(log n) time, which is what turns people
off. But sequential access using an iterator takes amortized O(1)
time, and that's really more common than random access. And then you
have all these operations -- prepend, append, concat, subseq, etc. --
all of which also take O(log n) time, so you can use them without
worrying about the sizes of your seqs. As people are so eloquently
arguing on the PLOT thread, Lisp is great for exploratory programming;
I think FSet makes it even better by allowing you to postpone
selection of higher-performance collection types until you know what
operations you really need to perform on them.
-- Scott
On 25 Apr, 23:55, Tamas K Papp <······@gmail.com> wrote:
> On Sat, 25 Apr 2009 23:29:20 +0100, Mark Wooding wrote:
> > namekuseijin <············@gmail.com> writes:
>
> >> Mark Wooding escreveu:
> >> > Yes. Python calls them lists, but they're really more like
> >> > adjustable vectors with fill pointers. Python's `list' performance
> >> > sucks if you try to prepend elements.
>
> >> Why would anyone want to do that? The default in Python is append.
>
> > Look up `deque' in any half-decent book on algorithms. Indeed, even a
> > simple queue requires insertion at one end and removal from the other,
> > and Python's lists suck at removal from the front too.
>
> > Besides, I'm well aware that few people would want to prepend items to
> > Python's lists. For one thing, the performance sucks. ;-) I do believe
> > that it'd be worth hacking Python's list implementation to allow
> > efficient insertion and removal at both ends, though.
>
> > But my main point is that this is a telling difference between Python's
> > `lists' and a Lisp-style linked list. The former suck at prepending
> > items; the latter suck at random access and (if you don't have a tail
> > pointer maintained by hand) appending. Neither is better than the
> > other. It's nice that CL provides both, really...
>
> And CL provides built-in hashtables, so by using integers as keys, you
> can easily implement a sequence type which is really great at both
> prepending and appending, and provids fast access.
>
> Or if you want something functional, look at FSet, etc.
>
> By the way, what is the purpose of the Qi->Python compiler? Proof of
> concept ("see if we can do it"), or do you have something else in
> mind?
>
> Tamas- Hide quoted text -
>
> - Show quoted text -
It was initially practical. I had a guy who wanted a web site done
for money and my usual cheap and cheerful £5 or so a month Fasthosts
do not support Lisp. They support Perl and PHP and .Net on their
Windows servers and Python et al on their Linux. I could have looked
for a CL friendly host but the range is more limited, support is
thinner, and I was aware that CL is a very small world and I wanted to
escape.
However I'm hooked on Qi which makes hacking in Perl etc. so stupidly
boring that I cannot face it. I don't program even in CL much any
more unless needed. I lose patience very quickly with stuff that I
regard as not optimal and that includes most of what programmers play
with. Hence I cannot get into it. I'm not capable of making
concessions to learning the commercial stuff. Thats where I was stuck
- a God on a little island.
But being omnipotent in your small island is boring. Hence I saw
that, since it was possible to generate Lisp, why not generate Python
instead and use Qi? This makes learning Python more fun since it
raises the bar intellectually somewhat to a level where I'm less
likely to get bored. And it makes money or me.
But more seriously perhaps, it opens out a picture that Qi could be,
par excellence, the vehicle for overcoming the Babel of language
differences that beset modern computing since the language is so well
suited for writing languages (Quip is 140 lines so far) and, of
course, you automatically get optional type security for Blub (Blub =
Python, Lisp etc.) whenever you employ it in this way.
Mark
On 26 Apr, 13:26, budden <···········@mail.ru> wrote:
> Hi Mark!
> Are Qi classes a lisp classes? Is Qi OO code faster than CLOS?
I looked at CLOS but didn't like it. There is an old thread here on
why I didn't like it but basically it came down to two things.
1. I thought CLOS was overblown and overcomplex; I didn't see why CL
designers needed to implement another seperate layer when functional
programming enables you to design class based programming quite
easily.
2. Fatally; I found destructive operations in CLOS very early and
that was sort of fatal and quite un-Qiish and I didn't like it.
I did think of adding classes to the language standard but decided it
belonged more in the library. I showed that you can implement type
secure classes in Qi quite easily - there is a chapter on implementing
structures, classes and abstract datatypes in Qi - and the code is
there for downloading - its bundled in the directory 'Qi Programs'.
You can also pattern match over classes and instances in Qi in this
code.
But I didn't develop it much. I think with a few days effort it would
make a fairly decent class system. But I was interested in showing
this from a pedagogic point of view - that you could do it. But I had
no direct use for it.
My guess is it would be fast - sure.
You could add CLOS to Qi easily by putting a thin wrapper round CLOS
and giving it a type theory. You can read how to do this in
http://www.lambdassociates.org/Book/page393.htm
I performed this service for the maths & strings stuff in CL and for
CL error handling and you can download those to see how I did it.
http://www.lambdassociates.org/Lib/libraries.htm
Its really quite easy.
Mark
On Apr 26, 12:29 am, Mark Wooding <····@distorted.org.uk> wrote:
> Look up `deque' in any half-decent book on algorithms. Indeed, even a
> simple queue requires insertion at one end and removal from the other,
> and Python's lists suck at removal from the front too.
>
> Besides, I'm well aware that few people would want to prepend items to
> Python's lists. For one thing, the performance sucks. ;-) I do believe
> that it'd be worth hacking Python's list implementation to allow
> efficient insertion and removal at both ends, though.
Guido's time machine at work, look at collections.deque
Michele Simionato