Useless Factor

> What i was hoping for was some kind of term for one character or symbol and use that as a unit There is one, kind-of: "grapheme cluster"[0]. This is the "unit" used by UAX29 to define text segmentation, and aliases to "user-perceived character"[1]. Most languages/API don't really consider them (although they crop up often in e.g. browser bug trackers), let alone provide first-class access to them. One of the very few APIs which actually acknowledges them is Cocoa's NSString — and Apple provides a document explaining grapheme clusters and how they relate to NNString[2] — which has very good unicode support (probably the best I know of, though Factor may have an even better one[3]), and it handles grapheme clusters through providing messages which work on codepoint ranges in an NSString, it doesn't treat clusters as first-class objects. > i guess if you asked a Sanskrit speaker how long a word/sentence was, you'd get the answer.. Indeed. [0] http://www.unicode.org/glossary/#grapheme_cluster [1] http://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries [2] https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptua… [3] the original implementor detailed his whole route through creating factor's unicode library, and I learned a lot from it: http://useless-factor.blogspot.be/search/label/unicode

If Church numerals’ unary representation bothers you, there is an efficient embedding of naturals in λ-calculus as linked lists of Booleans. Well, more efficient than the alternative… http://useless-factor.blogspot.com/2007/04/thoughts-on-church-numerals…

It would be nice to have an IDE that surfaced something like the AST. Of course lots do to some extent, but I bet there is room for improvement here. This also seems like a place where Lisp would have an advantage since the syntax is so transparent. For readers of yesterday's article about whether all the "easy" stuff has already been accomplished, here is an easy-to-read survey of the state of the art in diffing trees: http://useless-factor.blogspot.com/2008/01/matching-diffing-and-mergin… That sounds like a pretty interesting topic to research! And I note that his oldest citation is from 1997, and most are from the last ten years. He also briefly mentions "operational transformation," which I agree seems related and is another area of ongoing research. Both topics seem like they would have lots of practical applications, but right now the general-purpose tooling is weak or doesn't exist. So there is room not just for research but also for folks to implement that research.

> I don't know what the intended use case actually is, Generally speaking, if you've got a database system of some sort and want to write data to a file. > It's still not enough: with write ordering and notification but no instruction to actually write the data soon, the kernel can buffer it indefinitely. That's not really the problem -- being able to say "do this write operation after this other write operation" would let you pump modifications into some file at a faster rate than if you had to wait for every fsync. Suppose you have a modification that needs to be done. Right now, you might say, write a batch of blocks, wait for them to complete, and then write another block elsewhere (a new "superblock" or whatever the terminology you prefer is). Well, you'd rather send all the blocks simultaneously and say "the superblock write should happen _after_ these other blocks'". (Another option is to checksum the new blocks referred to by the superblock, but that requires pulling them up to the CPU and checksumming them.) (And there are other options that are more complicated with other trade-offs -- it would be nice if you could just send multiple blocks to write, with a partial ordering specified.) So, even if you had no fsync at all, you'd be able to pump modifications into a database file faster than before. Without some kind of fsync, you couldn't confirm they'd ever been written. With a fine-grained fsync or "flush and notify on a per block basis" call, you can…