Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Jeff Higgins Newsgroups: comp.lang.java.programmer Subject: Re: questions re Javascript Date: Fri, 25 Sep 2015 17:13:27 -0400 Organization: A noiseless patient Spider Lines: 239 Message-ID: References: <83722e36-4afe-4077-b936-229450613698@googlegroups.com> <47d69c57-6ce4-4f35-9e14-a348a3fbf1f7@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Fri, 25 Sep 2015 21:13:18 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="a78aad8b483612fbf45d18e918df0cca"; logging-data="22404"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19kcweaTRq5SRUc0dUNsP72BariLBJCCbY=" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 In-Reply-To: Cancel-Lock: sha1:Z2EPPX6Fuq+OywumjM1ZjxnKPig= Xref: csiph.com comp.lang.java.programmer:32709 On 09/25/2015 03:59 PM, Martin Gregorie wrote: > On Fri, 25 Sep 2015 14:03:55 -0400, Jeff Higgins wrote: > >> On 09/25/2015 01:00 PM, Martin Gregorie wrote: >>> On Fri, 25 Sep 2015 12:30:22 +0100, Eternal Hope wrote: >>> >>>> On 25/09/2015 12:17, Martin Gregorie wrote: >>>>> On Thu, 24 Sep 2015 20:55:59 -0400, Jerry Stuckle wrote: >>>>> >>>>>> Again - let's see you build the hardware. Then maybe we can discuss >>>>>> it. >>>>>> >>>>> Its already been done. https://en.wikipedia.org/wiki/Java_processor >>>>> >>>>> Or, just find a Jazelle chip or Javelin device and use that. Parallax >>>>> sold the Javelin. Physically they were very similar to their BS2 >>>>> STAMP. >>>>> However, they did that quite a while back, so it will be Java 1 or 2 >>>>> at the most. >>>>> >>>>> There's an interesting discussion in this reference: http:// >>>>> www.jopdesign.com/doc/jhal.pdf I just skimmed it, but it looks as >>>>> though they've had at least one HW implementation running. >>>>> >>>>> In any case, what does seeing a hardware implementation have to do >>>>> with a thread about clarifying natural language definitions and their >>>>> associated semantics? >>>> >>>> Splutter !!! >>>> >>>> You bought it up in the first place Martin. and you haven't yet >>>> answered the quastion about how your byte code gets translated into >>>> binary numbers ... how does that happen ? >>>> >>> How do you work that out? I did explicitly NOT make a distinction >>> between bytecode compilers and machine code compilers: indeed GCJ can >>> generate both. Pretty much at the start of all this, I said two things: >>> >>> 1) that you can define a high-level 'compiled language' as one where >>> a program, usually known as a 'compiler', must be used to translate >>> the human readable source code into something more computer >>> friendly before it can be run and that an interpreted language does >>> not have an explicit compilation step. >>> >>> 2) that compilers or assemblers that can directly generate executable >>> code without the aid of a linker are rare in my experience and that >>> I knew three cases (6800 assemblers, PL/9 and Elliott 503 Algol) of >>> compiled languages that don't use a linker in the sense of a >>> post-processor for compiler output. >>> >>> I should have included Java in this list since it too lacks an >>> explicit linkage stage that must be completed before attempting to >>> run the compiled code: my mistake. I suppose any system that can >>> run relocatable binary code can let the runtime loader handle >>> fixing up inter-module links. The JVM's loader does this and IIRC >>> so do the loaders used by IBM's OS/400 and ICL's VME/B >>> >>> I have always heard the phrase 'interpreted languages' used to describe >>> the case where source code is apparently executed directly without any >>> explicit compilation stage. Examples are Perl, awk and command-line >>> interpreters, e.g. bash or command.exe >>> >>> >> There are a dozen or so products described by their suppliers as C >> interpreters. Does this mean that C is an interpreted language? >> > The common C versions (K&R C, ANSI C and its derivative, C++) are > definitely compiled languages using a complex, multi-phase compiler. > 'cc' itself is just a shell to run the appropriate compilation phases in > the required order: > - preprocessor (a macrogenerator: it expands macro definitions, > and #defines, uses #ifdef statements to control what > parts of the source files are fed to the compiler > - assembly language generator (translates C source to the native > assembler) > - optimiser (applies the requested optimisations (inlining code, > unrolling loops etc) > - assembler > - linker > > How much of this you're aware of during a compilation depends on the > actual compiler. For instance: > > - GNU C looks and acts like a single unitary slab most of the time > > - Microware K&R C compiler for OS-9 showed all the phases as they > were run. > > - most Unices, which include Linux and BSD, also have the 'ar' tool, > which is used to build code libraries, and 'make', which does much > the same job as 'ant'. > > Other OSen have equivalent tools. > > However, there is an interpreted language, Tiny C, which is purely > interpreted. It dates from the time when an Intel 8080 was considered a > desirable mpu. Tiny C was really an IDE, being a combined > editor,compiler,interpreter - in short, very similar to a traditional > BASIC. > > Tiny C claimed to be a very small (integer) subset of C, but in fact > doesn't look a lot like it. Here's 'hello World' in tiny C: > > hello-world [ > pl "Hello, world" > ] > > and here's the equivalent in ANSI C: > > /* HELLO.C - compiler test piece */ > > #include > > int main(int argc, char **argv) > { > printf("Hello, C world\n"); > return(0); > } > >> That these products are not really C language products? >> > Does Tiny C look anything like the product you were thinking of? Well if it will not interpret the C language then no. The first hit for c+interpreter was "Ch is a C/C++ interpreter and scripting language environment" Which promises: from a command shell on several operating systems Ch supports all features in the ISO C standard called C90 which was ratified in 1990. #include int main() { printf("Hello, world\n"); return 0; } The output is: Hello, world > >> That somehow behind the scenes these products are really C >> language compilers masquerading as C interpreters? >> > I would say not, though of course people can and do use Eclipse for C > development, which would make it all look a lot different from the way I > develop C. But then, I develop C using a traditional multi-buffered > editor (microEmacs) plus make, GNU C ar and cvs for version control. I > run the lot from two or three console windows and command lines. > >> Something else? Does it make sense to >> declare a language as only either a compiled language or an interpreted >> language? >> > I think mostly yes, if only because interpreted languages tend to be much > terser and use untyped variables both of which make them easier and > quicker to enter and edit. I guess that it might make sense as a matter of convenience. I suppose I am most put-off by such absolute statements as Java is a compiled language. Java is an interpreted language. Clearly one could produce a compiler that outputs an executable ELF, COFF or whatever. And a you pointed out there have been working examples of systems on a chip that would run bytecode from a Jave bytecode compiler. Java language source code interpreted line by line? Not so sure of that, but Java 9 promises an REPL. Interpretation of HLL code line by line by some shell is a definition of interpretation? Some others in this thread have stated their definition of interpretation as the output of Javac running in a JVM. > >> Are there any programming languages that one strictly cannot >> compile or interpret? >> > Don't know. Strongly typed languages may be a pain to interpret line by > line as they're entered (think JOSS or Forth here) simply because you'll > probably have to enter the whole program and enter 'RUN' before type > mismatches etc get found and reported. > > I have a feeling that the ones that claim to be both will be organised > rather like traditional BASIC or Python, i.e. a combination of editor/IDE, > P-code compiler and interpreter. If you run these in interactive mode > they just a source editor until you enter the RUN command to cause a > compile-and-go. If the compile is successful, the program is run and > after it ends or fails you're back in the editor. If you run it as a > command (basic myprog.bas) then it will read in the file, do a command- > and-go and return errors and/or results to the console. > >> Somehow it makes more sense to me to say that a >> particular programming language is usually compiled to some form of >> native machine language, or is more usually interpreted by some virtual >> machine running on a native machine. I'm by far no C expert but I do >> seem to recall a C standard somehow referring to a virtual machine. >> > Agreed. Those that work both ways are fairly rare, especially if they > aren't IDE-like. Sorry to keep dragging up old systems, but about the > only ones, apart from various BASICs and JOSS, that worked this way that > I know about were the command processors for ICL's VME/B and IBM's > OS/400 operating systems. Both worked similarly and both used strongly > typed command languages, so error detection was excellent: > > - If you typed in a command it ran it and prompted for another > > - if you entered the command name and hit a special key, you got a > fullscreen prompt showing command names and boxes alongside each to > fill in. Default values were shown and could be overtyped. > Hitting ENTER ran the completed command. > > - if you started an editor and used it to write a command script, > you set up a header with argument names, types and defaults, typed > in the commands, loops and conditionals etc and closed the file. > > Under OS/400 you compiled it by running CRTCLPGM and fixed errors > like any other program before you could run your new command. > CRTCLPGM looks horrid but is a shortened form of "Create Command > Language Program" but is easier to remember than you'd expect. Yes, > CRTCPGM was the C compiler and CRTPLIPGM was the PL/I compiler. > > Under VME/B you simply issued the filename as a command, which tried > a compile-and-go. If it compiled, it would run. If not, you fixed > errors and tried again. > > Under both OS/400 and VME/B your new command worked just like a built-in > one: you could run it from a command line, cause it to do a full screen > prompt for arguments, or call it from another command file. > >