> >
> > > Even in English we have, in many dialects, "five hundreds of
> > > dollars" (as opposed to "five hundred dollars") not to mention
> > > "threescore dollars and twelve". I believe my grandfather wrote
> > > "Seventy-Five Pounds and 26/100", but "Seventy-Five Pounds Only";
> > > yet "One Hundred Pounds Exactly".
> >
> > Bear in mind here that we don't need to be able to parse all of the
> > possible valid constructions in a given language, we just need to be
> > able to output *one* valid construction for each language, which is a
> > much simpler problem.
>
> Yes, parsing is harder than determinstic generation.
> But:
>
> Some constructions are allowable in English (but not mandatory).
> Such constructions are within the gamut of the language center
> of the human brain. Virtually any natural-language syntactic
> construction that can be processed by the human brain turns out
> to be mandatory in some language, somewhere. Indeed, given the thousands
> of languages of astonishing variability that exist, it would be
> astonishing if this were not so.
>
> So chances are that some language or culture, somewhere, will require
> a construction like this. If our formalism for describing number
> notations can handle it, people will be able to do their own
> linguistic customization. (and contribute the results to our
> internationalization library, natch).
>
> Whether we want to do all this now, instead of just letting everyone
> program their own number code in Scheme, is another matter, or course.
> But Stephen's ad-hoc notation may indicate regularities that could simplify
> our code in the long run.
Remember:
What is *mandatory* is to have text which will be recognized as acceptable to
the bank clearing-houses of the world.
It would be *nice* to have grammatical correctness, but if some irregularities
of grammar persist, but which are things that the bank clearing-houses won't
care about, that is not a _severe_ problem.
--
"Any sufficiently complicated C or Fortran program contains an ad hoc
informally-specified bug-ridden slow implementation of half of Common
Lisp." -- Philip Greenspun
[EMAIL PROTECTED] - <http://www.hex.net/~cbbrowne/lsf.html>
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
