sturlamolden <[EMAIL PROTECTED]> writes:
> On May 10, 7:18 pm, "Terry Reedy" <[EMAIL PROTECTED]> wrote:
>
> CMUCL and SBCL depends on the dominance of the x86 architecture.
CMUCL and SBCL run on a variety of architectures, including x86, 64-bit x86,
PowerPC, Sparc, Alpha, and Mips. See
http
"sturlamolden" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| On May 10, 4:02 pm, Tim Golden <[EMAIL PROTECTED]> wrote:
| I know, I know. But that doesn't stop me from envying what the Lisp
| community has achieved.
But do not let your envy stop you from noticing and appreciating
On 11 May, 18:04, John Nagle <[EMAIL PROTECTED]> wrote:
>
> Another problem is that if the language is defined as
> "whatever gets put in CPython", that discourages other
> implementations. The language needs to be standards-based.
Indeed. This was suggested by one of the speakers at last ye
Tim Golden wrote:
> sturlamolden wrote:
>
>> On May 8, 5:53 pm, John Nagle <[EMAIL PROTECTED]> wrote:
>>
>>> The point here is that we don't need language changes or
>>> declarations
>>> to make Python much faster. All we need are a few restrictions that
>>> insure that, when you're doing so
On May 10, 7:18 pm, "Terry Reedy" <[EMAIL PROTECTED]> wrote:
> Unfortunately, native machine code depends on the machine, or at least the
> machine being emulated by the hardware. Fortunately or not, the dominance
> of the x386 model makes this less of a problem.
CMUCL and SBCL depends on the do
On May 10, 4:02 pm, Tim Golden <[EMAIL PROTECTED]> wrote:
> But the relevant bit of your last paragraph is at the start:
> "We should...".
Sorry, bad choice of words.
> see it faster. That's great. But unless people
> puts their money where their mouths are, I don't
I know, I know. But that doe
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| The idea is to create a special dictionary for python internals that
| contains a pointer-to-a-pointer for the value side of the dictionary,
| instead of just the standard PyObject*. Then when you start to eval a
| code block, you cou
On May 9, 5:02 pm, John Nagle <[EMAIL PROTECTED]> wrote:
> Paul Boddie wrote:
>
> Python has that capability mostly because it's free in an
> "everything is a dictionary" implementation. ("When all you have
> is a hash, everything looks like a dictionary".) But that limits
> implementation p
"sturlamolden" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Franz, CMUCL, SBCL and GCL teams made Lisp almost as fast as C. A
| dynamic language can be fast if the implementation is good.
|
| If you look at SBCL and GCL, no code is interpreted. It's all compiled
| on the fly to n
sturlamolden wrote:
> On May 8, 5:53 pm, John Nagle <[EMAIL PROTECTED]> wrote:
>
>> The point here is that we don't need language changes or declarations
>> to make Python much faster. All we need are a few restrictions that
>> insure that, when you're doing something unusual, the compiler ca
On May 8, 5:53 pm, John Nagle <[EMAIL PROTECTED]> wrote:
> The point here is that we don't need language changes or declarations
> to make Python much faster. All we need are a few restrictions that
> insure that, when you're doing something unusual, the compiler can
> tell.
Franz, CMUCL, SB
"John Nagle" <[EMAIL PROTECTED]> wrote:
> Paul Boddie wrote:
> > On 9 May, 08:09, "Hendrik van Rooyen" <[EMAIL PROTECTED]> wrote:
> >
> >>I am relatively new on this turf, and from what I have seen so far, it
> >>would not bother me at all to tie a name's type to its first use, so that
> >>the n
"Terry Reedy" <[EMAIL PROTECTED],,.edu> wrote:
> "Hendrik van Rooyen" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> | I am relatively new on this turf, and from what I have seen so far, it
> | would not bother me at all to tie a name's type to its first use, so that
> | the name
On May 9, 10:02 am, John Nagle <[EMAIL PROTECTED]> wrote:
> One option might be a class "simpleobject", from which other classes
> can inherit. ("object" would become a subclass of "simpleobject").
> "simpleobject" classes would have the following restrictions:
>
> - New fields and f
John Nagle wrote:
>
> Modifying "at a distance" is exactly what I'm getting at. That's the
> killer from an optimizing compiler standpoint. The compiler, or a
> maintenance programmer, looks at a block of code, and there doesn't seem
> to be anything unusual going on. But, if in some other
Paul Boddie wrote:
> On 9 May, 08:09, "Hendrik van Rooyen" <[EMAIL PROTECTED]> wrote:
>
>>I am relatively new on this turf, and from what I have seen so far, it
>>would not bother me at all to tie a name's type to its first use, so that
>>the name can only be bound to objects of the same type as t
"Hendrik van Rooyen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| I am relatively new on this turf, and from what I have seen so far, it
| would not bother me at all to tie a name's type to its first use, so that
| the name can only be bound to objects of the same type as the typ
On 9 May, 08:09, "Hendrik van Rooyen" <[EMAIL PROTECTED]> wrote:
>
> I am relatively new on this turf, and from what I have seen so far, it
> would not bother me at all to tie a name's type to its first use, so that
> the name can only be bound to objects of the same type as the type
> of the objec
"John Nagle" <[EMAIL PROTECTED]> wrote:
8< summary of existing work and thinking --
> The point here is that we don't need language changes or declarations
> to make Python much faster. All we need are a few restrictions that
> insure that, when you're doing
On May 9, 1:25 pm, John Nagle <[EMAIL PROTECTED]> wrote:
> Marc 'BlackJack' Rintsch wrote:
> > I don't see how this type inference for static types will work unless some
> > of the dynamism of the language will get restricted. But is this really
> > necessary? Isn't a JIT compiler and maybe type
Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
> John Nagle a écrit :
> >Some faster Python implementations are under development.
> > JPython has been around for a while,
>
> s/JP/J/
These days, yes, but it WAS originally called JPython (it was renamed to
Jython later). So, "has been aroun
Marc 'BlackJack' Rintsch wrote:
> I don't see how this type inference for static types will work unless some
> of the dynamism of the language will get restricted. But is this really
> necessary? Isn't a JIT compiler and maybe type hinting good enough?
Not necessarily. One of the more powe
John Nagle a écrit :
>Some faster Python implementations are under development.
> JPython has been around for a while,
s/JP/J/
And FWIW, I'm not sure Jython is really faster than CPython...
--
http://mail.python.org/mailman/listinfo/python-list
In <[EMAIL PROTECTED]>, Paul Boddie
wrote:
>> On the typing front, the neatest way to express typing is via
>> initialization. With the Shed Skin restrictions, if all variables are
>> initialized before use (preferably in __init__), there's no need to
>> maintain an "undefined" flag for a var
On 8th May, 17:53, John Nagle <[EMAIL PROTECTED]> wrote:
> Some faster Python implementations are under development.
> JPython
Ahem: Jython!
> has been around for a while, and PyPy and ShedSkin
> continue to move forward. It's worth thinking about what slows
> down Python implementations.
Some faster Python implementations are under development.
JPython has been around for a while, and PyPy and ShedSkin
continue to move forward. It's worth thinking about what slows
down Python implementations.
It isn't the dynamism, really. As others have pointed out
in the Python litera
26 matches
Mail list logo
