fP and regex

[Fairlight]

When asked his whereabouts on Thu, Oct 04, 2007 at 12:51:04PM -0400,
Brian K. White took the fifth, drank it, and then slurred:
> I don't know 2 things.
> 
> 1) I don't know how much it's worth to us (my company). I know it's useful, 
> very useful once it a while but how much it would really matter to us I 
> can't imagine. I think not much, because I can't think of anything that is 
> currently hurting for it's lack. Then again, I'm not a user of our software 
> so I could be completely ignorant.

I know I'd use it when I'm forced to code in fP.  But it has to be more
economically viable than that for me to even seriously consider it.  This
will -not- be another FairView, where I put in 72hrs and have made $49.95
off of it to date.  Phuque that.  And this would take significantly more
time than that, given what there is to work with as opposed to what needs
to be achieved.

> 2) How would it be implimented and used? This deals with both useability
> and run-time efficiency.  A call table? Pretty inconvenient and
> limiting. Though, maybe not too bad if it could be made so that it's easy
> to copy-in the table and use it as a gosub without much hacking, and
> be able to re-copy-in updated versions of the call table later without
> breaking the little hacking you did have to do.

I was thinking CALL table, yes.  Variables proposed:

FLREstr - String to be checked.
FLREpat - Pattern to be checked against.
FLREsub - Substitution to be made, if not ""
FLREret - PASS or FAIL depending whether it was matched/substituted.
FLREres - Resultant string from a substitution
FLREbr[sub] - Backreferences.

Can you -have- a long variable name for an array?  I'm just assuming you
can, but that may be wholly invalid.  If not, I'd go with 2 backrefs
maximum unless it was otherwise requested.

> A user command? Probably the closest thing to really useable from the 
> programmers point of view, but comes with a small bag of run-time issues.

You could already do that.  It's inefficient, resource-wise.  It's also
wholly a non-option on win32 because they've never implemented USER on that
platform.

> A daemon that new socket functions talk to? hmm maybe...

Two words:  Hell no.

And I have multiple reasons for that answer.  I'm not going to get into it
here except to say I don't consider it viable.

> I think good regex would be extremely (most?) useful in edits.

I think you should be able to define edits as either "classic" or regex,
and depending how they're defined, parse accordingly.  I've maintained for
years that RE's for edits would be exceedingly beneficial.  I'm in complete
agreement.

Until someone sees the light, we're stuck with the tools we have--which
means doing it the clumsy and less efficient way, after the fact, outside
the engine.

> veering OT
>
> This is a perfect example of why it would be awsome to be able to define
> functions in fp. gosubs and call tables (even now that they are limitedly
> nestable) just don't cut it for lots of things, neither does waiting
> forever (litterally) for fp to build-in the function you would have
> written for yourself.

That gets into a security quagmire.  How would you implement it?  The
-cleanest- way would be to allow use of a shared library that might start
off "empty" by default (maybe with a void function placeholder so it can
exist), but that could be replaced by developers that compile their own.

The downside to that is that you're letting someone add arbitrary code to
an suid program, and whatever security -might- be in fP already just flies
immediately out the window.  Goodbye runtime passwords, screen passwords,
screen checksums (which are lame anyway, IMHO), record deletion protection,
etc.  Hell, you could just rewrite the maps or indexes and totally scramble
someone's day.

I'm at a loss as to another elegant way to do it.  And that way is simply
not an option for the security-minded.

Actually...come to think of it, this isn't far off from what's already the
case.  My beloved raw I/O functions already run as fP, and aren't subject
to any restraints whatsoever.  There's no net difference.  You could do
the map/index/screen mangling already.  

> I wonder how feasible it would be to maybe write a filepro pre-processor as 
> a way to get functions that don't exist?
> 
> wherever fp lacks a feature, as long as it's physically possible to do in 
> processing, however much code it might take or or however unweildly, maybe 
> you could just write your process table and in it use your imaginary foo() 
> functions, save the table without syntax check or tokenizing, run the table 
> through the preprocessor which swaps out the foo() with a gosub or call and 
> whatever other necessary code like declaring variables, then it syntax 
> checks and tokenizes the result.

People still get DKNF.  You really want to futz with memory that much more?

Besides...to do the -really- interesting and neat stuff, you need things
that just don't exist in processing's language.  You'd really want
something hooked in at a lower level where you have structs, unions, etc.
Advanced data structures are not the language's strong point, to say the
least.  We don't even have infinite arrays, much less hashes, linked lists,
etc.  I'm seeing that as a kind of near-useless middle of the road approach
that's far less useful than it should be for the work required to obtain
it.

Actually, this discussion combined with one the other day leads me to
wonder what happens if you try to import data from a file, even using
binary mode on open(), and the "field" contains a NULL.  What exactly does
the field behave like?  Is it stripped?  Is it only taken up to the null?
Is it wholly taken including data past the null, up to the newline, but
displays oddly?  Could it open fP to a memory leak attack?  (Example:  Have
a 1GIG long line in a file, but put the null in after 5 characters.  If
they all display as only 5 characters on-screen but "secretly" take up the
memory of the full data...well, you get the idea.)

mark->
-- 
Most people think the defining traits of human beings are intelligence,
speech, writing, or creativity.  The sad reality is that the most singular
defining quality of humanity is cruelty.  No other species appears to be so
able and willing to inflict pain on its brethren for no logical reason.