newlispfanclub.alh.net

Hi to all,

I'm having a strange error with REPL in a couple of last releases; when I try to type a multiline expression, I'm receiving "ERR: missing parenthesis", e.g. .
Anyone knows how to solve this? Besides this obvious limitation (typing directly in REPL), my Vim/Screen setup for live evaluation becomes pretty unusable.

I'm running this on MacOS X 10.6.3 (nl-10.2.8) and tried with and without readline/utf8 support and their combination. The same happens on my linux box.

Btw. readline version does not match (or highlight) closing parenthesis in REPL; is this intentional? I know how rlwrap will provide solution for this, but what is the point of having readline support then ;)

Thanks.
Denis.

Welcome.

For multiline inputs, you'll have to do something like: Check http://www.newlisp.org/downloads/newlis ... xpressions

Thank you Kazimir for this tip; I missed it somehow :)

But... this is still strange to me, as readline is capable to accept multiple lines. Also, this makes a little bit cumbersome for sending code from environment (I can hack a vim script or rlwrap script to do this, but this solution seems to me quite strange). Does this mean how evaluator is not capable to accept multiple lines without additional markers?

As you might expect, this is a well-known aspect of newLISP:

http://newlispfanclub.ryon.webfactional ... 198da93af3

Here at one end of the newLISP spectrum, I use a text editor for all newLISP work, including evaluating small pieces of code - I find the command-line 'REPL' barely usable for anything except quick tests of short commands, and I don't enjoy typing more than a few words, since there's no parenthesis balancing, syntax prompting or colouring. It gets even less useful when you use the debugger... However, I don't claim to be a programmer, so I'm probably missing a lot of advanced features that serious programmers are expecting to find.

Aaahh, thanks for the tip and link :) I searched a couple of times through the forum, but seems I was looking via wrong search terms.

But, this solution is still quite odd to me, and even worse, it doesn't work. Please look at these examples: and here REPL hangs expecting something (not sure what) for input: Please Lutz, I found newLisp quite usable and irreplaceable in a number of occasions but, can we get at least somehow usable REPL ;)? Hacking readline (as you noted in given link) to append tags is IMHO wrong solution, as newLisp can be compiled without readline, which is my case for a couple of installations on a few old platforms.

> I find the command-line 'REPL' barely usable

Me too :(

Denis.

The fine manual says:

Multiline expressions can be entered by bracketing them with [cmd] and [/cmd] tags, each on separate lines.

Perhaps that's the problem.

I think it would be good if the built-in command-line reader were improved - i think Ruby and Python, and probably a lot of other languages, have something similar, and it makes sense to consider improvements if newLISP is falling too far behind. Ideally it could be made an opt-in command line switch, so that it would not be necessary to burden the newLISP executable with additional code unless required. That way, newLISP would still start up quickly when the command-line reader facilities were not required.

Remember that newLISP is 'stripped down to easy-to-learn essentials' - features have to work hard to justify their inclusion... :)

I tried to explore command-event hook to inject tags before they get into reader, but at the end I ended up rolling additional tags to mark when expression was ready for evaluation, which is another wrapper around the given problem: still I need to write additional Vim script for it. But, this will also not be possible, as screen is not able to accept large content (when sent from Vim) and expression needs to be sent in parts... which will not be correctly recognized from REPL.

Anyway, guys thank you for replies and explanations. Although I would like the author himself participated this tiny discussion, looks like he nicely ignored all of this. Who knows, maybe this bug (as it obviously is) is not worth of any discussion, because it's solution probably does not fit into his vision how things should work.

dig666 wrote: Anyway, guys thank you for replies and explanations. Although I would like the author himself participated this tiny discussion, looks like he nicely ignored all of this. Who knows, maybe this bug (as it obviously is) is not worth of any discussion, because it's solution probably does not fit into his vision how things should work.

More likely he is just insanely busy. Lutz is usually almost instant with his responses, even to silly questions. He's very involved with the forum, and is very approachable...

Our newer members might not be aware that this group is not a project of NewLISP, Nuevatec, nor Lutz Mueller. We're darn lucky that he spends time with us at all!

Posts attempting to shame one another into a response may be deleted by the moderators with the full support of this management.

dig666 wrote:IAlthough I would like the author himself participated this tiny discussion, looks like he nicely ignored all of this.

But http://www.newlisp.org/downloads/develo ... 0.2.11.txt suggests otherwise... :)

Time didn't permit me to read this thread thoroughly, but I use both vim and emacs and have
done considerable scripting for each.
If you use linux (and I presume that you may do the same on OS X), in vim
you can
1)Grab some text in visual mode
2)Feed it to a temporary file
3)Evaluate the temporary file
4)Read the output into a vim buffer (example: the same as where you captured the text).
Thus you can simulate the emacs *scratch* buffer without using readline and REPL.
I haven't done this for newlisp, since I use emacs for newlisp and employ comint mode,
but I have done a utility or two in vim that that employs the process I've outlined above.

Let me know and I could work with you on it. Or send the existing
code, which could then be modified.
cheers
tim