Log In  


Would save a ton in tokens since brackets are treated as separate tokens.

//edit: Or if you're calling version of function that takes no arguments, ex:

palt(12,true) -- <- brackets necessary
--draw something
palt -- <- brackets unnecessary since this version of palt has no parameters

Of course after such bracketless call/definition, a new line would be required, but most sane programmers do so anyway.



But... That doesn't even make any sense...


How it doesn't? If you call function without parameters/define such function you're wasting two more tokens (brackets) than you should. In pascal, if function takes no parameters you don't have to put in brackets when you call/define it. If this would be added to Pico, that would be huge token save.


functions and variables are the same in lua.

palt by itself is the function itself, palt() is calling the function, you need a way to differentiate those.

if the only reason is to reduce token usage, then it seems silly to change the language for that when you could just increase the token limit.


We both know zep won't increase token limit.

Also if you don't do anything with variable/function (not assigning it, etc.), you can safely assume you're calling it if it just lies in line alone.


and if he doesn't want to increase the token limit, then why would he want to change the language to allow more code
in the same limit?

and no you cannot assume that since lua ignores whitespace.

function bar()
  -- do stuff
end

local foo = {
    bar
}

would you want bar() be called in this case, or would you want it to hold the function bar as it currently would?


Yeah, -1 on this. I thought about this at first too, but there are better ways to reduce tokens than messing up how functions are called.


At least an exclamation mark could be used instead of () to save at least 1 character per a parameterless function call, like:

palt!

Tho i must say i also understand the people saying it's not needed to have alternative ways to call functions without parameters.


References to functions are needed too (no brackets).

car={}
car.draw=draw_entity -- this is a reference to the function below

function draw_entity()
  pset(0,0,7)
end

function _draw()
  car.draw() -- calling just "draw" which is pointing to draw_entity
end

@Up: Again, following is a call:

foo

and if you doing anything with it (store in array, variable, etc.) you need to use brackets unless you want to store reference. "Bracketlessnes" would only apply if you call it without "doing anything to it", like saving reference or storing in collection or putting as parameter to another function.

So this is a go:

foo
bar
baz
--will call foo, bar and baz in that order

while this is a no-no (unless you want to store references to foo/bar/baz)

a = {foo,bar,baz} -- stores references to foo/bar/baz
b = {foo(),bar(),baz()} -- stores return values of foo, bar and baz

Nevertheless, it'll still save tons of tokens, even if it'd be limited like that.

Someone said here that lua ignores whitespace, to which I say "short ifs".


personally, i really, really think pico should adhere as closely as possible to standard lua.

one of pico's big draws for me was that it provided a fun way to learn lua. lua has real traction out in the world at large, i don't think it should be overly modded for convenience.

just my $.02.



Ruby allows method calls without parenthesis, and that always felt completely normal when you had property-like methods. Ruby is a significantly different language though. Methods are not first class objects like functions are in Lua, and only methods and constants are publicly accessible so there is no reference/call ambiguity.

My worthless two cents is that the tokenization limit is pretty similar to how old BASIC interpreters worked on 8 bit machines. Sure, it's an arbitrary made up limit for Pico8, but isn't that what makes it sort of fun? For instance Löve2D is magnitudes more powerful than Pico8, but also orders of magnitudes less powerful than insert programming language and graphics API. I've never really liked Löve2D because it's limitations feel like shortcomings. Pico8's limitations are nothing more than nostalgia gimmicks, and I like those. ;)

Maybe a compromise could be asking to parse "()" as a single token instead of two?


I don't think this makes any sense. Having function references executing in random places would be confusing to most end users. It's not really a difference users would expect, and causes more issue for custom pico8 engines like impbox's.


@darkhog You should really slow down on feature requests. If you find that you're consistently bumping up against limitations, perhaps pico-8 isn't the platform for you. All this energy put into expanding pico-8 to fit your individual needs could be better directed toward, you know, making things with the tools at hand.



[Please log in to post a comment]