Promoting my blog.

[Kazimir Majorinc]

There is a subtle difference - in the case of letex, in the moment of evaluation local binding is still alive, in the case of eval-letex-quote, it is not.

Code Select Expand

(set 'y 'x)
(println (let ((x 2))
              (eval (letex((x 1))
                         '(+ (eval y) x))))) ;=>3 because y => outer x

(println (let ((x 2))
              (letex((x 1))
                    (+ (eval y) x)))) ;=>2 because y => inner x
                 
(exit)

[Lutz]

Kazimir:

yes, you are right, but it wouldn't make a difference. If the expression to expand has free variables, they would bind to the environment outside the 'letex' anyway and all locals are expanded ;-)



Also, the right side of the assignment in the 'letex' locals is always evaluated in the parent environment:

Code Select Expand

> (set 'y 1)
(letex ((x y) (y 2)) '(x y)) => (1 2)


Itistoday:

'letex', 'unify' and 'expand' (which is used by the first two) do not make expansion on the top level. So this:

Code Select Expand

> (letex (expr '(+ 1 2 3)) expr) => (+ 1 2 3)

is just the same as this:

Code Select Expand

(let (expr '(+ 1 2 3)) expr) => (+ 1 2 3)

to avoid 'expr' beeing the top level do:

Code Select Expand

> (letex (expr '(+ 1 2 3)) (begin expr))
6
>


[Kazimir Majorinc]

Well, maybe eval-let-expand has a bit more sense than let-eval-expand, maybe both have sense, but it is not really that important as long as one knows what can he expect.



However, I noted one thing that could be significant problem, and maybe one that is smaller problem:

Code Select Expand

(println (letex ((x 'y)) x))      ; => y
(println (letex ((x 'y)) 'x))     ; => y




(set 'x 4)
(expand 'x 'x)  ;=> error
(exit)

[Lutz]

Yes, 'letex' and 'expand' don't expand on the top level. 'expand' will throw and error on this and 'letext' doesn't.



So probably 'letex' should throw an error too, when trying to expand a symbol on the top level. Starting with 10.0.4 'letex' will throw an error in this case.

[Kazimir Majorinc]

Yes, 'letex' and 'expand' don't expand on the top level. 'expand' will throw and error on this and 'letext' doesn't.



So probably 'letex' should throw an error too, when trying to expand a symbol on the top level. Starting with 10.0.4 'letex' will throw an error in this case.

If some nonformal semantics is substitution, then evaluation, then such trivial cases -- I think mathematical notation is f(x|y) -- have sense. It is one of those things like x-x, x/x, trivial, but simplifies calculations.



> (letex((x ''y))'x)

'y

> (letex((x ''y))x)

'y ; -- why not just y?

>



for letex and evletex, I don't know, maybe you can define evletex "just in case," I think it is marginally more useful, whatever it is, it doesn't hurt. Finally, cos(x) is barely sin(x+1.57). But really not a big deal.







Itistoday:



I think it is simplified situation in your example:

Code Select Expand

(println (letex ((H1 '(let ((x ''y)) x)))
            (eval H1))) ; =>y, without eval it is (let ((x ''y)) x)

             ; is equivalent to

(println (letex ((H1 '((x ''y))))
             (letex H1 (eval 'x)))) ;=>y, without eval it is 'y
             
             ; is equivalent to
             
(println (letex ((H1 '((x ''y))))
             (letex H1 (first (list x))))) ;=> y, because (first (list x))=(eval 'x)

[Lutz]

Both 'letex' cases should (and in the future will) throw an error. Like 'expand' they should throw an error when trying to expand something not in a list on the top-level.



When you enclose the x or 'x in a list expression, you see it working correctly:

Code Select Expand

> (letex ((x ''y)) '('x))
(''y)
> (letex ((x ''y)) '(x))
('y)
>


When symbol-on-top-level expansion+evaluation is needed, than do an evaluation assignment without expansion. The 'letex' expression is then redundant:

Code Select Expand

> (set 'x ''y)
'y
> (set 'x 'y)
y


which is what you were expecting.

[Kazimir Majorinc]

When symbol-on-top-level expansion+evaluation is needed, than do an evaluation assignment without expansion. The 'letex' expression is then redundant:

Code Select Expand

> (set 'x ''y)
'y
> (set 'x 'y)
y


which is what you were expecting.[/quote]



Yes, it is clearly redundant. Unfortunately, sometimes we do not know whether it is redundant until runtime.

Code Select Expand

(letex((x (f)))
   (letex((y (g)))
       x)) ; <= we cannot know
            ;whether inner letex is redundant,
            ;because x will be replaced with (f)
            ;which might be known only during runtime  

Without that, we should do something like

Code Select Expand

(letex((x (f)))
  (if (not (list? x))
      x
      (letex ((y (g)))
          x)))

(I didn't tested that code)

[Lutz]

In the end a more generalized 'letex' and 'expand' could be implemented for 10.0.4, which allows expansion of symbols not enclosed in a list expression or quoted, as in the following examples:

Code Select Expand

(set 'x 123 'y 456)
(expand 'x 'x) => 123
(letex (x '(+ 3 4)) 'x) => (+ 3 4)
(letex (x '(+ 3 4)) x) => 7


previously 'expand' would throw an error (line 2) and 'letex' would skip template expansion silently (line 4). This is now consistent with 'unify', which always allowed top-level symbol unification:

Code Select Expand

(unify 'S 'v) => ((S v))

'expand', 'letex' and 'unify' all are based on the same symbol expansion subroutines.

[Kazimir Majorinc]

Good, it looks like two small steps forward, generalization and consistency.

[Kazimir Majorinc]

I didn't refered my blog posts for a while. Here is the list of a new posts:



62. Supressed Printing.

63. On Serial Substitution and Not Reading The Manual.

64. Propositional Variables and Formulas.

65. Reader Macros in Newlisp?

66. Some Lisp Related Alexa Ranks

67. Eval-string or eval?

68. Lispers on AI, 2009 poll

69. Random Propositional Formulas of a Given Average Length

70. On Expected Truth Value of a Random Propositional Formula

71. On Expected Truth Value of a Random Propositional Formula (2)

72. The Probability That Random Propositional Formula is Tautology

73. Lists of Propositional Formulas

74. Debug-wrapping Around Built-in Primitives

75. One Hundred Propositional Tautologies (1)



+ Poll on eval and Lisp.

[Kazimir Majorinc]

76. One Hundred Propositional Tautologies. (2)

77. Opinion on eval in Lisp, Python and Ruby - The Results of The Poll.



+ Poll: Why you do not use Lisp?



(Everyone who uses some other programming language beside Lisp can vote - why he doesn't use Lisp for that purpose.)

[Kazimir Majorinc]

78. Why you do not use Lisp? The results of the poll.

79. One hundred propositional tautologies (3).

80. One hundred propositional tautologies (4).

81. One hundred propositional tautologies (5).

82. Tortelvis.

83. Relatively short propositional formulas and symbols instead of pointers and tables.

84. Symbols as sexprs.

85. Speed of Clojure's eval.

86. Happy new year 2010.

87. PicoLisp and OpenLisp: New eval speed champions.

88. Those were the days.

89. Alan Kay on Lisp and Fexprs.

90. Composition of functions or macros.

91. Composing fexprs preserves short-circuit evaluation.

92. How many syllogisms are there?

93. The program for derivation of syllogisms, condensed version.

94. Another difference between C++ and C#: the weekends.

95. What Edsger W. Dijkstra blogged about Lisp?

96. McCarthy - Dijkstra short polemics in 1976.

97. Interesting case of mismatched parentheses.



+ Poll: Your favorite programming language and your political position.

[cormullion]

Nearly 100 posts! I'll crack a virtual beer with you when you post it... :)

[Kazimir Majorinc]

I published few posts in the meantime. And also stole some elements from http://www.taoeffect.com/blog/">Greg's design recently.  



098. Short notes on McCarthy's "Recursive Functions ... "

099. And, Why Didn't Dijkstra Like Lisp?

100. Lecture on Newlisp, 6. June 2010.



101. Small But Robust Bug in Gabriel and Steele's "Evolution of Lisp"

102. Using (sin cos 0.5) instead of (sin (cos 0.5))

103. "Nothing Will Happen", Split, Croatia, 19-22 August 2010...

104. The Cover of "Byte Magazine" 1979 Lisp Issue.

105. McCarthy's 1960 "Recursive Functions ..." Lisp



106. McCarthy-60 Lisp Implemented as Association List

107. A Few Photographies from "Nothing will happen", Split 2010

108. Politics - Programmers are not Conservatives.

109. McCarthy-60 Lisp in McCarthy-60 Lisp in ...

110. Change of The Blog Name.



111. On Pitman's "Special Forms in Lisp."

112. Lambda Calculus Interpreter.

113. Expansion of Free Variables.

114. The Fonts of Power.

115. Do You Need Five Hundred Random Lambda-Expressions...



116. In Search for The Irreducible Lambda-Expressions.

117. Two Thoughts on Lisp Syntax.

118. Cantor's Enumerations (1)

119. Cantor's Enumerations (2)

120. Cantor's Enumerations (3)



121. Enumeration of Lambda-Expressions.

122. 199019 Reduced Lambda-Expressions.

123. Lambda Calculus Interpreter (2).

124. Relative Popularity of Lisp Dialects and Some Trends.

125. When Were The Best Days for Lisp?



126. Why they say this is the most important metacircular blog post?

127. Find Your Way Through Lisp Labyrinth.

128. Some differences between lambda-calculus and Lisp (1).

129. Some differences between lambda-calculus and Lisp (2).

130. Some Basic Concepts Implemented and Reduced in Lambda calculus.



131. Lambda Calculus Meta-variables Supported in my Newlisp library

[m i c h a e l]

Hi Kazimir!



I was surprised and delighted to discover "The Fonts of Power" among the staggering number of posts you've done. Melissa is a certified font lunatic, and I caught the bug from her.



I noticed all the fonts you list are serifs. What are your favorite sans serifs? Also, I see you changed your photo from the green, vehement you to a full-color, slightly forlorn-looking you. There used to be a part after this asking if it reflected your feelings about the lack of Lisp use today, but Melissa said it sounded forced, so I deleted it ;-)



m i c h a e l