From: spir (denis.spir@free.fr)
Date: Fri Feb 19 2010 - 08:50:50 CST
On Fri, 19 Feb 2010 18:27:47 +0530
"vainateya" <vainateya@cdac.in> wrote:
[...]
> Different programming environments and applications seem to treat such
> scenarios differently, most seem to expect an application level code /
> routine which maps to equivalent ASCII before further processing or database
> select query.
I guess not.
Let me situate the context as I understand it --I may be wrong. You are developping a "decoder" for a given source language, which should produce models representing decoded source code (abstract syntax trees AST) to be then either interpreted or compiled into a target language, using an implementation language.
If no, then the rest of this post is irrelevant.
If yes, then for sure your decoder misses a phase, namely the one that transforms expressions of literal values such as 1, 1.1, "hello", or (1,2,3) into actual values --in the implementation language. The said values beeing used as arguments for (arithmetic, logical...) operations. Concretely, this means that after identifying (matching) literals, you need to convert them using a function, that depends on their type. Eg for an integer:
integer("3")
integer("3000e-3")
integer("III")
integer("<hindi 3>")
should all return the same value --providing they are correct in the source language. Common parser generators allow directly specifying such post-matching actions in the grammar.
What you were trying to do instead is to compare/process numbers according their string value -- which indeed makes no sense: basically "3">"123".
Note that this is independent of the use of unicode in source (the first 3 literals above are plain ascii).
Hope this helps.
Denis
________________________________
la vita e estrany
This archive was generated by hypermail 2.1.5 : Fri Feb 19 2010 - 08:52:59 CST