Why not allow empty code blocks?

bart4858 at gmail.com bart4858 at gmail.com
Mon Aug 1 09:19:39 EDT 2016


On Monday, 1 August 2016 11:12:30 UTC+1, Steven D'Aprano  wrote:
> On Monday 01 August 2016 18:05, bart4858 at gmail.com wrote:
> 
> > You think that my nearly 30 years' experience of designing interpreted
> > languages and writing fast bytecode interpreters doesn't make my opinions
> > have any more merit, that's fine.
> 
> If you are the only one who has ever seen or used these fast bytecode 
> interpreters, then they might as well not exist, in which case, no, your 
> opinions have no merit.
> 
> No offense intended Bart, but for all we know every single one of your 
> benchmarks are faked, your interpreters are buggy pieces of garbage, and for 
> all your self-promotion, your code wouldn't survive more than six seconds of 
> peer review.

Sure. I can't pretend the implementations are wonderful. But I think the ideas are good and they would make fine little languages when seriously implementated.

Not that it bothers me because I've sold $millions of software implemented 100% in these 'toy' languages (and versions from 20+ years ago too).

(If you want to try something out, go to:

https://github.com/bartg/langs

Download the interpreter pcc32.exe (a Windows binary, but I remember it seemed to work under 'wine' in Linux). And test program jpeg.bc (a binary bytecode file).

Run as pcc32 jpeg file.jpg (or as wine pcc32 jpeg file.jpg). If it works, the image will be displayed.

The sourcecode for jpeg.bc (its main module) is in jpeg.q. (jpeg.m is a separate static language version.) I don't have the Python version to hand, but that has been posted in the past (and which you have already commented on!).

There is also qq.bc, a bytecode compiler. Run as pcc32 qq filename.q, but I haven't provided libraries so only simple programs can be compiled.

(Note that pcc32.exe is not accelerated; that version is 2-3 times faster on this test.)

I'm working at the moment on a version that works like Python, directly on source code rather than precompiled bytecode. But it needs to be fast enough so I'm aiming for a 1M lines per second compilation speed; I've managed 0.8-0.9Mpls so far on real applications.)

-- 
Bartc



More information about the Python-list mailing list