open FILE, '<', ...
my @numbers;
while( <DATA> } {
push @numbers, m[^[ ]*[0-9]+[ ]*$] ? 0+$_
: m[^[ ]*[0-9A-Z]+[ ]*$]i ? hex()
: die "Bad number at $.";
}
## That hex() would do all of that for you and more is irrelevant
I would say not. I would call that data driven code. And this is the reasoning behind my "special casing" of syphilis' example of IV/UV/NV/PV branching within the Perl core. The type is SCALAR. The method called depends entirely upon the form in which the data in the scalar is currently stored, not its 'type', in Perl terms. You can equally apply substr to a scalar currently containing the NV = 1234.56789, as you can if it contains the PV = '1234.56789'. It just takes a little more (internal) work. In Perl terms there is no type change, just a storage format conversion. Like converting an integer to a double in order to call pow(), because that's all that is available in the library.
Of course, you might cause an exception if you try to apply + to 'fred', but no more so than if you try to divide by 0. Both methods ('+' and '/'), are available to every scalar at any time. Whether thay are applicable at any given time depends upon what value they currently hold. And if the source of data is external, there is no way to make a compile-decision about it. It (the potential exception), can only be dealt with at runtime, regardless of what language you use.
Then we come to the discussion of whether a parser, is an interpreter. Or perhaps more correctly, at what point a parser becomes an interpreter. That's the sort of thing CS guys will continue to debate until well after I'm going through my final type conversion, and is something that you are probably far better suited to argue than I--but I'll have a go :)
Does your "new type of rule" for your trading system, require a Turing complete language?
If so, you need an interpreter. If not, you only need a parser. Whether that interpreter needs runtime introspection to function is an open question, that could only be answered by a full definition of the rules, and the language to define them.
Indeed, we've now come full circle. Because, in that sense perl is a statically-type (by some definition), compiled program that parses and subsequently interprets runtime data, in the form of Perl.
Could you write a Perl parser and interpreter in Haskell. We know you can. (Whether its a good idea is another matter :). But, would you need to endow either Haskell or the Perl dialect you implement, with runtime introspection in order to do it?
Now were full circle yet again, because it depends upon how you define runtime introspection (see sbove:).
The only trading system with which I have any familiarity, was an Excel spreadsheet! A very large and complex one, but still just a spreadsheet. And traders would add their own pages to their private workbooks to look for new ways of discerning patterns and raising triggers. Occasionally, these would become useful enough and complex enough that they were 'adopted' and the meat of the calculations they performed would be converted to subroutines by professional programmers, written in Fortran for performance, packaged in a DLL, and accessible to the spreadsheets via OLE.
The system was extensible, dynamic and reactive, but was any runtime introspection involved? I'd have to say not. Not in any sense that a Ruby programmer would understand anyway.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| 