On Thu, 2007-03-29 at 23:52 -0700, Erick Tryzelaar wrote:
> skaller wrote:
> >
> > Er no, the problem is you need the nsub value BEFORE you actually
> > do a regexp, otherwise you can't tell how long the array needs to be
> > to hold the matches.
>
> I'm confused, I'm basing this off of your tre bindings. :) Here's what
> you wrote for doing a match:
>
> fun tre_regexec (re_in: tre_regex_t) (x:string): int * int *
> ptr[regmatch_t] =
> {
> var re = re_in;
> val nmatches = nsub$ addr re;
> var matches = Carray::array_alloc[regmatch_t] nmatches;
> var res = _tre_regexec(addr re, x, nmatches, matches);
> return res,nmatches,matches;
> }
>
> Does this not work?
Sure, it was just that your description was faulty: you said:
"Yeah, I believe it's the function "nsub". tre_regexec already returns
that along with the matches, so it'd be pretty easy to make the varray."
but this isn't the case as you see: it isn't returning the length
'along with the matches', nsub is applied to the compiled regexp
to count the matches BEFORE the regexp is executed.
> > I don't understand what you mean 'in general' :)
>
> What I mean is there are a variety of functions that can return a list
> of things. Consider a glob-like function, or a database returning a list
> of rows. What should this data type be? Python obviously prefers their
> array/list, but we have a couple different structures we could use,
> including streams and generators. What should most of our functions return?
One or the other ... or something else .. :)
Which one? That's a hard library design decision, probably chosen
case by case. arrays are faster than lists**, and suitable for
indexing, but they're not functional in nature.
So one guiding principle is: if you want indexing, or you have mutable
imperative stuff, arrays are better. But if you want functional
programming, lists are better.
** Felix arrays use a LOT less store than lists at the moment:
list have GC overhead per element, which is 48 bytes on 64 bit
machine at the moment (6 machine words). (Actually since varray
is added i think it is one more word!)
At least two words can be saved: one by packing two flags
into a pointer, and one by throwing away the ability to
explicitly delete pointers.
Even better could be done if the header were variant
length, since non-arrays don't need counters. However
that makes the address calculations harder (though not
impossible).
I'm inclined to ignore this for a while and focus on
correctness plus performance of 'C like functions'.
This is because ultimately the real limitation is that
the gc is world stop, which is not suitable for
a multi-processor. OTOH a parallel collector is probably
incompatible with C/C++ anyhow .. so if we really want
high performance, we'd need a native code generator and
to get rid of C/C++ altogther .. which sounds like a new
project but would make Gtk bindings rather hard .. :)
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
