Re: lpeg as a part of lua (was: An introduction to Lua)

["szbnwer@..." <szbnwer@...>]

Dirk Laurie:
no, i'm not talking about the power of lpeg, but the achievements of
directly merging it into the lua source code. i can really see it's
power, but i've got a preconception (without any code) for all my
future parsing jobs, therefore i still didn't go deeper into the lpeg
world, maybe if thatone will fail or if its alive and i'll have time
to compare them... however on the way i can see on the mailing list
that there are very hard stuffs to solve with it (sometimes), iirc
there were something that was even unsolveable, i can't really
remember what way that, maybe a theoretical similar task, but
everything have limits, (except the bullshit...) and i can see as well
that it's not suitable to learn it for breakfast :D possibly giving it
a syntax that is not built upon the possibilities of hacking lua but
any new own base on the ground instead of metamethod hacking could be
a reason to rework it directly in lua for more power, but that can
lead to incompatibility with its past...

more about power (i'm not familiar with its codes, but i promise that
ill give a bit time for check out a bit its sauce and docs :D ) so if
its in pure lua the it can be rewritten in c and there can be an
optimized version as well for luajit via ffi or if its in c then it
can be written in pure lua that luajit likes, and then you can switch
between them based on the platform... probably there can be always a
bit room to optimize most of any codes... so about the power approach
i dont think it would be a need, but with an own syntax instead of
metamethod magic it could be faster for sure, therefor i've thought
that its some serious stuff that it will be a part of the next lua
(maybe it will be as i catalyzed a a bigger conversation about the
topic :D )



Gavin Wraith:
that sounds good, i already had some thoughts around these, but i
dind't know the name of this concept, ill search a bit for it as its
interesting, thx :)

for your 2nd msg: if i've got right the basic concept, then its about
linking branches for the same root like a set of 'a, ad, an, and' 'a'
can be the root, (or thats the empty string and a is the 1st branch)
and then the remaining parts are linked, so first a special
link/pointer/whatever is needed to indicate its a freestanding
endpoint as well, not just a part of any other word, thinking in
pointers a NULL is fine for this, and there are 'd' and 'n' branches,
where 'n' have the same end marker and a continuation 'd'. here we can
play with using only single letters or longer strings, like for
'advert, advertisement' we can have a->d->vert->isement instead of
linking up all the letters by themselves. i'd guess this can be
useful. on this way we can have a good compressed archive of any kinda
strings, i think it needs some kinda paging and 'vacuum' like sql, but
maybe this is implementation dependent... cutting strings for
inserting stuffs like 'advanced' takes a cut at a->d->v|ert (so for
the 'v' of 'vert'). the new 'v' can still have the original pointer,
and that can hold the new branches, so this way nothing else should
take any harassing (lol, a->n just got a branch (for 'any') in my
head, i'm too much deeply involved into my mental game :D ) i think
this model is good for search and modification, there can be any kinda
monsters included like a gc mark to not go forward, because that will
be destroyed, and that can be removed when we wanna add something new
there. there can be references for the same substrings in other
branches, maybe they can be even merged, or can be used like a
dictionary if something appears in more points, for merging these,
there can be entrance dependent exits... and i dont wanna think about
circular references even if i have 2 (or 3?) different kinda recursion
protection implementations for one of my toys :D

... if we r talking about the same stuff, then changing a link from a
pointer to a file name/descriptor or an uri, its nothing horrible in
complexity, performance is straightforward worse a bit, but catching
and serializing are things to handle... and parallelization is much
dependent on the current task, but i think its straightforward...

that toy i've mentioned above can be a good base for everything around
structures and parsing, but currently i wanna finalize my installer
for my app (horrible cuz its in bash, but i've thought that's
something basic, that every linux should have on a fresh
installation...), cuz that will handle versioning (for the installed
components) and project compositions for whatever purposes, and i
wanna switch from firefox to luakit after that, and it will be then
automatized to get a new version on startup without wrecking the
previous installations :D after this i can move forward to finalize
that toy (no name cuz multiple components for multiple purposes, but a
'polimorphizer' and a structure handler currently for lua tables and
fs, but it's so much flexible, so it can be used for much different
purposes). then ill start to play with parsing (extending this toy)
and trying to make use of the flexibility of the graphics of tekui,
and making a home server with turbo :) - this is my roadmap, but i
dunno when it will be an alpha/beta/whatever, so available for the
public, ive got soooo much plans that i don't want to go to the wrong
path, and its so much easy to get this, and that could harm my plans
very deeply. any general advice for this can make me move forward
faster to the public, but i'm very busy with much other stuffs to
learn and make, so i still can't promise nothing for arrival, just as
well for the reactions, as it looks like a weird alien instead of a
miraculous palace :D


Charles Heywood
haha, nice, i've just jumped into a topic based on a typo (or whatever
this counts to be) :D - never mind it can lead to a valuable thought
exchange, so nothing wrong happened, if we r not counting my wrecked
"english" :D