Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - lotabout

Pages1
#1
newLISP in the real world / Re: `string' generates [text] [/text] markup instead of quot
April 21, 2013, 12:07:54 AM
I've tested again using other source strings, and the error occurs again.

It seems that this error is not caused by the `string' command, but the representation of long string with quotes.



That is, we have to represent long string in the format [text] long string [/text] or {long string} instead of "long string"(with quotes), I've changed this representation and it works all right.



Something I've tested:
Code Select
(eval-string {(setq str [text]...(long string)...[/text])})
or (eval-string [text] (string {...(long string)...} ) [/text])

both works fine.



So there must be something strange in the newlisp scanner which might not recognize long string with quotes?



And sorry for just noticed this feature has been described in the manual.

Is there any consideration in choosing this representation? I just felt a little inconvenient with the inconsistency.
#2
newLISP in the real world / Re: `string' generates [text] [/text] markup instead of quot
April 20, 2013, 07:13:59 PM
I just found that it directly captures the ouput of newlisp from stdout, I will search for some other ways to solve.



Anyway, I encountered another problem, maybe a bug?

it's that read-expr and eval-string will report
QuoteERR: string token too long : ...(some string)...
 if the length token is greater than about 2052.



Is this behavior expected? (nothing mentioned in the manual)



Example: some junk text.
Code Select
(eval-string "(string "abc asldfjazpxucvbzixuvbyzociuvbzoicuvbzoixuyvcozixucvyjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjsssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss")")
Will cause this error.
#3
newLISP in the real world / `string' generates [text] [/text] markup instead of quotes
April 20, 2013, 08:06:47 AM
Normally, functions string will wrap the contents with quotes, just like:
Code Select

(string '(a b c))
=> "(a b c)"


but when the text becomes too long, then it will wrap it with [text][/text] markup instead of quotes("). Is there a way to keep using quotes?


Code Select
(string (symbols))
=> "(...)"
instead of
Code Select

(string (symbols))
=> [text]( ... )[/text]

PS: I'm trying to integrate slimv with newlisp, and has to send the text in the quoted format, but the behavior of `string' differs.
#4
newLISP newS / Re: Built-in, unlimited precision, big integer arithmetik
April 13, 2013, 06:47:02 PM
Thanks Lutz.



It's very nice to feel that the tool in hand becomes much more powerful.



Works all right under Linux for now.
#5
Whither newLISP? / Re: Howto Solve Context Collision
March 22, 2013, 07:10:40 AM
This trick works!



And I think we should always use this trick when using a context as a data

container inside a module.



Thanks again for being so patient. And surely I will stay with newlisp, it is

just amazing.
#6
Whither newLISP? / Re: Howto Solve Context Collision
March 21, 2013, 12:02:40 AM
Thank you very much Lutz.



Now I have more confidence in using dynamic scope.



And understand that we can avoid variable capture by putting macros(fexprs) into a seperate context, and use it inside another context. Without interactions, no variable caputure will ever happen to macros(fexprs).



Just for discussion, consider the follwing situation:



Now we have this convension when writting modules(all I can think up):

1. segregate macros. => put them into a seperate context.

2. wrap all codes with a context. => i.e. the name of the module.

3. use only one context(which is specified by No.2) except those used as data

containers(such as dict/hash table)



And what if two developers use the same contex name for different

purpose? Here, we use contexts as data(dict/hash table, etc.) inside

another global context(to specify module name). Suppose developer A use the

context 'dict' to store (word

explanations) pairs, and developer B happen to use the same context for holding

(word frequency) pairs. Now we have to use both modules, because these two

modules will affect the other by operate on the same context 'dict', both will

fail to some extent.



How to deal with this one?



I have little experience of joinning large projects, but I do believe with the

modules for newLisp increasing, there will be a name collision. Of course we

can have all contexts as data named with a prefix such as "A-dict" or something

like that, which I believe is easy and will work, besides, can we prevent this

from happenning instead of fixed it as a bug?
#7
Whither newLISP? / Re: Howto Solve Context Collision
March 19, 2013, 11:23:26 PM
Quote from: "Lutz"Use only one context per module file. Different programmers maintain different contexts. The MAIN context is the only place where other contexts should be loaded and controls the main organization of the program and is maintained by a lead programmer. No context should redefine functions during runtime in contexts not maintained by the same developer.


Thanks for quick reply.



Using only one context per module file is a good convention. But in this

case, there won't be an easy solution of solving variable capture when defining

macros(in a module).



Also, that means we are not allow to use context as a 'dict' or 'hash table'

when writing modules.



How to deal with this situation?
#8
Whither newLISP? / Howto Solve Context Collision
March 19, 2013, 09:45:17 PM
I am new to newLISP, and just can't find out how to solve this problem.



As we know, we can surround a macro to avoid variable capture.

But if we write two diffierent modules without knowing the other one, we might

encounter a context collision, i.e. useing the same name for context.



here is an example:



In module 'A', we define a macro 'my-set' and put it in context 'my-set'(just to illustrate).
Code Select

; A.lsp
(context 'my-set)
(define-macro (my-set a b)
  (set (eval a) b))
(context MAIN)
(context 'A)
(define (my-test x)
  (letex (x x) (my-set:my-set 'y x)))
(context MAIN)


And now we write module 'B' without recognizing the existence of module 'A'.
Code Select

; B.lsp
(context 'my-set)
(define-macro (my-set a b)
  (set  (eval b) a))
(context MAIN)
(context 'B)
(define (my-test x)
  (letex (x x) (my-set:my-set x 'y)))
(context MAIN)


Now we see that we have two implementations of 'my-set' macro in the same

context, if we load these two files at the same time, one will break the other.

if we load 'A.lsp' first, and then 'B.lsp', then the definition of 'my-set' in

B will overwrite that in 'A.lsp', so the 'my-test' function in 'A.lsp' will

fail.



Cause contexts can be seen globally instead of being shadowed by the other

contexts. And we might be using different modules written by different people,

and somehow they might have context collision, and I just wondering how to deal

with this situation.
Pages1