From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ian Grant Newsgroups: gmane.comp.gnu.lightning.general,gmane.lisp.guile.devel Subject: Bug free programs Date: Mon, 15 Sep 2014 18:38:41 -0400 Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2314764225782136983==" X-Trace: ger.gmane.org 1410821199 15394 80.91.229.3 (15 Sep 2014 22:46:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 15 Sep 2014 22:46:39 +0000 (UTC) To: guile-devel , lightning Original-X-From: lightning-bounces+gcglg-lightning=m.gmane.org-mXXj517/zsQ@public.gmane.org Tue Sep 16 00:46:35 2014 Return-path: Envelope-to: gcglg-lightning@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XTf2X-0005bV-Uj for gcglg-lightning@m.gmane.org; Tue, 16 Sep 2014 00:46:34 +0200 Original-Received: from localhost ([::1]:34907 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XTf2X-0001aD-KJ for gcglg-lightning@m.gmane.org; Mon, 15 Sep 2014 18:46:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50737) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XTf2S-0001Zz-CJ for lightning-mXXj517/zsQ@public.gmane.org; Mon, 15 Sep 2014 18:46:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XTf2Q-0006CM-1r for lightning-mXXj517/zsQ@public.gmane.org; Mon, 15 Sep 2014 18:46:28 -0400 Original-Received: from mail-wi0-x22b.google.com ([2a00:1450:400c:c05::22b]:58804) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XTf2P-0006AR-Ml; Mon, 15 Sep 2014 18:46:25 -0400 Original-Received: by mail-wi0-f171.google.com with SMTP id bs8so5102037wib.16 for ; Mon, 15 Sep 2014 15:46:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=jfmDnV7rLtxXOFFQnFLm89bUtCRmjBv+nNe39rtR7zk=; b=RTEp/Y3kCbUK35Vo0ZT9LRM+1ssYH3CYUiGf+Y5oLWxXCJdihrx4XeJ7mdg3kCCdk1 7E77qqRVlP4Qa4FS76jkZSAeJYTstXKbAi2+l+h3MrH0MtyZPefCav94Wua2cDY0Iv0P 7Z43DdF+B9+eDu2wd3hfMZ5tsgYGgkpc2wIgDFTJbozCFFd5L45rVNroE5lXkB32w32+ hSfnIMTmzrqaletc9JBT+uzqPKRUlvrAdlazfTV0mmOnxKzOQX0i7+YXOunQdCdYuD8n ufRhvPMnEtd3Vl456OdllCWaz+bnSPH/LF5QeaWeAZXWflA+bVQ8BxOhDZKT22ECqteV ry3A== X-Received: by 10.194.57.237 with SMTP id l13mr8543299wjq.102.1410820721691; Mon, 15 Sep 2014 15:38:41 -0700 (PDT) Original-Received: by 10.194.81.194 with HTTP; Mon, 15 Sep 2014 15:38:41 -0700 (PDT) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::22b X-BeenThere: lightning-mXXj517/zsQ@public.gmane.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: lightning-bounces+gcglg-lightning=m.gmane.org-mXXj517/zsQ@public.gmane.org Original-Sender: lightning-bounces+gcglg-lightning=m.gmane.org-mXXj517/zsQ@public.gmane.org Xref: news.gmane.org gmane.comp.gnu.lightning.general:583 gmane.lisp.guile.devel:17458 Archived-At: --===============2314764225782136983== Content-Type: multipart/alternative; boundary=047d7b86c92ef5516e0503224bfa --047d7b86c92ef5516e0503224bfa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm posting this because it explains beautifully why we don't need to expend any great effort on getting GDB or other debuggers working with Guile. If some code needs a debugger, then it invariably needs re-writing much more than it needs the debugger. And _programmers_ who need the debugger are invariably much more in need of training. This is (a tiny) part of the Computer Security History Project interview with Roger Schell: http://conservancy.umn.edu/bitstream/133439/1/oh405rrs.pdf =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Yost: And Edsger Djikstra was a visiting faculty member when you were there. Can you talk about any interaction you had with him? Schell: Yes, he was one of a couple of people that probably had a major influence on my perspective on computer science. You know my background was FORTRAN. I mean, that=E2=80=99s what we used. The military programs were either assembly language or FORTRAN, or JOVIAL. JOVIAL was a military program language=E2=80=94sort of like FORTRAN. When I joined Proje= ct MAC; well, one of the things that you do with graduate students is they=E2=80=99re free labor for various things that have to be done. And one of the projects I had was what we called the Bootstrap Project in Multics, which brought it from essentially the bare iron up to the point where it could begin to run. It had been written an assembly language. And in Multics, the whole story was to write things in a higher [level] language. That makes them inspectable and viewable, and that=E2=80=99s what I was working on, looking at that problem. Okay, re= write the Bootstrap in PL/1, from assembler language. About that time Djikstra came to campus and he taught a class. And I took his class and his claims, of course, seemed to me pretty outlandish claims in terms of the ability to know that essentially you had, call it, bug-free programs. And I, of course, had read the T.H.E. paper that he had written about that and I was largely a skeptic. Well, it turned out his office was about three doors down from mine. By that time I had gotten an office in Project MAC; they had a cluster of graduate students that I was with. Down at the other end was Djikstra; they=E2=80=99d found a place for him. And so I=E2=80=99d = go down periodically and sort of challenge his claims. Well, he was not a particularly patient person, and obviously, I had a lot of respect for him so you wouldn=E2=80=99t debate him as you would another graduate studen= t; but still try and learn where he was coming from. So I sort of threw out to him; because his examples; although the T.H.E. was about an operating system, when he taught his classes they were about algorithms that were essentially applications. And I said well, I=E2=80=99m not sure that I am persuaded that I can get this approach really to work; he described it as putting beads on a necklace and you put them together, and that sort of thing. I said I=E2=80=99m not convinced. So he s= aid to me, what are you working on? I said I=E2=80=99m supposed to rewrite this assembly language thing in PL/1. And he says well, you understand what I do? Well, I think so. Well, you try it. And so, I said okay, fine, I=E2=80=99ll do that. I=E2=80=99ll modularize it that way; I=E2=80=99ll int= roduce those sort of layering constructs; and when I had questions and such=E2=80=94it isn=E2= =80=99t hard, and not a science as to how to construct that. And occasionally I=E2=80=99d say I don=E2=80=99t see how to do this, so I=E2=80=99d go down = and talk to him and say well, okay, I don=E2=80=99t see; you know, it doesn=E2=80=99t seem to m= e like this goes; and he=E2=80=99d patiently, or impatiently, put me on the right track. And so I did that and produced that program in that way, and of course, with a Bootstrap program, you can=E2=80=99t do much more than a des= k check and then go run it. And so you=E2=80=99d have to construct a new boot tape and it booted from tapes. You=E2=80=99d create all these files, then y= ou put them out, and they had this process of creating these tapes, and that was the job. And I was familiar with that process; I had worked in Multics; I had learned how to boot things up. I had written at that low a level. So when the system would come up, if it incurred a flaw early on in the process, it would type that the operating system was dead; this bombed; this is not here; you=E2=80=99d get some sort of very cryptic message that the operator console=E2=80=94which was a typewriter=E2= =80=94would type out. And so I put my PL/1 version of the bootstrap program, built the tape, and so I=E2=80=99m going to run my first test, and well, it=E2=80=99s where= it=E2=80=99s going to crash first, right? I mean, the usual kind of question, is can I know what happened? So I start the tape running and went to the operating console and waited for the message to type out. And I waited; and I waited. And I said oh boy, I=E2=80=99m in trouble. The thing= ; it isn=E2=80=99t even able to give me an error message or anything. Nothing happens. I=E2=80=99m really in trouble! And I turned around and looked bac= k at the processor. Well, when the system=E2=80=99s fully up and running, the background thing will flash the lights and a pattern on the console lights. And I looked back, and it was running. And, I said, what=E2=80=99d = I do? Run the wrong tape? So I looked down and made sure I had my tape. I booted it again. What? And it came up! Well, you know, from my FORTRAN experience I=E2=80=99d never written a thousand-line program (which this was) that ran the first time, right? It doesn=E2=80=99t happen. And so that was one that definitely changed my perspective from a software engineering point of view, in terms of Djikstra=E2=80=99s impact, which is your question. Yes, it had a definite impact on the way I view software engineering; I became obviously very much of an advocate of that way of thinking about the problem. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Anyone who has used Standard ML functors knows this feeling, but more so: when the code _compiles,_ you just know it's going to work. The way a Standard ML functor works is it composes ML code together. It allows you to implement an interface, and then totally replace the underlying implementation by plugging in a different one. And the type checking catches almost all the mistakes that people commonly make. And if your ML compiler can assemble lightning code, you can do this with assembler. The functor will snap assembler modules together, and the resulting assembler, although quite complicated, _just works._ No debuggers necessary. One may ask what has this to do with scheme? Well, Standard ML can compose scheme or C code just as easily as it can compose assembler code. So a Standard ML functor can define a typed template that will allow one to exchange underling scheme implementations of functional interfaces as easily as it does ML. This is why I want to get Moscow ML working under Guile. Moscow ML is really light-weight when compared with Guile. My machine takes 42 minutes (no, really, I timed it!) to byte-compile just ice9-pp.go. By comparison, the whole Moscow ML autoconf/build cycle takes less than 50s. This includes the runtime, the Standard ML basis library, and the lexer and parser generators and the compiler and toplevel REPL. And there's a fair bit of junk we could trip out, and we could make it a lot faster once we JIT compile the bytecode instead of interpreting it, and when that JIT compiled bytecode uses native Guile SCM objects to representall its data, then there will no penalty whatsoever in a Guile program just switching to Standard ML when it seems like a good idea. --047d7b86c92ef5516e0503224bfa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm posting this because it explains beautifully why w= e don't need to
expend any great effort on getting GDB or other debu= ggers working with
Guile. If some code needs a debugger, then it invaria= bly needs
re-writing much more than it needs the debugger. And _programm= ers_ who
need the debugger are invariably much more in need of training.=

This is (a tiny) part of the Computer Security History Project
i= nterview with Roger Schell:

=C2=A0=C2=A0 http://conservancy.umn.edu/bits= tream/133439/1/oh405rrs.pdf

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Yost: And Edsger Djikstra was a visit= ing faculty member when you were
there. Can you talk about any interacti= on you had with him?

Schell: Yes, he was one of a couple of people t= hat probably had a
major influence on my perspective on computer science= . You know my
background was FORTRAN. I mean, that=E2=80=99s what we use= d. The military
programs were either assembly language or FORTRAN, or JO= VIAL. JOVIAL was a military program language=E2=80=94sort of like FORTRAN. = When I joined Project MAC; well, one of the things that you do with graduat= e
students is they=E2=80=99re free labor for various things that have to= be
done. And one of the projects I had was what we called the Bootstrap=
Project in Multics, which brought it from essentially the bare iron up<= br>to the point where it could begin to run. It had been written an
asse= mbly language. And in Multics, the whole story was to write things
in a = higher [level] language. That makes them inspectable and viewable,
and = that=E2=80=99s what I was working on, looking at that problem. Okay, rewrit= e
the Bootstrap in PL/1, from assembler language.

About that time= Djikstra came to campus and he taught a class. And I
took his class and= his claims, of course, seemed to me pretty
outlandish claims in terms o= f the ability to know that essentially you
had, call it, bug-free progra= ms. And I, of course, had read the
T.H.E. paper that he had written abou= t that and I was largely a
skeptic. Well, it turned out his office was a= bout three doors down
from mine. By that time I had gotten an office in = Project MAC; they
had a cluster of graduate students that I was with. Do= wn at the other
end was Djikstra; they=E2=80=99d found a place for him. = And so I=E2=80=99d go down
periodically and sort of challenge his claims= . Well, he was not a
particularly patient person, and obviously, I had a= lot of respect for
him so you wouldn=E2=80=99t debate him as you would = another graduate student;
but still try and learn where he was coming fr= om. So I sort of threw
out to him; because his examples; although the T.= H.E. was about an
operating system, when he taught his classes they were= about
algorithms that were essentially applications. And I said well, I= =E2=80=99m
not sure that I am persuaded that I can get this approach rea= lly to
work; he described it as putting beads on a necklace and you put = them
together, and that sort of thing. I said I=E2=80=99m not convinced.= So he said
to me, what are you working on? I said I=E2=80=99m supposed = to rewrite this
assembly language thing in PL/1. And he says well, you u= nderstand what
I do? Well, I think so. Well, you try it. And so, I said = okay, fine,
I=E2=80=99ll do that. I=E2=80=99ll modularize it that way; I= =E2=80=99ll introduce those sort
of layering constructs; and when I had = questions and such=E2=80=94it isn=E2=80=99t
hard, and not a science as t= o how to construct that. And occasionally
I=E2=80=99d say I don=E2=80=99= t see how to do this, so I=E2=80=99d go down and talk to him and
say wel= l, okay, I don=E2=80=99t see; you know, it doesn=E2=80=99t seem to me like = this
goes; and he=E2=80=99d patiently, or impatiently, put me on the rig= ht
track.

And so I did that and produced that program in that wa= y, and of
course, with a Bootstrap program, you can=E2=80=99t do much mo= re than a desk
check and then go run it. And so you=E2=80=99d have to co= nstruct a new boot
tape and it booted from tapes. You=E2=80=99d create a= ll these files, then you
put them out, and they had this process of crea= ting these tapes, and
that was the job. And I was familiar with that pro= cess; I had worked
in Multics; I had learned how to boot things up. I ha= d written at that
low a level. So when the system would come up, if it i= ncurred a flaw
early on in the process, it would type that the operating= system was
dead; this bombed; this is not here; you=E2=80=99d get some = sort of very
cryptic message that the operator console=E2=80=94which was= a typewriter=E2=80=94would
type out.

And so I put my PL/1 versio= n of the bootstrap program, built the tape,
and so I=E2=80=99m going to = run my first test, and well, it=E2=80=99s where it=E2=80=99s going
to cr= ash first, right? I mean, the usual kind of question, is can I
know what= happened? So I start the tape running and went to the
operating console= and waited for the message to type out. And I
waited; and I waited. And= I said oh boy, I=E2=80=99m in trouble.=C2=A0 The thing;
it isn=E2=80=99= t even able to give me an error message or anything. Nothing
happens.=C2= =A0 I=E2=80=99m really in trouble! And I turned around and looked back
a= t the processor. Well, when the system=E2=80=99s fully up and running, the<= br>background thing will flash the lights and a pattern on the console
l= ights. And I looked back, and it was running. And, I said, what=E2=80=99d I=
do?=C2=A0 Run the wrong tape? So I looked down and made sure I had mytape. I booted it again.=C2=A0 What? And it came up!

Well, you kno= w, from my FORTRAN experience I=E2=80=99d never written a
thousand-line = program (which this was) that ran the first time, right?
It doesn=E2=80= =99t happen. And so that was one that definitely changed my
perspective = from a software engineering point of view, in terms of
Djikstra=E2=80=99= s impact, which is your question. Yes, it had a definite
impact on the w= ay I view software engineering; I became obviously very
much of an advoc= ate of that way of thinking about the problem.

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Anyone who has used Standard= ML functors knows this feeling, but more
so: when the code _compiles,_ = you just know it's going to work. The
way a Standard ML functor work= s is it composes ML code together. It
allows you to implement an interfa= ce, and then totally replace the
underlying implementation by plugging i= n a different one. And the type
checking catches almost all the mistakes= that people commonly
make. And if your ML compiler can assemble lightni= ng code, you can do
this with assembler. The functor will snap assembler= modules together,
and the resulting assembler, although quite complicat= ed, _just works._
No debuggers necessary.

One may ask what has th= is to do with scheme? Well, Standard ML can
compose scheme or C code jus= t as easily as it can compose assembler
code. So a Standard ML functor c= an define a typed template that will
allow one to exchange underling sch= eme implementations of functional
interfaces as easily as it does ML. Th= is is why I want to get Moscow
ML working under Guile. Moscow ML is real= ly light-weight when compared
with Guile. My machine takes 42 minutes (n= o, really, I timed it!)=C2=A0 to
byte-compile just ice9-pp.go. By compar= ison, the whole Moscow ML
autoconf/build cycle takes less than 50s. This= includes the runtime,
the Standard ML basis library, and the lexer and = parser generators and
the compiler and toplevel REPL. And there's a = fair bit of junk we
could trip out, and we could make it a lot faster on= ce we JIT compile
the bytecode instead of interpreting it, and when that= JIT compiled
bytecode uses native Guile SCM objects to representall its= data, then
there will no penalty whatsoever in a Guile program just swi= tching to
Standard ML when it seems like a good idea.


--047d7b86c92ef5516e0503224bfa-- --===============2314764225782136983== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Lightning mailing list Lightning-mXXj517/zsQ@public.gmane.org https://lists.gnu.org/mailman/listinfo/lightning --===============2314764225782136983==--