So being without tools is better than being with tools because that increases portability not to be dependent on anything. But I miss the Squeak debugger. What debugger do you use for fonc?
So: If you had done it in Smalltalk instead of gcc: Once you get fonc to compile on Squeak then you tell it to generate the independent fonc which doesn't use any tools and stands on its own. You retarget the Squeak assembler to each machine and try to modularize the machine dependent stuff. But I guess it's hard. Really hard. I saw an assembler in Dolphin Smalltalk that was just a big ascii table and somehow it took assembler and generated machine code. Or so said the liner notes. You have to make an assembler or assembler generator in Squeak though. But wouldn't that have been quicker to make an assembler in Squeak than have the assembler already there in gcc but then have to develope in ug gcc? C is a portable assembler. And it would be hard to make an assembler in Squeak that is as portable. Squeak generates C I guess. What is the C based development environment that you use? Is it as good as Smalltalk and by how much? Does fonc have a debugger? If fonc has a debugger inside of fonc like Smalltalk does then my mouth is shut. If not then, okay, we want to be minimal. But we need a fonc debugger that can step through all the different languages in fonc. A debugger module that you can load up if you want it. I guess I still believe that it is better to use all the tools you can and output minimality from there when you want it. But also be able to output the kitchen sink too. I guess I just dislike C and its ilk so much that I would make a Smalltalk to C translator if I could just to get out of having to compile link crash. Okay enough. I agree. It's water over the damn now. So what's the development environment you use to do fonc? On Sat, Aug 23, 2008 at 9:42 AM, Joshua Gargus <[EMAIL PROTECTED]> wrote: > I think that (part of) the point is to be able to bootstrap with minimal > tool support, and thereafter to be self-supporting. The bootstrap process > is described better than I can in Section 6.1 of "Accessible Language-Based > Environments of Recursive Theories", available on the VPRI website. C is > described as a "portable high-level assembly language". > > Cheers, > Josh > > > > > Kjell Godo wrote: > > Wouldn't this whole thing be better written in Smalltalk than in gcc? > > gcc is more portable? > > Couldn't Smalltalk output assembler that gcc could then compile? > I saw an assembler written in Smalltalk once. Hope I still have it. > It was very simple and clean looking. > > I am writting a compiler for a language called picoLARC and I am > doing the language specification in Smalltalk which compiles it to > trees of objects which are then run/evaluated by a recursive method. > I'm getting the ideas straight in Smalltalk first. > > Then I suppose I would rewrite the picoLARC system in picoLARC > on top of Smalltalk. It would be slow running but what do I care about > that? The picoLARC compiler etc gets translated into executable trees > which then translate themselves into assembler or machine language or > IL or whatever. > > These executable objects aught to be able to generate linearized > code like assembler or machine language. According to the book > Scheme in Small Pieces. > > Perhaps the executable objects could generate a C# program that > was nothing but op code generation statements and then picoLARC > could run on and access .net for windowing and stuff. Or it could > run in the browser like Vista Smalltalk( I think it's called Vista ). > > Wouldn't it be a lot easier to do fonc in Smalltalk? That way you > could map out all the VTables and everything in a quick way that > would be easy to follow. Then this Smalltalk thing could generate > assembler or whatever which could be compiled into a something > like running Smalltalk but when you open the browsers all the code > is cola jolt fonc or whatever you call it. And that thing could then > generate headless( no GUI ) executables if needed. > > Smalltalk is reflective. gcc is not. So what is the argument in favor > of gcc? Why was it chosen? Is programming in gcc faster than > programming in Smalltalk? > Easier to understand? Better documented? Self documented? > Easier to debug? > > If I could implement picoLARC on top of COLA or whatever it's called > that would be cool. But the idea of trying to program in gcc always > stops me dead. If cola or a version of cola was like Smalltalk but > removing the problems that Smalltalk has then that would be good. > > If I could make the picoLARC compiler in Cola and build up a picoLARC > that was like Smalltalk but was fast where it needed to be fast and > could access .net or the various libraries in Linux that would be good. > > I would like to request a version of Cola that can be used to make a > new language that is as fast as one made with gcc where it needs > to be fast and can access all the libraries. And that Cola would > have a Squeak like GUI that was detachable with all the browsers > in it. And it could generate all kinds of different executables in easy > ways. It could generate a VM like Squeak or a lib with no GUI. > > On 6/22/08, Ian Piumarta <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> wrote: > > > On Jun 22, 2008, at 2:41 AM, John Leuner wrote: > > > > What do you use a teletype for? > > > Backing up my sources to punched tape. > > Cheers, > Ian > > PS: if you're taking me seriously in this tread, it's time to stop. > > > _______________________________________________ > fonc mailing [EMAIL PROTECTED]://vpri.org/mailman/listinfo/fonc > > _______________________________________________ > fonc mailing [EMAIL PROTECTED]://vpri.org/mailman/listinfo/fonc > > > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
