Write some code which monitors file sizes and perhaps dates to detect changes. if you have a project, you could possibly compare the asset file dates to the last date the project file was saved and then update accordingly.

Allegro doesn't have such functionality. Anyway, the best way is what Neil Roy said: monitorize file sizes and/or dates by yourself. AFAIK there's no other way (I think no OS has such event, do they?).

Actually you should do it only when your game/engine recover focus after losing it. Look at the ALLEGRO_EVENT_DISPLAY_SWITCH_IN event.

As jmasterx says - never poll file size or dates that just wastes a lot of resources when the kernel already does it for free. In Linux I use inotify - it's very easy to use: http://man7.org/linux/man-pages/man7/inotify.7.html

I honestly didn't know about that. It's not exactly functionality most programs, even game programs need.

Of course, if you want to see such functionality added, feel free to download the Allegro source code and add it yourself. You could then submit your changes and they could be included in the library and you will be credited.

In the two decades I have used Allegro I have never seen a need for such functionality, so if you wait for someone else to add it in, well... it could be a while.

The OSX version requires -framework CoreServices. I have a rudimentary FileSystemChangeNotifier class that I was working on (close to being finished) and had to pivot to something else before I could finish it.

The unmerged branch against master is here. It currently works in its example program, and the implementation relies on a callback function. I haven't figured out an ideal way to write tests for it, partially because it requires writing files to the file system, and that's not the best environment to rely on for running tests.

Regardless, if this were to be modified to an allegro addon, it should emit an event instead, and would be functional (not object-oriented). But, for OSX it would likely work more-or-less the same way.

Functional as in C-like, and not Object-oriented as in C++ like. My projects are all (at least in this phase of my life) strongly Object-oriented. Allegro has no objects in the C++ sense.

Functionnal programming sucks.
Use C, it's and order ! (imperative language)

While I don't need to use graph based algorithms often, I really wonder if functional is just some big fad, or actually useful.

Like, I tried Haskell, and I tried making some toy algorithms. Factorial here. Some algorithm there. But... it felt terrible. Like, there was zero implicit understanding of whether or not the code would work 100% 10% 1% or .00001% of the speed of a C implementation. It felt like I was just specifying schematic and the "compiler" would become a wizard and magically run the code and if it was fast or slow, was a roll of the dice.

I mean, there are clear, useful, functional (ish) code. Map. Zip. Unzip. All those typical Javascript, Python (and D!) ones.

I like how D's API is setup to use method chaining and functional like calls.

Actual code, from dlang.org's example codes:

import std.stdio, std.array, std.algorithm;

// Print all lines of stdin, sorted.
void main()
{
    stdin
        .byLineCopy
        .array
        .sort!((a, b) => a > b) // descending order
        .each!writeln;
}

That's about as self-documenting, clear-intent code you can make in any language!

The really cool thing with D is... you can do most stuff at compile time too. So you can literally (on that same webpage, dlang.org) sort an array, at compile time, with a single call.

I kind of like the D version of functional programming. You can mark any imperative function as pure, and all calls it calls have to be pure as well. That's great for concurrency. You can also use functional snippets where ever you want, without requiring the entire program to be functional. (Or hell, write entirely functional in D, if you want.)

That way, I can use "as much as necessary and no more" functional programming, in the places where I gain a large productivity bonus, and if necessary, replace any slow sections with imperative versions.

But back to functional as a whole. It confuses me. Like, imperative languages bog down when you have to emulate functions. But, functional languages bog down when you have to use imperative logic. "Do this, then this, then this." is the core of 99% of all business logic in the world. So why would I try to map imperative, to functional, just for the sake of "functional"?

I don't know. I know there are lots of different use-cases for programmers. But literally zero of the professional works I've done have involved any need for functional programming and it's been only relegated to "for the sake of itself" or curiosity.