Re: [jinterface] add erlang term parse/match/bind features
Vlad Dumitrescu <[email protected]> Thu, 1 Jan 2015 15:12:08 +0100
| Newsgroups | gmane.comp.lang.erlang.patches |
|---|---|
| Message-ID | <CAA-EFXtkU6=NwYO-cCqAbcVd80ip87pLROZ1-hp6uK5ycv+Aqw@mail.gmail.com> |
--===============3917639575273307572== Content-Type: multipart/alternative; boundary=001a1134d57a73bc13050b97d0e4 --001a1134d57a73bc13050b97d0e4 Content-Type: text/plain; charset=UTF-8 Hi Dmitriy, I'm still going through your code, but I wonder if you could explain why equals should be implemented in terms of match? I think these are two different operations and can be relevant only if checking equals between a regular term and a pattern, but I can't see any reason to want to do that because these should never be equal. Or maybe I am missing a fine point?... I am also wondering if OEObject itself could implement OEMatcher and just call match/bind recursively instead of checking "instanceof OEMatcher" in OEList, OEMap and OETuple. It feels easier to understand (less conditionals in the code). In my implementation, I did it in a slightly different way, mostly in order to modify existing classes as little as possible, by using an utility class to traverse terms and do matching and binding. I also have more advanced conversion routines between Java and Erlang types (most useful are for Strings, List<->list and Array<->tuple/binary). Maybe you would like to check at https://github.com/vladdu/otp/compare/erlang:master...jinterface_new_api? Maybe we should try to unify our code first and then submit it to OTP? Happy New Year and I guess that for you it's even Merry Christmas in a week, right? Vlad On Wed, Dec 31, 2014 at 5:31 PM, Dmitriy Kargapolov < [email protected]> wrote: > Hi Vlad, > Thank you much for your notes. > > I agree some names were not good enough, I changed these per your > suggestion. > Old comment removed as well. > > As to OtpErangMap class - I was not going to re-implement it initially. > But in order to add match/bind I had to do this. I tried to not add much > new methods, keeping implementation rather "just enough" to work with maps. > You are very welcome to add/change whatever you see reasonable in separate > PR though. > > Best Regards and Happy New Year! > - Dmitriy. > > git fetch https://github.com/x0id/otp.git jinterface_pattern_matching > > > https://github.com/x0id/otp/compare/erlang:master...jinterface_pattern_matching > > https://github.com/x0id/otp/compare/erlang:master...jinterface_pattern_matching.patch > > > On 12/31/2014 10:27 AM, Vlad Dumitrescu wrote: > > Hi Dmitriy, > > Nice implementation! I have something similar that I wanted to submit, > but I like some of your details better. > > I have a few comments, after browsing the code just briefly: > > - I would prefer to have the OEMap changes as a separate PR, as it's a > separate issue and there are more things to address there, like for > example, OEMap could also implement Map, like OEList implements Iterable > (and might implement List). > - I don't like the name OEVarrier, it doesn't mean anything. Maybe > OEMatcher would be better? > - OEBind might be clearer as OEBinding, as it contains a set of bindings? > - I think there are still some merge issues, like for example OEList:299 > where the comment is from the old equals method > > best regards, > Vlad > > > On Tue, Dec 30, 2014 at 9:56 PM, Dmitriy Kargapolov < > [email protected]> wrote: > >> This implements functionality similar to following C functions, which are >> part of erl_interface application: >> - ETERM *erl_format(FormatStr, ...); >> - int erl_match(ETERM *Pattern, ETERM *Term); >> >> To acheve this new classes introduced: >> * OtpErlangVar - variable placeholder; >> * OtpErlangBind - variable values collection; >> * OtpErlangParser - "erl_format" parser implementation; >> * OtpErlangPattern - pattern abstraction with match/bind functions; >> >> Classes representing composite objects OtpErlangList, OtpErlangTuple, >> OtpErlangMap and new OtpErlangVar implement interface OtpErlangVarrier >> defining match and bind functions for these objects. >> >> Class OtpErlangMap reworked to be based on HashMap instead of two >> separate lists keeping keys and values. This is close to native semantics >> of maps and makes easier implementing basic map manipulations. >> >> It addition to OtpErlangBind custom user's class may be used as receiver >> of matched variables values. Java reflection is used to prepare variable >> value setters during the parse stage. Java doc has more details and >> examples. Test cases implemented. >> >> git fetch https://github.com/x0id/otp.git jinterface_pattern_matching >> >> Thanks. >> >> >> >> >> >> _______________________________________________ >> erlang-patches mailing list >> [email protected] >> http://erlang.org/mailman/listinfo/erlang-patches >> > > > --001a1134d57a73bc13050b97d0e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Hi Dmitriy,<div><br></div><div>I'm still going through= your code, but I wonder if you could explain why equals should be implemen= ted in terms of match? I think these are two different operations and can b= e relevant only if checking equals between a regular term and a pattern, bu= t I can't see any reason to want to do that because these should never = be equal. Or maybe I am missing a fine point?...</div><div><br></div><div>I= am also wondering if OEObject itself could implement OEMatcher and just ca= ll match/bind recursively instead of checking "instanceof OEMatcher&qu= ot; in OEList, OEMap and OETuple. It feels easier to understand (less condi= tionals in the code).</div><div><br></div><div>In my implementation, I did = it in a slightly different way, mostly in order to modify existing classes = as little as possible, by using an utility class to traverse terms and do m= atching and binding. I also have more advanced conversion routines between = Java and Erlang types (most useful are for Strings, List<->list and A= rray<->tuple/binary). Maybe you would like to check at=C2=A0<a href= =3D"https://github.com/vladdu/otp/compare/erlang:master...jinterface_new_ap= i">https://github.com/vladdu/otp/compare/erlang:master...jinterface_new_api= </a>?</div><div><br></div><div>Maybe we should try to unify our code first = and then submit it to OTP?=C2=A0</div><div><br></div><div>Happy New Year an= d I guess that for you it's even Merry Christmas in a week, right?</div= ><div>Vlad</div><div><br></div></div><div class=3D"gmail_extra"><br><div cl= ass=3D"gmail_quote">On Wed, Dec 31, 2014 at 5:31 PM, Dmitriy Kargapolov <sp= an dir=3D"ltr"><<a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a>></span> wrote:<br><blockquo= te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so= lid;padding-left:1ex"> =20 =20 =20 <div bgcolor=3D"#FFFFFF" text=3D"#000000"> <div>Hi Vlad,<br> Thank you much for your notes.<br> <br> I agree some names were not good enough, I changed these per your suggestion.<br> Old comment removed as well.<br> <br> As to OtpErangMap class - I was not going to re-implement it initially. But in order to add match/bind I had to do this. I tried to not add much new methods, keeping implementation rather "just enough" to work with maps. You are very welcome to add/change whatever you see reasonable in separate PR though.<br> <br> Best Regards and Happy New Year!<br> - Dmitriy.<span class=3D""><br> <br> git fetch <a href=3D"https://github.com/x0id/otp.git" target=3D"_blan= k">https://github.com/x0id/otp.git</a> jinterface_pattern_matching<br> <br> </span><a href=3D"https://github.com/x0id/otp/compare/erlang:master...jinte= rface_pattern_matching" target=3D"_blank">https://github.com/x0id/otp/compa= re/erlang:master...jinterface_pattern_matching</a><br> <a href=3D"https://github.com/x0id/otp/compare/erlang:master...jinterface_p= attern_matching.patch" target=3D"_blank">https://github.com/x0id/otp/compar= e/erlang:master...jinterface_pattern_matching.patch</a><div><div class=3D"h= 5"><br> <br> On 12/31/2014 10:27 AM, Vlad Dumitrescu wrote:<br> </div></div></div><div><div class=3D"h5"> <blockquote type=3D"cite"> <div dir=3D"ltr">Hi Dmitriy, <div><br> </div> <div>Nice implementation! I have something similar that I wanted to submit, but I like some of your details better.</div> <div><br> </div> <div>I have a few comments, after browsing the code just briefly:</div> <div><br> </div> <div>- I would prefer to have the OEMap changes as a separate PR, as it's a separate issue and there are more things to address there, like for example, OEMap could also implement Map, like OEList implements Iterable (and might implement List).=C2=A0</div> <div>- I don't like the name OEVarrier, it doesn't mean anything. Maybe OEMatcher would be better?</div> <div>- OEBind might be clearer as OEBinding, as it contains a set of bindings?</div> <div>- I think there are still some merge issues, like for example OEList:299 where the comment is from the old equals method</div> <div><br> </div> <div>best regards,</div> <div>Vlad</div> <div><br> </div> </div> <div class=3D"gmail_extra"><br> <div class=3D"gmail_quote">On Tue, Dec 30, 2014 at 9:56 PM, Dmitriy Kargapolov <span dir=3D"ltr"><<a href=3D"mailto:dmitri= [email protected]" target=3D"_blank">[email protected]</a>&= gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord= er-left:1px #ccc solid;padding-left:1ex">This implements functionality similar to following C functions, which are part of erl_interface application:<br> - ETERM *erl_format(FormatStr, ...);<br> - int erl_match(ETERM *Pattern, ETERM *Term);<br> <br> To acheve this new classes introduced:<br> * OtpErlangVar - variable placeholder;<br> * OtpErlangBind - variable values collection;<br> * OtpErlangParser - "erl_format" parser implementatio= n;<br> * OtpErlangPattern - pattern abstraction with match/bind functions;<br> <br> Classes representing composite objects OtpErlangList, OtpErlangTuple, OtpErlangMap and new OtpErlangVar implement interface OtpErlangVarrier defining match and bind functions for these objects.<br> <br> Class OtpErlangMap reworked to be based on HashMap instead of two separate lists keeping keys and values. This is close to native semantics of maps and makes easier implementing basic map manipulations.<br> <br> It addition to OtpErlangBind custom user's class may be use= d as receiver of matched variables values. Java reflection is used to prepare variable value setters during the parse stage. Java doc has more details and examples. Test cases implemented.<br> <br> git fetch <a href=3D"https://github.com/x0id/otp.git" target=3D= "_blank">https://github.com/x0id/otp.git</a> jinterface_pattern_matching<br> <br> Thanks.<br> <br> <br> <br> <br> <br> _______________________________________________<br> erlang-patches mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank">= [email protected]</a><br> <a href=3D"http://erlang.org/mailman/listinfo/erlang-patches" t= arget=3D"_blank">http://erlang.org/mailman/listinfo/erlang-patches</a><br> </blockquote> </div> <br> </div> </blockquote> <br> </div></div></div> </blockquote></div><br></div> --001a1134d57a73bc13050b97d0e4-- --===============3917639575273307572== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ erlang-patches mailing list [email protected] http://erlang.org/mailman/listinfo/erlang-patches --===============3917639575273307572==--