[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lua-l
Subject:    Re: operator overloading for string matching
From:       Mason Bogue <scythe+lua () ortsz ! com>
Date:       2015-08-21 23:02:10
Message-ID: CAA=oZpCPqSo_NXh-qaYUURvXYjkZ5-PDjvdRiD2xR0SV_9Q_SQ () mail ! gmail ! com
[Download RAW message or body]

@Rena:

> This is a trivial example and already looks near incomprehensible to me.

> > start, end = s:find("%s*$")
> > trailing_whitespace = end - start
> This on the other hand takes one more line and is much clearer, just
> for having fewer symbols grouped together.

I think it's really a matter of personal taste. From my perspective,
it's far more work to remember the vagaries of the different string
manipulation functions, whereas pattern-matching syntax is
semi-consistent across languages and usually easy to recognize. Also,
special characters |.%#(\)*$ etc are generally much easier to read in
programming fonts than Gmail's Helvetica. If you only use Lua and
rarely use regex-like tools (vim/sed, grep, etc) you'll probably have
a different experience.

VM limitations mean this idea is dead for now, though. Ho hum.

On Wed, Aug 19, 2015 at 3:20 PM, Pierre-Yves Gérardy <pygy79@gmail.com> wrote:
> On Tue, Aug 18, 2015 at 7:51 PM, Pierre-Yves Gérardy <pygy79@gmail.com> wrote:
> > 
> > On Mon, Aug 17, 2015 at 8:57 PM, Mason Bogue <scythe+lua@ortsz.com> wrote:
> > > 
> > > The proposal is this:
> > > 
> > > str1 / str2 -- equivalent to str1:match(str2)
> > > 
> > 
> > No time to test right now, but AFAIK, binary operators return exactly one value \
> > whereas function calls can return an arbitrary number of them. 
> 
> I remembered correctly, this is a bytecode limitation:
> 
> > t = setmetatable({}, {__div = function() return 1, 2 end})
> > = t / t
> 1
> 
> So this syntax would be useless for patterns that return more than one
> value, unless you change the VM to support more than one return values
> for operators.
> 
> —Pierre-Yves
> 


[prev in list] [next in list] [prev in thread] [next in thread]