I have already thought and tried the seek function (there are faster way for
long strings) and in that case I do not mind "patching" in lisp because the
lisp version can be made more useful, providing the position of the substring.
So far I have done all string processing in picolisp with lists of transient
symbols, each representing one char. For difficult problems, like finding the
end of a sentence, the list structure is great and the property list allows to
pass information around. On the 32bits version, this has seemed reasonable, but
on a 64bits one? Any thought will be welcome.
Thanks for the information,
From: email@example.com <firstname.lastname@example.org> on behalf of
Alexander Burger <a...@software-lab.de>
Sent: August 21, 2017 2:25 AM
Subject: Re: Missing functions in miniPicolisp?
> So, if miniPicolisp should be a "real" project, would sub? (and any other
> "missing" functions) be available in it sooner or later? pre? is available, so
> is there any reason why sub? and hash are not found? I might try it myself,
I think the reason is the bit-packed format of the string representation in
miniPicoLisp. This makes it quite tedious to scan the bytes for a substring.
> it would take the time of my understanding of the source code ;-)
Perhaps this is not necessary so much. It is quite straightforward, for example,
to build 'sub?' in Lisp:
(de sub? (A Str)
(setq A (chop A))
(seek '((L) (head A L)) (chop Str))
Str ) )
> Has the RAM/ROM trick an impact on performance when miniPicolisp is used on a
> regular computer (for command line application or embedded in a larger
No, it might even be an advantage, as it should start up slightly faster. In
reality, the difference is not noticeable though.
PԔ � &j)m����X�����zV�u�.n7�