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.

P#14163 2015-09-14 21:29 ( Edited 2015-09-16 15:52)

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

P#14164 2015-09-14 21:38 ( Edited 2015-09-15 01:38)

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.

P#14166 2015-09-14 21:59 ( Edited 2015-09-15 01:59)

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.

P#14168 2015-09-14 22:05 ( Edited 2015-09-15 02:05)

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.

P#14169 2015-09-14 22:12 ( Edited 2015-09-15 02:12)

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

local foo = {

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

P#14172 2015-09-15 00:56 ( Edited 2015-09-15 04:56)

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.

P#14179 2015-09-15 05:51 ( Edited 2015-09-15 09:51)

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


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

P#14180 2015-09-15 06:33 ( Edited 2015-09-15 10:35)

References to functions are needed too (no brackets).

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

function draw_entity()

function _draw()
  car.draw() -- calling just "draw" which is pointing to draw_entity
P#14181 2015-09-15 06:44 ( Edited 2015-09-15 10:44)

@Up: Again, following is a call:


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:

--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".

P#14183 2015-09-15 07:06 ( Edited 2015-09-15 11:07)

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.

P#14220 2015-09-15 22:19 ( Edited 2015-09-16 02:19)
P#14222 2015-09-15 23:25 ( Edited 2015-09-16 03:25)

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?

P#14245 2015-09-16 11:15 ( Edited 2015-09-16 15:15)

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.

P#14247 2015-09-16 11:40 ( Edited 2015-09-16 15:40)

@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.

P#14248 2015-09-16 11:52 ( Edited 2015-09-16 15:52)

[Please log in to post a comment]