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.
25 matches
Mail list logo
