Feature-Request - Macros

php.internals

Mathias Bank

19 years ago
Hallo, you know, that there was often a discussion about a "ifsetor" function. I want to generalize this discussion. If you know LISP, there is a fantastic macro function which allows you to generate own syntax (not a c macro function, which is really bad). It would be fantastic, if php could implement such a macro function. One example (for ifsetor): you could define macro ifsetor($param1, $param2) { return "if (isset($param1)) return $param1; else return $param2; } use: $test = ifsetor($_GET["blubb"],null); All you have to do is to not execute the parameters given in the macro parameter list. Instead, you have to evaluate the return statement and then to execute this statement. In this way, all discussions about ifsetor (or anything like this) could be avoided. The macro function could even be extended to allow new blocks, but then we have to extend the syntax to allow reference to the body. In this way, I always extend the syntax of the parameter data: only variables would be matched. macro foreachkey($array as $key, :body $body) { return "foreach ($array as $key=>$__dev0) { $body }"; } know, you can call $secondArray = array(); foreachkey($myArray as $myKey) { $secondArray[] = $myKey; } this would be extended to foreach ($myArray as $myKey=>$__dev0) { $secondArray[] = $myKey; } and this code will be executed. As you see, with this macro functions, it could be achieved any individual syntax. It would be a pleasure, if php could support it. It could shorten a lot of code. Mathias

Matt Sicker

19 years ago
On Monday 13 November 2006 04:42, Mathias Bank wrote:
> Hallo, > > you know, that there was often a discussion about a "ifsetor" > function. I want to generalize this discussion. If you know LISP, > there is a fantastic macro function which allows you to generate own > syntax (not a c macro function, which is really bad). It would be > fantastic, if php could implement such a macro function. One example > (for ifsetor): you could define > > macro ifsetor($param1, $param2) { > return "if (isset($param1)) return $param1; else return $param2; > } > > use: $test = ifsetor($_GET["blubb"],null); > > All you have to do is to not execute the parameters given in the > macro parameter list. Instead, you have to evaluate the return > statement and then to execute this statement. > > In this way, all discussions about ifsetor (or anything like this) > could be avoided. > > The macro function could even be extended to allow new blocks, but > then we have to extend the syntax to allow reference to the body. In > this way, I always extend the syntax of the parameter data: only > variables would be matched. > > macro foreachkey($array as $key, :body $body) { > return "foreach ($array as $key=>$__dev0) { > $body > }"; > } > > know, you can call > $secondArray = array(); > foreachkey($myArray as $myKey) { > $secondArray[] = $myKey; > } > > this would be extended to > foreach ($myArray as $myKey=>$__dev0) { > $secondArray[] = $myKey; > } > > and this code will be executed. > > As you see, with this macro functions, it could be achieved any > individual syntax. It would be a pleasure, if php could support it. > It could shorten a lot of code. > > Mathias
This could also help with writing code compatible across different major PHP versions (4, 5, and 6). It could help fuel upgrades so that supporting PHP4 isn't such a hassle in the future. I love the idea (especially the Lisp implementation).
-- Matt Sicker

Mathias Bank

19 years ago
Mathias Bank schrieb:
> Hallo, > > you know, that there was often a discussion about a "ifsetor" function. > I want to generalize this discussion. If you know LISP, there is a > fantastic macro function which allows you to generate own syntax (not a > c macro function, which is really bad). It would be fantastic, if php > could implement such a macro function. One example (for ifsetor): you > could define > > macro ifsetor($param1, $param2) { > return "if (isset($param1)) return $param1; else return $param2; > } > > use: $test = ifsetor($_GET["blubb"],null); > > All you have to do is to not execute the parameters given in the macro > parameter list. Instead, you have to evaluate the return statement and > then to execute this statement. > > In this way, all discussions about ifsetor (or anything like this) could > be avoided. > > The macro function could even be extended to allow new blocks, but then > we have to extend the syntax to allow reference to the body. In this > way, I always extend the syntax of the parameter data: only variables > would be matched. > > macro foreachkey($array as $key, :body $body) { > return "foreach ($array as $key=>$__dev0) { > $body > }"; > } > > know, you can call > $secondArray = array(); > foreachkey($myArray as $myKey) { > $secondArray[] = $myKey; > } > > this would be extended to > foreach ($myArray as $myKey=>$__dev0) { > $secondArray[] = $myKey; > } > > and this code will be executed. > > As you see, with this macro functions, it could be achieved any > individual syntax. It would be a pleasure, if php could support it. It > could shorten a lot of code. > > Mathias
I have recieved a few mails which have shown, that some people misunderstood my idea. It seems, that most of you know c/c++ macros. But I don't want to implement these macro functionality, because this functionality is really poor. Have a look at the macro functionality of lisp: http://www.gigamonkeys.com/book/macros-standard-control-constructs.html and http://www.gigamonkeys.com/book/macros-defining-your-own.html. There, it is described, what macros in lisp can do. You will see, that such macros cannot be compared with c/c++ macros. But it would be a pleasure for php, if such macros would be possible. You should really read it, I couldn't believe it until I have realized it at my own. PHP is a really great language and the syntax is much better than the syntax of lisp. But the macros are one big pleasure in lisp. And don't mistake lisp macros for c macros. They are much more powerful. Mathias

Marcus Börger

19 years ago
Hello Mathias, we would need a lexer/parser that support changing rules. That would mean changing bothtools. Eventhough that might happen if there are other reasons to do so,the toolswe change todo not necessarily support whatyou woule need. Based on our current experience re2c and lemon would be a big step forward as they also allow unicode handling. However i doubt that you can easily allow changing rules in lemon. Another solution would be to have your functionality as a stream operation. That is an extension could rewrite the incoming script while it is being compiled. I have however no idea if and how that could be achieved. best regards marcus Wednesday, November 15, 2006, 6:06:42 PM, you wrote:
> Mathias Bank schrieb: >> Hallo, >> >> you know, that there was often a discussion about a "ifsetor" function. >> I want to generalize this discussion. If you know LISP, there is a >> fantastic macro function which allows you to generate own syntax (not a >> c macro function, which is really bad). It would be fantastic, if php >> could implement such a macro function. One example (for ifsetor): you >> could define >> >> macro ifsetor($param1, $param2) { >> return "if (isset($param1)) return $param1; else return $param2; >> } >> >> use: $test = ifsetor($_GET["blubb"],null); >> >> All you have to do is to not execute the parameters given in the macro >> parameter list. Instead, you have to evaluate the return statement and >> then to execute this statement. >> >> In this way, all discussions about ifsetor (or anything like this) could >> be avoided. >> >> The macro function could even be extended to allow new blocks, but then >> we have to extend the syntax to allow reference to the body. In this >> way, I always extend the syntax of the parameter data: only variables >> would be matched. >> >> macro foreachkey($array as $key, :body $body) { >> return "foreach ($array as $key=>$__dev0) { >> $body >> }"; >> } >> >> know, you can call >> $secondArray = array(); >> foreachkey($myArray as $myKey) { >> $secondArray[] = $myKey; >> } >> >> this would be extended to >> foreach ($myArray as $myKey=>$__dev0) { >> $secondArray[] = $myKey; >> } >> >> and this code will be executed. >> >> As you see, with this macro functions, it could be achieved any >> individual syntax. It would be a pleasure, if php could support it. It >> could shorten a lot of code. >> >> Mathias
> I have recieved a few mails which have shown, that some people > misunderstood my idea. It seems, that most of you know c/c++ macros. But > I don't want to implement these macro functionality, because this > functionality is really poor. Have a look at the macro functionality of > lisp: > http://www.gigamonkeys.com/book/macros-standard-control-constructs.html > and http://www.gigamonkeys.com/book/macros-defining-your-own.html. > There, it is described, what macros in lisp can do. You will see, that > such macros cannot be compared with c/c++ macros. But it would be a > pleasure for php, if such macros would be possible. You should really > read it, I couldn't believe it until I have realized it at my own.
> PHP is a really great language and the syntax is much better than the > syntax of lisp. But the macros are one big pleasure in lisp. And don't > mistake lisp macros for c macros. They are much more powerful.
> Mathias
Best regards, Marcus

Richard Lynch

19 years ago
On Mon, November 13, 2006 4:42 am, Mathias Bank wrote:
> As you see, with this macro functions, it could be achieved any > individual syntax. It would be a pleasure, if php could support it. It > could shorten a lot of code.
It sounds like you could submit a patch and get it in... :-) While you are at it, if you want to dump the java-like OOP and put in all of CLOS, go for it :-) :-) :-)
-- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So?

Mathias Bank

19 years ago
Richard Lynch schrieb:
> On Mon, November 13, 2006 4:42 am, Mathias Bank wrote: >> As you see, with this macro functions, it could be achieved any >> individual syntax. It would be a pleasure, if php could support it. It >> could shorten a lot of code. > > It sounds like you could submit a patch and get it in... :-) > > While you are at it, if you want to dump the java-like OOP and put in > all of CLOS, go for it :-) :-) :-) >
Well, I have never said, that this is easy. But instead of telling "no" to ideas like ifsetor operator (or something else), we could say: "well no: there will be a general solution". And this solution must not be invented, it "just" has to be integrated - we can look at lisp and how it is implemented there. Of course this is no job for a week or a month (so surely not for php 6). I published this feature request to discuss the idea with you php developers because you should know it best, if it is possible and if there are ways, to achieve this (and what are the ways). So, there is no reason to be cynical. Mathias

Richard Lynch

19 years ago
On Wed, November 15, 2006 2:59 pm, Mathias Bank wrote:
> Richard Lynch schrieb: >> On Mon, November 13, 2006 4:42 am, Mathias Bank wrote: >>> As you see, with this macro functions, it could be achieved any >>> individual syntax. It would be a pleasure, if php could support it. >>> It >>> could shorten a lot of code. >> >> It sounds like you could submit a patch and get it in... :-) >> >> While you are at it, if you want to dump the java-like OOP and put >> in >> all of CLOS, go for it :-) :-) :-) >> > > Well, I have never said, that this is easy. But instead of telling > "no" > to ideas like ifsetor operator (or something else), we could say: > "well > no: there will be a general solution". And this solution must not be > invented, it "just" has to be integrated - we can look at lisp and how > it is implemented there. Of course this is no job for a week or a > month > (so surely not for php 6). I published this feature request to discuss > the idea with you php developers because you should know it best, if > it > is possible and if there are ways, to achieve this (and what are the > ways). > > So, there is no reason to be cynical.
Cynicism was not intended at all. Well, okay, the "all of CLOS" bit was maybe jokingly cynical. But I'm absolutely serious that there seems to be support for the lisp-like macros, so start working on a patch and submit it.
-- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So?

LAUPRETRE François (P)

19 years ago
Mathias Bank wrote:
>Well, I have never said, that this is easy. But instead of telling "no" >to ideas like ifsetor operator (or something else), we could say: "well >no: there will be a general solution". And this solution must not be >invented, it "just" has to be integrated - we can look at lisp and how >it is implemented there. Of course this is no job for a week or a month >(so surely not for php 6). I published this feature request to discuss >the idea with you php developers because you should know it best, if it >is possible and if there are ways, to achieve this (and what are the ways). > >So, there is no reason to be cynical.
I completely agree. I don't understand why some people on this list always give this kind of reply. You can give an idea and be unable to realize it. An idea is a contribution by itself. When you get such a reply, what do you understand ? Just that "If you are not ready to submit a patch, keep your idea for you". But coding is just one of the steps, bringing a good idea is at least as valuable. Once again, I submit an idea which got no reply yet: I propose to establish a more formal process for RFCs. You all know that the mailing list is perfect for many things, but not for somebody to propose something. If your suggestion is well thought, you certainly will need more than 10 lines to detail it. And, posting it to the list inserts it in a flow where it will probably disappear. Creating a real RFC process would, IMHO, bring many benefits. What do you think about it ? Regards Francois

Richard Quadling

19 years ago
For an outsider, an RFC would be a great mechanism. This will let us users see what future development is planned without having to be part of the inner group. Considering how much is done in IRC and therefore not visible to a lot of people after the fact, a formalized process would actually give the core developers some breathing space to actually get there job done. Not that they are not doing a good job. That is not what I mean. It would allow them to put down their plans have then discussed and the current situation be visible instantly without the need to resort to reading archives of a newsgroup. IMO (humble or otherwise) email/newsgroups/IRC is not the best way to conduct the future development of the excellent PHP. Maybe the discussion starts there (Hey! I've a great idea), but once some thought has gone into it, it needs to be concreted for others to REALLY review. And an RFC mechanism should be available for that. It may need nothing more than a rigidly administered forums/BB (phpBB anyone).Only on topic replies directly related to the RFC. Initially anyway. On 21/11/06, LAUPRETRE François (P) <francois.laupretre@ratp.fr> wrote: > Mathias Bank wrote: > > >Well, I have never said, that this is easy. But instead of telling "no" > >to ideas like ifsetor operator (or something else), we could say: "well > >no: there will be a general solution". And this solution must not be > >invented, it "just" has to be integrated - we can look at lisp and how > >it is implemented there. Of course this is no job for a week or a month > >(so surely not for php 6). I published this feature request to discuss > >the idea with you php developers because you should know it best, if it > >is possible and if there are ways, to achieve this (and what are the ways). > > > >So, there is no reason to be cynical. > > I completely agree. I don't understand why some people on this list always give this > kind of reply. You can give an idea and be unable to realize it. An idea is a contribution > by itself. When you get such a reply, what do you understand ? Just that "If you are not ready > to submit a patch, keep your idea for you". But coding is just one of the steps, bringing > a good idea is at least as valuable. > > Once again, I submit an idea which got no reply yet: I propose to establish a more formal > process for RFCs. You all know that the mailing list is perfect for many things, > but not for somebody to propose something. If your suggestion is well thought, you > certainly will need more than 10 lines to detail it. And, posting it to the list > inserts it in a flow where it will probably disappear. Creating a real RFC process would, > IMHO, bring many benefits. What do you think about it ? > > Regards > > Francois > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!"

LAUPRETRE François (P)

19 years ago
Exact. IMO too :), the main benefits are : - To keep tracks. Everyday, on this list, we see messages like 'I know we already talked about this (but not who and when)', 'We agreed on this (but cannot remember how and why...)', 'this question was already discussed', ... There's no way for a new comer to know if his idea/suggestion/request brings something new or if there an history on this subject. The only way is to ask on the list. And I must say that most PHP core people are very patient (more than I would be) as they spend a non negligible part of their time reading and replying to this kind of questions. Sometimes, unfortunately, somebody coming with a naive question gets a rough reply, although there was no alternative way for him to get the information. - To setup a quieter place to publish some documents and discuss about them. As opposed to the continuous flow on an irc/newsgroup mechanism, on such a space, you can expose your ideas on several pages, you can provide some diagrams, you can explain in details why you support/dislike somebody else's RFC... Just as you cannot explain everything in 1 minute with a Powerpoint slide, some valuable ideas/suggestions/concepts are not simple to explain. In practice, today, new ideas are filtered through their easiness to be understood in less than 10 seconds, and by the ability of their author to implement it by him/herself (sorry, Sara, I initially wrote 'by HIMself' :). It is not a bad filter but we can make it better. - Making the process more formal would force people to think more before submitting an RFC. Some suggestions we see on the list are not bad but their author do not think enough about the subject before submitting them, with 2 drawbacks : once again, core programmers spend some time writing basic replies, and the suggestion is generally rejected, not because it is bad, but because it is not mature enough. And don't tell me that people don't like to write the doc, that requesting more formal submissions would refrain people from submitting valuable ideas: for most of us, english is not a native language and, if somebody does not submit his idea just because he refuses to expose it clearly on 1 or 2 pages, it is OK, I consider that his idea was probably not so interesting. - Publishing the RFCs on a dedicated space will allow more people to read and discuss about them. Today, when you submit an idea on the list, the audience is quite limited. The list is primarily intended for 'core developers', many people interested in PHP strategy have no interest in day to day core development and they don't have any reason to subscribe to this list, where they will have to manually filter one message every 20 or 30. And, of course, if the subject of your submission is not 'visible' enough, very few people will read your proposal. - A last obvious reason is the ability to setup a real voting process. As Richard writes, it shouldn't be too hard to setup, from a forum basis. I didn't search the Internet but we can probably find more while keeping it light. I am ready to implement, to house, and to administer it. Regards Francois -----Original Message----- From: Richard Quadling [mailto:rquadling@googlemail.com]