Re: Argh! Regular expressions in Lua

[Philippe Lhoste <PhiLho@...>]

Luiz Henrique de Figueiredo a écrit :
> > is there a compelling reason for such limitation?
>
> Size and complexity. If you want to do complex pattern matching with full RE,
> then you can add it as an external libraries (and there are a few for Lua).

Well, (ab)* isn't so complex, both to implement (I think) or 
conceptually (that's not (?<=\w{5})...).
And as I wrote, we often find Lua embedded in softwares (SciTE...) which 
use only base libraries and don't plan to offer extra advanced features, 
so we are stuck.
Now, I take this as a "No, thanks". :-(

> > I found myself wishing to have a continue keyword [...]
> > can't recall an official reason why it isn't in the language.
>
> Lua evolves by answering "why?" not "why not?".

Well, I wrote it: I can do without, but by adding extra levels of 'if' 
nesting and indenting, which can be ugly with a complex automaton.
In such algorithm, I often has to test a state and / or condition, and 
if meet, do something and continue with the next iteration (ie. do 
nothing else for this step), else check the next state and / or condition.


for line in fileHandle:lines() do

  if IsState(a) then
    -- Do stuff
  elseif IsState(b) then
    -- Do stuff too
  elseif IsState(c) then
    s, e = string.find(line, ...)
    if s ~= nil then
      -- Do it
    else
      s, e = string.find(line, ...)
      if s ~= nil then
        -- Process that
      else
        -- Etc.
      end
  elseif IsState(d) then
    -- Stuff doing
  end

end


for line in fileHandle:lines() do

  if IsState(a) then
    -- Do stuff
  elseif IsState(b) then
    -- Do stuff too
  elseif IsState(c) then
    s, e = string.find(line, ...)
    if s ~= nil then
      -- Do it
      continue -- No further test needed
    end
    s, e = string.find(line, ...)
    if s ~= nil then
      -- Process that
      continue -- Idem
    end
     -- Etc.
  elseif IsState(d) then
    -- Stuff doing
  end

end

The given example isn't compelling, but with complex automatons, it can 
go far.
Now, the code can probably be refactored, I haven't searched much this way.
Oh well, I suppose convenience features beyond simple syntactic sugar 
are beyond question.


Oh, while I am on the topic, I found some surprising results with 
string.find.

I found that if string.find returns nil, all sub-captures are nil.
Otherwise, they don't match something, they are just empty.
Well, that's logical (they just matched empty string).
Not a problem but I wanted to mention it.

Also if the whole pattern matches the empty string (eg. with %w*),
the end index is the start index (equal to 'init') less one.
This is not documented.

--
Philippe Lhoste
--  (near) Paris -- France
--  http://Phi.Lho.free.fr
--  --  --  --  --  --  --  --  --  --  --  --  --  --