On Wed, 11 Oct 2017 10:57 pm, Stefan Ram wrote:
> FWIW, in is book "Touch of Class" (2009) Bertrand Meyer writes:
>
> |Such instructions are just the old goto in sheep's clothing.
> |Treat them the same way as the original:
> |
> |/Touch of Methodology/:
> | Sticking to one-entry, one-exit build
Gregory Ewing writes:
> A JIT compiler works by observing the actual values
To be pedantic, that's called a "tracing JIT". Other runtime code
generation is also frequently called JIT compilation even when it's
fairly stupid combining of assembly code templates, or the like.
--
https://mail.pyth
Chris Angelico writes:
> while True:
> c = sys.stdin.read(1)
> if not c: break
> if c.isprintable(): text += c
> elif c == "\x08": text = text[:-1]
> # etc
> Can you write _that_ as a do-while?
I prefer to write that sort of thing with iterators:
for c in iter(lambda: sys.st
On 19/04/2017 17:23, Marko Rauhamaa wrote:
bartc :
Enough works in that 'pcc' project, in terms of file i/o, that it can
still run plenty of useful programs, such as compilers.
This might have come up before, but do you have a language specification
somewhere?
(Nothing formal nor up-to-date.
bartc :
> Enough works in that 'pcc' project, in terms of file i/o, that it can
> still run plenty of useful programs, such as compilers.
This might have come up before, but do you have a language specification
somewhere?
Marko
--
https://mail.python.org/mailman/listinfo/python-list
On 19/04/2017 15:35, Chris Angelico wrote:
On Wed, Apr 19, 2017 at 11:46 PM, bartc wrote:
You'd be surprised how easy it is to be non-OS-neutral.
I misread that as 'easy to be OS-neutral'. If I turn it around, you're
saying it is easy to be OS-specific. But we know that! And that is the
pro
On Wed, Apr 19, 2017 at 11:46 PM, bartc wrote:
>> You'd be surprised how easy it is to be non-OS-neutral.
>
> It's not so simple. By OS-neutral I mean code that doesn't depend on special
> features of either OS (Ie. Windows and Linux). Not conditional code that
> does either Windows stuff or Linux
On 19/04/2017 12:27, Chris Angelico wrote:
On Wed, Apr 19, 2017 at 8:33 PM, bartc wrote:
[Warning: this is nothing to do with Python.]
My interpreter is on github as /one/ C source file (a link would be
inappropriate here). People can compile it with -O3 or -O2 if they wish.
It's a bit simpl
Op 16-04-17 om 19:07 schreef Terry Reedy:
> On 4/16/2017 11:35 AM, Michael Torrie wrote:
>> On 04/16/2017 07:57 AM, bartc wrote:
>>> But people just don't want it.
>>>
>>> /That/ is what surprises me, when people reject things that to me are
>>> no-brainers.
>
> Whereas to me, it is a no-brainer th
Chris Angelico :
> On Wed, Apr 19, 2017 at 8:33 PM, bartc wrote:
> You'd be surprised how easy it is to be non-OS-neutral. Have you
> compiled it on the three major platforms of today (Lin/Win/Mac)?
Generally, I don't try to be OS-neutral because
1. I need it for Linux only
2. I don't have W
On Wed, Apr 19, 2017 at 8:33 PM, bartc wrote:
> My interpreter is on github as /one/ C source file (a link would be
> inappropriate here). People can compile it with -O3 or -O2 if they wish.
> It's a bit simpler than building CPython, and OS-neutral; that was
> deliberate.
Then send me a link, an
On 19/04/2017 01:07, Erik wrote:
On 19/04/17 00:33, bartc wrote:
[Talking about an interpreter that is /not/ for Python]
With the sort of lower level programs I write (in another dynamic
language not Python), such an assembly layer improved performance 2-3
times over using 100% HLL compiled u
On 19/04/17 00:33, bartc wrote:
So that's 'label-pointers' which I assume must correspond to computed
goto.
Yes - just different terminology. Being able to take the address of a
label and "goto address" rather than "goto label".
(I don't know why they should be faster than a switch; they ju
On 19/04/2017 00:19, Gregory Ewing wrote:
bartc wrote:
Another optimisation for something like ADD, was to to check for very
common types such as INT, and deal with those locally.
And then you're on the path to writing a JIT compiler. If you
can identify such cases, you might as well generat
Steve D'Aprano wrote:
You seem to be describing a *tracing JIT* compiler.
Well, yes, but it seems to me that a JIT compiler that
*doesn't* use tracing is just an AOT compiler that you
happen to run immediately before executing the program.
Cython doesn't do any of that -- it's just a plain,
On 18/04/2017 23:33, Erik wrote:
On 18/04/17 11:30, bartc wrote:
On 18/04/2017 10:32, Erik wrote:
the
improvements over the original huge switch() to dispatch the bytecodes
to the correct handler appear to have made this type of optimization
less effective.
What did they do to it, and on whi
On 19/04/17 00:08, Gregory Ewing wrote:
Erik wrote:
When considering special-casing this opcode sequence, remember that
in-place operations can be performed on anonymous objects (i.e., those
referenced by a collection and not bound directly to a namespace):
I think this means you would want mu
On 19/04/2017 00:08, Gregory Ewing wrote:
Erik wrote:
When considering special-casing this opcode sequence, remember that
in-place operations can be performed on anonymous objects (i.e., those
referenced by a collection and not bound directly to a namespace):
I think this means you would want
bartc wrote:
But another problem was, there /are/ no simple byte-codes in CPython!
Yes, that's the crux of the whole thing. It's the reason it's
so hard to compile Python to anything that runs significantly
faster than interpreted code.
Another optimisation for something
like ADD, was to to c
Erik wrote:
When considering special-casing this opcode sequence, remember that
in-place operations can be performed on anonymous objects (i.e., those
referenced by a collection and not bound directly to a namespace):
I think this means you would want multiple versions of the +=1 opcode:
ADD_O
Ben Bacarisse wrote:
I fond the proportion on while True: loops surprising. Is there
something about Python that encourages that kind of loop?
Maybe because for-loops take care of most of the ordinary
cases in Python, leaving while-loops to cover the weird
ones, many of which need one or more
On 18/04/17 11:30, bartc wrote:
On 18/04/2017 10:32, Erik wrote:
the
improvements over the original huge switch() to dispatch the bytecodes
to the correct handler appear to have made this type of optimization
less effective.
What did they do to it, and on which version?
It's the computed 'g
On Tue, 18 Apr 2017 03:43 pm, Gregory Ewing wrote:
> Steve D'Aprano wrote:
>> I'm not sure why the Cython devs maintain this is not a JIT compiler.
>> Perhaps I misunderstand something.
>
> A JIT compiler works by observing the actual values taken on
> by variables at run time, and if it notices
On 18/04/2017 10:32, Erik wrote:
FWIW, I spent some time about a year ago looking at things like this
(small improvements to the peephole optimizer which allowed certain very
common sequences to be folded into a (new) opcode which in turn allowed
other optimizations to avoid branching). The chan
On 13/04/17 18:50, MRAB wrote:
On 2017-04-13 09:08, Steven D'Aprano wrote:
On Wed, 12 Apr 2017 16:30:38 -0700, bart4858 wrote:
Is it possible to skip the STORE_NAME op-code? If you knew *for sure*
that the target (x) was a mutable object which implemented += using an
in-
place mutation, then you
Christian Gollwitzer writes:
> Am 18.04.17 um 08:21 schrieb Chris Angelico:
>> On Tue, Apr 18, 2017 at 4:06 PM, Christian Gollwitzer
>> wrote:
>>> Am 18.04.17 um 02:18 schrieb Ben Bacarisse:
>>>
Thanks (and to Grant). IO seems to be the canonical example. Where
some languages would f
Am 18.04.17 um 08:21 schrieb Chris Angelico:
On Tue, Apr 18, 2017 at 4:06 PM, Christian Gollwitzer wrote:
Am 18.04.17 um 02:18 schrieb Ben Bacarisse:
Thanks (and to Grant). IO seems to be the canonical example. Where
some languages would force one to write
c = sys.stdin.read(1)
while c
Christian Gollwitzer :
> Am 18.04.17 um 02:18 schrieb Ben Bacarisse:
>> Python opts for
>>
>> while True:
>> c = sys.stdin.read(1)
>> if c != ' ': break
>
> This loop would be the archetypical do..while or repeat...until to me.
>
> do
> c = sys.stdin.read(1)
> while c== ' '
No,
On Tue, Apr 18, 2017 at 4:06 PM, Christian Gollwitzer wrote:
> Am 18.04.17 um 02:18 schrieb Ben Bacarisse:
>
>> Thanks (and to Grant). IO seems to be the canonical example. Where
>> some languages would force one to write
>>
>> c = sys.stdin.read(1)
>> while c == ' ':
>> c = sys.stdin.
Am 18.04.17 um 02:18 schrieb Ben Bacarisse:
Thanks (and to Grant). IO seems to be the canonical example. Where
some languages would force one to write
c = sys.stdin.read(1)
while c == ' ':
c = sys.stdin.read(1)
Python opts for
while True:
c = sys.stdin.read(1)
if c !=
Steve D'Aprano wrote:
I'm not sure why the Cython devs maintain this is not a JIT compiler.
Perhaps I misunderstand something.
A JIT compiler works by observing the actual values taken on
by variables at run time, and if it notices that a particular
variable seems to always have a particular ty
On Tuesday, April 18, 2017 at 2:09:19 AM UTC+1, Paul Rubin wrote:
> Ben Bacarisse writes:
> > ? I get "AttributeError: 'itertools.dropwhile' object has no attribute
> > 'next'" from your example.
>
> Hmm, .next() worked ok for me in Python 2.7.5. Not sure what happened.
> Maybe something went wr
Ben Bacarisse :
> Python opts for
>
> while True:
> c = sys.stdin.read(1)
> if c != ' ': break
I opt for that in C and bash as well.
In fact, when I start writing a loop, I first type:
while True:
Once it is done, I might notice that the loop begins:
while True:
On Mon, 17 Apr 2017 08:52 pm, Steve D'Aprano wrote:
> but research does continue into using gradual typing for optimizations:
>
> http://dl.acm.org/citation.cfm?id=2069175
Another interesting research project into speeding up Jython using type
hints:
http://scholar.colorado.edu/ecen_gradetds/57
Gregory Ewing :
> Marko Rauhamaa wrote:
>> What I notice in my numbers is that about one half of my while loops
>> are "while True", and about a third of my loops are while loops.
>
> Out of curiosity, what proportion of your 'while True' loops are
> infinite? (I.e. no break, return or raise in th
On Tue, Apr 18, 2017 at 1:37 AM, MRAB wrote:
> In Python 3 it's:
>
> c = next(itertools.dropwhile(
> lambda c: c==' ',
> iter(lambda: sys.stdin.read(1),None)
> ))
iter's sentinel should be an empty string.
--
https://mail.python.org/mailman/listinfo/python-list
On 2017-04-18 02:09, Paul Rubin wrote:
Ben Bacarisse writes:
? I get "AttributeError: 'itertools.dropwhile' object has no attribute
'next'" from your example.
Hmm, .next() worked ok for me in Python 2.7.5. Not sure what happened.
Maybe something went wrong with my paste. Oh well.
Coming
Ben Bacarisse writes:
> ? I get "AttributeError: 'itertools.dropwhile' object has no attribute
> 'next'" from your example.
Hmm, .next() worked ok for me in Python 2.7.5. Not sure what happened.
Maybe something went wrong with my paste. Oh well.
> Coming from the lazy language Haskell, I find
Paul Rubin writes:
> Ben Bacarisse writes:
>> c = sys.stdin.read(1)
>> while c == ' ':
>> c = sys.stdin.read(1)
(for the record: I was not suggesting this was how you'd do it but how
you'd be forced to do it in some languages)
> c = itertools.dropwhile(
> lambda c: c==' ',
>
On 18/04/2017 01:23, Paul Rubin wrote:
Ben Bacarisse writes:
c = sys.stdin.read(1)
while c == ' ':
c = sys.stdin.read(1)
c = itertools.dropwhile(
lambda c: c==' ',
iter(lambda: sys.stdin.read(1),None)
).next()
I tried this but it doesn't like the .next.
I wanted t
Marko Rauhamaa writes:
> Ben Bacarisse :
>
>> Marko Rauhamaa writes:
>>> What I notice in my numbers is that about one half of my while loops
>>> are "while True", and about a third of my loops are while loops.
>>
>> I fo[u]nd the proportion on while True: loops surprising. Is there
>> something
Ben Bacarisse writes:
> c = sys.stdin.read(1)
> while c == ' ':
> c = sys.stdin.read(1)
c = itertools.dropwhile(
lambda c: c==' ',
iter(lambda: sys.stdin.read(1),None)
).next()
--
https://mail.python.org/mailman/listinfo/python-list
Marko Rauhamaa wrote:
What I notice in my numbers is that about one half of my while loops are
"while True", and about a third of my loops are while loops.
Out of curiosity, what proportion of your 'while True' loops
are infinite? (I.e. no break, return or raise in the loop.)
--
Greg
--
https:
Steve D'Aprano writes:
> On the other hand, there's Cython. Cython claims *not* to be a JIT compiler,
One of the uses of "JIT compiler" these days is what's sometimes called
a tracing JIT, like PyPy or LuaJIT or the Javascript flavor-of-the-week.
That means it interprets the program while collect
On 2017-04-17, Ben Bacarisse wrote:
> Marko Rauhamaa writes:
>
>> Terry Reedy :
>>
>>> On 4/17/2017 3:11 AM, Marko Rauhamaa wrote:
Here's statistics from a medium-sized project of mine:
while True:34
while : 39
for ... in ...: 158
>>>
>>> As
On 17 April 2017 at 04:00, Steve D'Aprano wrote:
> On Mon, 17 Apr 2017 05:49 am, Dennis Lee Bieber wrote:
>
>> On Mon, 17 Apr 2017 02:48:08 +1000, Steve D'Aprano
>> declaimed the following:
>>
>>>On Sun, 16 Apr 2017 11:57 pm, bartc wrote:
>>>
But people just don't want it.
>>>
>>>Damn straig
Ben Bacarisse :
> Marko Rauhamaa writes:
>> What I notice in my numbers is that about one half of my while loops
>> are "while True", and about a third of my loops are while loops.
>
> I fo[u]nd the proportion on while True: loops surprising. Is there
> something about Python that encourages that
On 17/04/2017 19:02, Ben Bacarisse wrote:
Marko Rauhamaa writes:
Terry Reedy :
On 4/17/2017 3:11 AM, Marko Rauhamaa wrote:
Here's statistics from a medium-sized project of mine:
while True:34
while : 39
for ... in ...: 158
As I posted previously, the ratio
Marko Rauhamaa writes:
> Terry Reedy :
>
>> On 4/17/2017 3:11 AM, Marko Rauhamaa wrote:
>>> Here's statistics from a medium-sized project of mine:
>>>
>>>while True:34
>>>while : 39
>>>for ... in ...: 158
>>
>> As I posted previously, the ratio of for-loops in th
Terry Reedy :
> On 4/17/2017 3:11 AM, Marko Rauhamaa wrote:
>> Here's statistics from a medium-sized project of mine:
>>
>>while True:34
>>while : 39
>>for ... in ...: 158
>
> As I posted previously, the ratio of for-loops in the stdlib is about 7
> to 1.
What I
On 4/17/2017 3:11 AM, Marko Rauhamaa wrote:
Gregory Ewing :
bartc wrote:
Most of my loops start off as endless loops, until I can determine
the actual terminating condition, and where it best goes.
Interesting. My experience is quite different. Most of the loops I
write start off with me thi
On Mon, 17 Apr 2017 04:18 pm, Paul Rubin wrote:
> Steve D'Aprano writes:
>> Since it is *optional*, it is only a hint, not a fact. You can tell the
>> compiler that you believe that n will be an int, but it's not guaranteed.
>
> The runtime could check at the entry to the function that n is an i
On Sun, 16 Apr 2017 02:27 pm, Steve D'Aprano wrote:
> Are you aware that optional static typing CANNOT be used for optimization?
I think I've over-stated that. Considerably. In other words, I was wrong.
As Steve Yegge points out, dynamic languages like Smalltalk and Lisp were,
back in the 1980s,
On Thursday, April 13, 2017 at 10:31:22 AM UTC+1, Tim Golden wrote:
> On 13/04/2017 03:39, Jason Friedman wrote:
> >>
> >> However, it's simply a technical fact: the thing which we moderate is the
> >>> mailing list. We can control which posts make it through from the
> >>> newsgroup
> >>> by bloc
Gregory Ewing :
> bartc wrote:
>> Most of my loops start off as endless loops, until I can determine
>> the actual terminating condition, and where it best goes.
>
> Interesting. My experience is quite different. Most of the loops I
> write start off with me thinking "Now I want to do this for eac
Steve D'Aprano writes:
> Since it is *optional*, it is only a hint, not a fact. You can tell the
> compiler that you believe that n will be an int, but it's not guaranteed.
The runtime could check at the entry to the function that n is an int,
and then it wouldn't have to keep re-checking on the
On Mon, 17 Apr 2017 05:16 am, bartc wrote:
> But it was OK for Steve to 'win' the benchmark by substituting my test
> code with something only vaguely related, and much simpler?
Okay, you're now being obnoxious, and telling lies about me.
What I said was
"FOR WHAT IT'S WORTH [emphasis added],
On Mon, 17 Apr 2017 05:49 am, Dennis Lee Bieber wrote:
> On Mon, 17 Apr 2017 02:48:08 +1000, Steve D'Aprano
> declaimed the following:
>
>>On Sun, 16 Apr 2017 11:57 pm, bartc wrote:
>>
>>> But people just don't want it.
>>
>>Damn straight. Now you get it. It's not about how easy it is to impleme
bartc wrote:
> - describing the various syntax forms;
> - explaining how they differ;
> - tutorials for beginners showing each form;
And you don't have to explain how an endless loop should be written as
'while True', meanwhile advising against using 'while 1'?
You don't have to mention i
On 16/04/2017 19:42, Chris Angelico wrote:
On Mon, Apr 17, 2017 at 4:21 AM, bartc wrote:
Here is a function from some old CPython source that appears to be something
to do with While statements:
static int
validate_while(node *tree)
{
...
Look, no comments! Are you going to castigate the dev
On Mon, Apr 17, 2017 at 5:16 AM, bartc wrote:
> On 16/04/2017 20:00, Chris Angelico wrote:
>>
>> On Mon, Apr 17, 2017 at 4:43 AM, bartc wrote:
>
>
>> Sure! If all you care about is winning benchmarks,
>
>
> The benchmarks should be about comparing things. But they have to be like
> for like.
You
On 16/04/2017 20:00, Chris Angelico wrote:
On Mon, Apr 17, 2017 at 4:43 AM, bartc wrote:
Sure! If all you care about is winning benchmarks,
The benchmarks should be about comparing things. But they have to be
like for like.
Since this was about the effects of type annotations, it would b
On Mon, Apr 17, 2017 at 4:43 AM, bartc wrote:
>>
>> For what it's worth, on my machine (2GB RAM and 1.2GHz CPU) I can add up
>> 100
>> million ints in 14 seconds:
>>
>> py> with Stopwatch():
>> ... sum(range(1))
>> ...
>> 49995000
>> time taken: 14.032116 seconds
>
>
> I'm surp
On 16/04/2017 18:13, Steve D'Aprano wrote:
On Mon, 17 Apr 2017 02:20 am, justin walters wrote:
On Sun, Apr 16, 2017 at 8:46 AM, bartc wrote:
What were the results with Python on your machine?
Well, at first I tried to implement it with a generator. I gave up on
waiting for the program to
On Mon, Apr 17, 2017 at 4:21 AM, bartc wrote:
> Here is a function from some old CPython source that appears to be something
> to do with While statements:
>
> static int
> validate_while(node *tree)
> {
> int nch = NCH(tree);
> int res = (validate_ntype(tree, while_stmt)
>
On 16/04/2017 17:30, Steve D'Aprano wrote:
On Sun, 16 Apr 2017 10:06 pm, bartc wrote:
(The 30 Loc figure is with support for loops /in
general/ already in place, and is for /adding/ a new loop statement, in
this case 'while')
What part of *testing* and *documenting* do you not understand?
On Mon, 17 Apr 2017 03:00 am, Rustom Mody wrote:
> BTW I regard Steven's long list of things that youve missed such as
> regression tests, docs etc to be somewhat off the mark
> To see that try this experiment:
> Just add a feature to python that matters to you along with all these
> requirements
On Mon, 17 Apr 2017 02:20 am, justin walters wrote:
> On Sun, Apr 16, 2017 at 8:46 AM, bartc wrote:
>
>> What were the results with Python on your machine?
>
>
>
> Well, at first I tried to implement it with a generator. I gave up on
> waiting for the program to complete
> after about 6 minut
On 4/16/2017 11:35 AM, Michael Torrie wrote:
On 04/16/2017 07:57 AM, bartc wrote:
But people just don't want it.
/That/ is what surprises me, when people reject things that to me are
no-brainers.
Whereas to me, it is a no-brainer that we are better off *without*
multiple while/loop construct
On Sunday, April 16, 2017 at 7:27:49 PM UTC+5:30, bartc wrote:
> Technically, adding this one feature to Python /is/ trivial,
^
You are not paying attention bart and I am not likely to pursue this beyond this
post. I tried to say as are others that the substantive reasons to reject a
On Sun, 16 Apr 2017 11:57 pm, bartc wrote:
> Yet countless other, far more elaborate features /are/ added all the time.
Indeed. Because they are needed. Because they add functionality that Python
doesn't already have, or seriously improves the interface to that
functionality.
> Technically, add
On Sun, 16 Apr 2017 10:06 pm, bartc wrote:
> On 16/04/2017 03:51, Steve D'Aprano wrote:
>> On Sat, 15 Apr 2017 10:17 pm, bartc wrote:
>
>>> Yes, I'm constantly surprised at this, as such syntax has a very low
>>> cost (in my last compiler, supporting 'while' for example only added 30
>>> lines to
On Sun, Apr 16, 2017 at 8:46 AM, bartc wrote:
> What were the results with Python on your machine?
Well, at first I tried to implement it with a generator. I gave up on
waiting for the program to complete
after about 6 minutes.
After using your code almost exactly I get:
>>> Sum: 1499850
On 16/04/2017 15:22, Chris Angelico wrote:
On Sun, Apr 16, 2017 at 11:57 PM, bartc wrote:
Technically, adding this one feature to Python /is/ trivial, for example,
allowing while: as a synonym for while True:, but preferably using a new
keyword such as loop. Nothing else needs to be touched. An
On 16/04/2017 16:00, justin walters wrote:
On Sun, Apr 16, 2017 at 3:55 AM, bartc wrote:
Example C of the same silly program in Python:
def add(a,b):
return a+b
def testfn():
sum=a=b=0
for i in range(1):
sum += add(a,b)
a += 1
b += 2
print (a,
On 04/16/2017 07:57 AM, bartc wrote:
> But people just don't want it.
>
> /That/ is what surprises me, when people reject things that to me are
> no-brainers.
I simply don't care about these missing loop constructs. Python works
great for what I use it for, and apparently works well for many pe
On Sun, Apr 16, 2017 at 3:55 AM, bartc wrote:
> Example C of the same silly program in Python:
>
> def add(a,b):
> return a+b
>
> def testfn():
> sum=a=b=0
> for i in range(1):
> sum += add(a,b)
> a += 1
> b += 2
>
> print (a,b,sum)
>
> testfn()
>
>
On Sun, Apr 16, 2017 at 11:57 PM, bartc wrote:
> Technically, adding this one feature to Python /is/ trivial, for example,
> allowing while: as a synonym for while True:, but preferably using a new
> keyword such as loop. Nothing else needs to be touched. And it could have
> been done right at the
On 16/04/2017 13:22, Rustom Mody wrote:
On Sunday, April 16, 2017 at 5:36:28 PM UTC+5:30, bartc wrote:
On 16/04/2017 03:51, Steve D'Aprano wrote:
On Sat, 15 Apr 2017 10:17 pm, bartc wrote:
Yes, I'm constantly surprised at this, as such syntax has a very low
cost (in my last compiler, support
On Sun, Apr 16, 2017 at 8:55 PM, bartc wrote:
> On 16/04/2017 05:27, Steve D'Aprano wrote:
>>
>> On Sat, 15 Apr 2017 11:55 am, Rick Johnson wrote:
>>
>>> apparently, the py-devs believe we
>>> only deserve type declarations that do nothing to speed up
>>> code execution (aka: type-hints), instead
On Sunday, April 16, 2017 at 5:36:28 PM UTC+5:30, bartc wrote:
> On 16/04/2017 03:51, Steve D'Aprano wrote:
> > On Sat, 15 Apr 2017 10:17 pm, bartc wrote:
>
> >> Yes, I'm constantly surprised at this, as such syntax has a very low
> >> cost (in my last compiler, supporting 'while' for example only
On 16/04/2017 03:51, Steve D'Aprano wrote:
On Sat, 15 Apr 2017 10:17 pm, bartc wrote:
Yes, I'm constantly surprised at this, as such syntax has a very low
cost (in my last compiler, supporting 'while' for example only added 30
lines to the project).
That's the advantage of writing your own p
Steve D'Aprano writes:
> I don't remember the language, but I remember seeing one generalisation of
> the repeat/do loop that puts the test in the middle, rather than at the
> start or end of the loop. If I remember it was something like:
>
> DO
> setup code # executed once only
> REPEAT
>
On 16/04/2017 05:27, Steve D'Aprano wrote:
On Sat, 15 Apr 2017 11:55 am, Rick Johnson wrote:
apparently, the py-devs believe we
only deserve type declarations that do nothing to speed up
code execution (aka: type-hints), instead of type
declarations that could actually speed up the code. Go
fig
On Sun, 16 Apr 2017 09:48:15 +, alister wrote:
> On Sun, 16 Apr 2017 14:27:28 +1000, Steve D'Aprano wrote:
>
>> On Sat, 15 Apr 2017 11:55 am, Rick Johnson wrote:
>>
>>> apparently, the py-devs believe we only deserve type declarations that
>>> do nothing to speed up code execution (aka: type
On Sun, 16 Apr 2017 14:27:28 +1000, Steve D'Aprano wrote:
> On Sat, 15 Apr 2017 11:55 am, Rick Johnson wrote:
>
>> apparently, the py-devs believe we only deserve type declarations that
>> do nothing to speed up code execution (aka: type-hints), instead of
>> type declarations that could actually
On Sat, 15 Apr 2017 11:55 am, Rick Johnson wrote:
> apparently, the py-devs believe we
> only deserve type declarations that do nothing to speed up
> code execution (aka: type-hints), instead of type
> declarations that could actually speed up the code. Go
> figure!
>
> I'm not a fan of forced st
On Sat, 15 Apr 2017 10:17 pm, bartc wrote:
> On 15/04/2017 03:35, Rick Johnson wrote:
>> On Wednesday, April 12, 2017 at 8:44:30 AM UTC-5, bart...@gmail.com
>> wrote:
>
>> At a minimum, every language should offer
>> the following four loop-forms (using Python semantics):
>>
>> while CONDITIO
On Sun, 16 Apr 2017 12:37 am, bartc wrote:
> What proportion of Python implementations depend on executing byte-code?
My guess is 100%.
Pretty much all modern interpreters of any language execute some form of
byte-code or another. The bad old days where interpreters repeatedly parsed
and execute
On 04/15/2017 08:37 AM, bartc wrote:
> What proportion of Python implementations depend on executing byte-code?
Presumably Nuitka does not depend on any byte code at all. Jython uses
JVM byte codes. Iron Python uses .net VM bytecodes.
While CPython's byte codes do take their form in part becaus
bartc writes:
> 'do', in the original Algol 68 syntax, was part of its 'for'
> statement, where you could leave out the parts you don't need. The
> full syntax is something like:
>
> for var := a to b by c while d do body od
FOR name FROM e1 BY e2 TO e3 WHILE cond DO body OD
The significan
On 15/04/2017 14:27, Marko Rauhamaa wrote:
bartc :
while 1:
body
Why not say it like it is:
while True:
body
but it's more psychological; I don't want to use an idiom to denote an
endless loop, I want to be able to express it directly!
C's:
for (;;)
st
On Saturday, April 15, 2017 at 7:17:55 AM UTC-5, bartc wrote:
> On 15/04/2017 03:35, Rick Johnson wrote:
> > On Wednesday, April 12, 2017 at 8:44:30 AM UTC-5, bart...@gmail.com wrote:
>
> > At a minimum, every language should offer
> > the following four loop-forms (using Python semantics):
> >
> >
bartc :
> Of course, it's possible to overdo it; if you look at Lisp, you'll lose
> yourself in the myriad looping options.
Funny, in Scheme, the only looping construct I use is named-let.
> The former /can/ be easily written as:
>
> while 1:
> body
Why not say it like it is:
wh
On Sat, 15 Apr 2017 10:23 am, bartc wrote:
> On 15/04/2017 00:40, Rick Johnson wrote:
>> * `range(10)` will always produce a list of the _same_ 10
>> integers.
>
> You don't know if 'range' is still a range. If this has been executed
> first, then the answer will be 20:
>
> oldrange=range
>
On 15/04/2017 03:35, Rick Johnson wrote:
On Wednesday, April 12, 2017 at 8:44:30 AM UTC-5, bart...@gmail.com wrote:
At a minimum, every language should offer
the following four loop-forms (using Python semantics):
while CONDITION:
doSomething()
for VALUE in COLLECTION:
On Thursday, April 13, 2017 at 1:32:28 AM UTC-5, Steven D'Aprano wrote:
> On Wed, 12 Apr 2017 14:38:52 +0100, Ben Bacarisse wrote:
> > Steve D'Aprano writes:
> >> On Wed, 12 Apr 2017 03:39 am, Paul Rubin wrote:
>
> [...] Indeed, and this is a very common phenomenon:
> features which "ordinary" prog
On Thursday, April 13, 2017 at 1:32:29 AM UTC-5, Gregory Ewing wrote:
> Jussi Piitulainen wrote:
> > Traceback (most recent call last):
> > File "/dev/fd/63", line 37, in
> > SanityClauseException: code is blatantly sub-optimal
> >
> > As far as I know, no language does that. Because reasons?
>
On Wednesday, April 12, 2017 at 8:44:30 AM UTC-5, bart...@gmail.com wrote:
> On Wednesday, 12 April 2017 12:56:32 UTC+1, Jussi Piitulainen wrote:
> > bartc writes:
> > >
> > > These are straightforward language enhancements.
> >
> > FYI, the question is not how to optimize the code but how
> > to
On Wednesday, April 12, 2017 at 4:57:10 AM UTC-5, bart...@gmail.com wrote:
> On Wednesday, 12 April 2017 07:48:57 UTC+1, Steven D'Aprano wrote:
> > On Tue, 11 Apr 2017 21:10:56 -0700, Rick Johnson wrote:
> > >
> > > high level languages like Python should make it
> > > difficult, if not impossible
1 - 100 of 240 matches
Mail list logo
