(index 'any 'lst) implementation
Hi Alex, >From this example (using 32-bit PicoLisp) : (index 9 (list 1 2 (prinl 9) (prinl 'more) 9)) 9 more -> 3 I see that the index function evaluates the entire lst before searching for a match. Wouldn’t it be more efficient to evaluate the elements of lst one by one, testing the result for a match, and only proceed with evaluation of the next element if a match was not found? Is there a specific reason why you didn’t implement it that way? Another question re. index: In the method final static int indx(Any x, Any y) in ersatz/sys.src, on lines 988-989, there is this: if (z == (y = y.Cdr)) return 0; Can you explain which case this if-test is handling? /Jon-- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: (index 'any 'lst) implementation
On 3. Sep, 2014, at 09:58, Jon Kleiser wrote: > Hi Alex, > >> From this example (using 32-bit PicoLisp) > > : (index 9 (list 1 2 (prinl 9) (prinl 'more) 9)) > 9 > more > -> 3 > > I see that the index function evaluates the entire lst before searching for a > match. Wouldn’t it be more efficient to evaluate the elements of lst one by > one, testing the result for a match, and only proceed with evaluation of the > next element if a match was not found? Is there a specific reason why you > didn’t implement it that way? > > Another question re. index: > In the method final static int indx(Any x, Any y) in ersatz/sys.src, on lines > 988-989, there is this: > if (z == (y = y.Cdr)) >return 0; > > Can you explain which case this if-test is handling? Now I think I know the answer to the last question: It tests for circularity. /Jon-- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Swimming against the tide, again (this time with numbers)
On Tue, Sep 2, 2014 at 8:14 PM, Tomas Hlavaty wrote: >> >> «…by multiplying with (or dividing by) the scale factor, which is always >> `1.0`.» > > it doesn't have to be always 1.0. If it was, it would not need to be > there at all. Oops. Could you give me some details about my mistake? Isn't «1.0» always read as «10^(*Scl)» which is what I'd call the scale factor? Thanks for your explanations and warnings. chri -- http://profgra.org/lycee/ (site pro) http://delicious.com/profgraorg (liens, favoris) https://twitter.com/profgraorg http://microalg.info -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Swimming against the tide, again (this time with numbers)
Hi Christophe, > > it doesn't have to be always 1.0. If it was, it would not need to be > > there at all. > > Oops. Could you give me some details about my mistake? > Isn't «1.0» always read as «10^(*Scl)» which is what I'd call the scale > factor? Yes, but *Scl is concerned only in the reader, when expanding the quasi-read-macro '.'. Other parts of the program may well use another scale, independent of '*Scl'. For example, each '+FixField' in the GUI knows about its own private scale factor. ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: (index 'any 'lst) implementation
Hi Jon, > : (index 9 (list 1 2 (prinl 9) (prinl 'more) 9)) > 9 > more > -> 3 > > I see that the index function evaluates the entire lst before > searching for a match. Wouldn’t it be more efficient to evaluate the > elements of lst one by one, testing the result for a match, and only > proceed with evaluation of the next element if a match was not found? Is > there a specific reason why you didn’t implement it that way? What you describe here is call "lazy evaluation". While some languages support this, PicoLisp (like most other Lisps) doesn't. Think about what this would mean: The function 'list' must know somehow that it should stop, because some function up in the call history doesn't need the whole list. And even if it knew that, can it know that some side effects (like your 'prinl' above) may be omitted? The fundamental rule of Lisp function calls (a function recursively evaluates its arguments before it starts to run) is broken here. > Another question re. index: > In the method final static int indx(Any x, Any y) in ersatz/sys.src, on lines > 988-989, there is this: > if (z == (y = y.Cdr)) > return 0; > > Can you explain which case this if-test is handling? You found the answer by yourself in your next mail ;-) ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: (index 'any 'lst) implementation
Hi Alex, On 3. Sep, 2014, at 14:56, Alexander Burger wrote: > Hi Jon, > >> : (index 9 (list 1 2 (prinl 9) (prinl 'more) 9)) >> 9 >> more >> -> 3 >> >> I see that the index function evaluates the entire lst before >> searching for a match. Wouldn’t it be more efficient to evaluate the >> elements of lst one by one, testing the result for a match, and only >> proceed with evaluation of the next element if a match was not found? Is >> there a specific reason why you didn’t implement it that way? > > What you describe here is call "lazy evaluation". While some languages > support this, PicoLisp (like most other Lisps) doesn't. > > Think about what this would mean: The function 'list' must know somehow > that it should stop, because some function up in the call history > doesn't need the whole list. > > And even if it knew that, can it know that some side effects (like your > 'prinl' above) may be omitted? > > The fundamental rule of Lisp function calls (a function recursively > evaluates its arguments before it starts to run) is broken here. Thanks! I think I see it more clearly now. What I observed in my example above was not caused by the 'index implementation, it was caused by the (PicoLisp) standard way of operation of the 'list function. /Jon-- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: (index 'any 'lst) implementation
Alexander Burger writes: Hi Alex, >> I see that the index function evaluates the entire lst before >> searching for a match. Wouldn’t it be more efficient to evaluate the >> elements of lst one by one, testing the result for a match, and only >> proceed with evaluation of the next element if a match was not found? Is >> there a specific reason why you didn’t implement it that way? > > What you describe here is call "lazy evaluation". While some languages > support this, PicoLisp (like most other Lisps) doesn't. > > Think about what this would mean: The function 'list' must know somehow > that it should stop, because some function up in the call history > doesn't need the whole list. > > And even if it knew that, can it know that some side effects (like your > 'prinl' above) may be omitted? > > The fundamental rule of Lisp function calls (a function recursively > evaluates its arguments before it starts to run) is broken here. Funny how views differ - in the Clojure world "lazy evaluation" seems to be a big feature ... OTOH, Paul Graham writes 150pages about the beauty and power of macros in 'On Lisp', what made me think that macros are the ultimate thing in programming, only to read later that 'macros are cludge' in the PicoLisp docs ;) -- cheers, Thorsten -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: (index 'any 'lst) implementation
On Wed, Sep 3, 2014 at 2:56 PM, Alexander Burger wrote: > > What you describe here is call "lazy evaluation". While some languages > support this, PicoLisp (like most other Lisps) doesn't. > […] > The fundamental rule of Lisp function calls (a function recursively > evaluates its arguments before it starts to run) is broken here. But what about functions in PicoLisp that don't evaluate all their args? f-expr are to me a big strenght of the language! chri -- http://profgra.org/lycee/ (site pro) http://delicious.com/profgraorg (liens, favoris) https://twitter.com/profgraorg http://microalg.info -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: (index 'any 'lst) implementation
Hi Thorsten, > Funny how views differ - in the Clojure world "lazy evaluation" seems > to be a big feature ... I don't say that "lazy evaluation" is a bad feature. It is in fact very powerful. But it assumes a completely different internal evaluation machinery. Basically, each function must run it its own thread and "pipe" its data to the recipient. But I doubt it is worth the effort. It introduces quite some overhead. At least it is against the PicoLisp philosophy to keep the programmer in control: You can always achieve the same effect as with lazy evaluation if you say explicitly what you want. In Jon's example, this would be using 'make' in a loop instead of the brute force 'list'. In the typical 'mapcar' example : (mapcar - (mapcar inc (1 2 3))) -> (-2 -3 -4) lazy evaluation would avoid creating a temporary list, but the same effect can be achieved with : (mapcar '((N) (- (inc N))) (1 2 3)) -> (-2 -3 -4) ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: (index 'any 'lst) implementation
Hi Christophe, > But what about functions in PicoLisp that don't evaluate all their > args? f-expr are to me a big strenght of the language! Right! This is another example of what I wrote in my other mail just now, i.e. you can better control it directly by yourself. ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
