Re: Help on module name (working name 'Regexp::Query' - UPDATE: now 'Grep::Query')

[kenneth]

In case anyone is interested a working module is now available at 
https://github.com/kenneth-olwing/grep-query.git, also see an entry for 
it on PrePAN.


ken1

On 2016-07-26 10:39, kenn...@olwing.se wrote:

Hi David,

Many thanks for taking the time!


...
So, first of all, please do not take Scrooge. I am rather fond of that
name, and plan to publish my module with that name some day.


Noted :-) !


As to your idea, it looks like you're working with something like
grep. The key difference is that you provide some sort string parsing
for queries, along with a way to add keywords to those queries. In
that case, I think that GREP::QUERY might be the best name.


Yes - this is clearly better as it captures the essence. Basically:
'using this criteria, whittle down this list for me', which in normal
grep-speak means 'criteria' is either a BLOCK or EXPR, whereas I sort
of give the ability to have criteria be 'ARBITRARY QUERY'.

So yes, there's a small parser involved to parse the query language
(uses Parse::RecDescent for grammar).

Actually, I've already called the main method 'qgrep(...)' (i.e.
'query grep'), and also supply a tiny 'qgrep' script as a way to write
"qgrep 'some_query' ..." on the command line. So I should have seen it
coming :-).


Another
possibility, if you want to some day add map-like capabilities as
well, would be a top-level namespace. The name Matchbox comes to mind,
for some odd reason, with Matchbox::Grep and Matchbox::Map being your
two major namespaces.


I can't quite see what to do with that at the moment so I think
'Grep::Query' is a favourite right now. Given the fact that the actual
querying can be inside a block and on 'lists' with a single item, it
can be used in a map situation also. But any suggestions to do
something easier/better for map may be worth considering.

ken1

Re: Help on module name (working name 'Regexp::Query' - UPDATE: now 'Grep::Query')

[kenneth]

Hi David,

Many thanks for taking the time!


...
So, first of all, please do not take Scrooge. I am rather fond of that
name, and plan to publish my module with that name some day.


Noted :-) !


As to your idea, it looks like you're working with something like
grep. The key difference is that you provide some sort string parsing
for queries, along with a way to add keywords to those queries. In
that case, I think that GREP::QUERY might be the best name.


Yes - this is clearly better as it captures the essence. Basically: 
'using this criteria, whittle down this list for me', which in normal 
grep-speak means 'criteria' is either a BLOCK or EXPR, whereas I sort of 
give the ability to have criteria be 'ARBITRARY QUERY'.


So yes, there's a small parser involved to parse the query language 
(uses Parse::RecDescent for grammar).


Actually, I've already called the main method 'qgrep(...)' (i.e. 'query 
grep'), and also supply a tiny 'qgrep' script as a way to write "qgrep 
'some_query' ..." on the command line. So I should have seen it coming 
:-).



Another
possibility, if you want to some day add map-like capabilities as
well, would be a top-level namespace. The name Matchbox comes to mind,
for some odd reason, with Matchbox::Grep and Matchbox::Map being your
two major namespaces.


I can't quite see what to do with that at the moment so I think 
'Grep::Query' is a favourite right now. Given the fact that the actual 
querying can be inside a block and on 'lists' with a single item, it can 
be used in a map situation also. But any suggestions to do something 
easier/better for map may be worth considering.


ken1

Re: Help on module name (working name 'Regexp::Query')

[David Mertens]

Hello Kenneth,

My background: I have been working on a generic greedy pattern matching
engine for my years. It is called Scrooge. The original itch was to be able
to write "regexes" for numerical data (i.e. PDL). It took a long time
before that idea grew into an implementation (starting around 2012), which
then morphed into a generic sequential greedy pattern matching engine for
arrays of any type. I don't know if it handles hashes yet, but they will be
easy to weave in as arrays of zero length that are tested with zero-width
assertions. (If anybody is interested, my current development is at
https://github.com/run4flat/perl-Scrooge.)

So, first of all, please do not take Scrooge. I am rather fond of that
name, and plan to publish my module with that name some day.

As to your idea, it looks like you're working with something like grep. The
key difference is that you provide some sort string parsing for queries,
along with a way to add keywords to those queries. In that case, I think
that *Grep::Query* might be the best name. Another possibility, if you want
to some day add map-like capabilities as well, would be a top-level
namespace. The name Matchbox comes to mind, for some odd reason, with
Matchbox::Grep and Matchbox::Map being your two major namespaces.

That's just my two cents. I hope that helps.
David

On Mon, Jul 25, 2016 at 6:20 AM,  wrote:

> Hello all,
>
> I'd like to request some advice/thoughs/help on selecting a name for a
> module.
> The working name is 'Regexp::Query', but as it happens the realization of
> the
> original idea has moved slightly ahead of that so I'm no longer confident
> on the
> suitability...
>
> The Scratched Itch:
>
> I have a large number of commandline tools, and quite frequently I want
> the user
> to be able to express, with some flag(s), a selection among something.
>
> Example: the user gives the command
>
>   SomeCommand /some/path
>
> and it will scan the path and for all files it finds it will do something
> useful. Now, I also want to provide flags for the command such that they
> can say
>
>   SomeCommand -exclude 'some_regexp' /some/path
>
> Obviously not a problem, and I also provide the reverse if that is more
> convenient:
>
>   SomeCommand -include 'another_regexp' /some/path
>
> and this can be extended so flags can be given multiple times and
> interweaved:
>
>   SomeCommand -include 'rx1' -exclude 'rx2' -include 'rx3' /some/path
>
> coupled with rules that then shrinks the target set based on rx1, shrinks
> that
> set using rx2 etc etc. I think you get the idea.
>
> What I found however is that it becomes hard to string together regexps to
> find
> the exact subset you want. In fact, while regexps are powerful, they're
> not that
> suited to easily mix multiple of them, and some expressions are basically
> impossible, especially to provide a commandline interface to them...
>
> Thus, instead I'd like to provide a more capable way for a user to provide
> a
> more complex query, i.e. where it'd be possible to use AND/OR/NOT,
> including
> parenthesized, e.g. something very contrived:
>
>   (
> REGEXP/some_rx_1/ AND REGEXP/some_rx_2/
>   ) OR
>   (
> REGEXP/some_rx_3/ AND NOT REGEXP/some_rx_4/
>   ) OR
>   NOT (
> REGEXP/some_rx_5/ OR NOT REGEXP/some_rx_6/
>   )
>
> Basically, feed 'something' the query and a list of scalars and get back a
> list
> of the subset of scalars that fulfills the query. In short, behaving like a
> grep, you might say.
>
> This was my original goal, and stopping there, arguably calling such a
> module
> "Regexp::Query" could make sense IMHO.
>
> ===
>
> However, moving beyond this I realized two things:
>
> 1) It would be generically useful to allow simple numerical comparisons on
> the
> scalars, i.e. the usual suspects ==, !=, >, >=, <, <=
> 2) Why only scalars? With some additions it can handle lists of raw
> hashes, or
> even arbitrary objects
>
> The first now provides the opportunity to write a queries like this:
>
>   EQ(42) OR GTE(99) OR REGEXP(1\d\d\d2)
>
> This is not so interesting with a list of plain scalars, but adding the
> second
> capability, I introduce the notion of 'fields'. With plain hashes, this
> equates
> to plainly looking up the keys, but with objects we can provide a special
> hash
> which has keys corresponding to small anonymous subs that knowns how to
> dig out
> the data we want. Given a query like this:
>
>   name.REGEXP(^A) and age.GT(30)
>
> and having any kind of Perl objects that has these 'fields', we can do
> this:
>
>   my $fa = FieldAccessor(
>  {
>name => sub { $_[0]->getName() },
>age => sub { $_[0]->calculateAge() },
>  });
>
> which, passed along with the list of objects, will perform the query.
>
> Given the last features, I feel I'm slightly beyond just something in the
> Regexp:: namespace, but I have no good feel for what it could be instead.
> Pretty
> generic in a way, so just 

Re: help for module name?

[Jerome Quelin]

On 07/05/27 21:27 +0200, A. Pagaltzis wrote:
  well, i don't like the way to prereq sthg in pococm that i
  won't really use - that is, the whole non-poe logic of
  audio::mpd.
 
 What whole non-POE logic? All the logic I can find is the
 as_string method. Are we talking about the same modules?

i was talking of adding in this helper dist the modules stats, status
and time (always in audio::mpd::) which are also just structs and are
shared between the poe and non-poe implementation.

thus, the dist audio::mpd::items would not be enough - unless i also
release separately audio::mpd::stats and... which is a bit silly imo.

therefore:
- audio::mpdhelper?
- audio::mpdcommon?


regards,
jérôme 
-- 
[EMAIL PROTECTED]

Re: help for module name?

[Philippe Bruhat (BooK)]

Le lundi 28 mai 2007 à 08:47, Jerome Quelin écrivait:
 
 thus, the dist audio::mpd::items would not be enough - unless i also
 release separately audio::mpd::stats and... which is a bit silly imo.
 
 therefore:
 - audio::mpdhelper?
 - audio::mpdcommon?
 

Maybe Audio::MPD::Common, so that everythings stays in the namespace 
you're using?

-- 
 Philippe BooK Bruhat

 In war, the only winners are those who sell the weapons.
 (Moral from Groo #3 (Image))

Re: help for module name?

[Philippe Bruhat (BooK)]

Le lundi 28 mai 2007 à 13:11, Jerome Quelin écrivait:
 On 07/05/28 12:31 +0200, Philippe 'Book' Bruhat wrote:
   thus, the dist audio::mpd::items would not be enough - unless i also
   release separately audio::mpd::stats and... which is a bit silly imo.
   
   therefore:
   - audio::mpdhelper?
   - audio::mpdcommon?
  
  Maybe Audio::MPD::Common, so that everythings stays in the namespace 
  you're using?
 
 but it's to be used also in the namespace poe::component::client::mpd
 == therefore, why take one rather than the other?
 

Because it's not POE specific, so it should live in the POE namespace.

-- 
 Philippe BooK Bruhat

 For every winner, there must be one or more losers.
(Moral to the Sage story in Groo #111 (Epic))

Re: help for module name?

[A. Pagaltzis]

* Jerome Quelin [EMAIL PROTECTED] [2007-05-27 09:50]:
 so here's my question: how should i name this new module?
  - audio::item= isn't it too vague?
  - audio::mpditem = isn't it too specific? (would it be used by others?)
  - other?

The modules I see are just structs, and the only code in there is
the formatter method in Audio::MPD::Item::Song. I does not seem
to me that these things are very generically useful; you’d have
to do a lot of work to make them interesting for other purposes.

I’d suggest Audio::MPD::Item as the distro name, since you’ve
already organised them as a hierarchy in there. As a bonus you
won’t even need to change any of the Audio::MPD code, just add
the dependency and you’re done.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: help for module name?

[Jerome Quelin]

On 07/05/27 17:31 +0200, A. Pagaltzis wrote:
 * Jerome Quelin [EMAIL PROTECTED] [2007-05-27 09:50]:
  so here's my question: how should i name this new module?
   - audio::item= isn't it too vague?
   - audio::mpditem = isn't it too specific? (would it be used by others?)
   - other?
 
 The modules I see are just structs, and the only code in there is
 the formatter method in Audio::MPD::Item::Song. I does not seem
 to me that these things are very generically useful; you’d have
 to do a lot of work to make them interesting for other purposes.

they are indeed just structs, as i said.

 I’d suggest Audio::MPD::Item as the distro name, since you’ve
 already organised them as a hierarchy in there. As a bonus you
 won’t even need to change any of the Audio::MPD code, just add
 the dependency and you’re done.

well, i don't like the way to prereq sthg in pococm that i won't really
use - that is, the whole non-poe logic of audio::mpd. i'd really like to
have a small dist that could be used by the two. it would be way
cleaner imho.

after having sent this mail, i thought that i could as well add other
helper classes used by both audio::mpd and pococ::mpd...

== maybe Audio::MPDHelper could do the trick?


jérôme 
-- 
[EMAIL PROTECTED]

Re: help for module name?

[A. Pagaltzis]

* Jerome Quelin [EMAIL PROTECTED] [2007-05-27 18:05]:
 On 07/05/27 17:31 +0200, A. Pagaltzis wrote:
  I’d suggest Audio::MPD::Item as the distro name, since you’ve
  already organised them as a hierarchy in there. As a bonus
  you won’t even need to change any of the Audio::MPD code,
  just add the dependency and you’re done.
 
 well, i don't like the way to prereq sthg in pococm that i
 won't really use - that is, the whole non-poe logic of
 audio::mpd.

What whole non-POE logic? All the logic I can find is the
as_string method. Are we talking about the same modules?

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/