Coding: Fleeting Thoughts

[Yakk]

The type of a lambda is not function anything. They are just functors auto generated by the compiler. Such fun tors can be implicitly converted to a STD function type, which is convenient but it is not their type.

Creating a functor with a template operator() is not hard. It would be easier if we could do it with a lambda.

I am pretty sure it was not done because it would make compiler support a touch more tricky. And or making implicit casting to function was tricky.

[Sc4Freak]

What I would like before a variadic lambda is just a simple polymorphic lambda - that is, a template lambda with an automatically deduced type.

Code: Select all

vector<map<string, SomeHugeComplexType>> vec;
/*...*/
transform(begin(vec), end(vec), [](auto& x){ /* do stuff */ }); // alas this will not compile

The compiler already knows what the type of x is. Why must it make me type that out again!? Lambdas make the STL about 10x easier to use. And polymorphic lambdas would make lambdas another 10x easier to use.

[Yakk]

decltype helps there:

Code: Select all

vector<map<string, SomeHugeComplexType>> vec;
/*...*/
transform(begin(vec), end(vec), [](decltype(*begin(vec))& x){ /* do stuff */ }); // alas this will compile


or what have you.

[Sc4Freak]

For varying definitions of "help".

[EvanED]

What I would like before a variadic lambda is just a simple polymorphic lambda - that is, a template lambda with an automatically deduced type.

Code: Select all

vector<map<string, SomeHugeComplexType>> vec;
/*...*/
transform(begin(vec), end(vec), [](auto& x){ /* do stuff */ }); // alas this will not compile

The compiler already knows what the type of x is.

Well, sort of. (I'm pretty sure that what I'm about to say is correct, but I have to admit not being very familiar with the C++11 stuff. My main C++ project deliberately supports GCC 4.2. )

Depending on what you're suggesting, it could have to use an entirely different means to resolve it than anything it does now, however. In particular, if you really want 'auto' to mean 'figure out what this is', it needs to look at the uses of the argument within the function 'transform'; there's not enough information from the arguments. That goes far beyond current template parameter resolution, which can be done from the signature and invocation only.

It also opens up what I'd consider a can of worms. For instance, what should the parameter type be in the following:

Code: Select all

foo( [](auto& x) { ... })  // use

template<typename Functor>
void foo(Functor f) {
    f(1);
    f(1.0);
}

Should it be int? double? A compiler error?

However, I could see some other alternatives. For instance, currently a lambda desugars behind the scenes to an object that takes the bound variables from the environment in a constructor and saves them in fields, then has an operator() that does the work. Pretty much what you'd write by hand.

It would probably be possible for a lambda like what you suggest to desugar to an object that has a templated operator(), something like

Code: Select all

struct desugared_lambda {
    template<typename Param>
    Whatever operator() (Param & x) { ... }
};

In the example I posted, in some sense there would actually be two separate lambdas created, one for ints and one for double. (Both would be members of the same object, but there'd be two functions.)

[Sc4Freak]

Yes, the way this would be implemented would be to create a templated operator(). Normally a lambda can be expressed as a simple functor:

Code: Select all

struct MyLambda1
{
    void operator()(map<string, SomeHugeComplexType>>& x)
    {
        /* ... */
    }
}

In a polymorphic lambda, the type(s) are merely replaced my template parameters:

Code: Select all

struct MyLambda2
{
    template <typename T>
    void operator()(T& x)
    {
        /* ... */
    }
}

And normal template instantiation rules apply. In your example, two instances of the lambda would be instantiated. For example:

Code: Select all

foo([](auto& x) { x = x * 3 / 2; })

template<typename Functor>
void foo(Functor f) {
    int a = 1;
    double b = 1.0;
    f(a);
    f(b);
   
    // a is now 1
    // b is now 1.5
}

On the surface it seems to be a perfectly logical and consistent feature that would have made lambdas much easier to use. Why the C++ standards committee decided to omit it is beyond me.

[EvanED]

Personally, I'd go with a different syntax, to make it clear that this 'auto' isn't at all like the other 'auto's.

Something like

Code: Select all

foo([](template & x) { x = x * 3 / 2; })

[Sc4Freak]

I don't remember where I heard this, but I think one of the reasons this didn't make it into the standard is because it raised some additional questions: if you can make a lambda have templated parameters by just specifying "auto" as the type (or "template" or whatever keyword you want), why can't you do that with regular functions?

Code: Select all

void Frobnicate(auto& x) {++x;}

And apparently that was a hard enough question to answer that they just cut the feature entirely. I don't know if that's really a good enough justification to withhold such a useful feature, but I guess it's a concern for those worried about "elegance" in the language.

[Jplus]

That would pretty much amount to introducing Haskell-style type deduction into C++.

[EvanED]

That would pretty much amount to introducing Haskell-style type deduction into C++.

Still no need.

Code: Select all

void foo(template x, template y) { ... }

would just desugar to

Code: Select all

template<typename Tx, typename Ty>
void foo (Tx x, Ty y) {...}

Actually, I kind of like that idea, and don't see any immediate problems.

But that's not like Haskell as it's still not looking at what the function is doing internally. Or at least, it's not really like Haskell any more than current templates are like Haskell.

[You, sir, name?]

Yes, the way this would be implemented would be to create a templated operator(). Normally a lambda can be expressed as a simple functor:

Code: Select all

struct MyLambda1
{
    void operator()(map<string, SomeHugeComplexType>>& x)
    {
        /* ... */
    }
}

In a polymorphic lambda, the type(s) are merely replaced my template parameters:

Code: Select all

struct MyLambda2
{
    template <typename T>
    void operator()(T& x)
    {
        /* ... */
    }
}

And normal template instantiation rules apply. In your example, two instances of the lambda would be instantiated. For example:

Code: Select all

foo([](auto& x) { x = x * 3 / 2; })

template<typename Functor>
void foo(Functor f) {
    int a = 1;
    double b = 1.0;
    f(a);
    f(b);
   
    // a is now 1
    // b is now 1.5
}

On the surface it seems to be a perfectly logical and consistent feature that would have made lambdas much easier to use. Why the C++ standards committee decided to omit it is beyond me.

Can't you just delegate this template stuff to a function creating the lamda instead? Like

Code: Select all

template<typename T>
function<T(T)> createLambda() { return [](T t) { return 2*t; }; }


[EvanED]

The compiler wouldn't be able to deduce the template parameter in that context, so you'd have to explicitly specify it: for_transform(..., createLambda<int>()).

[Yakk]

Yes, auto or template lambdas would correspond to a functor with a template operator(). The C++ language can handle that easily.

Error messages get a bit annoying (because the traditional template error message would talk about the type of the class and the name of the template parameter, which would be auto-generated for a template lambda for most of the syntaxes I've seen above, which makes the template type error message even less readable...)

And there is the std::function problem. Ie:

Code: Select all

auto lambda = [](template x){return x+1;}
std::function<what?> func = lambda;

As it stands, lambda's can be stored and passed around in std::functions with the same signature. If template lambdas exist, template std::function? (as in, a std::function with a free template parameter). That is getting exceedingly hard (I would say impractical), because it ties compile time code generation to run time object use, which C++ avoids in other cases.

C++ also tends not to have an rvalue type deduction be based off the lvalue it is assigned to -- so you couldn't do this:

Code: Select all

auto lambda = [](template x){return x+1;}
std::function<int(int)> func = lambda;

and expect it to compile. You might imagine this:

Code: Select all

auto lambda = [](template x){return x+1;}
std::function<int(int)> func = lambda<int>;

or

Code: Select all

auto lambda = template<typename T> [](T x){return x+1;}
std::function<int(int)> func = lambda<int>;


but in both cases, we have moved away from a lambda being a really simple bit of code generation of a functor, and now changed the syntax of how it is used after the variable and type is generated.

And C++0x was already over time budget.

[EvanED]

And there is the std::function problem. Ie:

Code: Select all

auto lambda = [](template x){return x+1;}
std::function<what?> func = lambda;

std::function works by the usual type erasure trick, right? And that means virtual functions, and that means there's probably no reasonable thing to put as the type of std::function as you can't have virtual member template functions.

[Yakk]

Sure, it uses type erasure (or whatever). But the particular trick not working isn't the problem with wrapping a template method up like that.

Suppose you had some trick that allowed you to write std::function< template<T> void(T) > (or whatever syntax).

When you assign some template function or functor (of whatever type), you are actually assigning a way (at compile time) to create a function with those type arguments.

And it is the use of that std::function that determines which function is created. But the use of a particular std::function is determined at run time, not compile time.

So which T's in particular you are substituting in isn't known until run time, which would require run-time compilation of C++ code.

If we had some way of expressing a limited enumeration of types, and taught the std::function to go and compile every one of them, then the user of the std::function would end up calling one of those, we'd be in business. But making easy assignment syntax work would be a pain.

Now, in the particular case of passing a lambda functor directly to a std algorithm who always stores the functor's type as a template argument, this isn't a problem. But general use of lambdas involves using std::functions (or equivalents), and not having any decent support for auto or template lambdas in std::functions seems to me like a sign that the feature wouldn't be ready for prime time.

In short -- I'd want a way to take template functions as arguments to functions (!) (as well as template functors, which you can already do to some extent), and an easy syntax to enumerate a set of types.

Then syntax sort of like this:

Code: Select all

type enumeration {int, double, long, mystruct} E;
std::function< for e in E e(e) > foo = template<T>[]( T x ) { return ++x; };


might work. The std::function is now a bundle of a whole bunch of overrides. And traditional type erasure works.

[Sc4Freak]

Yes, there wouldn't be any way to convert a lambda to a std::function. But that in itself doesn't seem like it would be a problem.

In a sense, lambdas are analogous to functions (or functors) as std::function is to function pointers (if you understand my meaning). You can't take the address of a function template and store it in a function pointer. Similarly you can't store a polymorphic lambda in a std::function (and you can't store a regular function template in a std::function either). Yet this doesn't seem to cause any problems in the existing language.

There is the issue of how you specialize a lambda as you say (i.e. how you can specify the template parameters to make it a concrete type) but that's just syntax.

[Yakk]

When designing a language syntax matters. The use of [] for lambda was because it made parsing it easy in the context of c++.

Lambdas are just functors. And by making them just functors that are auto generated, code generation parsing etc is made easier.

Remember that concepts where dropped simply because they could not find a way to parse and validate them that was fast enough. And they even had working parsers for it! Polymorphic lambdas are probably doable, but just any old syntax won't do. A bad syntax or implementation is much worse than none at all.

[Sc4Freak]

But that's not why concepts were removed. Concepts were shown to make C++ slightly slower to compile but not fatally so. My understanding is that the real problem with concepts was semantic: there was disagreement about what a concept should be and how it should be implemented in the standard library.

Bjarne Stroustrup himself gave an excellent talk about it at GoingNative 2012. There's a recording here.

[Yakk]

Really? I had heard upward of a 3x slowdown on compiling.

Watching video.

[sdkelso]

I've heard a bit about automating tasks, but I'd never had a complicated task that needed to be performed frequently enough to justify trying to learn about the process. Recently, I've been emailing papers to my girlfriend to print--a task that takes quite a few steps and seems like it could be easily streamlined. Would it be possible, on Mac OSX Lion, to create a keyboard shortcut (I'm making up the terminology) that (1) only works in MS Word, (2) saves the document I am working on to my desktop with a filename of a random number between '001' and '999,' (3) and attaches it to an email (using MacMail), sending that email to a particular person? Possible? Difficult?

Thank you.

[Yakk]

Yes. But unless you are going to do it 100s of times it will be faster to do it manually than learn how to do it that way. This will remain true until you bite the bullet and sink some costs.

Is the desktop part important? What do you mean by random?

I would guess the easy way would be via a vb.net macro in word.

[Steax]

I use the app "Moom", but it's commercial software. I have a bucket folder, it detects .docx files landing in it, and runs a set of scripts that do the rest of the emailing process. There might be other ways. I thought of using QuickSilver and binding a script through that, but I'm not sure how it could get the contents of the file...

[sdkelso]

To Yakk: Neither the desktop nor the random number are important, I just wanted to provide a more detailed process than "save and email." In fact, I forgot to mention that I'd also want the task to delete the file once it has confirmed that the email was sent.

Thank you both. It sounds like this is a more difficult process than I'd thought. I'd gotten the impression that automating tasks was easy coding for people who don't know how to code. It's not a huge inconvenience, so I probably won't pursue it further; I just thought that if it was easy, then it would be nice.

[Steax]

It's a general issue on desktops: applications have little means to talk to each other. Manipulating files is easy, but "get the contents of the document" and "upload as attachment" isn't. I'm not sure how to trigger a script based on the open file - that is, not sure how to get the path of said open file. I can't think of a good way to do it. Uploading as an attachment... there might be an automator action that does that, I can't remember.

Personally, it's a really annoying issue, since most good web services and applications provide an outer API. It's easier to find a bunch of tweets based on subject, translate them into another language, plot their positions on a map, save all that as a PDF, and throw it all in dropbox... than it is to get the current path of a file in Word.

[joshz]

There's a built-in program called Automator you may find useful. You can also, in System Preferences, set up specific keyboard shortcuts (that will select a menu item) for specific applications.

[Steax]

Okay, a bit of fiddling does seem to make it more possible. There's an action that asks for a finder item (i.e. file), duplicate it, rename the duplicate, and another that makes a new mail message, automatically attaching the file from the last action. That's actually interesting... I never tried using it for file manipulation.

Edit: Okay, here you go. I'll keep the file there for a few days. It'll ask for a file, then create a temporary copy, make a new email with it as the attachment, and delete the temporary one. Note that I haven't actually tried sending the email (not sure if the deleted file would have an effect on that), but it's a starting point. The flow is a bit complex because it saves the file as a variable, since it needs to do more than 1 thing on it. Open it up to modify defaults.

It's what you wanted, except you have to manually select the file and manually hit the "send" button, which IMO are good things to avoid badly sent emails. You can trigger it through a global shortcut (or use another app to make it local - I think there's a way to do it too, I'll mention it if I remember how, it involves creating a new service), set that to a hotkey, and you're set.

Edit2: Oh, well... that's easy. To save that as a service, open up automator, make a new Service (I used "workflow" when I made one), and plastery my workflow there. Then save it as a service. Then go to system preferences > keyboard > keyboard shortcut > services, and assign one there. Additionally, the service might show up in the menu bar (under [Application Name] > Services) so you might be able to set a app-specific hotkey there too.

[Yakk]

This is someone doing pretty much what you are asking to do:
http://www.howto-outlook.com/howto/senddocasmail.htm
This is not mac-centric. I don't think there is much need for it to be a mac based solution.

[Steax]

I was thinking to use Mail over Outlook.

[Xeio]

I kinda wish List<T> did not allow null values to be added.

There is probably a reason this is allowed, that doesn't mean I have to like it though.

[Ubik]

I just saw this on the front page of gamedev.net, thought that some people might find it interesting: Functional programming in C++ by John Carmack. It doesn't offer anything radically new, but it's neat to see that Carmack approves of it.

[sdkelso]

This is someone doing pretty much what you are asking to do:
http://www.howto-outlook.com/howto/senddocasmail.htm
This is not mac-centric. I don't think there is much need for it to be a mac based solution.

I'm confused. That looks good, but I can't use it on Mac OSX, can I? I don't even have Outlook, and since the code is written for a Windows OS wouldn't it be looking in the wrong places on a Mac?

Eh, I think the problem is above me. Thanks for the help guys.

[Steax]

This is someone doing pretty much what you are asking to do:
http://www.howto-outlook.com/howto/senddocasmail.htm
This is not mac-centric. I don't think there is much need for it to be a mac based solution.

I'm confused. That looks good, but I can't use it on Mac OSX, can I? I don't even have Outlook, and since the code is written for a Windows OS wouldn't it be looking in the wrong places on a Mac?

Eh, I think the problem is above me. Thanks for the help guys.

I actually have a near-complete solution for what you needed in my last post.

[b.i.o]

I kinda wish $programming_language did not have null values

FTFY

[sdkelso]

I actually have a near-complete solution for what you needed in my last post.

Oh, that's great! I must have missed that. I'll give it a try and let you know how it works. Thanks a lot.

[Xeio]

I kinda wish $programming_language did not have null values

FTFY

Hrmmmm, no. Nulls can be useful (though some markup for enforcing not-null parameters functions would be nice).

Without null I'd have to either throw exceptions or otherwise keep track of a success/failure for many functions. Granted, there are probably other language constructs (not specifically in C#) that could handle that, but they're all as messy as null from what I'm aware.

EDIT: The async/await keywords in .Net 4.5 are pretty neat...

[Thesh]

Nullable types in C# make database interaction much less messy.

The thing that interests me in 4.5 is covariance. There have been many occasions where I could have made good use of that feature.

Code: Select all

Collection<IOrder> Orders = Dal.GetOrders(o => o.OrderDate > DateTime.Now.AddDays(-1));
//Compiler error, because GetOrders returns an object of type Collection<Order>, even though Order implements IOrder
//Works in 4.5, like magic and stuff


[EvanED]

If you've read a bit about this you probably know the following, but keep in mind, from a pure types perspective, that's not typesafe:

Code: Select all

Collection<Derived> cd = new Collection<Derived>();
Collection<Base> cb = cd; // use covariance
cb.add(new Base()); // locally correct (cb has a .add(Base) method) but globally wrong (cd should not contain any Base objects)

There are ways of dealing with this, sort of, in particular by throwing an exception on the problematic line, but that's compensating for a failure of the type system. Which one is more useful I'll not make an evaluation of.

[Sc4Freak]

As far as I'm aware the way covariance and contravariance is implemented in .NET is always type-safe (array covariance doesn't count, that's a holdover from Java).

I don't think Thesh's code will compile. You should be able to do this, though:

Code: Select all

IEnumerable<IOrder> Orders = Dal.GetOrders(o => o.OrderDate > DateTime.Now.AddDays(-1));

This is because IEnumerable's generic type parameter is explicitly marked as being covariant, which means that it can be substituted for any derived type.

This is safe because IEnumerable<T> has no methods which take objects of type T as arguments. If you try adding an Add method which takes a T, then you'll get a compiler error if you try to mark T covariant. It's why IList<T> is not covariant even though IEnumerable<T> is.

[You, sir, name?]

I kinda wish $programming_language did not have null values

FTFY

Hrmmmm, no. Nulls can be useful (though some markup for enforcing not-null parameters functions would be nice).

Without null I'd have to either throw exceptions or otherwise keep track of a success/failure for many functions. Granted, there are probably other language constructs (not specifically in C#) that could handle that, but they're all as messy as null from what I'm aware.

Doesn't make a lot of sense. Java collections deal with references. null is a perfectly valid reference -- there is no real reason why it wouldn't be allowed. It's not like a C++ collection, which actually creates a new copy of the object and stores that.

[Xeio]

Doesn't make a lot of sense. Java collections deal with references. null is a perfectly valid reference -- there is no real reason why it wouldn't be allowed. It's not like a C++ collection, which actually creates a new copy of the object and stores that.

True, it is perfectly valid, though convention usually dictates not storing null values, similarly to how conventions dictates to never return a null if the type you're returning is a collection.*

I was mostly annoyed because I'm pretty sure the code works, at best, by accident. The null values in question are supposed to be a unique ID, but at some point someone threw that out the window and using the same field for different things depending on the type (and decided at that point that null means something entirely different). I've been working around that for a while, since it's not something I can fix without introducing a breaking change.

*C# convention, your language may vary.