{"push_id":754140267,"size":1,"distinct_size":1,"ref":"refs/heads/master","head":"cfae703f4c2733dc58d020d65be7156c5f3d9593","before":"367ac2dc781459224d61b2ebe0058fdee6dbfc47","commits":[{"sha":"cfae703f4c2733dc58d020d65be7156c5f3d9593","author":{"email":"760e7dab2836853c63805033e514668301fa9c47@hostilefork.com","name":"Hostile Fork"},"message":"Custom infix operators via <infix> in spec, kill OP!\n\nThis provides the ability to make arbitrary infix functions.  This is\nfor both user code and to simplify the creation of Rebol's default\ninfix operators as mezzanines.  It introduces <infix> as the first\ncase of a function \"attribute\", which you put at the start of a spec:\n\n    +: func [<infix> value1 value2] [add value1 value2]\n\nThe INFIX attribute is implemented as one of the value-specific\noption bits in the Rebol header, which previously is where OP!\nwould store its \"actual type\" of the function it was wrapping.  The\nOP! datatype has been killed, and a new infix? test replacing\nOP?.\n\n(Note: an OP? implementation is temporarily provided, with the\ntraditional behavior of tolerating any type whether function or not.)\n\nThe infix mezzanines will perform slightly slower than their old\nOP! counterparts would, as they are functions with Rebol code\nbodies that execute vs. just a trampoline to the C code.  However\nby being \"just a bit\" on the spec, it means infixness would be able\nto be applied to any speedy mode of specialization or function\naliasing that gets implemented...which is a general need and will\nhave to be written to turn :append/only into a \"refined\" function\n(for instance).  In the meantime, the mezzanines are at least\npartially \"compiled\" with the literal NATIVE! value they wrap.","distinct":true,"url":"https://api.github.com/repos/metaeducation/ren-c/commits/cfae703f4c2733dc58d020d65be7156c5f3d9593"}]}