Here, the term "generalized regex" refers to something that can be used to match, say, the lists [1, 2, 3] and [4, 5, 6] (but not [3, 2, 1]) using regex-style syntax such as [_, _+1, _+2]. Instead of applying only to strings or lists, though, the goal is to develop a syntax that is applicable to a wide variety of objects.

Off the top of my head, the functionality present in regular regexes (har har) includes literals, wildcards, inclusive sets, exclusive sets, range of occurrences (i.e., +, *, ?, and {m,n}), capturing groups, balancing groups, look-aheads, look-behinds.

@ConorO'Brien Oooh, yes.

I think it'd also be awesome if it was possible to mix and match types so you can look for a string followed by an integer, but that's probably too big of a task to take on.

@El'endiaStarman I don't see why not. Perhaps it could act like string formatting--like, wildcard matching. [_, #{_ + 3}2] or the similar

Well, thing is, if we allow arbitrary types, then you need a type specification system...

I suppose we could just start with strings, ints, and floats since every (mainstream) language has those.

hm true

maybe as in formatting strings, you can specify the type symbolically--so perhaps \d_ could define _ to be a numeric wildcard

That could work, perhaps.

Blitz 2D/3D uses x = 0 for int, x# = 0.1 for float, and x$ = "x" for string.

hm, interesting--symbolic types

Yeah. It's been problematic for me on occasion though, but something like that could maybe work here.

it's nice not to specify the type with words--it makes these more universal and more concise

yeah

Maybe #_ for number, $_ for string, and %_ for float?

sounds good. are wildcards limited to the _, or can they be named? e.g. _x

also, the only problem then is extensiblility--one would require a new symbol for each type

Yeah. Maybe... @(foo)_ for something of type foo?

Or just @foo_.

that could work

@ConorO'Brien What benefit would naming wildcards give us in this situation?

@El'endiaStarman the ability to have multiple wildcards

e.g., [#_x, #_y, {#_x + #_y}] or something

Hmmmmm....

[(#_), (#_), {\1+\2}]

Using typical capturing group syntax.

oo, nice

Oh, we should have a symbol for lists too. ...but then we can have nested stuff...this oughta be interesting.

oh my, true

Alright, time for me to pack up and head home.

aight!

we could just do what we're doing for lists--e.g., [[1, 0], [0, 1]] for a 2-id matrix

Then what do we use for inclusive/exclusive groups? I.e., [abc]+ matches a string with one or more characters, any of which may be any one of 'a, b, c'.

Maybe something like $[abc]?

perhaps. I think that maybe the array should be implicit, and that we shouldn't assume the language's array looks like [x, y, z]

since we seem to be using {...} to be a matched expression, we could likewise use ${n,k} to denote the usual sense

since we are making our own dialect as it were, we could add xor in addition to alternation

wait nvm that doesn't make sense

+ and * are in their usual sense

{...} is a literal. Ideally, the inside would represent code in the parent language, but it is also possible to define a small language capable of most computation that would be used in a regex, in the event that the parent language has no easy way to eval. (I'm not sure if this would be the case with compiled languages.)

That, or we could leave it up to implementation. In any event, it couldn't be passed straight to eval, since we plan to have \1 and \2 be valid identifiers. We could modify it per language, e.g. $1 + $2.

We may wish to define a language, in this case, for consistency...