Re: C# is not Dylan (was: Re: C# : The new language from M$)

To: info-dylan@ai.mit.edu
Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
From: "Michael T. Richter" <mtr@ottawa.com>
Date: Wed, 5 Jul 2000 07:15:02 -0400 (EDT)
Organization: Half-Baked Software
References: <57D01C66CBEFE28E.0140FBE2F42B8951.48F3FDB0A810D9E0@lp.airnews.net> <m3zoo7w69a.fsf@cadet.dsl.speakeasy.net> <huvjls0t6hfio3htr0r1ee3bk57b0th1dr@4ax.com> <c29g0pxbubg.fsf@nerd-xing.mit.edu> <kpamlscdjl89ihfhsdk3d4rinoa1hji78j@4ax.com> <bruce-3485B7.01374830062000@news.akl.ihug.co.nz> <m2u2ebzfyf.fsf@gododdin.internal.jasmine.org.uk> <58rolsg17q7154fdf6dq5l038rbbnl10jt@4ax.com> <3171354053463029@naggum.no> <j7175.9050$Zr5.877270@typhoon.ne.mediaone.net> <3171366678290484@naggum.no> <395C9ACA.5272174C@thecia.net> <kib75.251582$MB.4396963@news6.giganews.com> <fto75.10724$Zr5.951646@typhoon.ne.mediaone.net> <m2og4hajrm.fsf@euler.axel.nom> <Goq75.11081$ZI2.229846@news1.rdc1.on.wave.home.com> <m2g0pqal5d.fsf@euler.axel.nom> <oLi85.18114$ZI2.543403@news1.rdc1.on.wave.home.com> <85wvj2ymf4.fsf@meta.verbum.org> <yen85.1474$8Q5.16779@news22.bellglobal.com> <slrn8m4n1e.h27.neelk@brick.cswv.com>
Reply-To: "Michael T. Richter" <mtr@ottawa.com>
Xref: traf.lcs.mit.edu comp.lang.dylan:12395

"Neel Krishnaswami" <neelk@brick.cswv.com> wrote in message
slrn8m4n1e.h27.neelk@brick.cswv.com">news:slrn8m4n1e.h27.neelk@brick.cswv.com...
>> Unfortunately I find Scheme easily as unreadable as Lisp.  As a
>> result, I have no tool available to evaluate the elegance of the
>> construct you posted.  Can you do a line-by-line commentary (if you
>> have the time) to explain: a) how it works and b) what you find
>> powerful in it?

> Here it is, in Dylan and in Scheme. (I'll use factorial as the
> example).

[snip explanation]

> The big advantage to using this style of iteration is that it's
> extremely clear what is changing on each pass through the loop,
> because you explicitly pass all the changed state to the next
> iteration. Invariants become very easy to identify.

> The big disadvantage (which Tim Bradshaw alluded to) is that there's
> no requirement that you can advance to the next iteration step at any
> old point; you can literally call the advance function anywhere. This
> can occasionally obscure the control flow.

That sounds interesting.  I'll have to explore this construct.

References: