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

Groups > comp.lang.forth > #14557

Re: pop quiz for Forth novices

Show all headers | View raw

Alex McDonald <blog@rivadpm.com> writes:

> On Jul 29, 8:02 pm, Aleksej Saushev <a...@inbox.ru> wrote:
>> Alex McDonald <b...@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.
>
> Thanks for the pointer.
>
>>
>> >> 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,
>
> No, that's what you would have me say so you can score Usenet points;
> but I didn't say it, nor do I think it.
>
>> since <Core/System/MemoryMgr.h> reads, literally:
>
> That's evidence for "Those that can't [manage without it] are free to
> augment whatever memory management scheme they wish to use." It
> doesn't address the point of why Forth would need such a thing, or why
> the OS should co-operate in remembering stuff that the application
> requested but forgot. Many OSes don't provide the functionality; the
> example you provide of the moribund PalmOS is an exception. And I
> quite clearly stated upthread, over a year ago;
>
> <quote>
> 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.
> </quote>

The problem is that you don't know what exactly was the design decision
behind the absense of corresponding function in C allocator. Perhaps, it
was nothing but an oversight, you don't know. Instead, you are so accustomed
to saving that size that you refuse to admit one simple fact: that in
most cases this operation takes small fixed amount of time to finish.
It is just stored at negative displacement relative to the chunk start.
Thus, instead of reusing the information allocator stores anyway (and
sometimes provides non-exported functions to access it, e.g. isalloc and
arena_salloc functions in jemalloc), you force all others to work around
this misdesign of standard library of _another_ programming language.


-- 
HE CE3OH...

Back to comp.lang.forth | Previous | Next — Previous in thread | 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