I once wrote my own top-level REPL, if I remember correctly it was
compatible with picolisp syntax but also had the capability of adding
reader macros in the way OP desires. Let me know if you're interested, as
it might take me a while to dig it up.
On Wed, Nov 26, 2014 at 8:05 AM, Alexander Burge
Hi,
If you need to output something that isn't 'read' readable, then you're
trying to output something that isn't lisp code. If that is the case, use
the functions to output text rather than code.
(prin "(This 'is (not) \"\\code\" ...)")
/Axel
On Fri, Jan 24, 2014 at 10:27 PM, Christophe Grag
Hi Alex,
I am not a Mac user, sorry. I'm mostly on Linux i386 and Windows i386,
including legacy OS's (for work).
However, I support the idea of focusing on asm-pil64 ports rather than
C-pil32 extensions. And as we said earlier, asm-pil32 is a project that
would allow us to get rid of C-pil32 ent
> we cannot (as in pil64)
> simply push the runtime expression onto the stack before the call, and
> pop it off afterwards.
How about pushing the expression to a global variable?
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
> for the 64-bit version at last we have a long-missed feature: A
> substantial backtrace mechanism.
Great!
> - a new function 'trail', which returns the complete backtrace as a
> list. Staying with the hype-terminology, we may call this a "first
> class backtrace" ... OK, just kidding, no bi
Also, a + at the end of the command line is special; it turns on *Dbg
and is not included in (argv).
> > bare dash. is there any way around it?
Make a wrapper like this:
#!/bin/bash
/usr/bin/picolisp /usr/lib/picolisp/lib.l file.l +++ "$@" +++
Then in file.l, remove the extraneous +++:
(setq A
> GNU readline library is bigger than the whole PicoLisp interpreter. So
> it didn't feel right to link with it.
Probably right feeling there. In production, command line interaction
might not even be used at all. But the option is nice, so if someone's
willing to tweak readline.l it would be a we
> 'expr' converts a SUBR function (i.e. a function written in C or
> assembly which evaluates all its arguments) to an EXPR (a Lisp level
> function).
OK, so it's not built for FSUBR conversion.
> Unfortunately, it doesn't work with FSUBR functions (C or asm functions
> _not_ evaluating all argum
Hi!
I noticed the 'daemon function does a fine job distinguishing builtin
C functions from lisp functions. However, it redefines the function to
evaluate all arguments, rather than letting the function decide for
itself. Here is an example transcript:
: (setq a 3)
-> 3
: (while (gt0 (dec 'a)) (pr
Hello Axel Svensson :-)
You are now subscribed
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
On Mon, Jan 23, 2012 at 11:23 AM, Imran Rafique wrote:
> I think the one thing which does bother me though, is the lack of a separate
> macro-expansion phase. Sure, fexpr's give you what macro's do, at runtime.
>
> But one of the key things which make me feel comfortable in any lisp is the
> kno
12 matches
Mail list logo
