Re: [stan-dev] user-defined stuff

[Bob Carpenter]

On June 10, 2013 05:48:01 PM EDT, Ben Goodrich <goodri...@gmail.com> wrote:

> The TO-DO file has a number of references to user-defined stuff. As a
> simple starting point, can we
>
> -- add a grammar rule so that any function in the .stan file whose name
> ends in __ (or some other magic character combination) is parsed as a
> literal C++ function call

We could do that. There wouldn't be any error checking on the model

function signatures, but presumably that would be OK for a user writing
their own C++.

> -- amend the target in the makefile so if a directory contains both
> foo.stan and foo.hpp, then after parsing foo.stan to foo.cpp the make call
> is like
>
> $(CC) -include foo.hpp -c -o foo.o foo.cpp
>
> which according to the documentation of g++ and clang++ is equivalent to
> manually adding
>
> #include "foo.hpp"
>
> at the very top of foo.cpp. That way a user could declare / define a
> function like bar__() in foo.hpp and use bar__() in foo.cpp that is
> generated from foo.stan.

Cool.

What namespace should they declare the function in or should they
just make it global? We only having "using" statements for some parts
of Stan.

> That seems easy and unlikely to break any existing code, although users
> would be on their own when utilizing anything in foo.hpp. It also lowers
> the barrier where someone maybe wants to try something out before deciding
> to make the effort to get it included in Stan.

It basically saves them having to (a) recompile Stan from scratch,
and (b) declare the function signatures. I'm not sure that's such
a huge savings in terms of work, but anything that lowers the complexity
level is probably helpful.

- Bob

[Ben Goodrich]

On Monday, June 10, 2013 7:22:36 PM UTC-4, Bob Carpenter wrote:

What namespace should they declare the function in or should they
just make it global?  We only having "using" statements for some parts
of Stan.

I would think global would usually be fine, but if someone is capable of using this plugin mechanism they are probably capable of figuring out what needs to go in what namespace. Anyway, we just need to make a couple of safe changes and then it's their problem if it doesn't work.

Ben

[Bob Carpenter]

On June 10, 2013 08:19:49 PM EDT, Ben Goodrich <goodri...@gmail.com> wrote:

> On Monday, June 10, 2013 7:22:36 PM UTC-4, Bob Carpenter wrote:
>>
>> What namespace should they declare the function in or should they
>> just make it global? We only having "using" statements for some parts
>> of Stan.
>>
>
> I would think global would usually be fine, but if someone is capable of
> using this plugin mechanism they are probably capable of figuring out what
> needs to go in what namespace.

Stan doesn't (currently) allow "::" in function names, so there'd be
no way to get a user namespace in. They'd have to define it in one of
the ones we already include.

> Anyway, we just need to make a couple of
> safe changes and then it's their problem if it doesn't work.

I don't quite look at things this way. We can make safe changes, but
then we need to (a) document them, and (b) help users get them working
when they write to us. The simpler the mechanism is, the easier these
two tasks are. Gradually piling on complexity, even if each incremental
change is no big deal, can add up in making a system hard to understand
or debug.

- Bob

[Ben Goodrich]

On Tuesday, June 11, 2013 1:17:33 PM UTC-4, Bob Carpenter wrote:

On June 10, 2013 08:19:49 PM EDT, Ben Goodrich <goodri...@gmail.com> wrote:

> On Monday, June 10, 2013 7:22:36 PM UTC-4, Bob Carpenter wrote:
>>
>> What namespace should they declare the function in or should they
>> just make it global?  We only having "using" statements for some parts
>> of Stan.
>>
>
> I would think global would usually be fine, but if someone is capable of
> using this plugin mechanism they are probably capable of figuring out what
> needs to go in what namespace.

Stan doesn't (currently) allow "::" in function names, so there'd be
no way to get a user namespace in.  They'd have to define it in one of
the ones we already include.

I was presuming that if the function name ended in __ then the :: would be permitted as well.
 

> Anyway, we just need to make a couple of
> safe changes and then it's their problem if it doesn't work.

I don't quite look at things this way.  We can make safe changes, but
then we need to (a) document them, and (b) help users get them working
when they write to us.  The simpler the mechanism is, the easier these
two tasks are.  Gradually piling on complexity, even if each incremental
change is no big deal, can add up in making a system hard to understand
or debug.

That is a reasonable perspective, but I think this is a good compromise that doesn't require much of us. We just have to tell people that they can do regular C++ if they have a foo.hpp file in the same directory as foo.stan and that their callable(s) need to end in __.

Ben