binrec
Well, I'm sold. Where do I buy Palmer amaranth? What about water hemp - is it edible?
Another issue I ran into recently is that `Symbol.for(str)` will cause the entirety of `str` to be allocated forever in Chromium, but not in Firefox. (It's inevitable that `Symbol.for()` will have some memory impact, as a global allocation, but it's possible to mitigate it somewhat.)
IMO it's too bad that the effort to create a Node-alike driven by Spidermonkey instead of V8 never got anywhere.
In English, "rock" and "human" are loans and "cloud" is an innovative form.
> For Proto-Japonic, we introduce two distinctly different versions of the wordlist, since there are some significant unresolved problems in its reconstruction where adhering to one or the other solution influences the results of testing – namely, the reconstruction of Proto-Japonic by Sergei Starostin (1991), later adopted for the Altaic etymological dictionary (Starostin et al., 2003), posits an initial *d- for Proto-Japonic, whereas a more conservative approach prefers the phonetic interpretation of the same phoneme as *y- (Martin, 1987, gives no preference to either approach; both Vovin, 2005, and Robbeets, 2005, explicitly reject *d-; see Supplementary Material for details). Ultimately, we have to perform two sets of calculations because of these differences in interpretation of Proto-Japonic phonology.
There's no legitimate reason to follow Starostin here - that reconstruction is based on back-projection of an obviously secondary fortition specific to Yonaguni.
Lexical comparison isn't the standard for demonstrating language relatedness, though. Regular sound correspondences, morphological evidence, and commonalities in irregularities (e.g. English I/me ~ French je/moi or English good/better ~ German gut/besser) are ideal. Quantitative methods range from extremely preliminary to nonsense.
This might be unfair of me, but IMO research from the Greenberg school (the Starostins, Bengtson, Ruhlen, etc.) or the automatic phylogeny school (List, the ASJP, etc.) can pretty much be ignored.
There are parasitic plants that don't photosynthesize at all, like the Monotropoideae and Rafflesiaceae.
Among photosynthesizing plants, rhubarb can be "forced" (grown in complete darkness to reduce bitterness and get an earlier harvest), and potatoes can sprout if left in the pantry for too long.
(In the US, a gherkin is a small pickled cucumber. A cornichon is a type of gherkin, but there are other types.)
On balance, having a hype man for [PayPal Mafia voice] innovation in the world of atoms seems like a good thing. Musk may not be the best person for the role, but you probably have to be a little crazy to want to be a celebrity in the first place.
I don't know much about the mobile world, so this may be a stupid question, but could you route around the app store problem by making a progressive web app?
I assume a backend of some sort would be necessary, since JS in the browser is a pretty limited environment, but if Chalkinator Desktop is handling your server setup anyway, it could install a personal backend on it for you, and the PWA could talk to that.
Existing attempts to solve this problem are hackish and difficult to customize: they typically treat each glyph as a set of features and handle diacritics and digraphs by naive composition and awkward special-casing. They also aren't written with an eye to customization in either alphabet or featural model: they typically map an ad-hoc extension of IPA to an ad-hoc featural model.
I think a natural improvement would be to develop a specification language in which each individual glyph (base character or diacritic) is a function from a feature set to a feature set, with Haskell-style pattern-matching to allow graceful handling of digraphs and context-sensitive diacritics - although syntactic sugar for digraphs would in practice be required for usability. Ideally it would also be possible to map feature sets to feature sets, in order to preserve a human-readable intermediate form (e.g. "unvoiced dental plosive") which is later mapped to the more customary binary features.
In addition to the utility for phonological databases and the like, this would also enable more rigorous testing of crosslinguistic feature sets: every feature set is implicitly a set of proposed linguistic universals and existence claims. If two segments have the same featuralization, they should never contrast in a given language; if they do, the featuralization is unsound. And if a featuralization proposes the existence of many contrasts that aren't attested anywhere, it could probably stand to be optimized.
But most of my interest in this comes from my work on a phonological database. The database needs some method of handling featuralization to facilitate feature-based search, and I just haven't seen a good way to do that yet.
...and now that I've complained about it I notice that there are extensions to enable regex search in the browser itself, nice
I have pretty bad eye floaters, and they're more visible in bright light. Having crud bouncing around my entire field of vision does not make for an easy or strain-free reading experience, so I enable dark mode whenever it's an option. I found checking Zulip at work pretty unpleasant until I realized I could enable dark mode.
If you're running a scientific study and basing your conclusions on the average of all participants, you might not pick up on things like that. And if you're running a scientific study on people with normal vision, a sufficiently strict definition of "normal vision" guarantees that you won't pick up on that, although the studies in question probably didn't use so strict a definition.
Even if dark mode is "scientifically worse" for most people, whatever that means, it's a useful accommodation. In fact, the Nielsen Norman Group article that this post links to argue against dark mode recommends dark mode as an accommodation for people with vision impairments.
The methodology probably wouldn't be comparable to Tyshchenko's, but there is an estimate for the lexical distance between Tocharian and the other Indo-European language families (10.2307/601651) - Tocharian comes out closest to Germanic and Greek.
Then again, Tocharian wasn't spoken anywhere near Europe when it was attested, so it isn't strictly within the scope of the map - but it's unclear how it got there. The most popular view, as far as I know, is that it was the second family to branch off of Indo-European, after Anatolian, but Adams showed that it shares some innovations with Germanic (the reflexes of syllabic resonants and the expansion of the singulative function of the n-stems to adjectives) and Greek (a locative dual *-oisi, represented in the Tocharian B genitive dual), and Eric Hamp placed Tocharian in a 'Northern Indo-European' subgroup with Germanic, Balto-Slavic, and Albanian.
Yes, and many imperative languages allow you to use, in an idiomatic manner, a functional style that avoids mutable state, even though these languages aren't designed around the functional paradigm, and don't require you to adhere purely, in the colloquial sense that means "strictly" or "completely" but has fewer letters, to it. And the reason for this is that people have taken ideas from languages that were designed to be functional rather than imperative.
If you want to bring up map and reduce, what's their genealogy? Did the imperative world get the idea from ALGOL? Maybe they did, but I'd be surprised.
>See? Concatenative programming in javascript. And it's not less convenient.
It still isn't great. To avoid stepping outside the paradigm, you have to be willing to curry every function that needs multiple parameters. And I don't know what that recursion is doing there - presumably I don't know what I'm talking about again, but it seems to me that the entire body of `xToYPower` could be replaced with `return y => x y`.
Yes, but that's beside the point. I said "style", not "paradigm". The basic structure, not the totality of the thing. I don't know what CS researchers would think of this distinction, but it seems convenient to have in practice.
You can use a functional style in Javascript without insisting on pure immutability throughout your entire project, and there are advantages to being able to do so. There are also advantages to being able to use a concatenative style, which is why the pipeline operator was proposed.
It would be possible to rewrite that code to use an immutable stack, but for the purpose of illustration - specifically, illustrating that there isn't currently a good way to write in a concatenative style in Javascript - I don't think it's necessary. You can use the style without the paradigm. (Besides, the reference implementation of Joy mutates the underlying stack variable, and if the way to get a concatenative paradigm in standards-compliant, runs-in-a-browser Javascript is to Greenspun's Tenth Law a concatenative language...)
The better option would've been not to use a stack at all, and illustrate it with integers, as you've done here. But you'd still need some way to manage multiple variables to use a concatenative idiom to compute 2x^y.
>Also your examples literally defeat the purpose of functional and concatenative programming. It makes the code worse.
Right. You can follow the rules of the paradigm in Javascript, once you've written enough of an interpreter for a concatenative language to let you do so, but it'll make your code worse. But there are languages that are designed for the paradigm - and in them, you can write good code that follows the rules of it.
>Javascript has been giving bootcampers completely wrong ideas about functional programming and what it is. Learn a real functional programming lang to actually get it. Haskell is a good one.
Not a bootcamper - even worse, I work in a warehouse - but I might quit and become one once my stock options vest...
Here's the best I can come up with:
function compose(...funcs) {
return stack => funcs.reduce((acc, cur) => cur(acc), stack)
}
function dup(stack) {
stack.push(...[,,].fill(stack.pop()))
return stack;
}
function mul(stack) {
stack.push(stack.pop() * stack.pop())
return stack;
}
const square = () => compose(dup, mul)
console.log(square()([4]))
function dup(stack) {
stack.push(...[,,].fill(stack.pop()))
return stack;
}
function mul(stack) {
stack.push(stack.pop() * stack.pop())
return stack;
}
const square = stack => stack |> dup |> mul
console.log([4] |> square)
console.log([2] |> square |> square)
The page for Joy, Manfred von Thun's concatenative language, is a little better:
> Joy is unusual ... in its ... lack of formal parameters.
So, where in a standard ALGOL- or C-type language, you'd define a function that squares a number like this:
def square(x):
return x * x
let square x = x * x in square 2
dup *
DEFINE square == dup *.
Now, Joy in particular was written as a research language about recursive combinators. So a mostly-idiomatic* factorial function in Joy looks like this:
DEFINE fac ==
[0 =]
[1 +]
[dup 1 -]
[*]
linrec.
The neat thing about this is that you don't need to define functions and reference them from inside themselves in order to get recursion, and you can write code that's a little more legible than using the Y combinator for everything. You could also write something like this:
DEFINE fac-explicit-recursion ==
[0 =]
[pop 1]
[dup 1 - fac-explicit-recursion *]
ifte.
`linrec` is a function that expects four quoted functions as the top elements on the stack. It executes the first function; if that 'returns' true, it executes the second one and stops, and if not, it executes the third function, recurses, and then executes the fourth.
A while ago, I started working on a Joy interpreter in the browser. I haven't gotten around to finishing it yet, but it's at least working well enough that you can (hopefully) step through the https://defseg.io/joyjs/
For a flashier example (which won't work there right now, because I haven't implemented... `binrec`... yet), here's quicksort:
[size 1 <=]
[]
[uncons [>] split]
[[swap] dip cons concat]
binrec
But if the condition is false, it executes the third function to produce two values, recurses on both, and then uses the fourth function to combine them. So you get your pivot, split your list, recurse on both lists, and then stitch the two result lists and the pivot back together in sorted order.
* 'Mostly' because you'd actually write `[null] [succ] [dup pred] [*] linrec`, but the two functions are identical. (`null` is overloaded to also test for zero elements in an aggregate, but if you pass it an aggregate it'll throw a type error anyway.) Similarly for quicksort: `[small] [] [uncons [>] split] [enconcat] binrec`.
The framerate isn't great - is drawing to the favicon inherently slow, or can it be improved? - but it's at least somewhat playable.