smosher_

It's because the generator recurses with:

    return fself(num - 1) + fself(num - 2);

instead of calling fib (or fib_gen) explicitly. fself is passed into the generator and it will need to be passed in again and again. That's what Y gets you. You could get tracing the way you suggest from something like:

    let fib f n =
        let n' = (* compute fib for n *) in
        f n'

and supply some f that will log (and return) the computed values, but that won't work with the motivating example: memoization. This really should have been clearer in TFA.

It's worth noting the memoization in the linked gist isn't pure. memo() allocates a cache and returns a function that references it. The cache is updated by mutating in place. After all the hoops we've jumped thorugh it's a bit of a let-down to end up here. (It's doable though.)

(Edit: improve clarity.)

If you read the comment you'll see that I'm talking about different interpretations of memory safety. You can't just decide what it means in Rust applies to all languages, or that everyone knows what you mean.

I was trying hard to have a conversation while avoiding arguing about semantics, so thanks for that.

> My objection is that I see unsafe just for memory integrity.

Either you think this way because of a sense of orthodoxy or because you think memory safety is important in a way the other kinds of safety aren't. I disagree, especially since "memory safety" may or may not imply protection against aliasing of mutable data. Those nuances I like about Rust probably wouldn't exist without the broader scope of safety concerns.

> As for voicing my objections to the Rust community,

About the discussion you linked? I meant to me, in the service of explaining your objections.

> My time is already quite filled following the JVM, .NET and C++ eco-systems, the ones I get payed to be an expert on.

Well, that was important information. Thanks for making the time to share!

> They are abusing it, specially as workarounds for constraints that cannot be expressed in the type system.

That doesn't sound like abuse to me, as long as the exposed interface remains safe.

> some Rust devs are using it for anything they assume isn't logical safe.

That sounds like an objection to the scope of what Rust defines as safe. Unless you mean to imply there are reasonable, Rust-safe ways to rewrite the transgressions. In the former case I have to disagree. It would be nice if we could prove more. But you can't prove everything.

I haven't seen the ICFP talk but I might watch it later if you can link to a video. I've skimmed that discussion before but you will need to point out your objections—IMO it is great that Rust devs are having that discussion.

> new generations never heard of those languages and think C was the very first systems programming language.

That's just it. Rust looks enough like C++ to catch on. This was not an accident though I can't say I'm jazzed about it.

Rust brings a lot to the table with its type system too. I would rather be using Rust tomorrow than having had the benefits of say Pascal derivatives for the past 45 years. I'm not saying this just for effect: after the obvious ML influence, the parts of Rust I like most are the nuances.

> Instead, many Rust users seem to sprinkle it everywhere.

Is that true? You will necessarily see it in bindings, or to implement certain essential features that can't be implemented otherwise. Beyond that there is the motivation to use unsafe code for speed, hopefully this is mostly restricted to modules.

Are you complaining that people are using when they could reasonably avoid it or that it is too often necessary?

> To me, green threads are just an implementation detail. The fact that green threading is being used shouldn't leak into the interface.

I think that mentality, which I supported, may be what ruined green threads for Rust. Perhaps the enemy was the perfect of the good. On the other hand, maybe not having to worry about differences is the better benefit. I would rather be slower-but-acceptably-fast than have to think about 1:1 vs M:N threading in the case that they are not interchangeable.

On the third hand, it could be that Rust is too close to the metal for green threads to be of any significant benefit. If that's the case, Rust ought to trounce all the M:N implementations, subject to reasonable limits on spawn rate, memory pressure and inter-thread communication. Does that sound right?

Incidentally, I've never seen a cooperative threading implementation that didn't have a yield call of some kind available, and you can usually jam any of them up by writing an infinite computation-only loop, so even in the langauges where the scheduler is automatically invoked, correct 1:1 code can deadlock in the M:N scenario. State machines can too, but a trivial example, translated, might read something like the following:

    for(;;);
    exit(EXIT_SUCCESS);

I've seen code like this written by complete newbies, but threading constructs can hide that relationship even from experts. In parallel code it isn't a sequential relationship, but it is with cooperative threads. I guess this is all fairly pedantic (such a minor detail, mostly affecting only poorly-written programs), but in the end, one of: yield(), sched(), sync(), etc. does show up in practically all of the cooperative threading interfaces.

Blocking at the request level is where it's at: you don't download the content, you don't execute the scripts, you don't interact with the DOM. You block requests to third party servers or resources based on lists or other policies. This saves you load time, execution time, and it keeps you from being tracked by targeted ad systems.

If people start bypassing the DOM with canvas we will have a bigger problem than cosmetic filters failing: we will no longer be served the same kind of document. Or we will, but the content will be in an opaque region of it. If that happens the web is dead. People tried this before with flash and that smoldered for a while in the 90s but didn't last, so I'm not feeling all doom-and-gloom about it.

Aside: Standardized document formats are important. If rendering to canvas takes on as the defacto standard, it would cripple the web technologically.

That's a little extreme. I think most computations are best¹ written in a way that is amenable to mathematical treatment, and most of the useful ones can be. Just because a counter-example exists doesn't mean we should give up hope.

I find constructing programs mathematically makes life easier in the common case and possible in nearly all others, unless you insist on things like proof-of-termination for programs which do not (I do not.)

1. 'best' because it gives us the means to reason about the code, and we know what kind of transformations we can perform on it, and do them abstractly without having to simulate it, potentially for infinite inputs, etc., etc. You know the drill.

> Stuff like SmallTalk wouldn't be possible if programming was turned into math

> and frankly I don't understand why mathematicians want to take over a completely different domain

I would like to challenge the assumption here: that programming (in whatever mode) can't be adequately described by mathematics. I don't have time to make a thorough argument, but consider this: instead of thinking of what programming would be like as some kind of math, think of what math would need to be like to adequately describe your favourite mode of programming. (Forget arithmetic, consider algebra, geometry.)

As for FP: these days it wants all the tools, and it is picking up whatever it can formalize. Some FP tools are uncommon or don't work well outside the paradigm. To me that makes all the difference: I'd feel more restricted working without FP than by being strictly within it.

FYI the quote above refers to the develeoper/community response to criticisms/ideas (eg. see the comment I replied to), not the criticisms/ideas offered by newcomers.

I don't know what it's like now. Rob Pike in particular made a lot of noise like this early on. There was a lot of parrotting of that, so it was hard to have a serious conversation. It seems like it's still getting play but I don't know how widespread that is today.

I think it's a canary. How many languages do you hear this said about? I've only heard it in regards to Go which is fairly pedestrian (read: looks and acts something like C / Java) as far as these things go.

More exotic languages, which take the uninitiated longer to acclimate to, don't seem to be trying to tell people they're not allowed to think deeper about and question the design of the language. Good criticisms of Go were made on day 1 and are being made to this day, Rob Pike's ego notwithstanding.

At the end of the day, if I see a problem with a developing language I am interested in, I'm going to report it. If I'm met with: "I don't know you but I'll assume you don't know what you're talking about" that's a second problem and I'm not about to double-down on it.

Fwiw I avoid writing both loops and recursion as much as possible. Collection data structures usually come with their own fold/map/etc functions, so this works well in practice.

I posted this in another comment, but her github repo has a Ceptre implementation: https://github.com/chrisamaphone/interactive-lp/

There are details on getting the trace graphed in the tutorial. (If you want more detail in the trace you can uncomment the code on this line: https://github.com/chrisamaphone/interactive-lp/blob/master/... )

I'm a big fan of this work. For the PDF-shy, there's some excerpted text on LtU: http://lambda-the-ultimate.org/node/5216 but you'll miss some of the goodies, like the graph of a scenario from Romeo and Juliet, showing the actors act concurrently at different locations.

See also the github repo: https://github.com/chrisamaphone/interactive-lp/

There is an emphasis on using Ceptre for developing interactive fiction¹ (text adventures/parser games.) From my perspective, a pain point in developing truly creative interactive fiction is the tools available tend to impose a world model on your work. I'm excited for Ceptre because it lets you write causal relationships directly and that makes starting from scratch a more realistic proposition.

1. With some work I think it could be (and should be) used in other kinds of games, such as sandbox games or anything that would benefit from a living world, even if only in part if the main story must be nailed down and deterministic.

In case anyone is wondering which project this is:

    The concrete contribution of the research report here
    is the design and implementation of a fully compartmen-
    talized operating system, MINIX 3. To properly isolate
    faults, we have removed all drivers from the kernel and
    run them as separate, unprivileged user-mode processes,
    protected by the MMU hardware. Since all servers also
    run in user mode in our design, only a tiny microker-
    nel that does not contain any foreign, untrusted code is
    left in kernel mode. Each component has only the mini-
    mum privileges it needs in order to prevent failures from
    spreading. In our design, driver failures are no longer
    fatal and do not require rebooting the computer.

^A in bash will go to the beginning of the line. I don't know if this is why tmux changed the key, but it certainly makes a bigger difference to me because I use that function a lot. I rarely press ^S by accident (less often than I press it on purpose.)

The idea is you can write this:

    let _ = print_string "foo"
    let _ = print_string "bar"

at the top level.

Of course you can write

    let msg = "foo" in print_string msg
    let msg = "bar" in print_string msg

(which isn't at issue, except no semicolons are needed.)

But you can't write

    print_string "foo"
    print_string "bar"

without semicolons.

Philip Wadler's paper Monads for functional programming is the first thing I read that made any sense. FYI this is the horse's mouth.

Did you even read the article? The article's description of "beat" doesn't conflict with the musical term but yours does. In fact the article even relates beats to tempo and describes the results in terms of tempo. This is about tempo detection.

The reason this technique is called "beat detection" is it can be used to collect the individual beats from the stream contrasted with knowing the just the tempo doesn't tell you where the beats are exactly (and doesn't help a lick with finding the off-beats.) Tempo detection is only one product of these algorithms, and guesses can be constructed from any of them, though sometimes additional heuristics are needed.

The accuracy of the LPF technique is well worth criticizing. Yes, it's fairly good, but it's not the best one we have and the article says part 2 will describe a better technique. I should note that even organs and vocals can create transients that are often associated with beats. The LPF probably does better simply by eliminating false-positives.

I agree. The title is downright bizarre until you realize the article is consumed more by JS idiosyncrasies than about the OCaml modules.

Sure, no prob. BTW, if you're interested, you might want to drop by http://operator-1.com/ which hosts the (unofficial) forums. The Teenage Engineering staff are known to browse and even make posts once in a blue moon.

It's expensive but well worth it for the people who click with it. I would recommend trying one before you buy it, especially if you can spend a good amount of time with it. I felt a little let down during my first week or so with it, but then it clicked and became instantly essential. It doesn't go that way for everyone, but it seems most people end up loving it.

> Mind me asking what you use? :)

I find gear lists distasteful so I won't go into much detail about most things, but I will give you an idea of what I have going on.

The thing I mentioned in the post is the OP-1: https://www.teenageengineering.com/products/op-1 (built-in synths, samplers, mic, radio, 4-track, sequencers...) It's my workhorse.

I like sampling, so there's a turntable and cassette deck. I like sampling a lot, so I'm getting another sampler.

I also have a subsynth to cover the areas the OP-1 synths don't. (They're very good, but each is specialized and has only 4 or 8 parameters.)

I also use a cheap (but not noisy) DJ mixer since I only need to mix two channels, and doing cuts with the crossfader when sampling is handy. The rest of it is cables, speakers, headphones and a few things I never use.

> I'm not criticising your preference for using hardware, that's your call. Some people still like to use vinyl, and I guess that's pretty cool.

The sound is incredibly hard to get right in some cases. You can simulate vinyl remarkably well with a timecode record or DJ controller and special software, but: the plugins have extremely limited range compared to the real thing and the controllers require the same investment as a turntable and timecode still needs the turntable. Nearly every used record store and thrift store has a pile of nearly-free records which are ideal for sampling: obscure stuff no one has heard of, ancient stuff that is no longer recognized by today's audience or may have even been obscure in its day.

As for preferring hardware, in my opinion it's the responsible thing to do. Because:

* Say you want to play a show. Are you going to bring a laptop in there and pray it doesn't do something insane, say... auto-discover the wifi, start installing updates during your gig? Or just crash because it has an undiscovered cooling problem an it's hotter than your usual environment with all those bodies dancing around?

* Software tends to cost money too. There are free options, but chances are you will want _something_ in your software setup that isn't free.

* Idiosyncrasies. Just like your audience wants to hear that vinyl sound, producers often want those hardware quirks. A lot of this amounts to fetishism, but sometimes there are more objective reasons.

* Dedicated functionality. Portable instruments. Playable instruments. Jamming on a PC keyboard does not give you the same response as jamming on instrument keys or pads, or whatever the instrument has that is designed to be played. You could buy a controller, but then you're back to buying hardware.

* Workflow is king. Nearly everything software needs a mouse these days. Or a dedicated hardware controller. It's a workflow-killer.

I learned the hard way that I can't produce very well with software. A few years ago I went with a nice portable piece of kit that does a little bit of everything from sampling to synthesis and mixing. When I did that everything changed drastically. I thought about music differently and really started to get my hands on it.

Hardware isn't that costly unless you need to have the most badass kit or a large setup. When my wish-list is complete, mine will have cost me about $1500. A decent laptop + Ableton Live + midi controller would be cost at least that much. That will take you far, but it's not an argument against just buying the hardware instead. Some people work better with software, and that's cool, but for anyone who works better with hardware, the word "preference" only works in the sense that "I would prefer not to have my hand chopped off." It probably goes both ways, but I couldn't tell you about that. ;)

I got yelled at by a teacher for this in the '90s. I used the command line to access things that weren't presented in the login shell's menu. Since the system had permissions which explicitly granted me the right to access other programs I didn't think anything of it... but he thought differently and accused me of hacking.

Take for example this technique: https://youtu.be/ljMePAmmxx4

Around 2:10 he mentions "you can actually set it for project as well" which is a lot closer to what's being done in this case.

Blender has to solve nearly the exact same problem for projections, the only differences being the projection has to be mapped backwards to a flat texture, and you have to account for the way the film clings to the surface and how it stretches. Topology and topography aren't an issue though, we've got that so covered. (But the material physics is something you would have to construct a model for, so if you wanted to solve this precise problem in Blender you might have better results with the physics engine.)

I have seen some variation on this available in even low-end 3D modelers since the 90s. IIRC Truespace's version of the feature did shrink-wrapping by running a simulation, much like they do here, but with different physics.

I thought I had even seen this used in printing before but I could be mistaken.

FYI hydrographic printing isn't new... nor is the computational part to be honest. I assume both of these techniques have been used together before, but what we are seeing here is both: very well done, and: using off-the-shelf components.

Bonus the-future-is-now moment: "3D vision systems" are "off-the-shelf components".

Yeah, that was the thing that impressed me most, too.