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

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

Hacker News Forth link

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

Contents

  Hacker News Forth link steve <jsgrahamus@yahoo.com> - 2013-10-14 16:49 +0000
    Re: Hacker News Forth link "Clyde W. Phillips Jr." <cwpjr02@gmail.com> - 2013-10-14 17:22 -0700
    Re: Hacker News Forth link Christian Kellermann <ckeen@pestilenz.org> - 2013-10-15 08:27 +0200
      Re: Hacker News Forth link albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-10-15 12:23 +0000
        Re: Hacker News Forth link Christian Kellermann <ckeen@pestilenz.org> - 2013-10-15 14:34 +0200
          Re: Hacker News Forth link albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-10-15 15:51 +0000
            Re: Hacker News Forth link Bill Richards <billrich@gmx.com> - 2013-10-15 16:01 +0000
              Re: Hacker News Forth link albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-10-15 16:38 +0000
                Re: Hacker News Forth link Bill Richards <billrich@gmx.com> - 2013-10-15 16:47 +0000

#26511 — Hacker News Forth link

https://news.ycombinator.com/item?id=6542556

[toc] | [next] | [standalone]

#26535

On Monday, October 14, 2013 11:49:40 AM UTC-5, steve wrote:
> https://news.ycombinator.com/item?id=6542556

Thanks!

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

#26541

steve <jsgrahamus@yahoo.com> writes:

> https://news.ycombinator.com/item?id=6542556

Interesting comment:

https://news.ycombinator.com/item?id=6544002

--8<---------------cut here---------------start------------->8---

rwmj 1 day ago | link

As the author of jonesforth[1], I found Forth to be a great hack and
enormous fun to write. However as an actual language to implement
things, not so good. It's terribly difficult to write correct code when
you've got no bounds checking, only primitive memory management, no
types, and having to manage the stack. (Modern Forths fix these problems
to some extent.)

It's my understanding that most language research is on safety features,
type systems and so on, so I don't know how interesting Forth would be.

[1] http://git.annexia.org/?p=jonesforth.git;a=summary
--8<---------------cut here---------------end--------------->8---

So that's maybe the reason we haven't seen updates there?

Kind regards,

Christian

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

#26545

In article <8761szaw1q.fsf@pestilenz.org>,
Christian Kellermann  <ckeen@pestilenz.org> wrote:
>steve <jsgrahamus@yahoo.com> writes:
>
>> https://news.ycombinator.com/item?id=6542556
>
>Interesting comment:
>
>https://news.ycombinator.com/item?id=6544002
>
>--8<---------------cut here---------------start------------->8---
>
>rwmj 1 day ago | link
>
>As the author of jonesforth[1], I found Forth to be a great hack and
>enormous fun to write. However as an actual language to implement
>things, not so good. It's terribly difficult to write correct code when
>you've got no bounds checking, only primitive memory management, no
>types, and having to manage the stack. (Modern Forths fix these problems
>to some extent.)
>
>It's my understanding that most language research is on safety features,
>type systems and so on, so I don't know how interesting Forth would be.
>
>[1] http://git.annexia.org/?p=jonesforth.git;a=summary
>--8<---------------cut here---------------end--------------->8---
>
>So that's maybe the reason we haven't seen updates there?

Maybe. Anyway it is well known that this is the stand of the author
about jonesforth.
It is a bit unfair to accuse him of providing an unusable language.

With yourforth I want to progress a little step. Slightly less unusable,
more ISO compliance, and slightly better in explaining the user how he
would write his own ideal language... and a considerably different take.
I can't believe how different the sources and explanations work out.
It probably will appeal to a totally different group, which is per se
not bad.

>
>Kind regards,
>
>Christian
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#26546

albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
> Maybe. Anyway it is well known that this is the stand of the author
> about jonesforth.
> It is a bit unfair to accuse him of providing an unusable language.

This has not been my intention.

> With yourforth I want to progress a little step. Slightly less unusable,
> more ISO compliance, and slightly better in explaining the user how he
> would write his own ideal language... and a considerably different take.
> I can't believe how different the sources and explanations work out.
> It probably will appeal to a totally different group, which is per se
> not bad.

I like it so far, thanks for all the effort you put in!

Kind regards,

Christian

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

#26555

In article <87vc0yaf23.fsf@pestilenz.org>,
Christian Kellermann  <ckeen@pestilenz.org> wrote:
>albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>> Maybe. Anyway it is well known that this is the stand of the author
>> about jonesforth.
>> It is a bit unfair to accuse him of providing an unusable language.
>
>This has not been my intention.

I didn't want to imply that. I should've said:
It would be a bit unfair to accuse him of providing an unusable language.

>
>> With yourforth I want to progress a little step. Slightly less unusable,
>> more ISO compliance, and slightly better in explaining the user how he
>> would write his own ideal language... and a considerably different take.
>> I can't believe how different the sources and explanations work out.
>> It probably will appeal to a totally different group, which is per se
>> not bad.
>
>I like it so far, thanks for all the effort you put in!

Lately I'm catering to those who want to have more of it in Forth, not
just defined in assembly like

    header  SIGN,   docol, SIGN+5*cw, 0, lastlink, "SIGN"
        dd      zero_less
        ifto  SIGN1
          dd      LIT, '-'
          dd      HOLD
SIGN1:  dd      EXIT

The source ends in

initdp:  end - start
start:
 ...
 db ":  POSTPONE    NAME PRESENT DUP 0= 15 ?ERROR " , 0x0a
 db "   DUP >FFA @ 4 AND 0= IF 'LIT ,   ,  ', THEN , ; IMMEDIATE " , 0x0a
 db ": FORGET   POSTPONE ' >R 'FORTH >BODY DUP "     , 0x0a
 db "BEGIN >LFA @ DUP R@ < UNTIL   SWAP >LFA ! R> >NFA @ DP ! ; ",0x0a
end:
which costs a ``  HERE $@ EVALUATE '' at startup.

So high level words that are not needed in the kernel as such, can be
defined here.
This is better IMO then having a separate Forth source, but Jones doesn't
like it, because of the clutter around the text.
(Maybe that can be fixed, I'm looking into it. For me the advantage of having
it all together weighs heavy. I managed once to combine a jonesforth.s
with the wrong jonesforth.f. And having to say
cat jonesforth.f - | ./jonesforth
is inconvenient, to say the least, as well as puzzling to those non-fluent in
Unix.)

One of the exercises is to do:
"newforth"  0 HERE ! HEX BM 54 - HERE OVER SWAP - CELL+
2SWAP PUT-FILE BYE

newforth now compiles an empty string at startup.
The exercise is to measure the difference in startup time.

>
>Kind regards,
>
>Christian
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#26558

On 2013-10-15, Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:

> Lately I'm catering to those who want to have more of it in Forth, not
> just defined in assembly like
>
>     header  SIGN,   docol, SIGN+5*cw, 0, lastlink, "SIGN"
>         dd      zero_less
>         ifto  SIGN1
>           dd      LIT, '-'
>           dd      HOLD
> SIGN1:  dd      EXIT
>
> The source ends in
>
> initdp:  end - start
> start:
>  ...
>  db ":  POSTPONE    NAME PRESENT DUP 0= 15 ?ERROR " , 0x0a
>  db "   DUP >FFA @ 4 AND 0= IF 'LIT ,   ,  ', THEN , ; IMMEDIATE " , 0x0a
>  db ": FORGET   POSTPONE ' >R 'FORTH >BODY DUP "     , 0x0a
>  db "BEGIN >LFA @ DUP R@ < UNTIL   SWAP >LFA ! R> >NFA @ DP ! ; ",0x0a
> end:
> which costs a ``  HERE $@ EVALUATE '' at startup.
>

This is very nice and seems to be heading to a self-hosted Forth. I wonder
if some of it can be done by defining macros in fasm? The only problem might
be the symbols such as $ @ ? etc. I don't know if you can use them for fasm
macro names. 

> So high level words that are not needed in the kernel as such, can be
> defined here.

That's really a nicer approach.

> This is better IMO then having a separate Forth source, but Jones doesn't
> like it, because of the clutter around the text.
> (Maybe that can be fixed, I'm looking into it. For me the advantage of having
> it all together weighs heavy. I managed once to combine a jonesforth.s
> with the wrong jonesforth.f. And having to say
> cat jonesforth.f - | ./jonesforth
> is inconvenient, to say the least, as well as puzzling to those non-fluent in
> Unix.)

Yes!

I checked your git link a few months ago. I didn't see that you had any
diagrams in the code. I really liked the ones in jonesforth. Are you
planning to include diagrams? I find them very helpful.

Bill

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

#26562

In article <l3jorr$pvf$1@speranza.aioe.org>,
Bill Richards  <billrich@gmx.com> wrote:
>On 2013-10-15, Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
>
>> Lately I'm catering to those who want to have more of it in Forth, not
>> just defined in assembly like
>>
>>     header  SIGN,   docol, SIGN+5*cw, 0, lastlink, "SIGN"
>>         dd      zero_less
>>         ifto  SIGN1
>>           dd      LIT, '-'
>>           dd      HOLD
>> SIGN1:  dd      EXIT
>>
>> The source ends in
>>
>> initdp:  end - start
>> start:
>>  ...
>>  db ":  POSTPONE    NAME PRESENT DUP 0= 15 ?ERROR " , 0x0a
>>  db "   DUP >FFA @ 4 AND 0= IF 'LIT ,   ,  ', THEN , ; IMMEDIATE " , 0x0a
>>  db ": FORGET   POSTPONE ' >R 'FORTH >BODY DUP "     , 0x0a
>>  db "BEGIN >LFA @ DUP R@ < UNTIL   SWAP >LFA ! R> >NFA @ DP ! ; ",0x0a
>> end:
>> which costs a ``  HERE $@ EVALUATE '' at startup.
>>
>
>This is very nice and seems to be heading to a self-hosted Forth. I wonder
>if some of it can be done by defining macros in fasm? The only problem might
>be the symbols such as $ @ ? etc. I don't know if you can use them for fasm
>macro names.

Very nice things can be done with macro's. The problems is that the reader
must be constantly aware of all macro's defined. Also I don't want to
assume too much assembler language experience.
So I've the same macro for all headers, high or low level, constants,
and do-objects, called header.
I've one macro to lay down a string.
I've the next macro.
I've a couple of structured programming macro's that are similar :
ifto whileto untilto goto
I'm careful that the reader sees all macro's all the time, such that
he can't forget about them.

That's it. More macro's would put it over the top. I must say I was very
tempted to introduce DC as a synonym for DD , each time a Forth cell
is laid down. (And it would be a convenience in porting to 64-bit.)
(Actually I edited it to get rid of the DC heritage from ciforth.)

>
>> So high level words that are not needed in the kernel as such, can be
>> defined here.
>
>That's really a nicer approach.

Nicer yes, or I wouldn't have done it, but by a narrow margin.

>
>> This is better IMO then having a separate Forth source, but Jones doesn't
>> like it, because of the clutter around the text.
>> (Maybe that can be fixed, I'm looking into it. For me the advantage of having
>> it all together weighs heavy. I managed once to combine a jonesforth.s
>> with the wrong jonesforth.f. And having to say
>> cat jonesforth.f - | ./jonesforth
>> is inconvenient, to say the least, as well as puzzling to those non-fluent in
>> Unix.)
>
>Yes!
>
>I checked your git link a few months ago. I didn't see that you had any
>diagrams in the code. I really liked the ones in jonesforth. Are you
>planning to include diagrams? I find them very helpful.

So noted.

You will be disappointed at the simpleness of them. That may be all the
more reason to put them in. For example, the only memory space not divided
into cells is character strings. All headers are brutally identically
structured. All strings are preceded by a one cell count.

There goes a terrible lot of work into this. Do you believe that for
several months now I'm totally happy with the yourforth "as is"?
It has exactly the words with the exact names I want, not too little
not too much. All words are documented in a reference manual.
It passes a comprehensive test and with a preamble it passes the Hayes
test.

Still I feel I'm at most 20% done till first release.

>
>Bill

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#26563

On 2013-10-15, Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
> In article <l3jorr$pvf$1@speranza.aioe.org>,
> Bill Richards  <billrich@gmx.com> wrote:
>>On 2013-10-15, Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
>>
>>> start:
>>>  ...
>>>  db ":  POSTPONE    NAME PRESENT DUP 0= 15 ?ERROR " , 0x0a
>>>  db "   DUP >FFA @ 4 AND 0= IF 'LIT ,   ,  ', THEN , ; IMMEDIATE " , 0x0a
>>>  db ": FORGET   POSTPONE ' >R 'FORTH >BODY DUP "     , 0x0a
>>>  db "BEGIN >LFA @ DUP R@ < UNTIL   SWAP >LFA ! R> >NFA @ DP ! ; ",0x0a
>>> end:
>>> which costs a ``  HERE $@ EVALUATE '' at startup.
>>>
>>
>>This is very nice and seems to be heading to a self-hosted Forth. I wonder
>>if some of it can be done by defining macros in fasm? The only problem might
>>be the symbols such as $ @ ? etc. I don't know if you can use them for fasm
>>macro names.
>
> Very nice things can be done with macro's. The problems is that the reader
> must be constantly aware of all macro's defined. Also I don't want to
> assume too much assembler language experience.

Understood. I was thinking about macros for Forth words like

POSTPONE
NAME
PRESENT
DUP
etc.

as you've hardcoded above. It would be a neat trick and aside from the issue
I mentioned about symbols you should be able to make things much more clear
than if you use db. It should look really like actual Forth. I myself avoid
macros that just make code generation easier because of the confusion issue.

>>diagrams in the code. I really liked the ones in jonesforth. Are you
>>planning to include diagrams? I find them very helpful.
>
> So noted.

Thanks.

> You will be disappointed at the simpleness of them. That may be all the
> more reason to put them in. For example, the only memory space not divided
> into cells is character strings. All headers are brutally identically
> structured. All strings are preceded by a one cell count.

Pictures help people understand the implementation which is after all the
main selling point of jones, isn't it?

Nice work on a very interesting project.

Bill

[toc] | [prev] | [standalone]

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

csiph-web