Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #14525

Re: pop quiz for Forth novices

Show all headers | View raw

Alex McDonald <blog@rivadpm.com> writes:

> On Jun 15, 3:22 pm, Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
>> On Jun 15, 2:50 pm, Alex McDonald <b...@rivadpm.com> wrote:
>> > On Jun 15, 2:10 pm, Hugh Aguilar <hughaguila...@yahoo.com> wrote:
>> > > On Jun 15, 3:52 am, Alex McDonald <b...@rivadpm.com> wrote:
>> > > > On Jun 15, 1:03 am, Hugh Aguilar <hughaguila...@yahoo.com> wrote:
>> > > > > On Jun 14, 12:01 am, Julian Fondren <ayrn...@gmail.com> wrote:
>>
>> > > > > > Your proposal here is identical to your initial proposal, except that
>> > > > > > you've dropped your example from Current Practice, except that you've
>> > > > > > changed the name of the word.  So you've just ignored all of the
>> > > > > > discussion about it, the distinction that was made between ALLOCATION
>> > > > > > and ALLOCATED , the discussion of some current practice, of some
>> > > > > > implementation strategies.
>>
>> > > > > I already said that what I'm presenting here is identical to what what
>> > > > > was presented and rejected earlier.
>>
>> > > > > I'm not ignoring the distinction between ALLOCATION (what was
>> > > > > requested of ALLOCATE or RESIZE) and ALLOCATED (what was actually
>> > > > > allocated, which would be >= to what was requested) --- I just don't
>> > > > > think the distinction is particularly important. The whole point of
>> > > > > this was to support CLONE-LIST. I have lists which have nodes of
>> > > > > various types. To make a copy of the list, I need to be able to
>> > > > > determine the size of each node because CMOVE> needs this size. I
>> > > > > don't really care if the size I get from ALLOCATION is the same size
>> > > > > that I originally requested, or is slightly larger, because CMOVE>
>> > > > > will work either way. CMOVE> might be slightly slower if it is copying
>> > > > > not only the data but a "tail" of garbage as well, but that is not an
>> > > > > issue to me.
>>
>> > > > > Currently in the novice package, I have rewritten all of the heap
>> > > > > memory words. The language is badly designed, else the application
>> > > > > programmer wouldn't be required to rewrite the basic functionality of
>> > > > > the language in order to support something as basic as linked lists. I
>> > > > > think the reason why there are so few Forth applications, is because
>> > > > > the Forthers spend way too much time dinking around with low-level
>> > > > > code that should have been provided already. This is also why Forth
>> > > > > applications are often hard to read --- because everybody implements
>> > > > > the low-level code differently from each other, and the programs seem
>> > > > > to be written in different languages --- "if you've seen one Forth,
>> > > > > you've seen one Forth."
>>
>> > > > > Keeping track of the size of the nodes when the nodes are created,
>> > > > > doesn't work very well. The constructor for the node must call the
>> > > > > constructor for the parent type first. That parent constructor sets
>> > > > > the node-size field in the node to the wrong value (too small). The
>> > > > > constructor then has to manually fix this node-size field with the
>> > > > > correct size. That is the way that I did it originally, and it was a
>> > > > > huge hassle. It was error-prone because I could easily write a
>> > > > > constructor and forget to do this manual fix-up, and not know about
>> > > > > this bug until later on when (if) I tried to run CLONE-LIST on the
>> > > > > list containing the node and failed to copy the entire node. Forcing
>> > > > > the application programmer to do this manually is just clumsy --- this
>> > > > > is low-level code that should be part of the language.
>>
>> > > > This is a fundamental design problem in your code, not a problem with
>> > > > the memory allocation words that Forth provides.
>>
>> > > > Many systems (Linux, BSD, every version of IBM mainframe systems to z/
>> > > > OS and others) do not provide any mechanism for discovering this
>> > > > length information. Here are the standard Linux kernel calls;
>>
>> > > > void *kmalloc( size_t size, int flags );
>> > > > void kfree( const void *objp );
>>
>> > > > There isn't any way of getting what you want from the system.
>>
>> > > > Effectively, what you are trying to do is push off a problem in your
>> > > > application code to a layer below you. That's not the correct
>> > > > response, which should be either to (1) redesign to remove the problem
>> > > > or (2) wrap the memory allocation functions -- effectively write your
>> > > > own, as you have done -- to store the information your application
>> > > > needs. That doesn't require an addition to the language
>> > > > specification.
>>
>> > > And the first B grade goes to --- Alex McDonald!
>>
>> > > I said at the beginning that my RfD violated *two* fundamental
>> > > principles of Forth-200x. This is the first principle violated:
>>
>> > > 1.) Gforth is written in C, and therefore it necessarily must have the
>> > > same limitations as C. The heap in C doesn't provide an ALLOCATION
>> > > function, and therefore the heap in Forth can't either.
>>
>> > > The fundamental disagreement between myself and Anton Ertl, is that he
>> > > believes that Forth is a toy interpreter written in C, and I believe
>> > > that Forth is a real language that is *better* than C. This is why he
>> > > gives me an F grade in Forth-200x.
>>
>> > You are sadly mistaken on several counts. There is no mechanism to get
>> > such information from many systems; please show me a system call that
>> > returns the information (specifically, the length allocated). Windows,
>> > BSD, Linux's SLAB SLOB SLUB.
>>
>> > I would like to see where Anton has ever said that Forth is a toy
>> > interpreter; or are you making stuff up again?
>>
>> > > > There isn't any way of getting what you want from the system.
>>
>> > > What a loser mentality! This reminds me of the old joke about the guy
>> > > who asked for directions to his goal and was told: "You can't get
>> > > there from here."
>>
>> > > Other languages run under these same systems (BSD, Linux, Windows,
>> > > etc.), and yet they work just fine. Factor, for example, has its own
>> > > heap system --- it doesn't rely on MALLOC and all of that other
>> > > garbage that comes with C.
>>
>> > AFAIK, Factor uses garbage collection, and it too has no way of
>> > telling you what length you previously allocated at a specific
>> > address. I'm struggling to think of a language (as opposed to library)
>> > that does.
>>
>> > BYW, here's GC in Forth;http://www.complang.tuwien.ac.at/forth/garbage-collection.zip.
>> > Oddly, it also runs on gforth, written in C.
>>
>> > > So long as Forth-200x is designed with the
>> > > constraint that it must support C implementations such as Gforth, then
>> > > Forth-200x will always be nothing more than a C wannabe --- Forth will
>> > > never be considered to be a better language than C, which is what
>> > > Chuck Moore wanted Forth to be from the very beginning (and why I got
>> > > interested in Forth way back in 1984). The C language is just a big
>> > > mish-mash of bad design decisions --- and one of them is that the heap
>> > > lacks an ALLOCATION function --- but why should Forth inherit all of
>> > > C's problems?
>>
>> > You really must start distinguishing between language and library.
>> > Java is a very small language supported by a huge set of libraries,
>> > and if you tried suggesting that feature X needs an addition to the
>> > language specification, you would get shot down in flames. In fact, a
>> > good language *minimizes language cruft, something that Chuck made
>> > abundantly clear over the years.
>>
>> > > I said at the beginning that there were *two* fundamental principles
>> > > of Forth-200x that my RfD violated. What was the other fundamental
>> > > principle violated? There is still room for another B grade to be
>> > > given out for the correct answer to this question.
>>
>> > Who cares? I certainly don't, since getting a B from someone who gets
>> > an F is hardly rewarding.
>>
>> Respectfully, you are sadly mistaken:
>>
>> "You are sadly mistaken on several counts. There is no mechanism to
>> get
>> such information from many systems; please show me a system call that
>> returns the information (specifically, the length allocated). Windows,
>> BSD, Linux's SLAB SLOB SLUB. "

PalmOS has it as system call.

>> You are approaching this from the mind-set that Forth HAS to sit on
>> top of an operating system. It doesn't. And it was never intended to
>> by the language's creator all those years ago. Indeed Forth's ideal
>> 'domain' isn't PC's and large systems at all. It's small embedded
>> systems, that don't need an operating system, as we all know. Surely,
>> the fact that a particular Forth system sits atop an OS is incidental?
>
> No, that is not my point. As a *design point, OSes do not provide the
> length of an allocated block. As a *design point, Forth's ALLOCATE
> does not return this information either, nor do several other
> languages, including C. It is, to be frank, superfluous, since
> generations of programmers at all levels have managed without such a
> feature. Those that can't are free to augment whatever memory
> management scheme they wish to use.

Thus, PalmOS (and, perhaps, MacOS too) designers must be idiots, in your opinion,
since <Core/System/MemoryMgr.h> reads, literally:

/******************************************************************************
 *
 * Copyright (c) 1994-2003 PalmSource, Inc. All rights reserved.
 *
 * File: MemoryMgr.h
 *
 * Release: Palm OS 5 SDK (68K) R3.
 *
 * Description:
 *		Include file for Memory Manager
 *
 *****************************************************************************/

...

//-------------------------------------------------------------------
// Pointer (Non-Movable) based Chunk Routines
//-------------------------------------------------------------------
MemPtr			MemPtrNew(UInt32 size) 
							SYS_TRAP(sysTrapMemPtrNew);
							
#define			MemPtrFree(	p) \
						MemChunkFree(p)

// Getting Attributes
MemHandle			MemPtrRecoverHandle(MemPtr p)
							SYS_TRAP(sysTrapMemPtrRecoverHandle);

UInt16			MemPtrFlags(MemPtr p)
							SYS_TRAP(sysTrapMemPtrFlags);

UInt32			MemPtrSize(MemPtr p)
							SYS_TRAP(sysTrapMemPtrSize);


Another popular allocator, Boehm GC, provides the function too:

/* Given a pointer to the base of an object, return its size in bytes.  */
/* The returned size may be slightly larger than what was originally    */
/* requested.                                                           */
GC_API size_t GC_CALL GC_size(const void * /* object_addr */);


Perhaps you should learn something from the real world outside Forth
rather than pull stupid arguments relating even to kernel programming
(which you don't know either, as it seems).


-- 
HE CE3OH...

Back to comp.lang.forth | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

Re: pop quiz for Forth novices Aleksej Saushev <asau@inbox.ru> - 2012-07-29 23:02 +0400
  Re: pop quiz for Forth novices Alex McDonald <blog@rivadpm.com> - 2012-07-30 03:41 -0700
    Re: pop quiz for Forth novices Aleksej Saushev <asau@inbox.ru> - 2012-07-31 01:01 +0400
      Re: pop quiz for Forth novices Alex McDonald <blog@rivadpm.com> - 2012-07-31 00:26 -0700
        Re: pop quiz for Forth novices Mark Wills <markrobertwills@yahoo.co.uk> - 2012-07-31 01:10 -0700
        Re: pop quiz for Forth novices Aleksej Saushev <asau@inbox.ru> - 2012-08-02 05:08 +0400
          Re: pop quiz for Forth novices Alex McDonald <blog@rivadpm.com> - 2012-08-02 00:12 -0700

csiph-web