Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - seetho

Pages1
#1
newLISP newS /
January 15, 2009, 05:47:53 AM
Quote from: "DrDave"
Now that is very interesting! Why does letex create a variable that seems to get evaluated?


Functions are left associative so, the letex expression gets evaluated first, so all y gets substituted and evaluated to its final value before case get evaluated, and by then it sees the final value there as a constant.
#2
newLISP newS /
January 14, 2009, 08:07:01 AM
Quote from: "Kazimir Majorinc"Actually, there is a problem, because in if statetement, it is not only result of the evaluation of then-branch and else-branch that matters, but side effects matter as well. So, in your mental model, it is not enough that processor #1 decides which result it will use (#3 or #4), it is important that evaluation of the "wrong one" never actually happened.


So in the example of an IF statement you'd have to wait for the PREDICATE clause to return before deciding on executing the THEN clause or the ELSE clause.  If I understand you correctly, this is because the PREDICATE clause may have some side effects on either the THEN or ELSE clauses, making it impossible to evaluate them in parallel.  Still either one will get evaluated eventually.


Quote(case exp-switch (exp-1 body-1) [(exp-2 body-2) ... ])


My original gripe was that exp-1 implied that it was evaluated.  It would've been better to call it const-1 so that you get](case exp-switch (const-1 body-1) [(const-2 body-2) ... ])[/code]

You see "const" then you know that you cannot put an expression there. I know it seems a petty matter to those already familiar with the concept, but to newbies like me emerging from decades of languishing in the "dark side" of imperative languages, it does make things easier to grasp.
#3
newLISP newS /
January 14, 2009, 06:39:05 AM
Quote from: "DrDave"However, I think in newLISP that if the first argument evaluates to true, then  the second argument is never processed (lazy evaluation), thereby saving the computation time, etc., that would be required for that evaluation.


Let's just say the 2nd argument "did not need to be" evaluated instead of "never" because it could have been evaluated if we wanted to.  Just that the results will not be used.  Of course in practice, resource efficiency is important so "lazy evaluation" is adopted to cut down on unneccessary work.  I can imagine that in a multi-threaded enviroment optimised for speed, the 2nd argument would've been evaluated in any case.
#4
newLISP newS /
January 14, 2009, 04:12:04 AM
At first look, the IF statement is really puzzling if you stubbornly insist that everything in a list is evaluated (sequentially), but then if you look again carefully as DrDave mentions it still is consistent.



If you think in terms of everything being processed in parallel then it may easier to imagine.  Take for example that this list/expression if received by a super multi-processor computing environment.  The statement



(IF (= 5 (+ 2 2)) "ok" (exit))



get passed to processor#1 to handle.  Processor#1 then decides that it can pass on



(= 5 (+ 2 2)) to processor#2, "ok" to processor#3 and (exit) to processor#4.



Everything is now evaluated in parallel and processor#1 knows that the IF function indicated that it needs to decide which result to use (either from processor#3 or #4) will depend on what's return by processor#2.  Of course processor#2 further divides up the work to more processors, but eventually it figures out that it should return NIL.



Upon receiving the NIL result from processor#2, processor#1 decides to take the result of processor#3.  The result of processor#4 is discarded.  Even if processor#4 went ahead and evaluated the (exit) expression it is not necessary that it is executed, it merely returns and EXIT signal back to processor#1.  Whether it is used or not and how this signal is ultimately handled is entirely up to processor#1.



So conceptually everything is evaluated.



Did that make sense?
#5
newLISP newS /
January 13, 2009, 10:14:48 AM
Hi cormullion,



Your tutorial is a great help in my learning newLISP.  I count programming as one of my hobbies since my first VIC-20 - ok some of you know my age group now ;)



I think that whatever number of rules that govern a programming language, be it 3 or 30, the most important thing is consistency.  (Although I really wish it to be just 3 for newLISP - and Why Not!?)  Simple does not equate to useless.  IMHO the most useful and enduring programming languages are, at the core, very simple.  



Anyway I feel that newLISP has great potential.  I look forward to getting enough stuffed into my head to start coding some useful applications soon.
#6
newLISP newS /
January 13, 2009, 01:00:34 AM
Hi Lutz,



Now it makes more sense that you are calling it "constants".  It naturally comes to mind that constants should not be evaluated.  Maybe it should be called "const-switch" instead of "exp-switch" in the manual.  Just my humble opinion.



Thanks for clearing it up.
#7
newLISP newS / Inconsistent syntax of "case"
January 12, 2009, 07:12:57 PM
I'm going through Cormullion's Introduction to newLISP.  Everything was going down really smoothly.  The syntax was very consistent and simple (in a good way) and everything governed by the 3 simple rules, until I came to the case statement example.  Syntax consistency was what drew me to newLISP in the first place (away from CL and Scheme).



I found that the "exp-switch" part is not evaluated as default.  This really (to a newbie like me) sticks out like a very tiny splinter on an otherwise very smooth piece - if you don't hold it just right it'll prick you!



Shouldn't the exp-switch be evaluated like everything else to keep consistency?  You can always stop the evaluation using quotes.  I think there's a macro that does evaluation, but shouldn't that be the rule instead of the exception?



I may be missing a bigger picture here, so I'd appreaciate some comments from any newLISP gurus here.



Thanks.
#8
newLISP in the real world / Small error in source and documentation of smtp.lsp
January 08, 2009, 06:57:23 AM
Hi,



I was just poking around the modules documentation and noticed that there was a small error:
Code Select
(load "/usr/share/modules/newlisp/smtp.lsp")
I think it should read
Code Select
(load "/usr/share/newlisp/modules/smtp.lsp")
instead.



The error is also in the source file.



I'm new to newLISP and to this forum so I'm not sure if this is the right place to report such things.



seetho
Pages1