www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Phobos PR: `call` vs. `bindTo`

reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
There are currently two Phobos PR's that implement essentially the same
functionality, but in slightly different ways:

	https://github.com/D-Programming-Language/phobos/pull/1255
	https://github.com/D-Programming-Language/phobos/pull/2343

From the discussion on Github, it seems to me that we should only
introduce one new function rather than two similar but not-quite-the-same functions. Since the discussion seems stuck on Github, I thought I should bring it here to the larger community to see if we can reach a consensus (who am I kidding... but one can hope :-P) on: (1) What name to use (bring on the bikeshed rainbow) (2) Exactly what functionality should be included. (3) Which PR to merge. T -- They say that "guns don't kill people, people kill people." Well I think the gun helps. If you just stood there and yelled BANG, I don't think you'd kill too many people. -- Eddie Izzard, Dressed to Kill
Aug 05 2014
next sibling parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
On Tuesday, 5 August 2014 at 19:31:08 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 There are currently two Phobos PR's that implement essentially 
 the same
 functionality, but in slightly different ways:

 	https://github.com/D-Programming-Language/phobos/pull/1255
 	https://github.com/D-Programming-Language/phobos/pull/2343

From the discussion on Github, it seems to me that we should 
only
introduce one new function rather than two similar but not-quite-the-same functions. Since the discussion seems stuck on Github, I thought I should bring it here to the larger community to see if we can reach a consensus (who am I kidding... but one can hope :-P) on: (1) What name to use (bring on the bikeshed rainbow) (2) Exactly what functionality should be included. (3) Which PR to merge. T
Can you explain the utility of both of them? I am not big into functional programming so I am not seeing it.
Aug 05 2014
parent reply "Idan Arye" <GenericNPC gmail.com> writes:
On Tuesday, 5 August 2014 at 21:10:25 UTC, Tofu Ninja wrote:
 Can you explain the utility of both of them? I am not big into 
 functional programming so I am not seeing it.
The purpose of `bindTo` is to emulate the `let` expressions found in many functional languages (see http://en.wikipedia.org/wiki/Let_expression). The idea is to bind a value to a name for the limited scope of a single expression. Note that `bindTo` could be implemented as: alias bindTo = std.functional.unaryFun; and I'll probably change the implementation to this if this PR will be chosen. The reason I think `bindTo` is needed even if it's just an alias to `unaryFun` is that `bindTo` conveys better that the you are binding a name to a value, not just overcomplicating the code.
Aug 05 2014
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 06.08.2014 00:17, schrieb Idan Arye:
 On Tuesday, 5 August 2014 at 21:10:25 UTC, Tofu Ninja wrote:
 Can you explain the utility of both of them? I am not big into
 functional programming so I am not seeing it.
The purpose of `bindTo` is to emulate the `let` expressions found in many functional languages (see http://en.wikipedia.org/wiki/Let_expression). The idea is to bind a value to a name for the limited scope of a single expression. Note that `bindTo` could be implemented as: alias bindTo = std.functional.unaryFun; and I'll probably change the implementation to this if this PR will be chosen. The reason I think `bindTo` is needed even if it's just an alias to `unaryFun` is that `bindTo` conveys better that the you are binding a name to a value, not just overcomplicating the code.
And my impression (in lisp/clojure) was, that let emulates (named) variables of imperative languages :P Cheers, Daniel
Aug 05 2014
parent "Idan Arye" <GenericNPC gmail.com> writes:
On Tuesday, 5 August 2014 at 22:25:53 UTC, Daniel Gibson wrote:
 Am 06.08.2014 00:17, schrieb Idan Arye:
 On Tuesday, 5 August 2014 at 21:10:25 UTC, Tofu Ninja wrote:
 Can you explain the utility of both of them? I am not big into
 functional programming so I am not seeing it.
The purpose of `bindTo` is to emulate the `let` expressions found in many functional languages (see http://en.wikipedia.org/wiki/Let_expression). The idea is to bind a value to a name for the limited scope of a single expression. Note that `bindTo` could be implemented as: alias bindTo = std.functional.unaryFun; and I'll probably change the implementation to this if this PR will be chosen. The reason I think `bindTo` is needed even if it's just an alias to `unaryFun` is that `bindTo` conveys better that the you are binding a name to a value, not just overcomplicating the code.
And my impression (in lisp/clojure) was, that let emulates (named) variables of imperative languages :P Cheers, Daniel
That's partially true. While `let` can be used to emulate named variables, it carries it's own weight - enough for many functional languages to have both `let` and regular variable declarations. Take a look at this Scheme example - http://repl.it/WVU - It shows both regular variable declaration with `define` and a `let` expression. `(define x 12)` declares("binds") `x` for the scope it was written in - the entire scope of `foo`. The `let` expression creates a new scope and binds `y` in it. Clojure doesn't have regular variable binding(`def` always uses the global scope, even if you use it inside a function) so you have to use `let` to emulate it, though `let` is still used for it's original purpose - which I think is useful enough for Phobos to have it.
Aug 06 2014
prev sibling next sibling parent "Brian Schott" <briancschott gmail.com> writes:
I'd probably never use either of them.
Aug 05 2014
prev sibling next sibling parent reply "Meta" <jared771 gmail.com> writes:
On Tuesday, 5 August 2014 at 19:31:08 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 There are currently two Phobos PR's that implement essentially 
 the same
 functionality, but in slightly different ways:

 	https://github.com/D-Programming-Language/phobos/pull/1255
 	https://github.com/D-Programming-Language/phobos/pull/2343

From the discussion on Github, it seems to me that we should 
only
introduce one new function rather than two similar but not-quite-the-same functions. Since the discussion seems stuck on Github, I thought I should bring it here to the larger community to see if we can reach a consensus (who am I kidding... but one can hope :-P) on: (1) What name to use (bring on the bikeshed rainbow) (2) Exactly what functionality should be included. (3) Which PR to merge. T
I don't think either is particularly useful. This is something that's either part of the language, or doesn't exist.
Aug 05 2014
parent reply Nick Treleaven <ntrel-public yahoo.co.uk> writes:
On 05/08/2014 23:10, Meta wrote:
 On Tuesday, 5 August 2014 at 19:31:08 UTC, H. S. Teoh via Digitalmars-d
 wrote:
 There are currently two Phobos PR's that implement essentially the same
 functionality, but in slightly different ways:
I don't think either is particularly useful. This is something that's either part of the language, or doesn't exist.
I think it should be part of the language (UFCS for lambda functions): some.long.ufcs.chain.(x => x + x/2).writeln; This can be useful in real code to avoid breaking a UFCS chain and having to introduce a temporary variable, which is more ugly.
Aug 07 2014
parent "Idan Arye" <GenericNPC gmail.com> writes:
On Thursday, 7 August 2014 at 11:47:02 UTC, Nick Treleaven wrote:
 On 05/08/2014 23:10, Meta wrote:
 On Tuesday, 5 August 2014 at 19:31:08 UTC, H. S. Teoh via 
 Digitalmars-d
 wrote:
 There are currently two Phobos PR's that implement 
 essentially the same
 functionality, but in slightly different ways:
I don't think either is particularly useful. This is something that's either part of the language, or doesn't exist.
I think it should be part of the language (UFCS for lambda functions): some.long.ufcs.chain.(x => x + x/2).writeln; This can be useful in real code to avoid breaking a UFCS chain and having to introduce a temporary variable, which is more ugly.
This syntax will also allow UFCS with fully qualified names, with functions-in-variables and with methods.
Aug 07 2014
prev sibling next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 6/08/2014 7:29 a.m., H. S. Teoh via Digitalmars-d wrote:
 There are currently two Phobos PR's that implement essentially the same
 functionality, but in slightly different ways:

 	https://github.com/D-Programming-Language/phobos/pull/1255
 	https://github.com/D-Programming-Language/phobos/pull/2343

From the discussion on Github, it seems to me that we should only
introduce one new function rather than two similar but not-quite-the-same functions. Since the discussion seems stuck on Github, I thought I should bring it here to the larger community to see if we can reach a consensus (who am I kidding... but one can hope :-P) on: (1) What name to use (bring on the bikeshed rainbow) (2) Exactly what functionality should be included. (3) Which PR to merge. T
I'm not convinced that either PR adds anything of use. As noted unaryFun can be used identically to bindTo. So its wasted code in my opinion.
Aug 05 2014
parent reply "Tobias Pankrath" <tobias pankrath.net> writes:
 From the PR:

---
A better way to bind multiple arguments would be:

((int x = 2,
   int y = 3,
  ) => (x * y))()
---

Could we make this possible?
Aug 05 2014
parent "Idan Arye" <GenericNPC gmail.com> writes:
On Wednesday, 6 August 2014 at 05:45:09 UTC, Tobias Pankrath 
wrote:
 From the PR:

 ---
 A better way to bind multiple arguments would be:

 ((int x = 2,
   int y = 3,
  ) => (x * y))()
 ---

 Could we make this possible?
This is already possible - the problem is that type inference doesn't work here, so we can't do ((auto x = 2, auto y = 3, ) => (x * y))()
Aug 06 2014
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 8/5/14, 4:29 PM, H. S. Teoh via Digitalmars-d wrote:
 There are currently two Phobos PR's that implement essentially the same
 functionality, but in slightly different ways:

 	https://github.com/D-Programming-Language/phobos/pull/1255
 	https://github.com/D-Programming-Language/phobos/pull/2343

From the discussion on Github, it seems to me that we should only
introduce one new function rather than two similar but not-quite-the-same functions. Since the discussion seems stuck on Github, I thought I should bring it here to the larger community to see if we can reach a consensus (who am I kidding... but one can hope :-P) on: (1) What name to use (bring on the bikeshed rainbow) (2) Exactly what functionality should be included. (3) Which PR to merge. T
It's called "variable declaration" in imperative languages, and I think D has that.
Aug 06 2014
parent "Idan Arye" <GenericNPC gmail.com> writes:
On Wednesday, 6 August 2014 at 20:12:16 UTC, Ary Borenszweig 
wrote:
 On 8/5/14, 4:29 PM, H. S. Teoh via Digitalmars-d wrote:
 There are currently two Phobos PR's that implement essentially 
 the same
 functionality, but in slightly different ways:

 	https://github.com/D-Programming-Language/phobos/pull/1255
 	https://github.com/D-Programming-Language/phobos/pull/2343

From the discussion on Github, it seems to me that we should 
only
introduce one new function rather than two similar but not-quite-the-same functions. Since the discussion seems stuck on Github, I thought I should bring it here to the larger community to see if we can reach a consensus (who am I kidding... but one can hope :-P) on: (1) What name to use (bring on the bikeshed rainbow) (2) Exactly what functionality should be included. (3) Which PR to merge. T
It's called "variable declaration" in imperative languages, and I think D has that.
Yes, D has variable declarations, but it doesn't allow you to declare them mid-expression for the limited scope of an expression - and that's what `bindTo` aims to achieve.
Aug 06 2014
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, 5 August 2014 at 19:31:08 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 There are currently two Phobos PR's that implement essentially 
 the same
 functionality, but in slightly different ways:

 	https://github.com/D-Programming-Language/phobos/pull/1255
 	https://github.com/D-Programming-Language/phobos/pull/2343

From the discussion on Github, it seems to me that we should 
only
introduce one new function rather than two similar but not-quite-the-same functions. Since the discussion seems stuck on Github, I thought I should bring it here to the larger community to see if we can reach a consensus (who am I kidding... but one can hope :-P) on: (1) What name to use (bring on the bikeshed rainbow) (2) Exactly what functionality should be included. (3) Which PR to merge.
I concur with what others have said. Neither of these proposals carry their own weight. They're just shuffling around functionality that we already have so that someone can write their code in a slightly different order. If someone really wants to alter their code like this, they can just write these functions themselves, but they're not of enough value to the community at large to be worth adding to Phobos. - Jonathan M Davis
Aug 07 2014