OT: Programming Languages (Was: Phoneme system for my still-unnamed "Language X")
From: | Henrik Theiling <theiling@...> |
Date: | Friday, September 9, 2005, 16:22 |
Hi!
"Julia \"Schnecki\" Simon" <helicula@...> writes:
> On 9/7/05, Henrik Theiling <theiling@...> wrote:
> >...
> > Originally, I wrote the four vowel phonemes /a i u @/ as <a i u e>,
> > but then I decided that at some time in the future, I want to use <e>
> > and <o> for allophones of /i/ and /u/. It's not implemented in Lisp
> > yet, but planned. Anyway, that's why I used <y> for /@/.
>
> Ah, so you use Lisp for your conlang-related programming. Does this
> language have any specific advantages that make it especially
> well-suited for language (or more generally, string) handling?
>...
String handling alone is much better/easier in Perl. (Common)Lisp is
very nice because it can handle symbolic information so well. It's
perfectly suited for programming grammars (generators) or parsers.
The string handling is not particularly clumsy or the like, but if you
need regular expressions, you'd better you Perl for that part.
CommonLisp is also nice because it encapsulates the gory details of
the computer hardware so well: the Integers are arbitrarily large (ok,
memory limits them...) and you won't be confronted with the limits of
the real hardware often (in Perl, the ints are 32bits and in C, you
need to know that Strings are quite different from Ints).
Furthermore, Lisp's special syntax (that many people dislike) makes
code quite indistinguishable from data. You must be careful with
this, you get spaghetti code easily, but it has advantages, e.g. after
writing a lexicon file, you can decide to preprocess every entry on
the fly on loading and implement this by re-defining a single
function.
This structure also made me programm an HTML-preprocessor in Lisp in
order to make Conlang web-pages: the whole page is programmed as a
large Lisp expression and then HTML is computed from that. It looks
just like a Lisp data expression, while in fact, it's an actively
running program. No parser for the preprocessor needed -- Lisp is my
parser. The advantage is that I can write new 'macros' that actually
callback by Conlang grammar and computed the correct forms on the fly.
So just like (b "this is bold") I can write (phonemic "hEnrIk") to
generate /hEnrIk/ (including translation from CXS to IPA) or I can
write
(s7-text-box1
(clause 'perception
head-read
(clause 'pat stem-book)
(clause 'agt (s7-name "Mary" '(ng a x i)))
)
"Mary reads a book."
)
to render a sentence in Qthyn|gai. :-)
And due to the hierarchical arangement of data types and due to the
careful design of the internal functions' parameter types, it took me
about 30 minutes to port that experimental framework from normal
strings to full Unicode support + own extensions -- I just changed
string to vector of arbitrary type and only had to fix very few code
lines.
Anyway, it's not a modern language, so it's not type-safe, and even
uses dynamic typing, to does not do type inference and you often get
*very* cryptic error messages that look a bit like: ,your program is
no good, please rewrite'. You need some discipline to write nice
programs because it allows so much.
I should add that for my private programming, I usually use a mixture
of C++, Perl and Lisp -- whatever feels more appropriate. None of
those is a modern language, but I'm still quite satisfied with that
constallation.
*Henrik
Reply