I get a feeling that most of the folks on this list have Alex as the first name :)
Here's my problem. I am convinced that PicoLisp is my final language but unfortunately I am unable to use it on Windows where I have to spend most of the time :( I just got it working with SDL on windows a couple of weeks ago (It's on my github page but I have not talked about it since it needs polishing :) ) It would be great if picoLisp could have a OS abstraction layer that normalizes all the POSIX calls - while P in POSIX is meant to be portable - my personal experience has been that there are subtle differences between HPUX/AIX/Solaris and GNU/Linux - ofcourse this personal experience is from 15 years ago so I am not sure of the current situation. One could then implement the OS abstraction layer on windows and have picoLisp running on windows too. Actually, its not just windows - this approach could perhaps make it easier for other platforms too - but since most new platforms support GNU/Linux these days, perhaps there is not a strong motivation there. Anyway, I agree with your statements Alex. Regards, Kashyap On Sat, May 16, 2020 at 10:15 AM Alex Gilding <alexg.n...@gmail.com> wrote: > With a system like miniPicoLisp, like any ultra-light footprint > interpreter - does a general purpose FFI really gel with the design? > > IMO the way people normally use interpreters in this weight class (see > also, Lua, Chibi, picoC, Jim, ...) is to embed them: i.e. the interpreter > becomes a first-class part of the hosting C (or equivalent) program. In so > doing it gains first-class access to all of the host's API on the runtime > level, and instead of using a dynamic API load native functions at runtime, > it has the ability to statically expose them as part of what effectively > becomes a domain-specific extension of the interpreter that provides the > useful parts of the program's internal C API as "builtins". > > This isn't necessarily a very picoLisp way to structure a program - I get > the impression picoLisp is usually the "host" by design - but I wonder > whether, if you avoid that and try to make miniPicoLisp the conceptually > freestanding language, you'd end up erasing most of what makes it distinct > from the main picoLisp anyway. > > AlexG > > On Sat, 16 May 2020, 16:43 C K Kashyap, <ckkash...@gmail.com> wrote: > >> Oh btw Andras, >> The main reason I would love those features in pil32 (C) is so that I can >> more easily translate it to miniPicoLisp >> I really want to be able to have a system that requires nothing more than >> C :) >> Regards, >> Kashyap >> >> On Fri, May 15, 2020 at 10:53 PM C K Kashyap <ckkash...@gmail.com> wrote: >> >>> Absolutely!!! >>> If that is done - I believe there is no reason not to have pil64 in C >>> too right :) >>> Regards, >>> Kashyap >>> >>> On Fri, May 15, 2020 at 9:55 PM Andras Pahi <pa...@t-online.hu> wrote: >>> >>>> Hi, >>>> >>>> If you are still interested in native/lisp in picolisp32 then I am >>>> working to support the pil64 >>>> features in picolisp32. The development branch of >>>> https://github.com/pahihu/picoLisp >>>> just missing the coroutines (stay tuned), and builds on 64bit/32bit >>>> targets. >>>> It uses libffi for the native C calls. >>>> >>>> Regards, >>>> Andras >>>> >>>> On 2020. May 8., at 16:36, C K Kashyap <ckkash...@gmail.com> wrote: >>>> >>>> Thanks Alex, >>>> I think I'll try and see if I can get a simple SDL callback to work >>>> with miniPicoLisp - that way, I can really understand the issues better. >>>> If I remember correctly - pil21 initially did not have the POSIX >>>> requirement. Is there a way to get older versions of pil21 (I know that it >>>> is a strange request for a POC :) ) >>>> >>>> Thanks Tomas for your ffi link. >>>> >>>> Regards, >>>> Kashyap >>>> >>>> On Fri, May 8, 2020 at 2:24 AM Tomas Hlavaty <t...@logand.com> wrote: >>>> >>>>> Hi Kashyap, >>>>> >>>>> C K Kashyap <ckkash...@gmail.com> writes: >>>>> > I am now trying to figure out how to do FFI min miniPicoLisp and I >>>>> > realized that only pil64 has native/lisp support. Is there any reason >>>>> > it could not be done in the 'c' implementation of pil32? I just >>>>> wanted >>>>> > to make sure that there is no "impossibility" about attempting to >>>>> port >>>>> > the native/lisp functions to miniPicoLisp. >>>>> >>>>> here is an example of ffi with minipicolisp: >>>>> https://logand.com/sw/mplisp/files.html >>>>> >>>>> Cheers >>>>> >>>>> Tomas >>>>> >>>>> -- >>>>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >>>>> >>>> >>>>
