Some entity, AKA "Dimiter \"malkia\" Stanev" <malkia>,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)


> I always thought .NET simply was made to replace Java more or less,
> but I can't say what were the original reasons.

Well, the (very very very) simple version of this traumatic event:

SUN-Java could NOT be bought or bribed.
SUN-Java could NOT be perverted with (ms-only)'standards'
SUN-Java could NOT be extented with (ms-only)'innovations'

Hence, MS had to roll it's own .NET & sharpies#.


Cor

Jon Harrop wrote:
> jurgen_defurne wrote:
>
>>That from the tail calls is one of the things that puzzles me the
>>most. I mean, the lambda papers date from the mid 70's and a little
>>bit later, and in them, Steele and Sussman show how languages can be
>>built, and then about 20 years later, Java is created without
>>(seemingly) any of the lessons that Steele and Sussman have provided,
>>despite Steele also working on Java, together with Gabriel (any other
>>people from the 70's/80's Lisp community?).
>> Indeed. Microsoft did this 7 years ago. Moreover, they did it deliberately
> because they knew languages like F# were on the books.

Thanks for the giggle.

>
> But the thing that really scares me is that Sun were focussing entirely on
> hugely inefficient dynamic languages (Groovy etc.), at least before they
> suffered a meltdown and fired thousands of people (again).
>

Hugely inefficient? What makes you... oh,christ, it's the frog.

kt

Dimiter "malkia" Stanev wrote:
>> Indeed. Microsoft did this 7 years ago. Moreover, they did it
>> deliberately
>> because they knew languages like F# were on the books.
>> You say this, as if you were part of that process. Anything to back what
> are you saying? Blog quote from one of the creators would be fine...
>
> I always thought .NET simply was made to replace Java more or less, but
> I can't say what were the original reasons.

World domination? Even more than they already had?

What I heard was that the guy who did NT was a/the main guy behind
Vax/Vms, and I believe it because vax/vms languages could all call each
other with sufficient programmer agonizing over call by reference vs.
call by value vs I forget the other one(s).

So you have some really cool technology but it is proprietary and it
solves the wrong problem: the problem is not how to get a Tower of Babel
of computer languages talking to each other, the problem is people not
all using the same language: Lisp.

hth, kzo

On Nov 26, 7:01 pm, Jon Harrop <j> wrote:
> jurgen_defurne wrote:
>
> Indeed. Microsoft did this 7 years ago. Moreover, they did it deliberately
> because they knew languages like F# were on the books.
>
> But the thing that really scares me is that Sun were focussing entirely on
> hugely inefficient dynamic languages (Groovy etc.), at least before they
> suffered a meltdown and fired thousands of people (again).
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.[..]

will java become lisp?

On Nov 26, 7:04 pm, Cor Gest <c> wrote:
> Some entity, AKA "Dimiter \"malkia\" Stanev" <mal>,
> wrote this mindboggling stuff:
> (selectively-snipped-or-not-p)
>> Well, the (very very very) simple version of this traumatic event:
>
> SUN-Java could NOT be bought or bribed.
> SUN-Java could NOT be perverted with (ms-only)'standards'
> SUN-Java could NOT be extented with (ms-only)'innovations'
>
> Hence, MS had to roll it's own .NET & sharpies#.
>
> Cor
> --
>            First directive to dissuade criminal intent: Present a Gun
>                        I may be blonde, but I'm not stupid
>                        Self-defense is a basic human right
>     God made man, Colt made some equal, Khalashnikov made the poor equal too



I want to learn enough lisp because I know enough linux to procude a
nice website and be like there In YER FACE java! [or insert other
language of management choice here]

Dimiter "malkia" Stanev wrote:
>> Indeed. Microsoft did this 7 years ago. Moreover, they did it
>> deliberately because they knew languages like F# were on the books.
>
> You say this, as if you were part of that process.

This 2001 paper describes tail calls in the CLR and is by the same guy who
did .NET generics (aka parametric polymorphism from ML) and is now doing
F#:

"ILX: Extending the .NET Common IL for Functional Language
Interoperability" -
http://icme2007.org/~dsyme/papers/babel01.pdf

> I always thought .NET simply was made to replace Java more or less, but
> I can't say what were the original reasons.

No, Microsoft had quite a few rocking ideas of their own. Indeed, F# is now
the world's gold standard functional language in terms of usability because
it combines industrial-strength libraries inherited from .NET with a
genuine functional language complete with tail calls.

Without tail calls on the JVM, Scala and Clojure cannot compete. With Sun
going bankrupt, it is unlikely we will ever see tail calls on the JVM.

On Nov 27, 6:00 am, Jon Harrop <j> wrote:

> Without tail calls on the JVM, Scala and Clojure cannot compete. With Sun
> going bankrupt, it is unlikely we will ever see tail calls on the JVM.

Fuck the lying thru the teeth Sun Microsystems fuck with its lawsuits
and deceptions with Java. Now, time to die!

One thing commercial companies do in the brink of death is to release
their software as Open Source (or $free$) and herald the moral praises
of the stealing youngsters that largely makes up the Open Source
community. The major precursor example is Netscape. Other examples
include: SGI, Be inc, Dylan, Macintosh Common Lisp, ...

See also:

• On Microsoft Hatred
http://xahlee.org/UnixResource_dir/w...hatred155.html

• The Microsoft Hatred FAQ
http://xahlee.org/UnixResource_dir/w...hatredfaq.html

• The Unix Pestilence
http://xahlee.org/UnixResource_dir/freebooks.html

Also, please avoid the term “tail call� or “tail recursion�. Instead,
when referring to compiler implementation that optimize recursion code
that is a algorithmically flat iteration, use terms like “optimized
linear recursion implementation� or something similar. See:

• The Jargon “Tail Recursion�
http://xahlee.org/UnixResource_dir/w...recursion.html

Xah
∑ http://xahlee.org/

☄

Xah Lee <xahlee> writes:

Hi,

> Also, please avoid the term “tail call� or “tail recursion�. Instead,
> when referring to compiler implementation that optimize recursion code
> that is a algorithmically flat iteration, use terms like “optimized
> linear recursion implementation� or something similar. See:
>
> • The Jargon “Tail Recursion�
> [..]

After reading that text I'd say that you're only half enlightened. Yes,
tail recursion is an implementation detail which enables recursive
functions to be executed in finite space, but in order to do that, the
recursive call must be the last expression. That's what makes the
"tail" in tail recursion.

Bye,
Tassilo

On Nov 27, 7:34 am, Tassilo Horn <tass> wrote:
> Xah Lee <xah> writes:
>
> Hi,
>>
> After reading that text I'd say that you're only half enlightened. Yes,
> tail recursion is an implementation detail which enables recursive
> functions to be executed in finite space, but in order to do that, the
> recursive call must be the last expression. That's what makes the
> "tail" in tail recursion.

Huh?

Let's make sure we are on the same page.

recursion can be that the algorithm is recursive or the source code is
recursive.

Here's 3 aspects of recursion in our context:

• the source code is recursive. Meaning, it calls itself.
• the algorithm is recursive. Meaning, the algorithm repeats (its
steps) itself.
• the compiler produced code is recursive. (i don't know compilers,
but the basic idea is that it will consume resources proportional to
number of recursion steps.)

The essential idea in SICP book about “tail recursion�, is that when a
source code is recursive, its algorithm expressed is not necessarily
so, and in fact can be linear (in other words, recursive source code
may just express a iteration algorithm). Such source code, we could
call it “linear recursion�. The concept of the compiler recognizing
linear recursion and produce compiled code that behaves as a
iteration, can be called “linear recursion recognition�.

You seem to suggest that linear recursion in source code has one
defining characteristics, namely, that the self call occures at the
end of the function definition. (and it is implied, because of this,
therefore it “tail recursion� is a very good term for linear
recursion) Is that what you are saying?

What you are saying seems to be obviously wrong... Here's a pseudo
lisp code to demo:

(set x 1)

(defun f ()
(set x (+ x 1))
(f)
(message "hi mom")
)

Xah
∑ http://xahlee.org/

☄

Xah Lee <xahlee> writes:

Hi Xah,

>> After reading that text I'd say that you're only half enlightened.
>> Yes, tail recursion is an implementation detail which enables
>> recursive functions to be executed in finite space, but in order to
>> do that, the recursive call must be the last expression. That's what
>> makes the "tail" in tail recursion.

[...]

> You seem to suggest that linear recursion in source code has one
> defining characteristics, namely, that the self call occures at the
> end of the function definition. (and it is implied, because of this,
> therefore it “tail recursion� is a very good term for linear
> recursion) Is that what you are saying?

Yes, quite so. When a function is called, the caller's address (and
other state information, like local variables of the caller) is pushed
on a stack. When the function call returns, control is passed back to
the caller by popping the stack and looking at the return address. If
the call hierarchy is deep, the stack grows and grows.

But if the compiler is aware of tail recursion and the last thing a
function does (control flow wise) is a recursive call, then it's not
necessary to save the caller's state informations in a stack, because
they won't be used anymore (hey, it's the last thing in the function),
and so this tail call optimization can be performed.

If the recursive call is somewhere in the middle of a function, then it
cannot be done, because then the caller's state is still needed after
the call.

Got it?

> What you are saying seems to be obviously wrong... Here's a pseudo
> lisp code to demo:
>
> (set x 1)
>
> (defun f ()
> (set x (+ x 1))
> (f)
> (message "hi mom")
> )

What should that demo? That can neither be optimized nor will it
terminate.

Look at that example.

Here's a definition that cannot be optimized. If I execute it with (sum
9999999999999999999999999999999999999) it'll abort, cause the stack gets
too big.

--8<---------------cut here---------------start------------->8---
CL-USER> (defun sum (n)
(if (= n 0)
0
(+ (sum (- n 1)) 1)))
SUM
CL-USER> (sum 17)
17
CL-USER> (disassemble #'sum)

Disassembly of function SUM
(CONST 0) = 0
1 required argument
0 optional arguments
No rest parameter
No keyword parameters
10 byte-code instructions:
0 L0
0 (LOAD&PUSH 1)
1 (CALLS2&JMPIF 172 L12) ; ZEROP
4 (LOAD&DEC&PUSH 1)
6 (JSR&PUSH L0)
8 (CALLS2 177) ; 1+
10 (SKIP&RET 2)
12 L12
12 (CONST 0) ; 0
13 (SKIP&RET 2)
NIL
--8<---------------cut here---------------end--------------->8---

And here's the same transformed to being tail recursive. (sum
9999999999999999999999999999999999999) yields its result in a fraction
of a second.

--8<---------------cut here---------------start------------->8---
CL-USER> (defun sum (n)
(summer n 0))
SUM
CL-USER> (defun summer (i j)
(if (= 0 j)
i
(summer (+ i 1) (- j 1))))
SUMMER
CL-USER> (sum 17)
17
CL-USER> (disassemble #'sum)

Disassembly of function SUM
(CONST 0) = 0
(CONST 1) = SUMMER
1 required argument
0 optional arguments
No rest parameter
No keyword parameters
4 byte-code instructions:
0 (LOAD&PUSH 1)
1 (CONST&PUSH 0) ; 0
2 (CALL2 1) ; SUMMER
4 (SKIP&RET 2)
NIL
CL-USER> (disassemble #'summer)

Disassembly of function SUMMER
2 required arguments
0 optional arguments
No rest parameter
No keyword parameters
9 byte-code instructions:
0 L0
0 (LOAD&PUSH 1)
1 (CALLS2&JMPIF 172 L12) ; ZEROP
4 (LOAD&INC&PUSH 2)
6 (LOAD&DEC&PUSH 2)
8 (JMPTAIL 2 5 L0)
12 L12
12 (LOAD 2)
13 (SKIP&RET 3)
NIL
--8<---------------cut here---------------end--------------->8---

As you can see in summer's disassembly, a tail call elimination was
done (the recursive call is replaced with a jump operation).

Bye,
Tassilo

Xah Lee <xahlee> wrote on Thu, 27 Nov 2008:
> The essential idea in SICP book about "tail recursion", is that when a
> source code is recursive, its algorithm expressed is not necessarily so,
> and in fact can be linear (in other words, recursive source code may just
> express a iteration algorithm).
[...]
> What you are saying seems to be obviously wrong... Here's a pseudo
> lisp code to demo:
> (set x 1)
> (defun f ()
> (set x (+ x 1))
> (f)
> (message "hi mom")
> )

Is this example meant to show linear recursion?

What result do you expect from the algorithm, by calling the function (f)?

What is the equivalent iterative way of expressing this same algorithm?

-- Don
__________________________________________________ _____________________________
Don Geddis http://don.geddis.org/ don
Sometimes I think I'd be better off dead. No, wait. Not me, you.
-- Deep Thoughts, by Jack Handey [1999]

2008-11-27

> If the recursive call is somewhere in the middle of a function, then it
> cannot be done, because then the caller's state is still needed after
> the call.

here's a actual elisp code to demonstrate a recursive code that
expresses linear algorithm but the self-reference does not happen at
the end (aka “tail�) the the source code.

(setq x 1)

(defun f ()
(when (< x 10)
(message "%d" x)
(setq x (1+ x))
(funcall 'f)
)
(+ 1 1)
)

(f)

(for those who don't know elisp: Paste the above into a empty file in
emacs. Select them all, then type Alt+x eval-region.)

Now, in the above, you see that the call to f itself happens in the
middle of the program, not at the end. However, the algorithm
expressed by this recursive source code is still linear.

Therefore, it contradict your claim that the self-call must be at the
end for recursive code to express iteration.

> Got it?

if you try not to begin to be a moron, i foresee we could have
fruitful conversation, where i teach you computer science and
mathematical thinking, while you might teach me something about
compiler.

To reduce back n forth posts, let me just say here first that you need
to pay attention to distinguish the source code, the algorithm, and
the algorithm produced by the compiler code. With clear awareness of
these distinctions, then we can have better communication.

Xah
∑ http://xahlee.org/

☄

On Nov 27, 12:19 pm, Tassilo Horn <tass> wrote:
[..]

Xah Lee wrote:
> On Nov 25, 1:41 am, Rock <roccoro> wrote:
>> Yeah, no complex number support! Very disappointing when I found out.
>> I even had an exchange with Rich Hickey on the issue. He says he's got
>> nothing against complex numbers obviously, but he hasn't got the time
>> to implement them, and for performance reasons it looks like it has to
>> be done in Java. I wanted to give it a try, but I am definitely no
>> Java programmer, so I've happily come back to good old Common Lisp.
>> I'm a mathematician and complex numbers are VERY important, and I
>> think CL (with few other languages) has got the best support in this
>> respect.
>
> Native support of complex numbers in a general purpose language of
> today, is absolutely necessary!

Complex numbers are very useful in scientific computing
but not in business computing.

> Java being a pain in the ass in so many ways, doesn't have complex
> numbers as a native datatype.

Scientific computing has never been a high priority for Java.

Arne

Bakul Shah wrote:
> Thomas F. Burdick wrote:
>> On 25 nov, 16:43, Xah Lee <xah> wrote:
>>
>>> Native support of complex numbers in a general purpose language of
>>> today, is absolutely necessary!
>>
>> How do you figure? It seems more like native support for complex
>> numbers were more valued 20-30 years ago. The GP languages with such
>> support date from then ... off the top of my head, I can't think of a
>> single such language "of today".
>
> C99?

The complex support in C99 is not that good.

Even Fortran is better.

Arne

Jon Harrop wrote:
> Bakul Shah wrote:
>> Thomas F. Burdick wrote:
>>> On 25 nov, 16:43, Xah Lee <xah> wrote:
>>>
>>>> Native support of complex numbers in a general purpose language of
>>>> today, is absolutely necessary!
>>> How do you figure? It seems more like native support for complex
>>> numbers were more valued 20-30 years ago. The GP languages with such
>>> support date from then ... off the top of my head, I can't think of a
>>> single such language "of today".
>> C99?
>
> Today != 1999

Today is very close to 99 when we talk about the C standard.

Lot of compiler have not even implemented all of C99.

Other priorities.

Arne