Re: Is there any library for converting common English words to its equivalent numeri

> From: "Steven M. Haflich" <s...@alum.mit.edu>
> Basically, ANSI-CL is an English programming language, like
> nearly every other programming language.  It's unfair, but if we do
> it again let's base it on Esperanto.

Why Esperanto, a totally artificial language nobody knows?
Why not Interlingua, a mixmash of various known languages, an
attempt to make an Esperanto-like language most people would party
recognize?
<http://en.wikipedia.org/wiki/Interlingua>
Interlingua's greatest advantage is that it is the most widely
understood international auxiliary language by virtue of its
naturalistic (as opposed to schematic) grammar and vocabulary,
allowing those familiar with a Romance language, and educated speakers
of English, to read and understand it without prior study. ...
.. There are several active mailing lists, and
Interlingua is also in use in certain Usenet newsgroups, particularly
in the europa.* hierarchy. ...

> We should leave car and cdr alone, but I'd be willing to use
> Esperanto words for first and rest.

English->Interlingua <http://www.interlingua.com/an/ceid>
English->Esperanto <http://dictionaries.travlang.com/EnglishEsperanto/>
When treating a single CONS cell as part of a tree:
* LEFT = leve (I don't like maldekstren)
* RIGHT = dextre (dekstren is almost as good)
When treating a CDR-linked chain of CONS cells as a list:
* FIRST = prime (the "e" is presumably pronounced as in Spanish)
(XXXX Esperanto! You need to know the gender of the
elements in your list!!! unua unue)
* NEXT = sequente (poste isn't bad at all)

IMO unua/unue is the killer. You can't do a runtime type-check on
the first element of the list until you fetch it to inspect it, but
you can't fetch it from the CONS cell until after you know its
gender, a classic Catch-22 blockage. The only way I see this
working is to have two kinds of CONS cells, those whose CAR can
store only male objects, and one whose CAR can store only female
objects, and then polymorphise higher-level code that does a
type-case on the CONS cell to determine whether it's a MALE-CONS or
FEMALE-CONS cell hence whether to call UNUE or UNUA respectively.
No way will I go along with such an absurdity.
(Nevermind how to decide, at system-design time, the gender of each
data type to appear in the software, to avoid later
mis-communication between different programmers on the team.)
(I you think the incompatibility between various kinds of connectors:
- EIA 12+13=25
- EIA 4+5=9
- EIA 5+5+5=15
- DIN
- USB
is a problem, at least you can *see* (or if blind, *feel* by
touch) the physical connectors before you try to plug one type of
plug into another type of socket. My Dell Latitude XPi has one of
each of the first four kinds, but it apparently pre-dated the new
USB type of connector!!)

> I'll leave it to the better minds on this list to derive a system
> of Roman numerology in non-decimal radix.

What's the problem? You scrap all the V stuff, using only I X C M etc.,
except in hexadecimal base you use E for eight in lieu of V for five.
I II III IIII IIIE IIE IE E EI EII EIII EIIII IIIX IIX IX X
XI XII XIII XIIII XIIIE XIIE XIE XE XEI XEII XEIII XEIIII XIIIX XIIX XIX XX
XXI XXII XXIII XXIIII XXIIIE XXIIE XXIE XXE XXEI XXEII XXEIII XXEIIII XXIIIX
..
XXXI XXXII XXXIII XXXIIII XXXIIIE XXXIIE XXXIE XXXE XXXEI XXXEII XXXEIII ...
You can still use L for #x80, and D for #x800.

(format nil "~@R" 5000)
Error in function FORMAT::FORMAT-PRINT-ROMAN:
Number too large to print in Roman numerals: 5,000
Hmm, curious ...
How did the Romans do a census in their day??
I'm sure Rome had more than five thousand citizens??
Maybe slaves don't count?
Or maybe this problem is why the Empire collapsed????