Re: initial lang spec: SXIL...


"Harold Aptroot" <harold.aptroot@xxxxxxxxx> wrote in message
news:60127$49adbb9a$53558f0b$18744@xxxxxxxxxxxxxxxxxxxxxxxxxx
"cr88192" <cr88192@xxxxxxxxxxx> wrote in message
news:gok848$a1p$1@xxxxxxxxxxxxxxxxxxxx

[...]
the reason for not using Lisp as such, is that I don't control the
implementation of most Lisp's, and also that most serious Lisp
implementations aren't exactly really designed to compile somewhat
non-Lisp languages (such as C, C++, C#, Java, ...).

would need a Lisp with: full JIT, strong FFI support, usable as a
library, ... and even though C# and Java could probably work effectively
on a Lisp-style core, C and C++ would probably not (given primarily that
they like using pointers for everything, and depend somewhat on how the
underlying memory is organized, both of which would be problematic...).


whereas, even for its apparently lispiness, the main point of this
language will actually be mostly to handle C# and Java...

[...]

Well, for Java I could see a pointerless approach work, but for C#? It's
possible* (see below) to write "nearly C++" in C#, that is, use pointers
for everything and depend on the layout of structs.
Only you'd have GC, interfaces instead of virtual inheritance, and some
other things.
I know you didn't actually say pointless, but you raised concern about the
pointeres in C and C++, so I'm raising it for C#.


for a proper Lisp, it is an issue...

however, my IL has pointers, and in fact the most novel thing of the IL is
the interpreter, but the code being compiled is far more mundane...


* not many C# programmers throw pointers around like rice on a wedding,
but it's possible to do so. Especially interop code, GDI code and weird
hacks depend on it. Even BitConverter uses pointers to type-pun a double
to a long.

yes, well, I wasn't really saying that one would be making use of 'unsafe'
on a Lisp style core (very possibly, one could get by making the compiler
complain and refuse to work, while still being standards conformant, since
an implementation is not "required" to accept unsafe code as such...).

but, in my case, there is no problem, since I am not using a Lisp-style
core, rather a C-style core with a bunch of extra features tacked on (such
as GC, exceptions, ...).


the big hairy issue though is just how to handle exception handling...

I started implementing an idea, but it has an silly issue:
the mechanism is structured in such a way as that the try block has to
finish successfully at least once before the handler can be properly
registered.

this means that if the first time a piece of code is run, it throws an
exception, then the handler will fail to catch it...

this issue is stupid (and would likely break many simple introductions to
exception-handling), but shouldn't really be too much of a problem in
practice...


a compiler could technically implement a hack to fix this, namely that it
could "prime" the exception handler by first jumping over the try block
(thus reaching the end of the try block), and then jumping back to before
the try block, and not jumping over the try block or jumping back this time.

in C:

static int _primed=0;
void *p;

....
L0:
p=dyllBeginTry();
if(!_primed)goto L1;
try...
L1:
p=dyllEndTry(p);
if(!_primed) { _primed=1; goto L0; }
if(p)
{
catch magic...
}
....

however, due to the limited nature of preprocessor macros, this issue
couldn't be glossed over in C... (or at least not restricting it to there
being only a single exception handler per function).

(actually, a compiler need not have this issue to begin with, as it can know
up-front where the beginning and end of the try block is, ...).


an alternative considered option is to always jump back to the start, but
this is less desirable.

actually, if the C-level interface is restricted to 1 exception handler
per-function, one can actually jump to the start and have it come out the
end. this would involve creative use of macros... (but this also messes
stuff up...).

groan... this kind of thing is why I don't yet have working exception
handling...



.

Relevant Pages

  • Re: Java connected Lisp
    ... versions of GNU Classpath and SBCL, ... Invent a nice and fast interface for calls from Lisp to Java and back. ... The trick could be to hack the compiler so that it recognizes accesses ... Rewrite the "compiler" ...
    (comp.lang.lisp)
  • Re: Reflections on a classic Lisp Paper
    ... its Lisp-1 semantics than defmacro, but would not serve CL as well. ... fexprs into those languages. ... this was the Lisp Machine's philosphy that led to offering ... do changes that the compiler cannot know, ...
    (comp.lang.lisp)
  • Re: Which programming language is better to start
    ... How does Lisp handle monomorphic types? ... If you don't specify a variable to have a type then the compiler ... ML does a lot of pattern match optimisations which, ... These operation would be done by representing the data as lists ...
    (comp.programming)
  • Places=lvalues and Pop11 (was months ago: Requesting advice how to clean up C code for vali
    ... there are equivalence classes of values modulo ... In fact the optimizing compiler could eliminate the ... character, or EBCDIC character, or IBM-PC character, or Latin-1 ... and I'm pleased you've essentially adopted the lisp ...
    (comp.lang.c)
  • Re: The origins of CL conditions system
    ... Machine experience explaining the Lisp Machine error handling. ... languages with continuable exceptions (including Mary Fontana from TI ... Why can't I resume after catching an exception? ... exception handling chapter of The Design and Evolution of C++. ...
    (comp.lang.lisp)
Loading