Question about feasibility: option to use JS function syntax for nested functions, especially inside dicts/object-literals about rapydscript HOT 7 CLOSED

from rapydscript.

For object-literal's functions defined using indentation comma is optional, so you can:

obj = {
    foo: 1,
    bar: 2,
    one: def():
        return 1  # semicolon and comma are not needed
    two: def():
        return 2
    three: 3,
    four: 4
}

or even:

params = {
    width: 50,
    height: 30,
    def onclick(self, event):  # note that `self` is required as first arg
        alert("you clicked me")
    def onmouseover(self, event):
        $(self).css('background', 'red')
    def onmouseout(self, event):
        # reset the background
        $(self).css('background', '')
}

if you still need extra begin/end tokens you can always use parentheses:

params = {
    width: 50,
    height: 30,
    onclick: (def(event):
        alert("you clicked me")
    ),
    onmouseover: (def(event):
        $(this).css('background', 'red')
    ),
    onmouseout: (def(event):
        # reset the background
        $(this).css('background', '')
    )
}


factorial = (def(n):
    if n == 0:
        return 1
    return n * factorial(n-1)
)

...to have clear open/close, whereas ;-or-newline can't provide that as well in a nested context.

I totally agree about ;, but what's the problem with newline+de-indentation? This is almost the same as in the class definition, no?

from rapydscript.

from rapydscript.

Yes indeed

There is already a way to inline an anonymous function with more logic
after it by using a semicolon, if that's what you're looking for

Right! The RapydScript README informed me of that functionality. It makes enough sense to me. I just believe this part of the syntax will be a turn-off for some people — and on a team of multiple programmers, it could be a deal-breaker for at least one of them. Does that make sense?

So I'm not making any critique of the existing functionality, rather I'm trying to say, there might be another syntax worth considering [perhaps in some contexts or when a compiler flag enables the option].

I'll use an example!

Here's one example from the README:

params = {
	width:	50,
	height:	30,
	onclick:	def(event):
		alert("you clicked me"),
	onmouseover:	def(event):
		$(this).css('background', 'red')
	,
	onmouseout:	def(event):
		# reset the background
		$(this).css('background', '')
}

I would really like the option (even if it's a compiler flag, rather than a contextually-allowed/idiomatic thing) ... to use a syntax like this:

params = {
	width:	50,
	height:	30,
	onclick: function (event) {
		alert("you clicked me")
        },
	onmouseover: function (event) {
		$(this).css('background', 'red')
	},
	onmouseout: function (event) {
		# reset the background
		$(this).css('background', '')
         },
}

params = {
	width:	50,
	height:	30,
	onclick: function (event) {
		alert("you clicked me")
        },
	onmouseover: function (event) {
		$(this).css('background', 'red')
	},
	onmouseout: function (event) {
		# reset the background
		$(this).css('background', '')
         },
}

Comparing the semicolon example — the README shows one like this:

hash = {
	'foo':	def():
		print('foo');,
	'bar':	def():
		print('bar')
}


// variation on that - nested
def example():
	obj = {
		'foo':	def():
			print('foo');,
		'bar':	def():
			print('bar')
	}
	return obj

well, compare with:

obj = {
	'foo': function () { 
		print('foo') 
	},
	'bar': function () {
		print('bar')
	},
}

def example():
	obj = {
		'foo': function () {
			print('foo')
		},
		'bar': function () {
			print('bar')
		}
	}
	return obj

Do you kinda see what I mean?

Even though it is a compromise of one principle, it's a trade-off ... A trade-off could be worth it, if the resulting RapydScript developer experience is a bit more Pythonic (arguably) thanks to less ambiguity/ less cognitive overhead. (I think it takes less cognitive overhead/ it's less ambiguous... to have clear open/close, whereas ;-or-newline can't provide that as well in a nested context.

def factorial(n):
	if n == 0:
		return 1
	return n * factorial(n-1)

factorial = def(n):
	if n == 0:
		return 1
	return n * factorial(n-1)

def factorial(n):
	if n == 0:
		return 1
	return n * factorial(n-1)

factorial = function (n) {
	if n == 0:
		return 1
	return n * factorial(n-1)
}

I'm also partial to this "unmodified" option, I guess... rather than devising a middle-ground syntax (in this case), I'm essentially wanting to be able to use the Python function syntax at the top level, with the option to use function () {} style [at least in some contexts].

Humbly submitted 😄 thank you for your amazing project!

from rapydscript.

@valq7711 This is great, it resolves the issue for me. I'm going to respond in two comments.

I totally agree about ;, but what's the problem with newline+de-indentation? This is almost the same as in the class definition, no?

I see what you mean in comparing it to a class definition, but IMHO it's different because a class definition does not occur inside curly braces / dict / object-literals.

I think the other context is Python's syntactic sugar for tuples, and the notorious gotcha associated with that (i.e. that return 1, means return (1,)). I know this isn't news! RapydScript is aware of and this, and it informed RapydScript's design decisions about these parts of the syntax.

As a side-effect of watching out for return 1, etc in Python, I think I've been trained to see a "stray" or "inconsistent" , as a bug. So, it takes cognitive overhead to "turn that off" — seeing that or something like it — when reading RapydScript code.

from rapydscript.

@valq7711:

if you still need extra begin/end tokens you can always use parentheses:

params = {
    width: 50,
    height: 30,
    onclick: (def(event):
        alert("you clicked me")
    ),
    onmouseover: (def(event):
        $(this).css('background', 'red')
    ),
    onmouseout: (def(event):
        # reset the background
        $(this).css('background', '')
    )
}


factorial = (def(n):
    if n == 0:
        return 1
    return n * factorial(n-1)
)

This is a great compromise, thanks for showing me this alternative. I didn't realize (def(): ...) would be valid syntax!

from rapydscript.

Thank you for the help @atsepkov and @valq7711. Really appreciate it!

Maybe the README could be updated to include an example of the parens syntax. (edit: I've just opened a quick draft PR)

from rapydscript.