Why not allow empty code blocks?

[BartC]

On 03/08/2016 14:31, Chris Angelico wrote:
> On Wed, Aug 3, 2016 at 11:23 PM, BartC <bc at freeuk.com> wrote:
>> On 03/08/2016 09:58, Steven D'Aprano wrote:
>>
>>> Python is sometimes described as a Lisp with more sensible syntax, so its
>>> not
>>> surprising that it is relatively simple to translate Python to Lisp and
>>> visa
>>> versa.
>>
>>
>> Translating Python would be easier if everything was implemented as Python.
>> But sometimes you try to find a .py import module and it doesn't seem to
>> exist anywhere. (sys.py for example).
>>
>> I would like to see how such references are translated to Lisp.
>
> Ultimately, you _cannot_ implement everything in Python, unless you
> create some sort of crazy fudge like having function pointers with
> real language support, in which case you're writing C code. Some
> modules have to be implemented in the host language (C for CPython,
> Java for Jython, etc), in order to provide lower-level functionality.
> You probably *could* implement the whole math module in pure Python,
> but you don't want to; and cryptography, likewise, you theoretically
> could implement in pure Python, and you'd get the same return value,
> but you risk opening yourself up to timing-based attacks.
>
> How, from Lisp, would you call on OpenSSL or another lower-level
> library? Or do you have to reimplement everything? What about simple
> things like opening files, how do you do that without native code?

The approach I use is to provide direct access, from the language, to 
external .dll or .so files.

Then it is possible, with a suitable interface *written in the byte-code 
language*, to directly call C's fopen() for example.

I believe Python also has a means of directly calling DLLs, so that in 
theory its file system can be build on top of the C runtime (msvcrt.dll 
or Linux' equivalent).

There still needs to be some magic support for this mechanism, but more 
can be written in Python.

-- 
Bartc