Hallo conlangers!

On Saturday 25 January 2014 18:41:44 And Rosta wrote:

> And Rosta, On 14/01/2014 23:58:
> > Xorban had the potential to be a state-of-the art loglang, and the
> > first ever loglang whose design is not patently a failure. (No
> > disrespect meant to Liva or its creator.)
> > 
> > For reasons I lack time to explain in this message, I suspect that a
> > viable loglang design is a mathematical impossibility (tho I am
> > hardly the most competent person to judge that), but Xorban would
> > represent about the closest to a viable loglang that anybody's been
> > able to conceive of. I take it that a viable loglang design makes the
> > language suitable for general purpose use and no less effectual than
> > natlangs. But even if that proves impossible, an ergonomic loglang
> > could be quite useful to the world.
> 
> I should explain the above more fully.
> 
> I define _loglang_ in a specific way. This humptydumptyism seems to me to
> be licit in a way that it would not be for, say _engelang_ and _artlang_,
> because whereas humptydumptyism with these would subvert discourse, since
> engelangs and artlangs are important natural kinds (of conlang design) and
> hence in need of terminological labels, there is no clearly preexisting
> natural kind waiting to have the label _loglang_ applied to it. But there
> is a certain kind of engelang goal that I think is important and this is
> what I call _loglang_.

Humpty Dumpty sat on a wall.
Humpty Dumpty had a great fall.
All the King's horses, all the King's men
Count not put Humpty together again.

Sorry, but I don't see how humptydumptyism is less illicit with
_loglang_ than it is with _artlang_ or _engelang_.  The word
_loglang_ means 'conlang that implements a system of formal logic'
and has been used with this definition for decades.  Changing the
definition would mean moving the goalposts.

As far as I know, it is defined as given below:

1. _loglang_: Any language that implements a system of formal
   logic.
2. _loglan_ (not capitalized): A language that is based on the
   principles laid down by James Cooke Brown in his article
   "Loglan" in 1960.
3. _Loglan_ (capitalized): The language proposed by James Cooke
   Brown in 1960.  Sometimes called _TLI Loglan_ to avoid
   confusion with the definition under 2.

Lojban is a loglan and of course also a loglang (a loglan, after
all, is a specific kind of loglang), but it isn't Loglan.

>       Here is the definition:
> 
> 1. For any predicate--argument structure (PAS) of any degree of complexity,
> the loglang encodes it unambiguously and losslessly. This is the basic
> criterion for loglanghood, and is very easy to achieve.

Well, unambiguity falls out from the implementation of formal
logic, I would say.  If the language is ambiguous, it has a bug ;)
(Before people cry out "But natlangs are often ambiguous!", let
me note that I am speaking specifically of *languages that
purport to be loglangs*, not natlangs or naturalistic artlangs!)

But is unambiguity *only* attainable by implementing a system of
formal logic?  If not, there are languages that aren't loglangs
by the usual definition that fit your definition.  I think
unambiguity can be attained by introducing a strict case marking
system that directly encodes semantic roles, which doesn't make
the language a loglang.

Or is the formal logic presupposed by your definition of a
"predicate-argument structure?"  If yes, what you define is a
kind of loglang, but I am not sure that it is equivalent to the
common definition of _loglang_.
 
> 2. The criterion for the success of a loglang design is its usability.

Right.  An unusable language is a bad language ;)

> (a) In particular, the successful loglang encodes PASs in on average no
> less concise way than a natlang does. Natlangs and 'para-loglangs' like
> Lojban do this lossily, by not encoding some of the PAS. (Lojban is lossy
> and reasonably concise, or lossless and unusably unconcise.) The criterion
> of conciseness is a criterion of ergonomicality: the cost, in user time
> and effort, of the unambiguous lossless encoding must be minimized.
> (Incidentally, concision is to be measured in a phonology-neutral way.)

What do you mean by measuring concision "in a phonology-neutral
way"?  Counting morphemes?  Concision is not a bad thing, but
redundancy is a good thing, too.  The best solution is not maximal
concision, but a balance between concision and redundancy.

> (b) More generally, the loglang design should be usable by humans. In
> increasing order of importance: how easy it is to learn; how easy it is to
> write and speak; how easy it is to read and hear. The less the design
> piggybacks on the natural language faculty, the harder it will be to use.

Sure.  This is, I feel, a general problem with loglangs!  As I
observed earlier, language and formal logic serve *different*
purposes; hence, it does not seem sensible to me to base a
language on formal logic.
 
> Standard predicate-logic notation and loglangs like Liva and Lojban and
> Xorban use a notation that repeats an argument-value for each predicate it
> is an argument of. This is anticoncise and also antiusable, since it
> requires the user to maintain in memory a temporary onomasticon of
> assignments between variables and the temporary name for the variable.

Fair.  I never found loglangs of this kind easy to use.  The
human language faculty is simply not made for them, I think.

> (But Xorban gets about as concise and mnemonic as is possible within this
> general method.) In 2D-Livagian notation, symbols represent only
> argument-places, and when arguments of different predicates have the same
> value, this is shown by placing the symbols for the argument places on the
> same row of a grid. But this is a two-dimensional grid-based notation, and
> not straightforwardly linearizable. Ordinary spoken Livagian relies on
> long inflections encoding combinatory operations between a list of
> arguments of the incoming predicate and a list of still-discourse-active
> argument-values from the sentence-so-far. The result is that m ost of
> sentence-form consists of inflection, and (!D) Livagian's fundamental
> list-combining mechanism of syntax probably fails to piggyback at all on
> the human language faculty's special talents.

As you have never shown us Livagian and how it works, I cannot
say anything about its qualities.
 
> Having essayed this explanation, I'll now essay, in another message,
> replies to the many interesting contributions from others.

Do so.

--
... brought to you by the Weeping Elf
http://www.joerg-rhiemeier.de/Conlang/index.html
"Bêsel asa Éam, a Éam atha cvanthal a cvanth atha Éamal." - SiM 1:1