Path: csiph.com!usenet.pasdenom.info!gegeweb.org!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Christian Kellermann Newsgroups: comp.lang.forth Subject: Re: Request for comments on a first forth program Date: Fri, 26 Jul 2013 09:34:20 +0200 Organization: A noiseless patient Spider Lines: 85 Message-ID: <877ggddbb7.fsf@pestilenz.org> References: <87wqomga80.fsf@pestilenz.org> <26e3733d-d76f-4a4a-8b30-0f888f9bb318@googlegroups.com> <87txjpjais.fsf@necronomicon.my.domain> <2013Jul22.174305@mips.complang.tuwien.ac.at> <87fvv3c9xt.fsf@pestilenz.org> <912b40eb-9435-4b53-a32f-3fd868fdedad@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: mx05.eternal-september.org; posting-host="4ef1a003bef0ba48c3eff117c3a74ccb"; logging-data="28617"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19TIJWY3UUlENeDwoSTIjto" User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.90 (gnu/linux) Location: Nuremberg, Germany Cancel-Lock: sha1:ST6nsW/05Gt6CsYdF0c/dBlY3kI= sha1:vgZ5axbI9G/yhOpZEOsyWLX+NSE= Xref: csiph.com comp.lang.forth:24793 hughaguilar96@yahoo.com writes: > On Thursday, July 25, 2013 1:37:02 AM UTC-7, Christian Kellermann wrote: > >> hughaguilar96@yahoo.com writes: >> > As I said before, you should not initialize data-structures when >> > defining them. You should have a word INIT that initializes >> > everything. If you don't want to do a TRY and recompile the code >> > (because you haven't changed the source-code), you can just do an INIT >> > and run it again. >> >> Which data-structures are you referring to? The buffers? These are not >> meant to be resizeable once the program runs. The other magic values in >> my code that aren't set by words are constants and necessary to >> determine the memory the buffers need to hold. > > I was referring to code like this: > > variable #moves 0 #moves ! > variable #teleports 3 #teleports ! > > 2 value #robots > > You want to have a word like this: > > : init > 0 #moves ! > 3 #teleports ! > 2 to #robots > ; > > INIT gets your program back to a pristine state. That way you can test > it from a known configuration. > > As your program is currently written, you have to recompile to get > back to a known state. Compilation in Forth is quite fast, so this > isn't a terribly bad thing, and with TRY it is convenient. Still > though, it is a bad design in which you to have to recompile every > time that the program is run. Ok, I am still a bit confused about this though. How does INIT differ from RESET-GAME and/or INIT-PLAYER which sets these? Arguably #robots only gets reset in RUN but this has been quite convenient when testing… > This bit about INIT is a fairly minor point. I still think that the > best way to simplify your program is like this: > > 1.) Use structs to reduce the amount of data that you have on the > stack. For example, a struct for a point that contains X and Y > coordinates, rather than putting the X and Y data directly on the > stack. > > 2.) Use an array definer. You currently implement several arrays > manually, which tends to clutter up your source-code. You don't want > low-level code, such as array access, intermingled with your > application code --- factoring out the low-level code helps make your > application code shorter and easier to read. For larger code bases this may be true but I think this is overdoing it for this little program. Also while a REQUIRE or INCLUDE from a library makes this program shorter to read it becomes more difficult to understand as I would have to read the included source code part first, as people already had to do with the RANDOM word I used. In general I tend to agree though, abstraction is good… > If you don't yet know how to implement structs or arrays, or definer > words in general, then you can use what I have provided in the novice > package. The point of the novice package is to allow people to get > started on writing programs, without requiring them to first implement > a lot of low-level support code. Later on you will likely develop your > own package of low-level code, but that is not something that you want > to get bogged down in right now. …but I like to implement my own abstractions which I fully know and understand. To abstract things you first have to know the inner workings then you can forget about them for a while. But I guess know I am preaching to the choir. > Keep at it! Your Forth code is quite good for a first effort. :-) Thanks for your supportive comments! Christian