Re: Builtin Interpretation

"Philip Herron" <herron.philip@googlemail.com> wrote in message
> I am getting on much better with my programming language i am making
> at the moment, when i get it to a decent state I'll send around the
> link.
>
> Anyways, this doesn't affect me but i was thinking about interpreters,
> say you have a programming language which needs to like read/write to
> a file or otherwise some System interface call, so for that
> programming language the library for doing that is probably written in
> its own language, but when it comes down how does it exec:
> fopen()... or otherwise...
>
> Or more precisely how does it know to do such a thing, is it that
> there is a special built-in keyword which the interpreter picks up to
> know hey we need to do 'X'. Thats one way i think it could be done,
> but is that the way most things do it? I need to do some more reading
> into interpreted languages.


Under Windows, the OS (and also the C runtime) can be called via DLL
interfaces, so by arranging a way of calling DLL files, it's easy to
make all these essential system calls.


In one of my interpreted languages, these declarations look like:


library "crtdll"
...
clang function fopen (istring,istring)int


library "kernel32"
...
windows function DeleteFileA <erasefile> (istring)int


(istring means something like char*, and maybe that library should be
msvcrt.dll..)


This provides a mechanism to call /any/ dll functions, independently of
whether the interpreter is aware of them.


But if the interpreter is coded in C for example then C runtime calls can be
statically linked in, and Windows calls can also be taken care of. Then yes
there can be a list of standard, built-in function calls that the
interpreter understands.


(However an interpreted language might need a softer, more tolerant
interface than is provided by raw C or Win32 functions...)


--
Bart

Return to the comp.compilers page.
Search the comp.compilers archives again.