RE: Re: [haXe] Re: sugar for functions?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

RE: Re: [haXe] Re: sugar for functions?

interaction-designer
Hi Marc(&list),

I did say I am all for using keywords intelligently, not leaving out the keyword function. And I do mean not _completely_ leave out the keyword function. Of course there can be cases where leaving out makes sense, it's ok as long there is choice and some restrictions making it too easy too abuse until it becomes inefficient for the compiler and humans too read. For me abstracting a function (and leaving out the keword) is already the case in haxe inside arguments, and it makes sense.

function foo(count:Int, funct:Int->String){
...
}  
function bar (someInt: Int):String{
...
}
foo(1, bar);

There are more cases where shorthanding can be intelligently used I am sure, like the ones you brought up:

>I understand that users may uncomfortable with such a syntax at the
>beginning. But there is a reason why Ruby and grails and such are
>popular.
>Such sugar is one of them (IMHO).

I am not convinced by the sake of populairity. Perl is also populair, and it's quite unreadable which is also a populair statement about it.

>You can't protect against programmers abusing a language. So I always
>assume people use sugar wisely. I posted enough examples illustrating
>what I think is more readable. Of course you can think differently.

>I think that whether someone finds code readable or not depends heavily
>on which languages he used in the past :)

I have used many languages (still do), so I have been able to stay sensitive on the subject of uniqueness/quirkyness of languages and their syntax. However, my personal judgement is that if it becomes too easy to abuse shorthands and it reaches a point where the compiler can only suffer from it, it has clearly gone too far. How too implement it such that shorthanding will be invoked to be used wisely?

Cheers, Simon

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

RE: Re: [haXe] Re: sugar for functions?

MarcWeber
> I have used many languages (still do), so I have been able to stay sensitive on the subject of uniqueness/quirkyness of languages and their syntax. However, my personal judgement is that if it becomes too easy to abuse shorthands and it reaches a point where the compiler can only suffer from it, it has clearly gone too far.
Great. Then you know that C/C++ doesn't use a function statement either :)

> How too implement it such that shorthanding will be invoked to be used wisely?
How to define wisely? Can you give some examples of abuse - of wise use?
Maybe I get a feeling about what you have in mind then.

I think redundancy is bad. And the function keyword is redundant, isn't it?

Cheers
Marc Weber

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Re: [haXe] Re: sugar for functions?

tommedema
The function keyword is not redundant, because it represents what you are defining. Unlike some magical sugar you want to implement.

You define a function, not a hash or whatever you replace this 8 letters word with.

- Tom

2010/8/2 Marc Weber <[hidden email]>
> I have used many languages (still do), so I have been able to stay sensitive on the subject of uniqueness/quirkyness of languages and their syntax. However, my personal judgement is that if it becomes too easy to abuse shorthands and it reaches a point where the compiler can only suffer from it, it has clearly gone too far.
Great. Then you know that C/C++ doesn't use a function statement either :)

> How too implement it such that shorthanding will be invoked to be used wisely?
How to define wisely? Can you give some examples of abuse - of wise use?
Maybe I get a feeling about what you have in mind then.

I think redundancy is bad. And the function keyword is redundant, isn't it?

Cheers
Marc Weber

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Re: [haXe] Re: sugar for functions?

MarcWeber
Excerpts from Tom's message of Mon Aug 02 15:32:33 +0200 2010:
> The function keyword is not redundant, because it represents what you are
> defining. Unlike some magical sugar you want to implement.
 
> You define a function, not a hash or whatever you replace this 8 letters
> word with.
Still your argumentation lacks. Because this argumentation could be used
to propagate

app(+, 2, 3) instead of 2 + 3 because you apply a "add" function to the
values 2 and 3 (That's what you're doing - so we should add redundancy
? )

I agree that it makes sense to have a function like keyword for class
methods so that tools such as ctags can find them. This doesn't apply to
lambdas though.

I should have asked "Can you think of a nicer syntax which adds less
redundancy than function .. return for small lambdas which is easy to
read by both: humans and compilers" in the first place.

Finally I consider { .. } execution blocks being magical as well.
I'd prefer

  BEGIN EXECUTION BLOCK
   // do stuff
  END EXECUTION BLOCK

*kidding*

because { .. }
is sugar. I think it depends on how you look at it.

So why do you think having { .. } is ok (do you?)
and why is having sugar for lambdas is not?

I don't want to offend. I want to show you that you can't convince me by
arguments like "Its what you're doing, so give lets give it a name".

Marc Weber

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Re: [haXe] Re: sugar for functions?

tommedema
"app(+, 2, 3) instead of 2 + 3 because you apply a "add" function to the
values 2 and 3 (That's what you're doing - so we should add redundancy
? )"

This is totally different. The + character's meaning does correspond with the action (adding two values). Also, I never said that we should add redundancy.

And no, I cannot think of a nicer syntax to create a function. Simply because function is the best syntax available for numerous reasons I described earlier, of which the two most important are that it's short and descriptive.

Finally, there sure is syntax that does not directly express what you're doing if you never learned their meanings. Fact that it's already there doesn't mean that we should add more of this magic. Rather, we should make sure that it doesn't get worse.

- Tom

2010/8/2 Marc Weber <[hidden email]>
Excerpts from Tom's message of Mon Aug 02 15:32:33 +0200 2010:
> The function keyword is not redundant, because it represents what you are
> defining. Unlike some magical sugar you want to implement.

> You define a function, not a hash or whatever you replace this 8 letters
> word with.
Still your argumentation lacks. Because this argumentation could be used
to propagate

app(+, 2, 3) instead of 2 + 3 because you apply a "add" function to the
values 2 and 3 (That's what you're doing - so we should add redundancy
? )

I agree that it makes sense to have a function like keyword for class
methods so that tools such as ctags can find them. This doesn't apply to
lambdas though.

I should have asked "Can you think of a nicer syntax which adds less
redundancy than function .. return for small lambdas which is easy to
read by both: humans and compilers" in the first place.

Finally I consider { .. } execution blocks being magical as well.
I'd prefer

 BEGIN EXECUTION BLOCK
  // do stuff
 END EXECUTION BLOCK

*kidding*

because { .. }
is sugar. I think it depends on how you look at it.

So why do you think having { .. } is ok (do you?)
and why is having sugar for lambdas is not?

I don't want to offend. I want to show you that you can't convince me by
arguments like "Its what you're doing, so give lets give it a name".

Marc Weber

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Re: [haXe] Re: sugar for functions?

Cauê W.
Tom, are you acquainted with functional programming? Have you programmed in any functional languages, and have you tried to do that with haXe? As you know, haXe has many functional programming-inspired functions.

2010/8/2 Tom <[hidden email]>
"app(+, 2, 3) instead of 2 + 3 because you apply a "add" function to the
values 2 and 3 (That's what you're doing - so we should add redundancy
? )"

This is totally different. The + character's meaning does correspond with the action (adding two values). Also, I never said that we should add redundancy.

And no, I cannot think of a nicer syntax to create a function. Simply because function is the best syntax available for numerous reasons I described earlier, of which the two most important are that it's short and descriptive.

Finally, there sure is syntax that does not directly express what you're doing if you never learned their meanings. Fact that it's already there doesn't mean that we should add more of this magic. Rather, we should make sure that it doesn't get worse.

- Tom

2010/8/2 Marc Weber <[hidden email]>
Excerpts from Tom's message of Mon Aug 02 15:32:33 +0200 2010:

> The function keyword is not redundant, because it represents what you are
> defining. Unlike some magical sugar you want to implement.

> You define a function, not a hash or whatever you replace this 8 letters
> word with.
Still your argumentation lacks. Because this argumentation could be used
to propagate

app(+, 2, 3) instead of 2 + 3 because you apply a "add" function to the
values 2 and 3 (That's what you're doing - so we should add redundancy
? )

I agree that it makes sense to have a function like keyword for class
methods so that tools such as ctags can find them. This doesn't apply to
lambdas though.

I should have asked "Can you think of a nicer syntax which adds less
redundancy than function .. return for small lambdas which is easy to
read by both: humans and compilers" in the first place.

Finally I consider { .. } execution blocks being magical as well.
I'd prefer

 BEGIN EXECUTION BLOCK
  // do stuff
 END EXECUTION BLOCK

*kidding*

because { .. }
is sugar. I think it depends on how you look at it.

So why do you think having { .. } is ok (do you?)
and why is having sugar for lambdas is not?

I don't want to offend. I want to show you that you can't convince me by
arguments like "Its what you're doing, so give lets give it a name".

Marc Weber

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Re: [haXe] Re: sugar for functions?

MarcWeber
In reply to this post by tommedema
Excerpts from Tom's message of Mon Aug 02 16:11:12 +0200 2010:
> Finally, there sure is syntax that does not directly express what you're
> doing if you never learned their meanings.

That's called abstraction, isn't it? Funny that you say this when using
HaXe - because meaning depends on the backend. So by writing function
you do no longer know what is happening exactly.. You kind if idea about
the behaviour. Even then maybe assembler is the best way. Then you write
and know exactly what is happening (after learning tons of opcodes..).

Anyway I see that we have different points of views - and that probably
nothing is changing that. If I want this feature I"ll implement it -
send a patch to the mailinglist and that's it.

I've had the funny idea of having a haxe -haxe switch which exports to
HaXe.. Eg experimental features such as (short lambdas) could be
rewritten to conservative HaXe so that still everyone can use the code?

Its just a funny idea which was jumping around in my head...

I'm still interested what you think about shortening function to fun or
fn. Then its like dad to father or mum to mother ;)

Another way would be asking the editor to fold "function".. (don't
display it) But I'm not
aware of any editor which can do this kind of beautifying code on the
fly :)

I'm not using HaXe enough (yet) to force anything.

Thanks to everyone participating in this discussion.

Marc Weber

--
haXe - an open source web programming language
http://haxe.org