g...@jpl.nasa.gov (Erann Gat) writes: > In article <8z0x576x....@ccs.neu.edu>, Joe Marshall <j...@ccs.neu.edu> wrote:
> > There is a definite difference between interpretation and > > compilation.
> What is it? Your definition does not work to describe a "definite > difference" because it relies on the definition of the word "machine", > which you don't define. On your definition whether something is a > compiler or an interpreter depends on what you decide to call your "target > machine", but that is itself an arbitrary choice, so the boundary between > interpretation and compilation is likewise an arbitrary choice.
Not at all. I'm claiming that interpretation and compilation are a relationship between two languages (you choose the languages, I don't care). You have the option of
a) compiling a program from the source language into the target language,
b) writing an interpreter for the source language in the target language,
or
c) introducing an intermediate language and creating an interpreted or compiled relationship between it and the source and target languages.
Yes, your choice of source and target language is arbitrary, but the notion of interpretation or compilation isn't.
> > > (NB: IMO, the artificial distinction between "program" and "data" is > > > actually very destructive, in fact the root cause of many of the problems > > > that software engineering faces today. That's why Lisp is the Right > > > Thing: it is (so far) the only programming language that works to erase > > > this distinction rather than reinforce it.)
> > But there *is* a difference between program and data: a program (in > > all practical languages) is a proper subset of data.
> No, there is no difference. There is a *distinction*, but not a > difference. There's a difference :-) To see this, try to come up with an > example of something that is data but not program.
Trivial: (1 2 3 4)
this is a list of 4 integers, but not a Common Lisp program. You could define a language for which this *is* a program, but most programming languages have `data' elements (pure untyped lambda calculus and TECO are notable exceptions).
> You can't do it, > except by referring to some artificial standard (like the C > standard).
There is a `natural' standard for programming languages?
> Even then one can argue that all data are programs, but only a proper > subset are "correct" or "useful" programs. Even then you get into > trouble. Take a correct C program and introduce a syntax error: is it > still a program, or is it now merely data?
If it isn't a `well-formed' C expression, then it isn't a program. I.e., the definition of the language C has no mapping for it.
> What if you had a compiler > with a bug (or a feature) that didn't recognize the error (e.g. a compiler > that automatically inserts a semicolon whenever it thinks one is missing)?
> In Lisp, all data are programs. (Some of them throw exceptions when they > "run".)
You *could* take this viewpoint, but in doing so you are discarding huge amounts of relevant information. I'm not interested in creating `programs' that throw syntax exceptions: there's a lot of them and they are all boring.
> In fact, for any data it is possible to generate a Lisp > environment where that data is not only a program but a *correct* program, > i.e. one that does not throw an exception.
Yes. Lisp is a universal language, so it is possible to write an interpreter for any other language in it. Because of the flexibility of lisp, you can even reuse large amounts of the system components to do so. But you can't do it without writing an interpreter or compiler.
> In fact, if you really want to > get funky, it's possible to generate a Lisp environment where any > arbitrary piece of data has an arbitrary specified result. I can build a > Lisp environment where the program "owjf2goi#jwe@oijw" ends up running > Microsoft Excel.
> The problem, IMO, is precisely that the customary *distinction* between > program and data causes people to believe that there is an actual > *difference* between the two. There isn't.
Is there a difference between numbers and cons cells? I certainly think so. You can add numbers, you can take CAR and CDR of cons cells. Is there a difference between programs and other data? You can APPLY or FUNCALL a program, you cannot APPLY or FUNCALL a number.
> E.
> P.S. Note that I put the word "run" in scare quotes. That's because > "programs" don't really "run".
That's absurd. I assume you typed that on a computer. The fact that it got here and that I am reading it is because your computer (and mine, and several in between) is running a program.
> Both "program" and "run" are purely artificial concepts with no > corresponding physical (or even metaphysical) reality. Alan Turing > proved this in 1936.
He did no such thing. You are spouting mystical nonsense. The common definition of `program' and `run' is more than adequate for this argument.
> I guess I'm reading 'compiled' as 'code not subject to
> change'.
Hmmm. An interesting definition for a language with dynamic typing and garbage collection. How imutable is this `not subject to change?' and what happens if you have code that in itself calls compile?
> I've always thought that interpreted referred to the fact that part of > the natural evolution of the Lisp use of operations on forms is > recursive in nature.
I have read and re-read this about four or five times and I can still make head-nor-tail of it. Maybe it's just me.
>;; * spammers suck wrote: >;; >;; > I've been told that Lisp IS an interpreted language! Now I'm even more >;; > confused. >;; >;; Lisp systems may be interpreted or compiled or both. Almost all >;; serious modern implementations have a compiler. Common Lisp (which is >;; the dominant modern dialect, at least as far as this group is >;; concerned), specifies a compiler and some minimal things that it must >;; do (which are not very onerous - it could be implemented as an >;; interpreter more-or-less). All CL implementations that I know of have >;; a compiler, although one compiles to a virtual machine, and at least >;; one uses the system's C compiler as the back-end of the compiler. >;; >;; The myth that Lisp is an interpreted language is just that - a myth:
>What does this mean for the "Lisp code *is* Lisp data" paradigm? It >seems to me that 'compiled Lisp code isn't Lisp data'... Compiled code >is then an object to be used, yes, but not quite in the same manner, I >think. I guess I'm reading 'compiled' as 'code not subject to >change'. I dunno if that's a worthy, or even worthwhile, distinction >to be made.
You're reading "compiled" wrong for most practical purposes. There are some things you can't do with compiled code that you can do with interpreted, but thanks to incremental compilation and friends, changing function definitions, object classes, methods and so forth on the fly are relatively straightforward.
There are a few things, such as macroexpansions, that you can't change as easily (see the recent thread on recompiling/re-evaluating), but those restrictions aren't exactly a result of compilation.
The fact that lisp programs have always been data (in pure s-expression form rather than text in some implementations) means that as the language has evolved, so have the tools needed to maintain that point of view.
* Christopher Browne wrote: > No, the point was that it reported "bad constructs." That's exactly > what this thread has been talking about.
But the specific thing I followed up to was saying:
I have always detested compilers that report things like: ``Expected a ; found a }''
If it is smart enough to know what ought to go there, why doesn't it just fix it?
In general that kind of annoying-but-trivial error is not the sort of thing lint detected (it probably did detect it, but so did the compiler, at least in most cases (I seem to remember the early C compilers were pretty sloppy)), and neither did it correct these things. Lint was useful for picking up things that were dubious, (like the classic if (a = b) ...;), not things that were just wrong-but-correctable like a missing but inferrable semicolon.
* Petr Swedock wrote: > What does this mean for the "Lisp code *is* Lisp data" paradigm?
Lisp *source* code is structured data with a structure that is standardized.
> It > seems to me that 'compiled Lisp code isn't Lisp data'... Compiled code > is then an object to be used, yes, but not quite in the same manner, I > think. I guess I'm reading 'compiled' as 'code not subject to > change'. I dunno if that's a worthy, or even worthwhile, distinction > to be made.
Compiled code is also Lisp data, may also be structured (other than being a sequence of words), but that structure is not standardized. The only operation defined on a function is to call it (this isn't true - you can also ask for (and may get) its lambda expression, as well as various operations common to all objects such as asking them their type &c).
In article <r8eo4x0i....@ccs.neu.edu>, Joe Marshall <j...@ccs.neu.edu> wrote: > Yes, your choice of source and target language is arbitrary, but the > notion of interpretation or compilation isn't.
It is no more and no less arbitrary than the choice of languages, which is to say (as you yourself just admitted), completely arbitrary.
> > No, there is no difference. There is a *distinction*, but not a > > difference. There's a difference :-) To see this, try to come up with an > > example of something that is data but not program.
> Trivial: (1 2 3 4)
> this is a list of 4 integers, but not a Common Lisp program.
Which is an arbitrary decision made by the designers of Common Lisp, as you yourself observe in the very next sentence:
> You could > define a language for which this *is* a program, but most programming > languages have `data' elements (pure untyped lambda calculus and TECO > are notable exceptions).
... so it seems to me like we're in violent agreement here.
(As an interesting aside you should look at the recent discussion in comp.lang.scheme over what (call/cc (lambda (e) (0 (e 1)))) ought to do.)
> > You can't do it, > > except by referring to some artificial standard (like the C > > standard).
> There is a `natural' standard for programming languages?
No, that's the whole point. The "natural" standards (the mathematical formalisms that describe computations) say nothing about "programming." That means that interacting with computational machinery by doing what is today called "programming" is a choice, not a requirement.
Interacting with Microsoft Excel, for example, is in some ways very similar to programming, but in other ways very different. An Excel spreadsheet is in some ways like a program, and in other ways not. Interacting with a Lisp environment is likewise in some ways very similar to what a C programmer considers "programming" but is in other ways very different. For example, it is hard for a C programmer to conceive of "programming" without "creating" something called an "executable." For a Lisp programmer "programming" without "creating executables" is perfectly natural. For an Excel user, "programming" without creating a "program" is perfectly natural.
> You *could* take this viewpoint, but in doing so you are discarding > huge amounts of relevant information. I'm not interested in creating > `programs' that throw syntax exceptions: there's a lot of them and > they are all boring.
Imagine that someone hands you two non-programs. One is a completely random string, and the other one is one syntax error away from being a "real" program. Do you consider both of these to be equally boring?
> > In fact, for any data it is possible to generate a Lisp > > environment where that data is not only a program but a *correct* program, > > i.e. one that does not throw an exception.
> Yes. Lisp is a universal language, so it is possible to write an > interpreter for any other language in it. Because of the flexibility > of lisp, you can even reuse large amounts of the system components to > do so. But you can't do it without writing an interpreter or > compiler.
Since "interpreter" and "compiler" are not well defined this is a vacuous statement. I can make this happen by doing nothing but modifying the readtable, which is arguably writing neither an interpreter nor a compiler but rather a parser. But "parser" is also not well defined. That's my whole point. Computatinal systems do interesting things when you interact with them. Sometimes it's useful to impose some mental structure onto those interactions and use labels like "program" and "interpreter" and "compiler" to label that mental structure. But it's important not to confuse that mental structure with the underlying reality because then you can end up restricting yourself (and others) unnecessarily.
> > The problem, IMO, is precisely that the customary *distinction* between > > program and data causes people to believe that there is an actual > > *difference* between the two. There isn't.
> Is there a difference between numbers and cons cells? I certainly > think so.
Have you heard of Church numerals?
> You can add numbers, you can take CAR and CDR of cons cells.
You can also add cons cells (which is to say you can define an operation that has the same semantics as addition, except that it operates on cons cells), and take the car and cdr of numbers (likewise). These operations are not built in to Common Lisp, but nothing prevents you from adding these capabilities to the language.
> Is there a difference between programs and other data? You > can APPLY or FUNCALL a program, you cannot APPLY or FUNCALL a > number.
Again, this is just an arbitrary restriction imposed by a particular language design. As an absolute claim it is no more true than when a C programmer says it's impossible to create lexical closures. It is true in C. It is not true in general. Likewise the claim that you can't apply a number is true in Lisp, but not in general. I can think of at least two reasonable semantics for applying numbers: the first is to simply return the number, i.e. a number is a function that discards its argument and returns itself. The second is for numbers to be shorthand for projection functions, i.e. when you apply N you get back the Nth argument to N. These ideas may be useful, or they may not be, but the point is that you would never even consider them if you took the non-applyability of numbers and the immutable Gospel truth.
> > P.S. Note that I put the word "run" in scare quotes. That's because > > "programs" don't really "run".
> That's absurd. I assume you typed that on a computer. The fact that > it got here and that I am reading it is because your computer (and > mine, and several in between) is running a program.
My computer is performing a computational process, but that's not necessarily the same thing as "running a program" in the sense that the term is normally understood. The difference is that when a process stops it ceases to exist. When a "program" no longer "runs", it (the program) is commonly understood to continue to exist. (When I quit my newsreader, the newsreader process vanishes, but the program doesn't.) Programs can be a useful way to think about computation, but they are not necessary, and IMO the concept is often harmful.
Actually, this newsreader is a perfect example of how "program" is a harmful concept. My newsreader *is* a "program". It is, in fact, a particular kind of program, an "application" (as contrasted with, say, a "plug-in"). Because of this it is extremely limited in how it can interact with other "programs", and it is virtually impossible for me to change its behavior. In some contexts, those limitations are features. In others, they are problems.
> > Both "program" and "run" are purely artificial concepts with no > > corresponding physical (or even metaphysical) reality. Alan Turing > > proved this in 1936.
> He did no such thing.
Well, of course he didn't show this directly (the idea of a "program" didn't exist in Turing's day, and the word doesn't appear in his paper). But he did show that if you draw a line between "program" and "data" in a universal computer then the information in the "program" can be freely migrated into the "data" (and it's straightforward to extend this result to show that by repeated application of this process the "program" can be arbitrarily obfuscated inside the "data"). It seems to me a reasonable interpretation of this result that a distinction between "program" and "data" is not fundamentally meaningful.
* Wade Humeniuk | People make observations of how easy it is for children to learn new | things, this is partly because they do not resist change (in fact they | have nothing to change from). For an adult to change, with ingrained | neural pathways, the choice needs to be made to subject oneself to | situations where one can potentially come into conflict with how the | brain is currently wired.
If what one already knows is reasonably consonant with reality, learning should be so much faster when you know a lot. For instance, a surgeon with 15 years' worth of experience regularly learns a new technique in one tutored session while a novice surgeon may require a dozen. I think it all depends on whether you are "open for learning" or not, and this is a mental state that appear to require significant energy. Evolutionarily unsurprising, since it should be effortless to use internalized knowledge (or as close to effortless as possible) and most things needing learning should be learnable only once. Many animals, even insects, are touted as being particularly "intelligent" this way -- they learn from all mistakes and do not repeat them. (E.g., my cat now knows all the prepartory steps I have not been fully aware that I took preceding a trip to the vet. It now takes significant effort for me to be creative enough each time that I actually make the appointment. She is even smart enough to become suspicious if I close off certain places with good hiding places and run hide elsewhere.)
| You have to choose to be uncomfortable (the insecurity of being a child | again), and the faith that the brain/mind will adapt once again and | everything will be fine.
Quite. The confidence that you most probably will end up better off, and certainly no worse off on the other side of the learning experience than you would if you did not engage in it must be established. It usually works very well to artificially lower the predictable outcome of not learning, however, but some of the best ways to do this (such as grades and exams and making people feel bad for not knowing) unfortunately cause a minority of people to get stuck at the artificially lower level despite efforts to return it to normal.
| Marvin Minsky's draft section on Consciousness is an interesting read.
Thanks for the pointer.
| To be able to change, one would surmise that you need a fairly secure | environment (like a secure job) until the transition is complete (as one | is fairly vulnerable during large changes), and some assurrance that you | are making a good change (or at least a neutral one). Also some mental | image (imagination) of the desired outcome is needed to help motivate and | spur change.
I appears to me that there are some problems caused by the way children are encouraged to work in school that could need some improvement. I do not think that one needs to motivate people to take small risks to get something better even with a low probability of success -- if that were the case, we would have serious problems with the sorts of things that are financed by the stupid tax, better known as "lotteries". I think the only /really/ important task is to instill in children or others you care about personally a confidence that they will never be worse off for trying to learn something. Even if they fail, they could not /possibly/ be worse off than if they did not try, but for some reason, some people take failure personally and feel or actually believe they are measured by their failures, not by their successes.
-- Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
"Erik Naggum" <e...@naggum.no> wrote in message news:3243890791963016@naggum.no... > Many animals, even insects, are touted as > being particularly "intelligent" this way -- they learn from all mistakes > and do not repeat them. (E.g., my cat now knows all the prepartory steps > I have not been fully aware that I took preceding a trip to the vet. It > now takes significant effort for me to be creative enough each time that > I actually make the appointment. She is even smart enough to become > suspicious if I close off certain places with good hiding places and run > hide elsewhere.)
My dog (a beagle) is not quite so smart, but he does know all the prepatory steps for going for a walk (his favorite activity). Even though I think I am performing the same activities, getting ready to leave the house, etc., he seems to sense my intention if I am taking him or not. BTW my dog actually likes going to the vet, when we pull into the parking lot he gets very excited and can't wait to go in.
> | To be able to change, one would surmise that you need a fairly secure > | environment (like a secure job) until the transition is complete (as one > | is fairly vulnerable during large changes), and some assurrance that you > | are making a good change (or at least a neutral one). Also some mental > | image (imagination) of the desired outcome is needed to help motivate and > | spur change.
> I appears to me that there are some problems caused by the way children > are encouraged to work in school that could need some improvement. I do > not think that one needs to motivate people to take small risks to get > something better even with a low probability of success -- if that were > the case, we would have serious problems with the sorts of things that > are financed by the stupid tax, better known as "lotteries". I think the > only /really/ important task is to instill in children or others you care > about personally a confidence that they will never be worse off for > trying to learn something. Even if they fail, they could not /possibly/ > be worse off than if they did not try, but for some reason, some people > take failure personally and feel or actually believe they are measured by > their failures, not by their successes.
I have two kid's, my son seems to unaffected by failure and just keeps plugging along. My daughter takes failure harder. The only environmental explanation I can think of is that we did not coddle our son like we did to our daughter when he was a baby. (our son was the second child)
I understand about taking failure personally. I had major surgery two months ago and it would have been very easy to take the disease and resultant sugery as a very personal failure. It was a very personal thing. I was extremely impressed by the Surgeon's compassion in not treating my physical state as a personal failure on my behalf. Amazing enough I found the Surgeons to be the easiest personalities to interact with, in addition to this compassion I found that they were very intelligent and capable. It took a minimum of conversation to communicate. Though it was difficult to decide to do it, and actually go thorugh it, it was a great learning experience. I have always learned from every situation I have been in, though sometimes it takes a long time to figure out what it was.
On 17 Oct 2002 08:52:55 +0100, Tim Bradshaw <t...@cley.com> said:
* Coby Beck wrote: CB> PS Hmm...now i thought there was a limit somewhere in CLHS for the length CB> of an identifier but I don't find it...maybe infinity is not so far off CB> after all.
[...] TB> But, hah! *uninterned symbols*! TB> No measly limits on them now
On Wed, 16 Oct 2002 22:11:01 +0930, arien <spammers_s...@getlost.invalid> said:
[...] *> At least curly brace, semicolon, comma etc are all different. It becomes *> easier to find the error, and the compiler will even tell you which line *> has the error.
*> In lisp, all you have is parentheses, parentheses, and more *> parentheses.
In non-Lisp, it is significantly harder to determine where the other matching endpoint of a syntactic unit is, so navigation, copying, cutting, etc. are significantly harder (e.g. the cursor is immediately before ``if'' and I want to move to the point immediately after the if statement, or to cut (`kill') the if statement).
Joe Marshall <j...@ccs.neu.edu> wrote: +--------------- | g...@jpl.nasa.gov (Erann Gat) writes: | > On your definition whether something is a compiler or an interpreter | > depends on what you decide to call your "target machine", but that is | > itself an arbitrary choice, so the boundary between interpretation and | > compilation is likewise an arbitrary choice. | | Not at all. I'm claiming that interpretation and compilation are a | relationship between two languages (you choose the languages, I don't | care). You have the option of | a) compiling a program from the source language into the target language, | b) writing an interpreter for the source language in the target language, or | c) introducing an intermediate language and creating an interpreted or | compiled relationship between it and the source and target languages. | | Yes, your choice of source and target language is arbitrary, but the | notion of interpretation or compilation isn't. +---------------
Exactly so. Those definitions and relationships are *decades* old!! If one is not familiar with them then one's computer science education (whether formal or self-taught) is sadly lacking.
Possibly the best presentation I have seen of them is the transformational "T-diagrams" in the book "A Compiler Generator" (for the XPL language) by McKeeman, Horning, and Wortman <URL:http://www.cs.toronto.edu/XPL/>. Inside the front & back covers of that book are a series of T-diagrams which graphically & clearly show the relationships between four kinds of things -- Machines, Interpreters, Translators/Compilers, and Programs -- and how each is used at various stages of, say, bootstrapping a language system to a new environment.
The XPL book itself goes into much further detail on T-diagrams and their uses, but if you're not familiar at all with the concepts, the following pages (especially the first one) will give one some taste of them:
On 18 Oct 2002 11:48:03 +0100, Tim Bradshaw <t...@cley.com> said:
* Vassil Nikolov wrote: VN> They also have names.
TB> But that doesn't matter, since two uninterned symbols with the same TB> name can nevertheless be distinct: [...]
I was referring to the fact that the limit on the length of a string still applies to uninterned symbols. Re-reading the thread, I can see you were in fact referring to the absence of explicit limits on the total number of distinct uninterned symbols, even in the presence of an explicit (albeit *very* large) limit on the number of distinct symbol names (as a consequence of the limit on their length). So I was not in fact responding to what you had written, my bad.
Will Deakin <anisotro...@hotmail.com> writes: ;; Petr Swedock wrote:
;; > I guess I'm reading 'compiled' as 'code not subject to ;; > change'. ;; ;; Hmmm. An interesting definition for a language with dynamic typing and ;; garbage collection. How imutable is this `not subject to change?' and ;; what happens if you have code that in itself calls compile?
I dunno. I guess I'm fuzzy on the concepts here. Which is why I ask the questions.
;; > I've always thought that interpreted referred to the fact that part ;; > of the natural evolution of the Lisp use of operations on forms is ;; > recursive in nature. ;; ;; I have read and re-read this about four or five times and I can still ;; make head-nor-tail of it. Maybe it's just me.
Or maybe it's me... the bulk of my experience with Lisp, to date, is with the Symbolics Virtual Lisp Machine running on Alphas. There, if you got into trouble C-M-<esc> would drop you into the debugger and you could modify your code, get out of the debugger, and keep moving. My understanding is that you could do this only because the code was not compiled and that, in fact, compiling would interrupt this cycle because it changed the structure of the data. I've always thought that the interpreter was simply 'stopped' at one level of recursion and that the debugger was simply a means of stepping throught the levels of recursion.
g...@jpl.nasa.gov (Erann Gat) writes: > In article <r8eo4x0i....@ccs.neu.edu>, Joe Marshall <j...@ccs.neu.edu> wrote:
> > Yes, your choice of source and target language is arbitrary, but the > > notion of interpretation or compilation isn't.
> It is no more and no less arbitrary than the choice of languages, which is > to say (as you yourself just admitted), completely arbitrary.
Imagine a computer language in which
void main (int argc, char ** argv) { return 0; }
is a valid program (for the colloquial definition of `valid program'). Now consider Common Lisp as defined by the hyperspec. The above `program' is *not* a Common Lisp program. No one would expect that all conforming Common Lisp systems would understand it.
However....
Considering that the above *is* a program in a language, then we can set up a relationship involving Common Lisp, our hypothetical language, and our program. That relationship is either an `interpreter' or a 'compiler'. An interpreter is a Common Lisp program that, when given a program in our hypothetical language, performs the same effect. A compiler is a program that, when given a program in our hypothetical language, finds an *eqivalent* program in Common Lisp.
> (As an interesting aside you should look at the recent discussion in > comp.lang.scheme over what (call/cc (lambda (e) (0 (e 1)))) ought to do.)
If you look at that thread you will see that I am of the opinion that such a program ought to return 1 (and not complain about zero in function position). I also think that it would be desirable for the compiler to warn about such an unlikely program, but should not disallow it. My rationale is that it may be possible for such a form to be created via some macro expansion and forcing the user to avoid `erroneous' expansions in `dead code' is a burden. But I digress....
> That means that interacting with computational machinery by doing what is > today called "programming" is a choice, not a requirement.
If you want to interact with a computer, you have to, at the very least, tell it what you want done. This will be the case until they make computers that can read minds. These days, we have to use a very formal language and describe the mechanism to achieve what we want. In the future we may be able to speak our native language and just ask for some result. Either way, though, we are programming the computer.
> > > In fact, for any data it is possible to generate a Lisp > > > environment where that data is not only a program but a *correct* program, > > > i.e. one that does not throw an exception.
> > Yes. Lisp is a universal language, so it is possible to write an > > interpreter for any other language in it. Because of the flexibility > > of lisp, you can even reuse large amounts of the system components to > > do so. But you can't do it without writing an interpreter or > > compiler.
> Since "interpreter" and "compiler" are not well defined this is a vacuous > statement. I can make this happen by doing nothing but modifying the > readtable, which is arguably writing neither an interpreter nor a compiler > but rather a parser. But "parser" is also not well defined. That's my > whole point.
They *are* well defined. If you modify the readtable such that reading your program results causes the computer to perform as if it were executing the other language, you have built an interpreter. If you modify the readtable such that the result of reading your program is a valid common lisp program that performs the same action as your original program, you have built a compiler. If you wish, you may introduce an intermediate language which is `compiled' by the readtable and `interpreted' by a common lisp program.
> > Is there a difference between numbers and cons cells? I certainly > > think so.
> Have you heard of Church numerals?
Yes, have you heard of the `typed lambda calculus'? When did Church numerals become part of the hyperspec?
> > You can add numbers, you can take CAR and CDR of cons cells.
> You can also add cons cells (which is to say you can define an operation > that has the same semantics as addition, except that it operates on cons > cells), and take the car and cdr of numbers (likewise). These operations > are not built in to Common Lisp,
and as such *not* part of the language
> but nothing prevents you from adding these capabilities to the > language.
Yes. I could either extend the semantics with a program that knows how to `add' cons cells (write an interpreter), or define a macro that transforms (jrm:+ '(a b) '(c d)) into (cl:append '(a b) '(c d)) (write a compiler).
> > Is there a difference between programs and other data? You > > can APPLY or FUNCALL a program, you cannot APPLY or FUNCALL a > > number.
> Again, this is just an arbitrary restriction imposed by a particular > language design. As an absolute claim it is no more true than when a C > programmer says it's impossible to create lexical closures. It is true in > C. It is not true in general. Likewise the claim that you can't apply a > number is true in Lisp, but not in general.
I'm not talking in general. I'm talking about the relationship between two arbitrary, but concrete, languages. The notion of universal computation is that any universal computer can simulate any other. The mechanism by which this occurs is either interpretation (writing a program on the target machine that emulates the source machine) or compilation (writing a program that transforms source code into target code).
> > > P.S. Note that I put the word "run" in scare quotes. That's because > > > "programs" don't really "run".
> > That's absurd. I assume you typed that on a computer. The fact that > > it got here and that I am reading it is because your computer (and > > mine, and several in between) is running a program.
> My computer is performing a computational process, but that's not > necessarily the same thing as "running a program" in the sense that the > term is normally understood.
It isn't? It certainly seems so to me. When I talk about `running a program' I am talking *exactly* about the computer performing a computational process described by the program.
> The difference is that when a process stops > it ceases to exist. When a "program" no longer "runs", it (the program) > is commonly understood to continue to exist. (When I quit my newsreader, > the newsreader process vanishes, but the program doesn't.) Programs can > be a useful way to think about computation, but they are not necessary, > and IMO the concept is often harmful.
Programs are as necessary as words are. A program is a formal description of a computation. As you mention, the newsreader process disappears when you are done reading. Without the notion of a program, we would be restricted to talking about only those computations that are currently being performed.
> Well, of course he didn't show this directly (the idea of a "program" > didn't exist in Turing's day, and the word doesn't appear in his paper). > But he did show that if you draw a line between "program" and "data" in a > universal computer then the information in the "program" can be freely > migrated into the "data" (and it's straightforward to extend this result > to show that by repeated application of this process the "program" can be > arbitrarily obfuscated inside the "data"). It seems to me a reasonable > interpretation of this result that a distinction between "program" and > "data" is not fundamentally meaningful.
At one level I agree. I said before that a program is a subset of `data' in most languages. The difference between `interpretation' and `compilation' is in the direction that you do the migration. It isn't all that big a deal, but it *is* well defined.
> is a valid program (for the colloquial definition of `valid > program'). Now consider Common Lisp as defined by the hyperspec. The > above `program' is *not* a Common Lisp program. No one would expect > that all conforming Common Lisp systems would understand it.
> However....
> Considering that the above *is* a program in a language, then we can > set up a relationship involving Common Lisp, our hypothetical > language, and our program. That relationship is either an > `interpreter' or a 'compiler'.
(null? '()) is is program in a language, but it is not a Common Lisp program. But it can be made to be a valid program within the context of a Common Lisp environment by writing (defun null? (x) (null x)), but that is neither an interpreter nor a compiler. It is a "library". So your argument does not apply in general, but only for very specific examples, which is precisely my point.
> An interpreter is a Common Lisp > program that, when given a program in our hypothetical language, > performs the same effect. A compiler is a program that, when given a > program in our hypothetical language, finds an *eqivalent* program in > Common Lisp.
On this definition an interpreter and a compiler could be identical but for the fact that the interpreter runs the resulting Common Lisp code and the compiler doesn't.
> > That means that interacting with computational machinery by doing what is > > today called "programming" is a choice, not a requirement.
> If you want to interact with a computer, you have to, at the very > least, tell it what you want done. This will be the case until they > make computers that can read minds. These days, we have to use a very > formal language and describe the mechanism to achieve what we want.
No, you don't. That just shows a lack of imagination. In fact, it has been the case for a long time that you don't have to use any formal languages in order to interact with a computer to perform a wide variety of useful tasks -- drawing pictures with a mouse, for example. It is not out of the question to imagine that we could extend this interaction paradigm to those activities that given today's technology still require formal languages. (In fact, there is a system called Labview that is already a significant step in this direction.)
> In the future we may be able to speak our native language and just ask > for some result. Either way, though, we are programming the computer.
Of course. Look, I'm not saying that programming is a useless concept. What I'm saying is that 1) today there is a sharp distinction made between "programming" a computer and "using" one, 2) that this distinction is one that we *choose* to make rather than being imposed on us by the underlying mathematics of computation, 3) that maintining this sharp boundary line between "programming" and "use" can be harmful and therefore 4) it can be fruitful to consider making the boundary line less sharp.
Consider an analogous argument that one might find in a C++ newsgroup: 1) today there is a sharp boundary line between "code" and "data", 2) this distinction is one that we choose to make (by virtue of the fact that many facilities present in our compilers are not required to be available at runtime), 3) maintaining this sharp distinction between "code" and "data" can be harmful (because we spend half our lives writing lex and yacc code for badly designed mini-languages) and therefore 4) is might be fruitful to consider making the boundary between code and data less sharp (by inventing Lisp).
> > > > In fact, for any data it is possible to generate a Lisp > > > > environment where that data is not only a program but a *correct* program, > > > > i.e. one that does not throw an exception.
> > > Yes. Lisp is a universal language, so it is possible to write an > > > interpreter for any other language in it. Because of the flexibility > > > of lisp, you can even reuse large amounts of the system components to > > > do so. But you can't do it without writing an interpreter or > > > compiler.
> > Since "interpreter" and "compiler" are not well defined this is a vacuous > > statement. I can make this happen by doing nothing but modifying the > > readtable, which is arguably writing neither an interpreter nor a compiler > > but rather a parser. But "parser" is also not well defined. That's my > > whole point.
> They *are* well defined. If you modify the readtable such that > reading your program results causes the computer to perform as if it > were executing the other language, you have built an interpreter. If > you modify the readtable such that the result of reading your program > is a valid common lisp program that performs the same action as your > original program, you have built a compiler. If you wish, you may > introduce an intermediate language which is `compiled' by the > readtable and `interpreted' by a common lisp program.
You've defined "interpreter" and "compiler" but not "parser". And you've defined them in such a way that the only difference between an interpreter and a compiler is that an interpreter runs the code and a compiler doesn't.
> > > Is there a difference between numbers and cons cells? I certainly > > > think so.
> > Have you heard of Church numerals?
> Yes, have you heard of the `typed lambda calculus'? When did Church > numerals become part of the hyperspec?
I must confess I am not well versed in the typed lambda calculus.
When did matrix multiplication become part of the hyperspec? Oh, it's not in the Hyperspec? Does that mean that Common Lisp can't do matrix multiplication?
> Yes. I could either extend the semantics with a program that knows > how to `add' cons cells (write an interpreter), or define a macro that > transforms (jrm:+ '(a b) '(c d)) into (cl:append '(a b) '(c d)) > (write a compiler).
Do you consider a library function to be an interpreter? I don't think that jibes with most people's intuition about what an interpreter is.
> > > Is there a difference between programs and other data? You > > > can APPLY or FUNCALL a program, you cannot APPLY or FUNCALL a > > > number.
> > Again, this is just an arbitrary restriction imposed by a particular > > language design. As an absolute claim it is no more true than when a C > > programmer says it's impossible to create lexical closures. It is true in > > C. It is not true in general. Likewise the claim that you can't apply a > > number is true in Lisp, but not in general.
> I'm not talking in general.
Well, there's the source of our disagreement. I am.
> I'm talking about the relationship > between two arbitrary, but concrete, languages. The notion of > universal computation is that any universal computer can simulate any > other. The mechanism by which this occurs is either interpretation > (writing a program on the target machine that emulates the source > machine) or compilation (writing a program that transforms source code > into target code).
And my claim is that this is not a meaningful distinction in general because you cannot in general distinguish what is "code" and what is not.
> > > > P.S. Note that I put the word "run" in scare quotes. That's because > > > > "programs" don't really "run".
> > > That's absurd. I assume you typed that on a computer. The fact that > > > it got here and that I am reading it is because your computer (and > > > mine, and several in between) is running a program.
> > My computer is performing a computational process, but that's not > > necessarily the same thing as "running a program" in the sense that the > > term is normally understood.
> It isn't? It certainly seems so to me. When I talk about `running a > program' I am talking *exactly* about the computer performing a > computational process described by the program.
"Running a program" as the terms are commonly used is a *subset* of the computational processes that a computer is capable of performing. For example, an operating system is, strictly speaking, a program, but it's usually not talked about that way. It is not completely nonsensical in common usage to say, "My computer has booted up, but it isn't running any programs yet."
(BTW, "operating system" is another convenient fiction that isn't really necessary for computation.)
> > The difference is that when a process stops > > it ceases to exist. When a "program" no longer "runs", it (the program) > > is commonly understood to continue to exist. (When I quit my newsreader, > > the newsreader process vanishes, but the program doesn't.) Programs can > > be a useful way to think about computation, but they are not necessary, > > and IMO the concept is often harmful.
> Programs are as necessary as words are.
I would actually agree with that, but counter by saying that words aren't necessary for doing a lot of the things we try to do with words, and in fact, a lot of things we sometimes try to do with words might be better done with something other than words (like pictures), or with words augmented with other things like inflections and gestures. Words are at once enabling and constraining, just like programming.
> A program is a formal > description of a computation. As you mention, the newsreader process > disappears when you are done reading. Without the notion of a > program, we would be
g...@jpl.nasa.gov (Erann Gat) writes: > (null? '()) is is program in a language, but it is not a Common Lisp > program. But it can be made to be a valid program within the context of a > Common Lisp environment by writing (defun null? (x) (null x)), but that is > neither an interpreter nor a compiler. It is a "library". So your > argument does not apply in general, but only for very specific examples, > which is precisely my point.
No, that is an interpreter. Had you written:
(defmacro null? (x) `(null ,x))
you would have written a compiler.
> > An interpreter is a Common Lisp > > program that, when given a program in our hypothetical language, > > performs the same effect. A compiler is a program that, when given a > > program in our hypothetical language, finds an *eqivalent* program in > > Common Lisp.
> On this definition an interpreter and a compiler could be identical but > for the fact that the interpreter runs the resulting Common Lisp code and > the compiler doesn't.
You could mimic an interpreter by compiling on the fly and executing the resulting code.
> Of course. Look, I'm not saying that programming is a useless concept. > What I'm saying is that 1) today there is a sharp distinction made between > "programming" a computer and "using" one, 2) that this distinction is one > that we *choose* to make rather than being imposed on us by the underlying > mathematics of computation, 3) that maintining this sharp boundary line > between "programming" and "use" can be harmful and therefore 4) it can be > fruitful to consider making the boundary line less sharp.
Agreed.
> Consider an analogous argument that one might find in a C++ newsgroup: 1) > today there is a sharp boundary line between "code" and "data", 2) this > distinction is one that we choose to make (by virtue of the fact that many > facilities present in our compilers are not required to be available at > runtime), 3) maintaining this sharp distinction between "code" and "data" > can be harmful (because we spend half our lives writing lex and yacc code > for badly designed mini-languages) and therefore 4) is might be fruitful > to consider making the boundary between code and data less sharp (by > inventing Lisp).
> > > > > In fact, for any data it is possible to generate a Lisp > > > > > environment where that data is not only a program but a *correct* > program, > > > > > i.e. one that does not throw an exception.
> > > > Yes. Lisp is a universal language, so it is possible to write an > > > > interpreter for any other language in it. Because of the flexibility > > > > of lisp, you can even reuse large amounts of the system components to > > > > do so. But you can't do it without writing an interpreter or > > > > compiler.
> > > Since "interpreter" and "compiler" are not well defined this is a vacuous > > > statement. I can make this happen by doing nothing but modifying the > > > readtable, which is arguably writing neither an interpreter nor a compiler > > > but rather a parser. But "parser" is also not well defined. That's my > > > whole point.
> > They *are* well defined. If you modify the readtable such that > > reading your program results causes the computer to perform as if it > > were executing the other language, you have built an interpreter. If > > you modify the readtable such that the result of reading your program > > is a valid common lisp program that performs the same action as your > > original program, you have built a compiler. If you wish, you may > > introduce an intermediate language which is `compiled' by the > > readtable and `interpreted' by a common lisp program.
> You've defined "interpreter" and "compiler" but not "parser".
In general, a parser is a subset of `compiler'. (Note that parsers are generally not capable of universal computation.) The parser transforms a program from one form (typically a string of characters) into another form (typically some sort of expression tree).
> And you've defined them in such a way that the only difference > between an interpreter and a compiler is that an interpreter runs > the code and a compiler doesn't.
I've been *trying* to show that the difference between an interpreter and compiler is that a compiler is a `code' to `code' transform while an interpreter is a `machine' to `machine' transform.
> When did matrix multiplication become part of the hyperspec? Oh, it's not > in the Hyperspec? Does that mean that Common Lisp can't do matrix > multiplication?
Common Lisp doesn't do matrix multiplacation right out of the box. You need to extend it. You can either add functions to the environment that can perform matrix multiplication or you can transform the matrix multiplication syntax into a common lisp program that does the equivalent.
> > Yes. I could either extend the semantics with a program that knows > > how to `add' cons cells (write an interpreter), or define a macro that > > transforms (jrm:+ '(a b) '(c d)) into (cl:append '(a b) '(c d)) > > (write a compiler).
> Do you consider a library function to be an interpreter? I don't think > that jibes with most people's intuition about what an interpreter is.
Perhaps not, but formally, a library function extends the `machine' and is thus an interpreter.
> > I'm not talking in general.
> Well, there's the source of our disagreement. I am.
I suspected that.
> > I'm talking about the relationship > > between two arbitrary, but concrete, languages. The notion of > > universal computation is that any universal computer can simulate any > > other. The mechanism by which this occurs is either interpretation > > (writing a program on the target machine that emulates the source > > machine) or compilation (writing a program that transforms source code > > into target code).
> And my claim is that this is not a meaningful distinction in general > because you cannot in general distinguish what is "code" and what is not.
You can't define `compilation' or `interpretation' in an absolute (general) sense because it is a relationship between languages. Any language can either be compiled or interpreted by any other.
> > > The difference is that when a process stops > > > it ceases to exist. When a "program" no longer "runs", it (the program) > > > is commonly understood to continue to exist. (When I quit my newsreader, > > > the newsreader process vanishes, but the program doesn't.) Programs can > > > be a useful way to think about computation, but they are not necessary, > > > and IMO the concept is often harmful.
> > Programs are as necessary as words are.
> I would actually agree with that, but counter by saying that words aren't > necessary for doing a lot of the things we try to do with words, and in > fact, a lot of things we sometimes try to do with words might be better > done with something other than words (like pictures), or with words > augmented with other things like inflections and gestures. Words are at > once enabling and constraining, just like programming.
Well, we could go semiotic and just talk about signs....
> > A program is a formal > > description of a computation. As you mention, the newsreader process > > disappears when you are done reading. Without the notion of a > > program, we would be restricted to talking about only those > > computations that are currently being performed.
> No, again you're showing a lack of imagination. A program is one way to > construct a computational process, but it is not the only way.
Let me re-iterate: a program is a formal description of a computation. `Formal' in this sense doesn't mean `all dressed up with no place to go' or even `stilted', but rather `in an agreed-upon common terminology' that can be rather `informal'. It is a description because as you mentioned, a program is not in itself a computation.
> > > Well, of course he didn't show this directly (the idea of a "program" > > > didn't exist in Turing's day, and the word doesn't appear in his paper). > > > But he did show that if you draw a line between "program" and "data" in a > > > universal computer then the information in the "program" can be freely > > > migrated into the "data" (and it's straightforward to extend this result > > > to show that by repeated application of this process the "program" can be > > > arbitrarily obfuscated inside the "data"). It seems to me a reasonable > > > interpretation of this result that a distinction between "program" and > > > "data" is not fundamentally meaningful.
> > At one level I agree. I said before that a program is a subset of > > `data' in most languages. The difference between `interpretation' and > > `compilation' is in the direction that you do the migration. It isn't > > all that big a deal, but it *is* well defined.
> The definitions you've given do not produce a meaningful distinction > between interpretation and compilation. On your definitions, anything > that ends up running a program is an interpreter, and anything that > performs any kind of transformation on code without running it is a > compiler. (Rot13 is a compiler according to your definitions.)
Rot13 could very well be a compiler. If someone were perverse enough to define a language `ROT13 Java' which was identical to Java but for having to be expressed in ROT13, a compiler that transformed a `ROT13 Java' program into a `standard' Java program would be that simple.
On the other hand, someone could take a Java interpreter and fudge around with the representation of characters and create a `ROT13 Java' interpreter rather trivially, too.
g...@jpl.nasa.gov (Erann Gat) writes: > In article <elan4tqq....@ccs.neu.edu>, Joe Marshall <j...@ccs.neu.edu> wrote:
> > If you want to interact with a computer, you have to, at the very > > least, tell it what you want done. This will be the case until they > > make computers that can read minds. These days, we have to use a very > > formal language and describe the mechanism to achieve what we want.
> No, you don't. That just shows a lack of imagination. In fact, it has > been the case for a long time that you don't have to use any formal > languages in order to interact with a computer to perform a wide variety > of useful tasks -- drawing pictures with a mouse, for example. It is not > out of the question to imagine that we could extend this interaction > paradigm to those activities that given today's technology still require > formal languages. (In fact, there is a system called Labview that is > already a significant step in this direction.)
Graphical languages such as LabVIEW's G and Gensym's G2 system are still formal languages.
Petr Swedock wrote: > Will Deakin <anisotro...@hotmail.com> writes:
> ;; Petr Swedock wrote: > ;; > I guess I'm reading 'compiled' as 'code not subject to > ;; > change'. > ;; > ;; Hmmm. An interesting definition for a language with dynamic typing and > ;; garbage collection. How imutable is this `not subject to change?' and > ;; what happens if you have code that in itself calls compile?
> I dunno. I guess I'm fuzzy on the concepts here. Which is why I ask > the questions.
Sure. (I'm probably just being smart and, as my dad often told me, nobody likes a smartarse.)
I have now read this and thought about this a little bit and FWIW my rather muddled take is: Common lisp is really powerful in many ways. One of which being that you can in a running lisp modify and evaluate a new function and the next time the function is called the new ernie is run and it *doesn't* matter if the function is compiled or not. I think you can break things -- like if the new function is broken -- but otherwise you should be fine.
Do this in c or c++ -- even using shared libraries -- or perl and then you then get to run `find . -name core -exec rm {} \;' unless you are running windows in which case you could get to cycle the power. Although maybe this is due to my hamfisted programming.
There are some wrinkles to do with macros which are being discussed elsewhere on c.l.l. Probably at this very moment.
> Or maybe it's me... the bulk of my experience with Lisp, to date, is > with the Symbolics Virtual Lisp Machine running on Alphas.
Cool. (sigh). Wish I had...
> My understanding is that you could do this only because the code was > not compiled and that, in fact, compiling would interrupt this cycle > because it changed the structure of the data.
Since I don't know enough -- or is that anything -- about Symbolics I couldn't say but this is not my experience of common lisp.
> I've always thought that the interpreter was simply 'stopped' at > one level of recursion and that the debugger was simply a means of > stepping throught the levels of recursion.
What is puzzling me is the use of recursion in this context. If you were talking about, say, stack frames and you were moving up or down these stack grames it would sit more happily with what I think goes on. Again I don't know how symbolics work.
In article <ouyof9rzjpq....@panix3.panix.com>, Carl Shapiro
<cshapiro+s...@panix.com> wrote: > Graphical languages such as LabVIEW's G and Gensym's G2 system are > still formal languages.
Well, that just begs the definition of the word "formal". If you believe Church's thesis then everything is a formal language.
Whether Labview is a formal language or not (I'm happy to concede that it is) I claim that Labview is fundamentally different from other formal languages in one important way: Labview has a structure that is inherently two-dimensional, while most other languages have a one-dimensional structure. Let me explain what I mean by that.
Most languages are sets of *sentences* or strings of symbols. The semantics of a sentence is determined by the identity of the symbols and their order, but not by their physical relationship to each other when presented in written form (except insofar as their layout helps to define their order). If I say "The dog chased the cat" that means something different from "The cat chased the dog." But "The dog chased the cat" means the same thing as
"The dog chased the cat."
The way you make connections between symbols that are far apart from each other in a sentence is with symbolic identity. If I say "The dog chased the cat which had stolen the dog's bone," I make a connection between the thing doing the chasing and the thing whose bone has been stolen by referring to both with the symbol "dog."
In Labview things are very very different. There is no order defined on the symbols, and connections between entities are made not by identical-looking references, but by physically drawing lines and arrows between them. It's very hard to represent Labview in ascii because ascii was designed for traditional languages, but here's my best shot at rendering the dog-and-cat example into something labview-like:
The -> dog -> chased -> the -> cat.
cat. <- the <- chased <- dog <- The
In labview, those two examples are identical. (Of course, the whole point is that by drawing arrows you can create structures that are more complex than the simple order of the cat-and-dog example, but I am not a gifted ascii artist.)
So Labview is an existence proof that you can produce the effect of "writing a program" by "drawing a picture" instead. If you let your imagination run wild you could imagine producing the same effect by playing a song, or doing a dance. And before you say, "That's ridiculous", think about motion-capture technology and Midi controllers.
> "Erik Naggum" <e...@naggum.no> wrote in message news:3243777529201772@naggum.no... > > | *That's* why I have more problems with ()'s than I ever had in Java.
> > People actually forget the pain of learning something and assume that > > when they know the first thing well, they should be able to learn the > > next thing with the same ease that they use the first thing. This is so > > horribly misguided that I fail to see how people can possibly believe it, > > but many people evidently do. I think it is because people only really > > learn one thing of each kind, the first they ever encounter, and hence > > never realize what it costs to learn anything, or they may actually fail > > at learning something and hence only accumulate simple-minded coping > > strategies in the face of repeated failure. Learning is /work/, however.
> Like I was saying before, arien's brain has not adapted yet. It literally takes > time and work that reinforces the brain's pathways. It takes time. Even if one > is extremely intelligent the brain still needs time and repeated exposure. I > think some people have extremely pliable minds and adapt quickly, but > it takes a conscious letting go of what you think you know.
> We had the perfect example of this in Canada where we officially converted > from English to Metric measurements. Many people still cannot function > (its been almost 25 years) and when they hear temperatures in Celsius, > they still have to convert from Fahrenheit. My tactic was to hear the > temperature, go outside, feel how warm or cold it was and get an > internalized experience of what it meant. I stayed away from converting, it > would not have helped in the end.
> Wade
The problem is, that the only languages I have learnt are Java and C++. Java first. Learning C++ wasn't much more difficult because the syntax is similar. Then you get lisp thrown in your face, and all these ((((((()))))))'s. I mean, a missing ; at the end of a line is easy to find, even in Notepad. The syntax of lisp makes it virtually impossible to use without a suitable editor. Now this, regardless of what you all say about how good it is, puts lisp behind the eight-ball when it comes to readability. I have sat there with my lecturer going through the code, trying to find where the error is. But like I said, Java never has this problem.
-- Mel
Please post reply to newsgroup. Reply address isn't valid.
> to readability. I have sat there with my lecturer going through the > code, trying to find where the error is. But like I said, Java never has > this problem.
> On Fri, 11 Oct 2002 12:27:48 +0930, arien <spammers_s...@getlost.invalid> > wrote:
> > Hey, I agree with them on the silly parentheses! I haven't had a single > > error yet that wasn't caused by parentheses being in the wrong spot!
> Here is some food for thought. The Lisp family of programming languages has > been around for over four decades (compare this to the average longevity of > technology fads). Some of the brightest and more creative researchers and > practitioners have worked on its design and used the language to solve > large, complex and challenging problems.
> Although there have been a number of proposals for changing the Lisp syntax > and getting rid of the parentheses, none of them caught up. Lisp has been > preserving its parentheses for a very long time.
> What does all of this suggest you?
It explains to me the reason why no one has ever heard of lisp :-)
-- Mel
Please post reply to newsgroup. Reply address isn't valid.
In article <ey3k7kgviqk....@cley.com>, t...@cley.com says...
> * Christopher Browne wrote:
> > No, the point was that it reported "bad constructs." That's exactly > > what this thread has been talking about.
> But the specific thing I followed up to was saying:
> I have always detested compilers that report things like: > ``Expected a ; found a }''
> If it is smart enough to know what ought to go there, why doesn't it > just fix it?
Because the solution may not be missing a ; at all. Although the compiler reports this, it may actually be something missing eariler in the code. Look at this Java code for example:
System.out.print ("Print this statement);
now this is just an example. When you try to compile this, it reports that a ) and ; is missing. Now, they're not missing at all. The " is missing, so the compiler leaves this up to you to intepret the problem and fix it.
But like I said, at *least* Java takes you to the line that the error has occured. The quote mark is also pretty easy to identity in any editor.
-- Mel
Please post reply to newsgroup. Reply address isn't valid.
