I'd meant to mention this at some earlier point; notice how naturally whose translates here:
VT `CLĀMŌ CLĀMĀMVS' DĒCLĪNANTVR VERBA QVŌRVM ĪNFĪNĪTĪVVS DĒSINIT IN -ĀRE (Like `CLĀMŌ CLĀMĀMVS' are declined words whose infinitive ends in -ĀRE.)
>>133
It has been discussed here already.
>>134
Murderers breathe air. I can begrudgingly use something. The URL is a fine example of where domain acknowledgment so often isn't done; rather than parse a URL into a real data structure, they're often passed around verbatim, and there have been many flaws resulting from conflicting views thereof.
The Internet has no bearing on Elision any more than it does on, say, ASCII or Unicode. While I seek to minimize the size of messages, this is a general advantage.
That said having a document where each word is a symbol in say a namespace or linguistic environment pointing to data about said word might be kind of cool.
This is what a tertiary dictionary would fulfill. For useful but unnecessary information, such as storing synonyms, there would be a dedicated table that must be used with a dictionary, but without which the dictionary can safely be used. In any case, Elision is primarily concerned with form, not semantics. The word pump has different connotations in medical or engineering contexts, but the word is the same.
Maybe an IPFS hash instead of a URL, to facilitate persistence, with some means of linking earlier instances of community maintained db's (linguistic namespaces/environments) to later ones.
I figure IPFS is larger and more complicated than the entirety of all of the code I'll write ever will be. I've no interest in implementing my beautiful idea as a tumor on an elephant.
Would also probably facilitate autotranslating language documents.
I mean, we kind of already do this with things like spellcheck, it makes sense to move the spellcheck db into actually being part of the document itself.
All of this should happen without any Internet connection necessary. Spell checking is something that naturally falls out of Elision.
A pretty dependent clause?
The word what is a pronoun is the point.
I was careful not to read any commentary before I had written my own.
I'm glad to have such a dedicated reader.
If I follow the approach is one of structuring the state-space from the top down, and using lookup tables at run-time.
That's how I did it there. For a different problem, I may have thought of the composition rule beforehand, and will be able to exhaustively compare these to the full table afterwards.
You must understand I'm a mathematician and learned to program from SICP.
I never finished SICP; I barely read any of it, really; I prefer TAoCP.
As such the conversion of a rule into ad hoc cases does not naturally sit well with me.
It's ad hoc compression, sure, but it's a fun way to program.
It even depressed me slightly to read this; where has the spirit that lives in the computer gone?
It exists in the tiny composition rules, in checking my proofs, and in automating whatever else I need for the table construction.
I agree that analyzing a state-space can be a useful tool, but disagree that it should be dominant.
This is what I want Elision to resemble. I want to find the limits of the approach in general.
Having multiple perspectives on a problem tends to be beneficial.
Yes. I've never seen programming really done this way. It's novel, and unique.
I suppose my fear is that a large number of ad hoc modifications would be difficult to know, and unless reality dictates otherwise knowing is more important than computation.
Better tools can ease this.
I really did enjoy the article though. It was very understandable, and made me think of things I hadn't before.
I'm glad.
There may just be a cultural difference here which I need to ponder further.
Do let me know how that goes.
>>138
Don't apologize to me for such things. I'll make it known if I be offended.