Re: Type checking (was: The strengths of FORTH)

<m_l_g3@[EMAIL PROTECTED]
> schrieb im Newsbeitrag 
news:1089f560-8cfe-4607-aff4-9a76775d24b3@[EMAIL PROTECTED]
> On Mar 29, 12:33 am, an...@[EMAIL PROTECTED]
 (Anton Ertl)
> wrote:
>> "dkel...@[EMAIL PROTECTED]
" <dkel...@[EMAIL PROTECTED]
> writes:
>> > One of the complaints I see often is the lack
>> >of type checking.
>> > I can't recall when I had an error in my code
>> >related to incorrect use of type. Still, it is
>> >considered a major problem with Forth?
>>
>> Depends on whom you ask.  Outside the Forth community, there are two
>> religions:
>>
>> - Those who believe in static type checking
>>
>> - and those who detest it.
>>
>> I am pretty sure that the believers consider the lack of static type
>> checking a problem in Forth.
>>
>> Now, looking at the Forth community, there are experiments with static
>> type checking (StrongForth and some research projects) and with
>> dynamic type checking (e.g., Factor).  However, it seems that those in
>> the Forth community who have a problem with the lack of type checking
>> are a small minority, otherwise we see more such experiments
>> (especially since StrongForth is only a 16-bit DOS system) and we
>> would have seen such experiments earlier.
>>
>
> StrongForth is based on a brilliant idea, the solution to the type
> checking problem *is* untrivial. Strictly speaking, StrongForth is
> inherently unstandard.  Currently Forth is an exotic esoteric
> language, and StrongForth is an exotic (within the Forth community)
> dialect, in addition, with only one MS-DOS-based implementation. I
> think, if it was not a 16-bit DOS system, it would be more popular.

Maybe. I thought about providing a 32-bit version for Linux, but since I 
have no experience with Linux and with 32-bit x86 assembly programming, I 
finally discarded the idea. It seemed to be too much effort, given the 
"success" of StrongForth so far. I hoped someone who likes the idea of a 
strongly typed Forth dialect and who has more experience in the required 
areas would pick up the GPL sources and do the port.

> And, by the way, StrongForth does not just type ckecking, but stack
> effect checking.
>
> StrongForth allows a normal implementation of structures, that is, no
> need to include type names into field names, because two structures
> can have fields with the same name (depending on the argument type,
> different field selectors will be invoked).

Yes. There's actually a sample implementation of structures in the latest 
release (1.3) that allows field names to be overloaded. And the next 
version, which will be released in a few weeks, will come with a 
full-featured OO library that takes advantage of overloaded data members
and 
member words.

Regards,
Stephan