Damon Simms

To start this page off, here are some answers: yes, no, no, and 42 (of course)

Damon Simms (talk) 17:39, 17 June 2009 (UTC)

Great answers. Looks like I was programming before you were born. I use older terms maybe that you understand differently. But we have a lot in common. Except for the Rubik's Cube. I solved it within the first hour I had it. My basic communication problem is also my strength when it comes to coding. My mind just automatically maps details of how something works. I have the Sylar supper power of knowing how things work. OK. It just might be IQ. I was tested in 8th grade to have an IQ of 186.

Sense you responded to my post in Talk MetaCompiler about bootstrapping. Why did you not reply to my more specific question on what compilers could be classed as meta compilers. I do not believe that self compiling is a significant factor. On your web site you explained bootstrapping up from entering hex through the console interface. That is exactly how we got to were we are to day. We started with computers that had to be programmed numerically by entering machine instruction directly into it's memory. Early computers had retentive memories usually magnetic core memory or drum. So programs remained when they were shut down.

Have you looked at the similarities of META II and yacc output directives. It looks like yacc could generate code directly as equally well as META II. The unique thing about META I, META II, TREEMETA, and CWIC is not that they compiled them selves. The unique thing about them is that do not use a generative descriptive language like bnf. The are defining the language. A rule is not a set of possible solutions. But an ordered list of tests to be applied to the input. And taking the first that succeeds. NOT BNF. NOT A GENERATIVE LANGUAGE SPECIFICATION. Thats basicly a PEG. Second they all produce executable code directly specified by the compiler source.

At this point. I don't think you know what you're talking about. You were not there. I knew Val Schorre and Erwin Book. Met them at SEGPLAN meetings and visited with Erwin at SDC several times when I was implementing SLIC. I had his phone ext at SDC. I didn't learn that CWIC had been classified till years later. Strange for SLIC implemented CWIC exactly except for outputting code. Code output by my generator language was pseudo code. The pseudo code could be further transformed by the ISO language before being expanded into binary machine code. I did not implement a MOL language. On the DEC-System-10 I used MACRO-10. Bliss-10 was also available. A pseudo instruction was coded in the same LISP 2 dialect used in the generator language. PSEUDO functions were not called when planted in a generator. The pseudo instruction were saved on lists and later executed.

You youngsters just think you know everything!!

It seams we both are prejudiced on the subject of meta compilers. The META xx compiler are becoming better known. I do not know many people that know CWIC. And those that do have written meta compilers. Erwin book worked on the LISP 2 project at SDC. He brought that to CWIC. CWIC is basically a full implementation of LISP 2 combined with META compilers written by Val Schorre. Very close to TREEMATA. The syntax included new back tracking alternate // operator and list making operators < >. The meta compilers can process context sensitive languages. In CWIC one can implement any type of parser. What parsers that can not be programmed in the syntax language could be done in the LISP 2 generator language.

I makes me angry that this technology seams to have been lost by the top secret classification of CWIC in the early 70s. My contribution to the META compilers was the assembler defining language. It allows any instruction to be defined as fields in a bit addressable memory space. Most assembly operand syntax of the day could be specified. Work is needed in the operand syntax area to cover using square brackets [ ] index and scaled indexing of new assemblers. Maybe segment registers. Mostly changes for the intel chips.

The first PASCAL compiler I wrote in PASCAL was ran on a P-code interpreter. The P-code interpreter machine was first written and then the PASCAL compiler was written in PASCAL and hand compiled into P-code. That compiler was changed to produce machine code and used to compile it's self into machine code. The machine code compiler was used to maintain the PASCAL compiler and implement code generators for many target processors. The compiler is written in it's own language and compiles it's self. What separates a meta compiler from the PASCAL compiler described. The feature that sets a metacompiler apart from a standard compiler-compiler is that a metacompiler is written in its own language and translates itself. OK by the definition the PASCAL described is a MetaCompiler. NOT!!!

There is no computer science reference any ware on that page to that definition.

--Steamerandy (talk) 00:41, 7 October 2014 (UTC)

Hey Andy -- if you bothered to check the first reference on the Metacompiler page, you would see Dr. Neighbors thesis project is built on metacompiler technology, and that website has a complete tutorial on metacompilers. Here are some other references:

http://www.bayfronttechnologies.com/mc_tutorial.html

http://dictionary.reference.com/browse/cwic -- "One of the early metacompilers."

http://www.forthfreak.net/index.cgi?MetaCompiler

"meta: (greek) A prefix, meaning 'one level of description higher'"

"A metacompiler is a compiler which processes its own source code, resulting in an executable version of itself. Many Forth-systems have been written as metacompilers."

http://www.forthfreak.net/index.cgi?MetaStic

"MetaStic is the reimplementation of Elastic (which was written in assembly language) as metacompiler. It differs from other Forth metacompilers in that respect that it does not implement a Forth system, which can be extended to become the meta compiler. It rather implements a meta compiler, which can be extended to become Forth. The minimal system (the kernel) can metacompile without any additions."

http://archive.org/stream/gpglmodelinterac00bean/gpglmodelinterac00bean_djvu.txt -- "GPGL: A Model Interactive, General Purpose Graphic Language ", James Dale Beans, Thesis, Naval Postgraduate School, December, 1971.

"More recently, graphic languages have also used metacompilers, compilers, interpreters, and subroutine calls."

http://archive.org/stream/graftrangraphice00elki/graftrangraphice00elki_djvu.txt -- GRAPHTRAN: Graphic Extensions to Fortran, David R. Elkins, Naval Postgraduate School, December, 1972.

"Kulsrud further proposed that the GPGL compiler be constructed through the use of a meta-compiler in order that it may be implemented on various hardware configurations"

And as I've related elsewhere, I know of other implementations of metacompilers in private industry that are based on completely different approaches from the recursive-descent parsers of the Meta family of compilers.

"Metacompiler" is an accepted term of art in Computer Science and compiler technology, independent from the work of Schorre et al.

02:47, 8 October 2014 (UTC)

Hay metayou

metayou means yourself right? It should sense meta means self to FORTH freaks.

http://www.bayfronttechnologies.com/mc_tutorial.html

Is a tutorial on META II. Schorre meta compiler.

http://dictionary.reference.com/browse/cwic -- "One of the early metacompilers."

CWIC was about the last of the Schorre metacompilers.

http://www.forthfreak.net/index.cgi?MetaCompiler

"meta: (greek) A prefix, meaning 'one level of description higher'"

The so called FORTH metacompiler one level of description higher is false. The forth self-compilation happens from the lowest level of FORTH that is able to define new words

"A metacompiler is a compiler which processes its own source code, resulting in an executable version of itself. Many Forth-systems have been written as metacompilers."

A misguided concept of self-hosting compilers being metacompilers. Acceptance of such would mean that every self-hosting compiler is a metacompiler.

http://www.forthfreak.net/index.cgi?MetaStic

"MetaStic is the reimplementation of Elastic (which was written in assembly language) as metacompiler. It differs from other Forth metacompilers in that respect that it does not implement a Forth system, which can be extended to become the meta compiler. It rather implements a meta compiler, which can be extended to become Forth. The minimal system (the kernel) can metacompile without any additions."

Again a self-hosting compiler starting at the lowest level of able to define new words.

FORTH is not a metacompiler recognized in Computer Science. And for good reason. It is a self hosting compilers. I think I found the confusion that may have started this. In some definitions of meta the meaning about (its own category). Is stated as self referencing. The description and examples are the same. Metadata is date describing data. "self referencing" meams about its own category. A so metacompiler has been misinterpreted to mean self compiler. Which is a self-hosting compiler. metacompiler in no way means self-hosting compiler as FORTH has misused the term metacompiler for over 40 years. It would corrupt the meaning of metacompiler to include all self-hosting compilers. The first usage of metacompiler in conection with FORTH was on the FORTHinc site promoting the sales of FORTH systems. It was advertising crap promoting FORTH product sails.

The invalid references to FORTH being a mertacompiler will be deleted. It is not in common use by real computer scientists. Not used anywhere except by FORTH fanatics.

http://archive.org/stream/gpglmodelinterac00bean/gpglmodelinterac00bean_djvu.txt -- "GPGL: A Model Interactive, General Purpose Graphic Language ", James Dale Beans, Thesis, Naval Postgraduate School, December, 1971.

"More recently, graphic languages have also used metacompilers, compilers, interpreters, and subroutine calls."

the GPGL metacompiler was written in PL/1. Not it's self proving that self compilation is not required to be a metacompiler.

The misguided FORTH metacompiler concept of self compilation will be deleted.

http://archive.org/stream/graftrangraphice00elki/graftrangraphice00elki_djvu.txt -- GRAPHTRAN: Graphic Extensions to Fortran, David R. Elkins, Naval Postgraduate School, December, 1972.

"Kulsrud further proposed that the GPGL compiler be constructed through the use of a meta-compiler in order that it may be implemented on various hardware configurations"

The metacompiler was written in PL/1. Again a metacompiler that does not compile it's self.

Your misguided claim that a metacompile compiles it self is a feature that sets it a part from other compiler compilers is wrong and will be deleted.

And as I've related elsewhere, I know of other implementations of metacompilers in private industry that are based on completely different approaches from the recursive-descent parsers of the Meta family of compilers.

put up or shutup. You have put nothing forth, well, except FORTH. Unless they produce a compiler for other then the language they are written in they are not a compiler compiler and therefore not a metacompiler compiler sense a metacompiler is a type of compiler compiler.

I have never claimed that Schorre metacompiler are the only type of metacompiler. yacc is claimed to be a metacompiler. And the only metacompiler you seam to be putting forth are simply self-hosting compilers that can not be allowed to muck up a proper definition of a metacompiler.

BOOK1 and BOOK2 were meta compilers written in LISP. They were not Schorre metacompilers. The compiler-building system developed by Brooker and Morris was a metacompiler written in CL/1.

Many metacompiler are not written in their own language. Nor do they compile the language the metacompiler is written in.

metacompiler does not mean self compilation, Never has. Except by mislead FORTH advocates.

I now wonder if you have the credentials that you claim. According to your contribution history you have done vary little outside of metacompilers. You erroneously changed the term "unparse" in TREEMETA to non-parse. Just how ignorant are you. You could of checked the TREEMETA manuals and found about unparse rules. You have this misguided concept that FORTH is a metacompiler. It was well explained in ACM documents what a metacompiler is. Technical term references say that a metacompiler is for creating compilers for other programming languages. NOTE. COMPILERS and LANGUAGES being plural. Meaning that a metacompiler creates many different compilers for different languages. They are not for creating just a single compiler that is for the language the compiler is written in.

I have fired people having higher degrees over people having no degrees or associate degrees. Simply a mater of who could do the job. By the way Dumb Ass I was addressed as Dr. Andy at my last four job positions.

And by the way CWIC was never classified. Another vary active editor here, who worked on CWIC at SDC, informed me it was never classified as rumoured. It was simple classed internally as preparatory technology by SDC.

So either come back to the table on this or I must assume that you are a FORTH freak trying to legitimize FORTH as a metacompiler (Which it is not!!!). And that you have abandoned the topic, your devious plot now exposed.

Can we work this out

Hello Damon.

Maybe I was wrong about you. It seamed to me that you were trying to push the Forth idea of FORTH being a meta compiler. In no way is forth a meta compiler. It does not take a language description as inpout. It simply compiles vocabulary extending it's self from a vary basic set of words. If it is included then you would have to include all extensible languages. Lisp for one. You would not mind if I put LISP up as an example of a metacompiler would you? It compiles it's self in the same way that Forth does. It starts with a minimal set of actions and defines it's self building on predefined actions. If you allow metacompilers that do not take a language description into the metacompiler club. Then the PASCAL compilers would also be included. The PASCAL compiler I and others developed was changed to make ADA and MODULA compilers. We still generated the same intermediate trees that went to the code generator. We started with a subset of PASCAL and incrementally added features to arrive at an extended PASCAL.

But if it is the case you are a forth freak trying to push forth as a meta compiler I have a bunch of old associates and friends that think forth is a fools version of lisp. They would be glad to know that lisp is a metacompiler. several have claimed lisp is a metacompiler because of forths clame. Thanks for reminding me. I had forgot all about this forth crap.

Extensible languages like forth and lisp all have the same problem. Everyone creates their own dialect. And then they are no longer compatible with each other. It all but destroyed lisp.

That is also a problem with metacompilers. TREEMETA uses [2] to make a 2 element tree while CWIC uses !2.

This acting like children is getting us no ware.

I am just as fanatical about forth not being a meta compiler as the forth freaks are about forth. I actually implemented a forth like language in lisp on the DEC-10.

I have thought about buying the Dragon Book for reference. I lost a lot of books when our washer flooded the garage right after moving and my books were boxed up in the garage. I have only replaced a few.

But the thing is: there are many meta compilers that were not written in them selves. Even in the early Schorre line the lexical function were written in assembly. There were meta compilers developed with CL-I on IBM 7090 computers. There is a wealth of information in the book "PROGRAMMING SYSTEMS & LANGUAGES" COMPUTER SCIENCE SERIES McGRAW-HILL, Saul Rosen. There are early meta compilers that do not call them selves meta compilers. One in the Saul Rosen book (page 332) has three languages: BNF GSL and MDL and was writen in CL-I on a 7090 and cross compiled to a CDC 1604 computer. Not by cross compiling it's self but by cross compiling the language it was written in. It does not call it's self a meta compiler. That was before 1967 as the book was published in 1967. There is no mention in that book on Schorre meta compilers. That meta compiler is a completely different type of metacompiler taking BNF syntax language description. The MDL language is a machine description langauge. GDL is a generator description language. It also had an in sequence optimizer phase. It had the same phases I implemented in my SLIC compiler compiler.

I went to Cerritos Collage in Norwalk Calif. I had professors offering me an A in computer courses for not showing up. I was just asking questions I was asked in lab class by other students. But that intimidated some of them. I left Collage in 1973 for a 40k job with Ramada Inns developing their reservation system. That was more then my professors were making. I left Cerritos with written acknowledgement of rights to SLIC that I had written on my own time. My job at Ramada Inns was to supervise and make changes to the TOPS-10 operatoring system. The main thing that was being added to TOPS-10 was a raid system for the reservation data base. John More And Rick Copland were doing the RAID changes and only needed vary minor help. They were both top notch programmers. John is the one who wrote the two call stack tree balancing routine. I left Ramada at the completion of reservation system development to work for Digital Equipment Corporation. DEC got me the Job at Ramada.

I really favor the CWIC type of meta compiler. I have never used the earlier Schorre metacompilers. META II is basically a toy compared to CWIC. Maybe it was the classification of TOP Secret Sensitive Technology put on CWIC development to lost their momentum. yacc came out about that time and took over compiler development. We do not know why CWIC was classified. If you look at computer language development around that time the government was pushing hard for a single language platform for all government sites. When I went to work for DEC the U.S. ARMY was restricted to using COBOL and FORTRAN, requiring a great effort to get aprovel to use any other language. At CDEC Fort Hunter Legit Calif where I first worked for DEC they had to use assembly for several projects. The justification documentation was a 2" thick paper. Various portable computers used there only had assembly available. I wonder if CWIC weren't classified to slow down compiler development. From what I can find out not much development was done on CWIC after it was classified.

The differences between CWIC and SLIC are mostly for readability. CWIC could perform tree/list manipulations accomplishing similar optimizations. It's binary output was simplistic building instructions by adding fields. My machine operation language specified the bit size of instruction fields and detected over flow errors when valuers were to large for the field. I also added DEC linker technology having expressions evaluated at link time using polish fix up blocks. The IBM linker didn't have that ability.

I really do not know how to classify the parser of CWIC and SLIC. They are basically TOP down and BOTTOM up at the same time. You have lexical rules that are bottom up and syntax rules that are TOP down. These parsers are not recursive decent in the same sense, a recursive decent parser is defined by compiler theory. You do not have the tree levels that are taught in compiler courses today. What you have is a functional expression tree. You have symbols in a symbol table that have attributes. The tree structure it's self does not contain attributes. I am looking at adding attributes to nodes in cc. In the PASCAL compiler we generated node lists (a tree having any number of elements) for terms and factors and the elements sorted by data size lowest to highest. The node contained the highest calculation precision. That way calculations were done at the least precision necessary and only upconverted as higher precision elements were processed.

About the last time I spoke with Erwin Book they were finishing up a complete implementation of PL/1 in CWIC. These were real compiler writing tools. Not toys like META II. Very optimized code was being generated. The COBOL compiler written in SLIC was faster then the DEC COBOL compiler in number of lines per minuet by 10 to 25 percent. And was producing as good or better optimized code. These compilers had extensive backtracking. These were far more powerful compiler writing tools then the yacc shit and it's breed.

There were not enough SegForth members to sustain it as a ACM special interest group. When SegPlan dropped their support all of SegForth was removed from the ACM and went to some Forth archive. The only remnants left are in SegPlan and general ACM papers and notices. The Forth user group made up only about 3% of the SegPlan membership. So why would the small Forth fringe group be allowed to change the definition of metacompiler.

The metacompilers I like are programming languages. And I recognize that there are many that are not.

Have you done the Jim Neighbors META II tutorial? I do not really care to learn META II. Any more then what I have already learned to contribute to the metacompiler topic. I learned CWIC and have no reason to learn an earlier inferior flavor. CWIC is a better compiler writing tool then any of the yacc based tools. It handles context sensitive languages as well as context free languages. It has that extensive look ahead feature that is only limited by memory constraints. On most of today's computers that is an entire program.

If you are really serious about helping develop cc email me at hotmail or gmail. You already have what you need to email me and should be able to figure out how to email me.

I am still gathering metacompiler history. And already there are three metacompilers that were written in languages other then them selves, One an assembly codded META II based metacompiler and two written in LISP. You gave me one that was written in PL/1.

The only people that are clamoring that a metacompiler compiles it's self are the forth freaks. All the real metacompilers have a complete transformation from input to output. Not half a compiler like yacc that only describe syntax and do not even provide much in the way of specifying the output form. Most generate tables that is then processed by a parser algorithm written in C or C++.

If we look at how CWIC defines an expersion:

expr = term $(('+'|'-') term);

That is not a recursive rule. It loops. It can be written using right recursion. Doing so would not change what is matched. It matches a single term or a series of turms seperated by a + or - operator. In the above form there would be no output produced. When producing a tree it is usually a form of polish prefix functional notation.

expr = term $(('+':ADD|'-':SUB) term!2);

If we give that rule the expression a+b. Term would recognize a and put it on the parse stack. The '+':ADD recognizes the + and puts ADD on the node stack. And b is recognized by term and pushed on the parse stack. Finally !2 removes the top 2 parse stack entries and combines them, poping the top element node stack entry to form a list [ADD, a, b]. A node is an object type and default output would display as ADD[a,b]. We do not have the intermediate tree elements that are produced by a yacc parser. We do not have extra shit in the generated tree structure to process when generating code. The compiler processes the tree in less cycles not having to traverse extra tree nodes. Usually tree structures are dynamically allocated and not allocating extraneous tree nodes is avoided. More saved processor cycles.

Have you taking a compiler course?

Yes these metacompilers are special to me. And rightly so. I am not sure why these didn't go mainstream. Maybe because CWIC was classified sensitive technology. Maybe because UNIX spread to universities and came with yacc. That is what students and professors knew. So became the foundation. With many books written and elaborate parser techniques devised to get around the problems with yacc. The proper pronunciation of yacc should be yuck. META II is not all that much different then yacc.

War or Peace

Andy

Don't be a baby

Either you are a forth freek or not. I really do not care.

If however you are not a forth freak and serious about teaching about real metacompilers you might learn something from me. The metacompiler I wrote was used by a few students (admittedly the best of the crop) to write compilers. It didn't take them 4 or 5 weeks to learn to write a compiler as seams to be the norm in the compiler writing courses today. And that 4 or 5 weeks is a group of 4 or 5 students all coding different parts of a compiler. The students I showed SLIC to at Cerritos were writing compilers usually by the next day and in less then a week were improving the code produced in most cases to to a level close to directly coded assembly. I am not talking about a group but individual writing a compiler. The thing I posted from the CWIC paper is absolutely true. These compiler do make it practical to start a project with a language design. In 1970 it described domain specific languages. So if your are really serious about teaching metacompilers at least go through the intro to mata compilers on James Neighbors site.

At Ramada Inns RaY Work pretty much wrote the COBOL cross compiler in SLIC by him self. I coded the TI990 machine instruction set in the MACHOP language. And a few of the pseudo instruction mostly for testing the machine code generation. That was like a days work. If I had been familiar with the TI990 it wouldn't have taken near as long. Ray did most of the rest with minimal help from me. I was busy modifying the communications protocol to talk with a venders terminal concentrator we planed to use in the reservation center. We managed to cause probably the first denial of service in the world. The reservation center was in Omaha Nebraska. Were the SAC headquarters was at the time. All the phone trunks ran through Ohma. Or reservation system was a dial up system then. Mid 70s. We had about 1000 installed hotels. The TI990 computers were programed to call in at midnight to get any undelivered messages. They were actually staggered around local time. We had lease lines from Phoenix to Omaha. WATs lines were cheep in Omaha because SAC was there (why all trunk lines ran there), Anyway The denial of services was on the phone lines. The message concentrator (answered the data phone lines and forwarded messages to the DEC-10 in Phoenix) in Omaha crashed and nobody to answer the 1000 phone calls that came every 15 seconds. The front office terminals were programed to call back in 15 seconds if the call didn't get answered. When I came in to work the place was surrounded by black SUVs and military standing guard. around the computer center. We shut the US phone system down for several hours.

Just to point out your self hosting was being the defining feature is not true.

I put up history of meta compilers that were not self hosted. One was in assembly for speed. Another was used in analyzing it's recursive decent parsing. So it had extra data collection code that could not be specified in it's self. TWO others were written in LISP. And the graphics application metacompiler you supplied the link to that was written in PL/1. It shows that you forth freak wording of compiling it's self being the meta step is not the case. That is five separate instances of meta compiler not written them selves. Schorre was active in SegForth and wrote several papers. He does not consider forth to be a meta compiler. --Steamerandy (talk) 09:46, 1 November 2014 (UTC)

RFC position

The Forth concept of a metacompiler has never been accepted in mainstream Computer Science. I have did a lot of research on this subject. Forth qualifies as metaprogramming. It even modifies it's self on the fly. It was claimed at one time not to be a language. I do not have a problem with FORTH as a programming language. I like RPN. I like stack languages. But that doesn't equate to acceptance of the forth concept of a metacompiler. It is no more then a self-hosting extensible language. Whet it calls a metacompiler qualifies as metaprogramming. But not all metaprogramming qualifies to be a metacompiler.

The compiling it's self is not a defining feature. And just because someone or group claims something to be a metacompiler (meta compiler) does not make it one.

In Computer Science the prefix meta commonly means about. But you like the one step above meaning. That does not work for FORTH. The "FORTH metacompiler" is a step below FORTH. It is the minim subset of FORTH words required to compile FORTH. It is not a COMPLETE FORTH implementation. It's a minimum subset that thru metaprogramming extends it's self into a full implementation of FORTH. A metacompiler is on a level of abstraction above the compiler it is compiling. Who ever came up with FORTH being a metacompiler did nit understand the prefix meta. Meta can mean "change". But not in Computer Science Circles. I have conferred with a couple of professors specializing in compilers and programming languages and they agree. Their undergrads teaching compiler writing also agree. A matecompiler compiling it's self is not an important feature of a compiler. It doesn't distinguish it from other compiler compilers and most compiler compiler systems compile themselves. It was pointed out to me that BISON and YACC compile themselves. By the way of you actually looked at yacc you can see that it has semantic production that work similar to META II. META II and yacc are on the same level with productions embedded in the syntax analysis rules. TREEMETA is a big improvement generating tree structures and calling a unparse rule on the tree

Your clumsy linking to Formal Grammar and Production Rules shows you do not understand what grammars are in Computer Science.

Compiling themselves is the least amazing thing about a metacompiler. You choose to ignore the fact that there are metacompilers that do not compile themselves. Look at the history of metacompilers I documented. There is a recent graphical metacompiler that does not compile it's self. You can write parsing rules and code producing blocks or simply use drag and drop pre codded blocks. It is written in c++ and several web languages. Some Java code and PHP.

How about it are you ready to come to the table on this.

I suppose that you should get full credit for clamming that a "being self-hosting compiler is the defining feature that sets it a part from other compiler compilers". --Steamerandy (talk) 20:18, 13 November 2014 (UTC)

FORTH is a real metacompiler

Hey DAMON I have edited metacompiler page. Take a look. It does not include you absurd concept that compiling it's self makes it a metacompiler. Just read it and find out why FORTH is a metacompiler written in a metaprogramming language. You wont FORTH to be a metacompiler? OK. Check out how it really is a metacompiler. Hope you like this. You should have came to the table and worked with me.

I might have figured this a lot quicker. There is a big difference in our IQs. I solved RUBICs CUBE in less then an HOUR. Not months. I was clinically tested as having an IQ of 186 in the 8th grade. You may have a bigger dick. But I have a higher functioning brain. I use both sides of my brain. Find FORTH documents on right brain thinking.

So check out my grammar and typo error if you please.

Andy--Steamerandy (talk) 16:58, 18 November 2014 (UTC)

RfC on metacompiler

I left a message in response to the RfC on the talk page about metacompiler. PizzaMan (♨♨) 22:20, 2 December 2014 (UTC)