[YG Conlang Archives] > [engelang group] > messages [Date Index] [Thread Index] >
##NOT READY!: SEE lambda-var , codename:VOCALL (Versatile,
Ontology-based, Compund-oriented, Auxiliary Logical Language)
--- In engelang@yahoogroups.com, John E Clifford <clifford-j@...> wrote:
> >
> > My memory of classes with Church is fading and
> my
>
> Alonzo Church ?!!
>
> Yes; at both Princeton and UCLA. I am ancient
> (see phto at conlangs.berkeley.edu)
Nice pic :)
>
> Y4s, *labelled* brackets would probably help but
> are bound to fail concision unless you get some
> good conventions that allow dropping a goodly
> percentage of them. Most languages have such
> conventions; LISP is totally explicit.
I'd make the following remarks (as I said, I'm no Lisp expert or even
user, so take it with a grain of salt) :
1) Closing at the end of the outest expressions could be omitted, but
if you want to
use the expression inside another one, you have to add them, or
replace them with something equivalent. Otherwise it would be ambiguous.
2) There are lots of visual aids that can replace those big chunks of
closing parenthesis, such as using color boxes, or special kinds of
parenthesis , such as the "super parenthesis" that closes all the open
ones, and so on.
see:
http://www.gavilan.edu/csis/languages/parentheses.html
http://www.foldr.org/~michaelw/emacs/#color-box
Regarding the color box metaphor, I like to think of full parenthesis
as a box metaphor, and I guess I would enjoy programming in Lisp with
this visual representation, though, anyway, it's of no use for spoken
language.
The super-parenthesis is more interesting for this purpose, but it
breaks encapsulation: if an expression has a super-parenthesis, you
can't use it inside a bigger expression without first replacing the
super-parenthesis with the appropriate number of parenthesis. Besides,
it can only be used for the outest parenthesis.
So, my method to reduce verbosity are hierarchical labeled
parenthesis, as described with examples in message 131 (a correction
of message 128). Its advantages, I think, are:
First, you never have to write two brackets in a row. You can always
fuse them, even close-open of different levels.
Second, you never have to modify expressions (beyond their outest
brackets) so as to use them as terms inside other expressions.
Third, you can always use an expression of the "wrong" level, that
is, one with higher-level brackets than those of the outer expression,
as long as you don't "fuse" their brackets.
Another consideration for reducing the number of brackets
3) You can customize the syntax of Lisp, by using macros. More on that
below.
> A-coord-B:
> something that has some combination of features
> of A's and B's
>
> A-subord-B:
> something that is an A , and is related in some
> way to those things
> that are B's (other than having some features of
> B's) .
>
> A-literal-B: something that belongs to the set
> described by "(lambda x
> (A B x))" in Lisp notation.
>
> Which I can no longer read, so I forget just what
> ABx amounts to: "good hunter" model ("good at
> hunting," so a hunter but not good or even good
> as hunters go, the goodness directly modifies
> (and is modified by) the hunting) ?
>
Yes, I think your example is valid. In a more formal syntax, it could
be something like:
(hunt John) : John is a hunter, John hunts
((beGoodAt hunt) John) : John is good at hunting
(beGoodAt hunt John): idem
(beGoodAt-lit-hunt John) : John is-good-at-hunting.
The last expression contains the literal compound "beGoodAt-lit-hunt".
So, if John is-good-at-hunting, then
he must be good at hunting (assuming no metaphors allowed) but the
reverse is not true in general. It could be a word for describing,
say, a particular style of hunting that some good hunters have.
I still hesitate on whether to require that he is a good hunter, or
allow a metaphoric use. I said I can always be strict in principle and
reserve a particle to indicate metaphoric use (something like
beGoodAt-met-lit-hunt), but if it turns out that most compounds need
the metaphoric particle, it would be better to allow metaphors by
default, and indicate strict use with a particle (something like
beGoodAt-NoMet-lit-hunt). I intend to allow maximum flexibility for
jargons, so it should be possible to define, in every jargon, whether
metaphors are allowed or forbidden by default.
> I haven't quite decided, but in
> any case, the compound word should not be
> completely equivalent to a
> syntactic phrase.
>
> Good. Lojban suffers from an excess of
> literalness and strict equivalence, with the
> result that compounds are often both ugly and
> pedestrian.
I've found this article about Lojban semantic problems quite interesting:
http://www.lojban.org/files/papers/nsn_semantics_paper
I'd say that, every time a new concept needs to be expressed in
Lojban, the trial path is as follows:
(in non-lojbanic terminology)
existent root -> syntactic phrase -> derived word (root + derivational
morphemes) -> compound word -> new root
And Lojban tends to favor the "new root" approach by making the other
ones too restrictive.
I want my language to have the following trial path:
existent root -> syntactic phrase (possibly including derivational
lexemes) -> compound lexeme (compound word with types and hierarchies,
or supra-word lexeme) -> (new root ??)
I wrote "(new root ??)" because I should support it, but I don't want
to use it for the core language. This suggests that I should
allow metaphors in compounds by default.
>> The idea is to have a multi-typed, hierarchical
>> word production system
>> that lets speakers build new words by combining
>> existing ones in
>> different ways, instead of having to create most
>> new words from
>> scratch. This seems more natural, better for
>> mnemonics and more fun.
>> But it should be clear that those are new words
>> with their own
>> meanings, only partially determined ,at most, by
>> their production method.
>
> This is probably the linguistic parallel to
> building macros, though a bit freer.
>
Interesting comparison. Some compound lexemes (for instance, in some
technical jargons) could act *exactly* as macros, in the sense that
they would be a shorthand for a long syntactic phrase. We may call
them "shorthand lexemes". For instance, in thermodynamics, after we
have some basic notions such as mass, temperature, volume, heat, work
and energy, we can define others such as enthalpy and entropy using a
formula for each one. Whenever you encounter a sorthand lexeme, you
can replace it with the formula. This is cool, but you can never
improve the expressiveness of a lexicon by adding shorthand lexemes.
So, I also need compounds that are totally different from a macro.
On the other hand, I need macros for making the syntax more concise
when convenient. I'll elaborate in another post, where I'll try to
outline a first sketch of a syntax. Needless to say, this is
exploratory and subject to rapid change. I'm nowhere near of having a
usable language, but I'd like to share some ideas I'm considering. I
don't even have a native name for my language, since I have no fixed
lexicon yet, so I've codenamed it VOCALL (Versatile Ontology-oriented
Compound-based Auxiliary Logical Language) for convenience.
Regards,
Martin Baldan