Giter Site home page Giter Site logo

philosophical-language-group / freetnil Goto Github PK

View Code? Open in Web Editor NEW
25.0 7.0 4.0 96.89 MB

A community driven philosophical language

License: GNU General Public License v3.0

Shell 0.83% HTML 0.20% XSLT 98.97%
conlang ithkuil conlangs nlp parsing communication

freetnil's People

Contributors

ntsekees avatar porpoiseless avatar syst3ms avatar toimine avatar uakci avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

freetnil's Issues

Switching to Markdown

I think orgmode is fine, but there are a few issues:

  • There’s less support for rendering org files, while Markdown is ubiquitous.
  • Markdown doesn’t require you to use zero-width spaces to resolve weird parsing edge cases.
  • Markdown is what we already use here—for GitHub Issues.
  • GitHub renders org files with the headings off by a level (the main sections of an RFC should be h2’s, not h1’s).
  • Orgmode depends on Emacs features for plugin extras and easy editing. Other editors don’t get such Emacsian luxuries (at least not to such an extent). Markdown, on the other hand, is a level playing field.
  • GitHub-Flavoured Markdown has table syntax, so that’s not a problem.

May I have everybody’s consent to rewrite the org files into Markdown? Or am I being too ridiculous? cc @porpoiseless.

RFC 0003: regarding Cr

I agree with the heart of the proposal and how you plan to implement it for Cr roots.
For Cs roots, I make a separate post

18-cell grid with a 24-cell grid.

Technically not exact, because for many TNIL roots, only Stem 1 has all of its Specifications explicited. So this is just a 4 Specifications + 2 other Stems + three FML = 9 cell thing. Not really a grid, since you're expected to devise the Specifications by yourself, which might be even worse, as:

  • there is no rule for doing so
  • if the definitions of the 4 Specifications count as "rules", then why not use those rules for Stem 1 also (if they are productive enough..)

We can extract several law-like observations from this table:

I would change the wording to "This root exemplifies several observations that can be worded as"

Further remarks

There is worse. Specification does not play well with Function.
Take for example the BSC of -G-: (to be) an instance of bodily ambulation; to ambulate

Because there is a (to be) before an instance of bodily ambulation, and because to ambulate has clearly a more verbal reading than an instance of bodily ambulation, it can be deduced that:

  • an instance of bodily ambulation is the STA nominal reading
  • to be an instance of bodily ambulation is the STA verbal reading
  • to ambulate is the DYN reading

This is problematic in many ways:

  • the nominal/verbal distinction is left undefined for the DYN reading
  • for many roots, the STA nominal reading is just "a state of ...", this is not very useful, and can be easily derived via a VxCs
  • for roots that have a "to be a state of ..." CTE, this is even harmful, because this prevents from transparently using any other cases than THM. The only transrelative case that is meaningful and useful with "to be a state of ..." is THM. Other cases could be used, but that would not result in something useful. For example, using ERG with a "to be a state of ..." verb would mean "(it) causes sth to be a state of ...".
    This is meaningful, but far from useful. It is way more interesting to have instead: "it causes sth to be in a state of ..."

So the default meaning, for a STA reading, should be "to be in a state of ...".

[[note: the Format solution allows that by using STA + an AFF Format]]

Having "to be a state of" is harmful because it adds a layer between the base meaning of the root, and the argument structure that Cases can access. The core slots/roles of the base root are not usable anymore, only remains the mostly ininteresting "THM is a state of ..."

hereafter called Format

Sounds a good name to me, but we should be wary of two things:

  • the terminology "Format" already exists, and have another meaning, albeit a similar one
  • it's better to not mess up with JQ's terminology, which will directly cause incompatibilities. If we invent our own, it might suffer from incompatibilities if JQ decides to use it for his own dark designs, but this is not sure.

Which of ABS-clown-(verbal) you-CTE and ABS-clown-(verbal) you-THM would be correct?

If angry-(verbal) you-AFF this-CTE means ‘this is [an instance of] you being angry’, then
ABS-clown-(verbal) you-CTE should mean "you are an instance of 'being a clown'" / "you are a state of being a clown"

So ABS-clown-(verbal) you-THM is more correct to me

SNT EFF MPL

What are SNT and MPL?

Also why did you not consider the EMBodiment and a new ConTEnt that I've proposed? (just curious of the reason)

TODO: how about implementing inverse Case accessors, too? This would help shave off a significant amount of coantonymic Cases. Observe that V’V forms are not restricted to monophthongal Vs, and instances of )

Implementing case accessors seems worth, but I think it's better to do it by inserting an h for reverse accessors. This is simpler and cleaner (and personally I don't mind [ç~j̊] and [ʍ], which I expect to appear when inserting h in a diphthong)

The lexicon is redesigned so that every root has at most six definitions (2 Designations × 3 Stems); it is not required that every root have all of its Stems defined.

If so, we should enforce Stem 0 as being the generic Stem, not Stem 1.

(TODO(anybody): discuss removing Designation in favour of a large pool (5–8) of Stems).

I would prefer having a semantically-productive Designation rather than an opaque one, but allow to describe "reasonable gloss" in the dictionary.

Having an opaque Designation only makes sense, IMHO, if it is really irregular (not just "domesticated version of" or "in a quasi-permanent context"), and is not just a lexical kitchen sink

For example, the FML of -Ň- (from the v3.1 list) are good to me, but those of ith2k11's -ŇKY- are not

RFC 0003: Regarding Cs

2020 Ithkuil’s Affixes document defines six affix gradient patterns (see p. 3 therein); however, they only conceal the fact that there is no feasible way to derive the degrees from the consonantal affix values.

Is it that bad?
Consider the reverse: all affixes are perfectly regular. This makes Vx pretty useless as a slot. One important vocalic slot is wasted just for precising the degree the affix.
Even if it's more irregular, I think it's more efficient (from a cognitive standpoint) to:

  • have a globally regular Gradient with a clear progression from Deg 1 to Deg 9
  • allowing irregular connotations in Degrees

The degree assignments are predominantly pragmatics-driven

Is it that bad?

Some VxCs are pretty interesting, like PWF (part to whole functional metaphor).
It seems convenient to me to be able to quickly derivate such part to whole metaphors.

Though I agree with you, many VxCs are just bag-of-words at best, and do not seem useful at all.

having no semantic impact, do not correspond to any root in any way, nor under any mapping

Okay this is bad.

This is unacceptable: an ideal Ithkuilic language would ideally restrict its irregular syntactic affixes to a minimum

I agree, but the only syntactically irregular affix is, IMHO, TPF. (DCD and SQP are weird, but do not introduce new syntax, it changes only the meaning of the surrounding syntax, so this is not as bad as TPF)
As for COO and friends, I don't worship with JQ's adverbial interpretation of connectives, but it is coherent and interesting.

In addition, it is a great drawback that only those roots which John Quijada has considered to render as affixes can be used as affixes, with all other roots only appliable via incorporation or periphrasis.

Agreed. We need a general mean to make Cr and Cs work together.
Even if, as I've said above, I don't think removing all suffixes with irregular gradients will make the language better / more usable..

Anyway I'm also dubious about the solution you propose replacing Degree by Case-Acc'.

I don't think it will work because in order to be morpho-phonologically efficient, we have to use very few structural morphemes. But using Case takes a lot of space..
Moreover, Case has too much features for what we need.
We don't need 70 Cases for just applying functions to other functions, and gaining a new function (an affix) as the result.
Using all the power of Case can provide handy shortcuts, but morpho-phonologically, I don't think it will pass.

Instead, for combining Cr and Cs, I propose to make a new, trimmed version of Case based on Latejami.

Latejami only considers 4 roles: Agent, Patient, Focus (THM), and Agent-Patient (IND), but, contrary to Ithkuil, expands a bit their semantic, and rely on a powerful case-tag system for creating other roles (like Lojban's {fiho})

Let's work through an example, and build the suffix:

-rc DEG4: X number of seconds

with

-RV- S1: a second

-LG- S1: amount of elapsed time over which an event or state occurs

I assume that -LG- can be used that way:

> -LG-(verb) this-AFF second-THM two-COM

< ‘This takes 2 seconds’

ABS is not appropriate since it implies an agent.
On the contrary, Latejami's Patient is more general and contains both ABS and AFF.

Let's first define a new Vx Slot, that will show, among other things:

The Four Latejami Role: A / P / F / AP; plus an "operator"/verb role
    ×
Type 1 / 2 / 3
    ×
Stem 1 / 2 / 3
    ×
return / applied

So -rc DEG4 is modelled as:

P-return-RV-(Stem:1)-F-applied-operator-(LG-Stem:1)

where P-return is a value of this new Vx which shows that the thing to which this suffix is applied

  • plays the Patient role in the relation described by -LG-Stem:1
  • is "returned" after the application of the suffix (the formative still refers to it after)

where F-applied-operator is a value of this new Vx which shows that RV-(Stem:1) is the Focus argument of LG-(Stem:1), the "operator" (verb) of this suffix

With only four cases to consider, there will be enough morphological space to show other interesting things like Type or Stem (and maybe other things like skewers's Closure).

However, reforming VxCs as we currently know them will be a massive task
Many of them are based on simple concepts (they don't require the trick described above based on Latejami's), e.g. FRQ; so Cr roots should have clear semantics right from the start if we want to use them as Cs.
For those that could use the Latejami's trick described above, things will get messy quickly. For example, it is possible to generate the suffix RPN Deg1 "slow-paced repetition at regular intervals" as the application of "... repetition at ... intervals" on "slow" and "regular" but this will not be verbose only if "regular" and "slow" have their dedicated roots and Stems.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.