I think we'll need to start small in the
implementation (go for the low hanging fruit)
and build on that.
The basic scheme might be to use 3 basic
token types: [] for grouping, whitespace
and commas for separating and other stuff
(technically anything else but we can
start with numbers and +/- operators), e.g.
[
[0 1]
[2 3]
[4 5]
]
versus
[
[0 +1]
[2 -3]
[4 -5]
]
versus
[
[0 + 1]
[2 - 3]
[4 - 5]
]
Once we have the basic recognition of a string
argument that is non-numeric, we can do whatever
parsing is needed. Upgrades should be seamless
since the result is just a piddle.
--Chris
On 4/17/2010 11:19 AM, David Mertens wrote:
> Chris, I'm just thinking aloud about how to best handle this. On my
> first pass I figured writing code to directly parse this would make
> sense. Then I thought about how on earth we would write code that could
> handle erroneous input. It seems to me like the possibly easiest way to
> get this to work would be to to a global search-and-replace like this:
>
> ----%<----
> $string_arg =~ s/(\d)\s(\d)/$1, $2/g;
> $my_nested_array_ref = eval($string_arg);
>
> croak("Malformed input: $@") if ($@);
> ----%<----
>
> If we get passed the croak, then we can continue processing
> $my_nested_array_ref with code that's already in place. It may not be
> super fast, but it'll probably be a lot less buggy than hand coding a
> recursive parser.
>
> Thoughts?
> David
>
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.437 / Virus Database: 271.1.1/2816 - Release Date: 04/17/10
> 06:31:00
>
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
