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

Groups > comp.lang.forth > #14525 > unrolled thread

Re: pop quiz for Forth novices

Back to article view | Back to comp.lang.forth

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

#14525 — Re: pop quiz for Forth novices

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...

[toc] | [next] | [standalone]

#14551

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>

[toc] | [prev] | [next] | [standalone]

#14557

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...

[toc] | [prev] | [next] | [standalone]

#14563

On Jul 30, 10:01 pm, Aleksej Saushev <a...@inbox.ru> wrote:
[snipped]
>
> The problem is that...

The problem is you. You keep telling me what I'm thinking, what I'm
doing, what opinions I hold and so on. It's an irritating habit, and
doesn't make for a high quality discussion. Now you're shouting at me
like some usenet fruitcake. Is there a serious point you wish to
discuss? If there is, dig it out and make it without using the word
"you".

[toc] | [prev] | [next] | [standalone]

#14565

On Jul 31, 8:26 am, Alex McDonald <b...@rivadpm.com> wrote:
> On Jul 30, 10:01 pm, Aleksej Saushev <a...@inbox.ru> wrote:
> [snipped]
>
>
>
> > The problem is that...
>
> The problem is you. You keep telling me what I'm thinking, what I'm
> doing, what opinions I hold and so on. It's an irritating habit, and
> doesn't make for a high quality discussion. Now you're shouting at me
> like some usenet fruitcake. Is there a serious point you wish to
> discuss? If there is, dig it out and make it without using the word
> "you".

Aleksej is a well known troll around here. He recently showed up again
after quite a long hiatus. I assume he was in prison or something. Or
his mother took his computer away.

[toc] | [prev] | [next] | [standalone]

#14642

Alex McDonald <blog@rivadpm.com> writes:

> On Jul 30, 10:01 pm, Aleksej Saushev <a...@inbox.ru> wrote:
> [snipped]
>>
>> The problem is that...
>
> The problem is you. You keep telling me what I'm thinking, what I'm
> doing, what opinions I hold and so on. It's an irritating habit, and
> doesn't make for a high quality discussion. Now you're shouting at me
> like some usenet fruitcake. Is there a serious point you wish to
> discuss? If there is, dig it out and make it without using the word
> "you".

There is serious point, and it involves you. Directly. Personally.

This particular flame outburst is caused by you. It was your thinking
inside C box here that caused this discussion with the surrealistic
outcome of "noone in C world uses it, hence it is generally useless."

In particular, you haven't brought any evidence why it is generally
useless, while anyone familiar with at least Unix-like systems would be
correct to point you to one simple fact that there exist many things
determined by early misdesigns that stuck. The latter is well-know in
the world around Unix. In fact, it is part of required knowledge of Unix
programmer to know which standard interfaces or features not to use.

In addition, there is a long-running tradition of using the lowest common
denominator, when some code would be intentionally implemented
ineffectively in order to build and run on some strange Unix version.
There's a heavy legacy which played against many extensions in Unix
systems besides very effective ones.

You pretended to have competence in this and were demonstrated to have none.
It wouldn't be a problem at all, if you didn't teach others about design.
"This is a fundamental design problem in your code, not a problem with
the memory allocation words that Forth provides," those were your words.

I understand that it is irritating to find someone who knows something
better than you. But then it is your problem again. Not mine. I don't
claim competence in systems I don't actually know (e.g. z/OS), and
I don't pull arguments about design quality of not exporting "dynamic sizeof"
basing on assumptions that if it wasn't done then it was supported
by some experimental evidence rather than a mere historical accident.
(That it might be the latter is demonstrated by the fact that PalmOS,
which was designed somewhat independently of Unix-BSD line, does have
the proposed "dynamic sizeof".)

I agree with you on one point though. It is useless to discuss anything
with you until you change your attitude in respect of pulling arguments
you cannot support with any evidence, be it historical or experimental.
And until you stop playing rhetoric tricks by turning serious arguments
into personal plane. If I point that your reasoning is based on your
personal experience limited to "Linux, BSD, every version of IBM
mainframe systems to z/OS and others" is wrong here, since it is
mostly based on the same source that isn't relevant when discussing
a programming language, then it might be really wrong.
Besides, there's no straight way to express it without the word "you".
English isn't rich enough for it, it looks heavy-weight with passive
voice in each sentence.


-- 
HE CE3OH...

[toc] | [prev] | [next] | [standalone]

#14656

On Aug 2, 2:08 am, Aleksej Saushev <a...@inbox.ru> wrote:
> Alex McDonald <b...@rivadpm.com> writes:
> > On Jul 30, 10:01 pm, Aleksej Saushev <a...@inbox.ru> wrote:
> > [snipped]
>
> >> The problem is that...
>
> > The problem is you. You keep telling me what I'm thinking, what I'm
> > doing, what opinions I hold and so on. It's an irritating habit, and
> > doesn't make for a high quality discussion. Now you're shouting at me
> > like some usenet fruitcake. Is there a serious point you wish to
> > discuss? If there is, dig it out and make it without using the word
> > "you".
>
> There is serious point, and it involves you. Directly. Personally.
>
> This particular flame outburst is caused by you. It was your thinking
> inside C box here that caused this discussion with the surrealistic
> outcome of "noone in C world uses it, hence it is generally useless."

Now you're telling me what languages I know.

I've never written a single line of code in C or any of its relatives.
Nor have I ever said, nor would I think, that "noone in C world uses
it, hence it is generally useless."

[snipped, since it's more of the same]

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web