Re: [proto] Proto v5

2013-06-17 Thread Eric Niebler 
On 6/16/2013 11:59 AM, Agustín K-ballo Bergé wrote:
 On 15/06/2013 10:59 p.m., Eric Niebler wrote:
 - Some specific uses of Proto actions in constant expressions fail. GCC
 reports an ambiguity with ref-qualifiers in the following scenario:
 
  struct foo
  {
  int bar() 
  { return _bar; }
  //~ int bar() 
  //~ { return static_castint(_bar); }
  constexpr int const bar() const 
  { return _bar; }
  constexpr int const bar() const 
  { return static_castint const(_bar); }
 
  int _bar;
  };
 
  foo().bar();
 
For that to work correctly, the 4 overloads need to be provided.
 Huh. According to the standard, or according to gcc? I won't work around
 a bug in a compiler without filing it first.

 
 I got a thorough explanation on the subject from this SO question:
 http://stackoverflow.com/questions/17130607/overload-resolution-with-ref-qualifiers
 . The answer confirms this is a GCC bug, and hints to a better
 workaround that would retain constexpr functionality. I may pursue this
 alternative workaround if I ever get to play with the constexpr side of
 Proto v5 (that is, if I use it in a place other than next to an `omg` or
 `srsly` identifier :P).
 
 Another GCC bug (as far as I understand) is that instantiations within
 template arguments to a template alias are completely ignored when the
 aliased type does not depend on those, thus breaking SFINAE rules. I
 have attached a small code sample that reproduces this issue.

Thanks for your research. When I get a chance, I'll check gcc's bugzilla
to see if they have been filed already, unless you beat me to it.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Proto v5

2013-06-15 Thread Agustín K-ballo Bergé 

On 15/06/2013 03:43 a.m., Agustín K-ballo Bergé wrote:

On 14/06/2013 11:06 p.m., Eric Niebler wrote:


(Sorry for the top-posting. I'm away from my computer.)

The repository *is* compilable, if your compiler is clang built from
trunk. I suspect there are bugs in Proto, gcc, and clang, and sorting
it all out will be fun.

Thanks for your patch. I'll apply it as soon as I can.

Eric


That's the green light I was expecting to start picking Proto v5 at GCC.
I just got the first test compiling and passing successfully
(action.cpp). I have pushed all the changes to my fork of the
repository, so if you are interested keep an eye on it.

Even after disabling the substitution_failure machinery (to get the full
instantiation spew), going through the compiler output is mind
bending... My respects to you, sir!





The fork of Proto v5 at https://github.com/K-ballo/proto-0x correctly 
compiles and passes (almost*) all test cases and examples with GCC 
4.8.1. There are two caveats:


- GCC does not allow the use of `this` within noexcept specifications, 
so those are disabled. This is a bug in GCC (reported by Dave Abrahams 
here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52869)


- Some specific uses of Proto actions in constant expressions fail. GCC 
reports an ambiguity with ref-qualifiers in the following scenario:


struct foo
{
int bar() 
{ return _bar; }
//~ int bar() 
//~ { return static_castint(_bar); }
constexpr int const bar() const 
{ return _bar; }
constexpr int const bar() const 
{ return static_castint const(_bar); }

int _bar;
};

foo().bar();

  For that to work correctly, the 4 overloads need to be provided. 
This, in turn, means that non-const rvalues (?) cannot be used in 
constant expressions since constexpr implies const (in C++11, not 
anymore in C++14). Anyway, this is more than I can digest at the moment.


(*) the bit failing to compile is a use of Proto actions as a constant 
expression [the `omg` case at everywhere.cpp], due to the issue with 
ref-qualifier overloads.


Regards,
--
Agustín K-ballo Bergé.-
http://talesofcpp.fusionfenix.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Proto v5

2013-06-15 Thread Agustín K-ballo Bergé 

On 15/06/2013 10:59 p.m., Eric Niebler wrote:

On 13-06-15 03:40 PM, Agustín K-ballo Bergé wrote:

On 15/06/2013 03:43 a.m., Agustín K-ballo Bergé wrote:

On 14/06/2013 11:06 p.m., Eric Niebler wrote:

- Some specific uses of Proto actions in constant expressions fail. GCC
reports an ambiguity with ref-qualifiers in the following scenario:

 struct foo
 {
 int bar() 
 { return _bar; }
 //~ int bar() 
 //~ { return static_castint(_bar); }
 constexpr int const bar() const 
 { return _bar; }
 constexpr int const bar() const 
 { return static_castint const(_bar); }

 int _bar;
 };

 foo().bar();

   For that to work correctly, the 4 overloads need to be provided.


Huh. According to the standard, or according to gcc? I won't work around
a bug in a compiler without filing it first.


I do not know, this little experiment has got me re-reading the standard 
back and forth, but I am not that fluent in standardeese. I'm still 
researching this and a few other of the issues.



This,
in turn, means that non-const rvalues (?) cannot be used in constant
expressions since constexpr implies const (in C++11, not anymore in
C++14). Anyway, this is more than I can digest at the moment.

(*) the bit failing to compile is a use of Proto actions as a constant
expression [the `omg` case at everywhere.cpp], due to the issue with
ref-qualifier overloads.


I see you included all of these fixes in your one pull request. I'll
need to go through this carefully and file compiler bugs where
necessary.


I did not, or if I did it was unintentional. I only wanted to submit the 
first change I did, the one that fixes the duplicated constexprs. That's 
the single one I'm confident enough that has to be applied. Alas, the 
last change I did silences a GCC warning, so that one is another good 
candidate (after refactoring to your coding style). The others probably 
won't fit your coding style anyways, plus some are even incorrect and 
further reverted/fixed. They are only intended to be a guide of what has 
to be changed to please GCC.



I also want to use BOOST_WORKAROUND if we actually include
any temporary workarounds in the code. I say temporary because I have
every intention of ripping out all workarounds once the bugs actually
get fixed. I intend to keep this code as clean as possible.



I would appreciate if we could discuss (off-list if appropriate) all 
these changes I've done as you go through them, whenever you have the 
time. I am particularly interested in determining whether the code is 
standard conforming, or whether they are the result of bugs in either 
GCC or Clang.



A million thanks for your work. It's a huge help.



My pleasure. This has been a productive learning experience for me (one 
that has not yet ended I hope).


Regards,
--
Agustín K-ballo Bergé.-
http://talesofcpp.fusionfenix.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Proto v5

2013-06-14 Thread Eric Niebler 

I've made no effort so far to port Proto v5 to any compiler other than clang. 
I'm sure it would be a big job. I welcome any contributions. Otherwise, it'll 
get ported eventually, but probably not before I get the API settled.

Eric


Sent via tiny mobile device

-Original Message-
From: Agustín K-ballo Bergé kaball...@hotmail.com
Sender: proto proto-boun...@lists.boost.orgDate: Fri, 14 Jun 2013 16:19:23 
To: Discussions about Boost.Proto and DSEL designproto@lists.boost.org
Reply-To: Discussions about Boost.Proto and DSEL design
proto@lists.boost.org
Subject: [proto] Proto v5

Hi,

I watched the C++Now session about Proto v5, and now I want to play with 
it. I do not have the luxury of a Clang build from trunk, but I do have 
GCC 4.8.1 which should do pretty well.

I cloned the repository at https://github.com/ericniebler/proto-0x/. 
After jumping a few hoops, I am now left with tons of instances of the 
same errors:

- error: no type named 'proto_grammar_type' in ...
  using type = typename Ret::proto_grammar_type(Args...);

- error: no type named 'proto_action_type' in ...
  using type = typename Ret::proto_action_type(Args...);

For at least some cases, those are clear errors since the Ret type 
represents an empty structs (e.g. `not_`).

What is going on? What should I be doing to get Proto v5 to compile?

Regards,

-- 
Agustín K-ballo Bergé.-
http://talesofcpp.fusionfenix.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto