whenever i make a function, such as the one below, and try to run it, pico-8 almost always returns a syntax error, saying something along the lines of "<EOF> EXPECTED AT LINE 23", where line 23 is the last line of the last function in the code.
below shows the framework of the functions i usually code, "blah" obviously being substituted with code.

FUNCTION DOSTUFF()
IF BLAH THEN
BLAH BLAH BLAH
BLAH BLAH BLAH --this line is where an "<eof>" is usually expected
END
END

It sounds like most of the time you're managing to forget the "then" on your IF BLAH THEN line; an if without a then is treated as a one-liner that in turn requires (and allows) no corresponding END statement.

So, for example, this as the sole content of a program runs fine (and does nothing interesting):

function dostuff()
  if true then
    local x = 0
    x += 1
  end
end

Whereas this, without that "then", barfs up the EOF warning you're mentioning:

function dostuff()
  if true
    local x = 0
    x += 1
  end
end

@joshmillard: I, too, am guilty of forgetting thens and dos but I'm soon reminded. your last example brings up " 'then' expected near 'local' "

@badatcoding: could you provide a copy/paste example? tried a few things but never got that error.

edit:
@joshmillard:
this one though:

function dostuff()
 if (true) x = 0
    y=2
 end
end

Syntax error line 3
y=2
<EOF> expected near 'END'

should be line 4/5 or "unexpected 'END'" on line 5 I guess...
well I'm often puzzled by error messages in pico8, I think I mostly read 'problem around there' (might be only related to lua though, I don't use it anywhere else so I wouldn't know)

Yeah, the error reporting on these could be clearer -- an "unexpected END on line x" message would be more communicative than just barfing about EOF more generally -- though that's easy for me to say as someone who has never had to implement such a thing. I don't know how much of what exists is native Lua reporting being passed through vs. zep bootstrapping his own error system.

Just thought I might add, my game Flappable also mentions an <EOF> AT line 23 - could this be a coincidence or more generic error?

In this case mine was only happening in the web player, I actually cleared all traces of nested/comments (I was told may be relevant to a recent pico 8 update - 0.2.5e). This reproduced the error in the non web player, however only got working when I finally just deleted any reference to the apparent offending (screenshake function) which contained references to the inbuilt (camera function)..

This is probably because Lua was originally written to be embedded into other apps and grew in popularity partially because it was so useful as a scripting language in games, which at the time were being written for hardware that included stuff like the ps2 or the gamecube, where you had a very limited amount of instruction cache, in the range of 16k.

For those who don't know, not all processors utilize a generalized cache. They'll have cache memory for fetching data, and cache memory for fetching upcoming instructions. Code is almost never run directly from memory anymore, because that would be ludicrously slow, like going back 20 years in processor progress.

So Lua ideally wants to fit most, if not all, of its code inside the instruction cache, so that while running, there will be no cache misses which result in pipeline stalls while the processor waits for slow fetches from ram into the i-cache.

The point of mentioning this is that Lua is able to parse source code at runtime and therefore the parser has to be as minimal as possible, causing error detection to produce only broad-strokes reports like these, rather than having additional code to figure out what exactly caused the problem.

Now, it's up to @zep if he wants to write such additional code, but honestly, the Lua source code is a bit of a nightmare to read and it's also a bit hard to follow because of how it does long-jumps, a C feature that basically just lets you move the program counter to another place in memory without a compiled branch instruction and also doing trickery to keep the call stack from making no sense.

In short, I think it might be a bit much to ask of just one guy to expand this stuff while also getting other important stuff done. I just want to set your expectations reasonably.

Edit: Which is not to say I don't think @zep should let some other people inside the castle who could do such work. Cough. Cough.