Re: Ersatz update: Method references and functional interfaces
On Sun, Mar 17, 2013 at 12:45:32PM -0300, Guillermo R. Palavecino wrote: > > It is an important feature of PicoLisp that a construct like 'funcall' > > is NOT needed. > ... > Funcall is not meant for one-liners, it's meant to avoid the horrible > indentation that ((..) ..) gives in multi-line expressions: I agree with that. My main concern is just -- as I said -- that the existence of a function 'funcall' would induce wrong associations for new users. ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Ersatz update: Method references and functional interfaces
On Sun, 17 Mar 2013 15:18:43 +0100 Alexander Burger wrote: > It is an important feature of PicoLisp that a construct like 'funcall' > is NOT needed. > > One of the fundamental principles of the PicoLisp evaluation > mechanisms is that the CAR of a list is evaluated, and then used as a > function. > > Writing > >(de funcall "Args" > (eval "Args") ) > >(funcall (expression) 3 4) > > is the same as > >(eval '((expression) 3 4)) > > instead of > >((expression) 3 4) > > and thus a tautology, just with a considerable overhead. > > > Moreover, if you publish code using 'funcall', new users will assume > this is the right way to do, and use it also in cases like > >(de foo (Fun) > (funcall Fun 3 4) ) You are blowing it out of proportion with that example. It's not like users will start writing: (funcall mapcar pack (funcall split (funcall chop Lst) " " ) ) >(dm method> (Arg) > (funcall (: hint) Arg) ) > >(dm method> (Arg) > ((: hint) Arg) ) Funcall is not meant for one-liners, it's meant to avoid the horrible indentation that ((..) ..) gives in multi-line expressions: ((expression that returns a function) (the rest of the code ((that otherwise would) not look nice when (indented in a multi-line layout) ) ) ) where you end up with a case/cond looking layout for normal code (not to mention what you get if you happen to have (((..) ..) ..) as multi-line). I like this much better: (funcall (expression that returns a function) (the rest of the code (funcall (that otherwise would) not look nice when (indented in a multi-line layout) ) ) ) And it's not that much overhead anyway. From funcall to the actual call you just get: + Binding of "Args" + Call to eval + Restoring of "Args" which is as a bit less expensive than let plus one extra cell in the prg, so it's about as costly as a let. Just that, no big deal. -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Ersatz update: Method references and functional interfaces
Hi Guillermo, Samuel, I agree with all you both discussed, except for the 'funcall' issue. > By the way, the current build of srborlongan-picolisp now includes > java/funcall.l, 'cause you're awesome and your code is beautiful. It is an important feature of PicoLisp that a construct like 'funcall' is NOT needed. One of the fundamental principles of the PicoLisp evaluation mechanisms is that the CAR of a list is evaluated, and then used as a function. Writing (de funcall "Args" (eval "Args") ) (funcall (expression) 3 4) is the same as (eval '((expression) 3 4)) instead of ((expression) 3 4) and thus a tautology, just with a considerable overhead. Moreover, if you publish code using 'funcall', new users will assume this is the right way to do, and use it also in cases like (de foo (Fun) (funcall Fun 3 4) ) and (dm method> (Arg) (funcall (: hint) Arg) ) instead of simply (de foo (Fun) (Fun 3 4) ) and (dm method> (Arg) ((: hint) Arg) ) ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Ersatz update: Method references and functional interfaces
On Sun, 17 Mar 2013 12:06:27 +0800 Samuel Dennis Borlongan wrote: > Thanks for the critique! > > Pre-emptive apologies for the structure (or lack of it) of the reply > below: > > Apologies for making you refactor my sucky code. It was I who decided to refactor it so no worries. > I wrote that at around 2 am because I wanted to post a (in > retrospect, quite bad) example. And I replied that email at 5:30am ;-) > Please note that I only use superparens in code that I need to type > in the command line, I used to do that, but even in the commandline, I usually just put parens, maybe it's a habit I picked writing code in emacs and evaluating code from emacs itself (as well as interacting with the repl for debugging) instead of using a commandline separately and (re)loading files. (Just subtly throwing hints at you...) > since unfortunately my build environment is a > lot more awkward than you imagine: > > I use Notepad++ and the default shell in Windows XP and above. Indeed, that's awkward. > Apologies for the mapcars and code nesting. I've found that the best > way to solve that problem in my "production" code is to refactor the > nesting and mapcar-ing code into tiny easy-to-read functions (that do > not depend on nesting and mapcar-ing). The beautiful thing about the > Lisp family of languages is that refactoring (even via Notepad++) is > significantly easier compared to other languages (though Java in > Eclipse comes close, somewhat, maybe, probably, I don't know). You've got to try emacs + paredit (an advanced s-exp editor). Wish I still had some old screencasts I made of what was my full emacs editor stack for picolisp back then, but trust me, it's a life changer. > P.S. Apologies for replying to this message in a delayed manner. No worries about that. Actually I don't usually reply emails right away even if I have the time, unless it's an urgent matter. My reasons are: 1. I don't really like email. 2. I like to distille what's going to be in an email (quality > speed/quantity) 3. I don't care a lot about emails that: a. Have little or nothing to do with me. b. Treat topics I have_not_much_to_say/don't_care about. > Personal issues (much more stressful than all the possible blunt > critiques you can throw at me, and news on the state of the video > game industry combined) prevented me from reading my mail. Oh? video game industry? Could you elaborate on that? if you don't mind, that is... Last but not least, you should visit us sometimes at #picol...@irc.freenode.net ;-) > On Fri, Mar 15, 2013 at 4:31 PM, Guillermo R. Palavecino > wrote: > > > You should reconsider writing mapcars like crazy. Not only makes > > the code overly redundant and verbose, but since picolisp has no > > compiler, it will do exactly what you express, and so it will > > traverse the list once for every mapcar you do, and what's worse, > > it will create a new list each time (not to mention the resulting > > list isn't used anywhere at all). Also, you are adding a lot of > > unnecessary nesting by filling the ArrayList inside of the method. > > All that code can be rewritten like this: > > > > (let ArrayList (ArrayList.new) > >(for N (range 0 20) > > (funcall (.add> T ArrayList) > > (big: > > (java > >(funcall (.compareTo> T BigInteger.TEN) > > (big: N) ) ) ) ) ) > >(.forEach> (.stream> ArrayList) > > (Consumer.new > > (.println> T System.out) ) ) ) > > > > Personally I don't like the ((..) ..) nesting for function calls, > > so I define a helper for these cases: > > > > (de funcall "Args" > >(eval "Args") ) > > > > Learn to write with proper style before your codebase grows any > > further or you'll have a lot to cleanup later. Readability matters. > > > > Also, even though the superparens are nice and all, they don't > > play well with most editors' paren matching, let alone advanced > > s-exps editing tools. Instead of compulsively using them you can > > try formatting your code better so you don't get that much nesting. > > When someone is trying so hard to avoid parens, it usually means he > > has not yet noticed that lisp parens are not nearly as abundant as > > other symbols in common languages. Try to count the amount of > > braces, parens, commas, infix operators, semicolon, etc you need in > > java, then compare with lisp. Then ask yourself, are there really > > so many parens? This is mostly a matter of getting used to lisp > > syntax, but you never will if you don't try... and when you do, > > maybe something will click inside you that will change for the > > better the way you see lisp syntax... forever. > > I'm betting you are using some awkward editor to code picolisp. > > Try emacs, with picolisp-mode, and paredit. It will change your > > life. > > > > Just my 2 cents. Hope you don't mind me being so blunt. > > > > On Wed, 13 Mar 2013 01:26:15 +0800 > > Samu
Re: Ersatz update: Method references and functional interfaces
You should reconsider writing mapcars like crazy. Not only makes the code overly redundant and verbose, but since picolisp has no compiler, it will do exactly what you express, and so it will traverse the list once for every mapcar you do, and what's worse, it will create a new list each time (not to mention the resulting list isn't used anywhere at all). Also, you are adding a lot of unnecessary nesting by filling the ArrayList inside of the method. All that code can be rewritten like this: (let ArrayList (ArrayList.new) (for N (range 0 20) (funcall (.add> T ArrayList) (big: (java (funcall (.compareTo> T BigInteger.TEN) (big: N) ) ) ) ) ) (.forEach> (.stream> ArrayList) (Consumer.new (.println> T System.out) ) ) ) Personally I don't like the ((..) ..) nesting for function calls, so I define a helper for these cases: (de funcall "Args" (eval "Args") ) Learn to write with proper style before your codebase grows any further or you'll have a lot to cleanup later. Readability matters. Also, even though the superparens are nice and all, they don't play well with most editors' paren matching, let alone advanced s-exps editing tools. Instead of compulsively using them you can try formatting your code better so you don't get that much nesting. When someone is trying so hard to avoid parens, it usually means he has not yet noticed that lisp parens are not nearly as abundant as other symbols in common languages. Try to count the amount of braces, parens, commas, infix operators, semicolon, etc you need in java, then compare with lisp. Then ask yourself, are there really so many parens? This is mostly a matter of getting used to lisp syntax, but you never will if you don't try... and when you do, maybe something will click inside you that will change for the better the way you see lisp syntax... forever. I'm betting you are using some awkward editor to code picolisp. Try emacs, with picolisp-mode, and paredit. It will change your life. Just my 2 cents. Hope you don't mind me being so blunt. On Wed, 13 Mar 2013 01:26:15 +0800 Samuel Dennis Borlongan wrote: > [let ArrayList (ArrayList.new) > (.forEach> > [.stream> > (prog1 ArrayList > (mapcar (.add> T ArrayList) > (mapcar 'big: > (mapcar 'java > (mapcar (.compareTo> T BigInteger.TEN) > (mapcar 'big: > (range 0 20] > (Consumer.new > (.println> T System.out] -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
