Unsubscribe
Re: String syntax, or Transient Symbol syntax
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 Burger a...@software-lab.de wrote: Hi Dave, I am having some trouble working with Strings or Transient Symbols. (I'll call them strings for now.) ... ^(a+)\) In picoLisp, I must enter that as: \^(a+)\\) That's right. This is the syntax of the PicoLisp reader. See, the escaping syntax is a pretty heavy burden for the types of strings I work with... So, I considered using a reader macro. I imagined something like: (re-handler /^(a+)(.*)'.*(\)+)/ nd here's some input! :) -- (re-handler \^(a+)(.*)'.*(\\)+) nd here's some input! :) A read macro won't help, because it is still based on 'read', the PicoLisp reader synax. A read macro reads an expression, evaluates it, and returns the result to the reader. ..Then I discovered that we don't have a defmacro. (I've read previous discussion about macros and I accept Alex's stance.) A macro won't help either, because it also processes the data *after* they are read by the Lisp reader. And though you can do everything a macro would do in PicoLisp with a normal function, it also operates on s-expressions and not on the input stream. Any advice for implementing some sort of special case for /strings/, which would be just like strings but with different escape mechanics? On the *application* level, you can do everything you like, using low-level I/O functions like 'char' and 'line'. I think the problem is that you want to change the *language* level, and the reader is the core of the language (read/eval/print). I see src64/io.l contains (code 'readA_E) which handles reading strings. But I don't understand this assembly code. Yes, that's the right place to change the language :) The normal REPL (i.e. the 'load' function) doesn't operate on raw input data. What you could do is write you own top-level REPL, using e.g. 'line' and 'eval' directly. Another possibility is using 'pipe' and perhaps external tools to process the input stream. In any case you need to get hold of the data and process them *before* they are seen by the reader. ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Transient symbol with a single backslash
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 Gragnic christophegrag...@gmail.com wrote: Hi, I'm a long time fan of Picolisp but never went through the whole docs, and never found a practical use for it, until today! Well, I'm not using the real Picolisp but EmuLisp but I asked Jon and in fact his Emulisp acts as the real Picolisp regarding my problem. As you can see here: http://profgra.org/lycee/mathjax.html I'm trying to make my students write LaTeX or LISP to typeset formulas. I need to output a transient with a single backslash. The problem is that if I write my transient like this: a backslash:\\, it may contain a backslash internally, but is printed/returned so to be read again (my guess). I make my system work with an ugly «text = text.replace(, \\);», but I'd be curious to know the solution to my problem. Christophe -- http://profgra.org/lycee/ (site pro) http://delicious.com/profgraorg (liens, favoris) https://twitter.com/profgraorg -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe
Re: Backtrace with 'trail' and 'up' (64-bit)
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 big thing :) If the first class backtrace would be modifiable programmatically, it would allow for a whole new range of control structures, in some aspect possibly going beyond what's implementable by call/cc. That would be a big thing. - an extension to 'up' which returns the current expressions (or the nth expression if a numeric argument is passed) Note that 'up' now allows to implement things which were until now only possible in FSUBRs (i.e. on assembly level), because the CAR of the expression (the function or method) are not passed to EXPRs or FEXPRs. I proposed this feature on Jan 26, 2012, so at least for me this is also a long-missed feature. This will among other things allow redefinition of the message passing (or method execution) function, and a 'defmacro' that is cleaner than my example from a week ago. Question: How hard would it be to extend 'up' the same way in pil32? -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: `rd' behavior
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 Arguments (cdr (reverse (cdr (reverse (argv)) (for A Arguments (prinl A)) (bye) This makes sure there will never be a dash as first argument, or a plus sign as the last. A little cumbersome perhaps, but it is caused by how the picolisp interpreter works. -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: bug in daemon?
'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 arguments). This is generally not possible, due to the way FSUBRs are executed by the interpreter. Right, FSUBR to EXPR conversion isn't possible. I guess it would be possible to convert FSUBR to FEXPR, though. Example: : (de fexpr (F) (set F (list 'X (list 'eval (list 'cons (cons 'quote (box (getd F))) 'X))) ) ) - fexpr : (fexpr 'while) - (X (eval (cons '$268284617 X))) : (setq while (list (car while) '(prinl while called) (cadr while))) - (X (prinl while called) (eval (cons '$268284617 X))) : (setq a 3) - 3 : (while (gt0 (dec 'a)) (prinl @)) while called 2 1 - 1 And since SUBR's are a subset of FSUBR's, the fexpr conversion could be used for both. Would performance suffer? -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Meta key in PicoLisp program
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 welcomed contribution. -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Subscribe
Hello Axel Svensson svenssona...@gmail.com :-) You are now subscribed -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
bug in daemon?
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)) (prinl @)) 2 1 - 1 : (daemon 'while (prinl while called)) - (@ (prinl while called) (pass $268284695)) : (setq a 3) - 3 : (while (gt0 (dec 'a)) (prinl @)) 3 while called # infinite loop -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
PicoLisp macros
On Mon, Jan 23, 2012 at 11:23 AM, Imran Rafique im...@rafique.org 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 knowledge that I can effectively re-arrange the syntax of certain operation sequences to forms that I prefer. You call for a separate macro-expansion phase, but what you really want is the runtime performance. I believe it is possible to achieve this runtime performance without the ugliness that would be introduced with CL style macros. Let me explain the ugliness first, and then the solution. IMHO, CL style macros would be ugly in picolisp because there is no way to tell code from data. Suppose you have a quoted list beginning with a symbol defined as a macro. If it is expanded as a macro, you'll never feel safe when quoting a list that's supposed to be data, but if it's not expanded you won't be able to use quoted lists to pass code into other functions, at least not without feeling the agony of the supposed runtime penalty. In a language where lambda is quote, this would be very sad indeed. There are several additional ugliness aspects I won't mention for the sake of brevity, just think CL vs PicoLisp. Now, the proposed solution: Picolisp style FEXPRs have the ability to not only read the argument list unevaluated, but also modify it. These modifications are preserved in the loaded code until next time the function is called from the same place in the code. This is how 'job' environments work. Picolisp style FSUBRs (a C compiled function) on the other hand can read and modify the entire form. This allows them to modify not only the argument list (the cdr of the form) but also the functional expression of the form (the car). I propose this ability is given to FEXPRs as well. A macro would then be a function that alters the car and cdr of it's own form and then evaluates it. This type of macro will work inside quoted code without disturbing quoted data, since it will expand the first time it is executed. I believe this method would preserve the simplicity of picolisp, since macros are not introduced explicitly - only the possibility of rolling your own macro engine is added. This addition to the language would also open up many interesting possibilities other than macro engines. I have used this technique before (in picolisp, with an ugly workaround,) to achieve some things with this type of... let's call it lexical reflection. In short, it would give FEXPR's a power they now lack compared to FSUBR's. If this ability is given to FEXPR's, anyone could make their own 'defmacro'. Macro expansion would still occur once every runtime, but not more than once. Also, unnecessary macro expansions (of forms that won't be executed anyway) will never occur. Example of a form-altering function (not tested, of course): (de loop X (set *FORM 'prog) (con *FORM (apply circ X)) (eval *FORM)) This defines an eternal loop as a macro expanding to a prog carrying a circular body. I don't necessarily propose this feature is introduced with a variable *FORM as in the example above, but any other way I can think of seems just as ugly. -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
