середа, 2 січня 2019 р. о 11:30:24 UTC a...@littlepinkcloud.invalid пише:
> Paul Rubin <no.e...@nospam.invalid> wrote:
> > an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> >
> > We're in an era where ram in kilobyte amounts costs almost nothing.
> > Or on even smaller parts, I think it's hard for Forth to compete
> > resource-wise with C, because of the memory used by Forth's stacks,
> I know there are some C compilers that statically allocate everything
> based on whole-program analysis, but I don't know of any that are
> effective on tiny MCUs that are too small for Forth. Apart from
> anything else, if you're constrained for code space you'll want to use
> something like byte-token-threading, and that's easy in Forth.
> > the higher inconvenience of using bytes instead of wider cells,
> > program space used by the interpreter and extraneous Forth word
> > definitions, etc. Maybe there are Forth compilers that can target
> > an 8-bit MCU with 0.5k of program flash and 32 bytes of ram, but
> > (like C) they will be external compilers that don't bring much
> > interactivity to the target app either.
> Interactivity on very small devices has been a solved problem in Forth
> for some 30 years, ever since talker PROMs and then chipFORTH. 0.5k of
> program space is tight, though. For Forth, especially if you want
> multi-tasking, I think that a reasonable minimum is 128-256 bytes of
> RAM and 4k program space.
> > Once you're at the level of an industrial device (not battery
> > powered) you might as well use an embedded Linux board (starting at
> > the 5 dollar Raspberry Pi Zero) and then have basically unlimited
> > resources and software options.
> Not necessarily. If you have a very small MCU that is controlling
> something, you're quite likely to be at the sharp end of real
> time.
>
> Andrew.

You got me interested. I am new to programming and have not learned all the languages yet. I'm just learning how to create and manage databases. This source https://www.programmingassignment.net/services/dbms-assignment-help/ helps me a lot to solve difficulties in this direction Programming is not such a simple science as I thought, there are many nuances here and you need to spend time to figure it all out.

One of the most interesting things about Forth is the lack of collaboration with in a community to excel and promote the language, while I see lots of individual efforts, lots of great intentions, it’s this lack of collaboration that creates greater fragmentation and in the end and a deterrent reason for new uptake in the language IMO.

From an embedded perspective, I firmly believe that FORTH really does have something that should greatly appeal commercial application, provided it is wrapped into a set of tools that enable commercialization and collaboration with in a community. IMHO the is is so much wasted effort into trying to build “ my forth is better than your’s “ with the right intent, yet this does not serve the community to capture new adoption of users or commercial applications.
Forth has so much to offer, and yes, doing interactive programing is a great thing, but provided the way most (i’ll use traditional forthers here as to not not hurt anyone as I still have my Franklin 1000 for 84 where I started programing just to prove that it’s not age related ) traditional forthers, where they are building a great deal of tools into a little MCU intended to placed in it’s single uprose function once deployed, it does not add lot’s of value to have editors or complex tools other than the development fase. Provided a Forth (i’ll use IDE here explain a concept ) IDE with in a Forth where you could have a single Forth, a target compiler, tools to have the interactiveness of been on the HW *tethered to the target IMHO would probably be the best solution.

In this view of Forth on a PC *IDE and a tethered system would allow the efforts of the Fort community to focus on building target compilers for each of the platforms they wish to incorporate. Once this happens, it would allow the community and in interest of newcomers to extend the (tools as a collection of vocabulary to help and build the IDE experience ) tools need to help in development of the applications. One of these tools for example would be having the capacity to see the register values as the applications executes, again in a idealized tethered forth, you are executing the extended vocabulary to get the output needed and presenting it on the IDE.

Ideally, this would allow for more repeatability of cross platform compiling the forth code, and it should attract new users that would extend the platform provided collaboration along with commercial backing in a open source effort.

Call me an idealist, but once you are there, the community can further consider how to extend the tethered functionality, like wireless, OTA updates, etc.

Well, that is a thought, and many can choose their own path and that is perfectly fine as we don’t hold the ultimate truth… * i certainly do not * but if anyone is truly interested in helping drive FORTH’s adoption, I hope this could be, not a blueprint of what to consider, but more of a seed of where to lead the discussion.

Forth has a very strong potential to, IMHO, reevaluate how programing is learned for embedded systems, it would give users a better understanding of the underlining HW, it would allow for more efficient programs, great opportunity to build commercial solutions while still gaining the hobbyist’s interest along with the interactiveness and the DSL capabilities of forth naturally has to offer.

Moving to a stack based programing does take effort and application for the programmer, it has taken me about two to three months to really begin to understand the return stack and how to best use it to grasp some of the more advanced ways of implementing forth to solve problems. It’s a fun language once you start, but the fragmentation and the lack of repeatability is the hardest barrier to grasp some of these concepts IMO, specially from those that learn by reading the code, testing it, the making changes to experiment with the reinforcement of expected outcomes *repeatability of the code*.

FWIW, food for thought.

Jose.

On Sunday, 6 November 2022 at 12:12:48 UTC, jem...@gmail.com wrote:
> One of the most interesting things about Forth is the lack of collaboration with in a community to excel and promote the language, while I see lots of individual efforts, lots of great intentions, it’s this lack of collaboration that creates greater fragmentation and in the end and a deterrent reason for new uptake in the language IMO.
>
> From an embedded perspective, I firmly believe that FORTH really does have something that should greatly appeal commercial application, provided it is wrapped into a set of tools that enable commercialization and collaboration with in a community. IMHO the is is so much wasted effort into trying to build “ my forth is better than your’s “ with the right intent, yet this does not serve the community to capture new adoption of users or commercial applications.
> Forth has so much to offer, and yes, doing interactive programing is a great thing, but provided the way most (i’ll use traditional forthers here as to not not hurt anyone as I still have my Franklin 1000 for 84 where I started programing just to prove that it’s not age related ) traditional forthers, where they are building a great deal of tools into a little MCU intended to placed in it’s single uprose function once deployed, it does not add lot’s of value to have editors or complex tools other than the development fase. Provided a Forth (i’ll use IDE here explain a concept ) IDE with in a Forth where you could have a single Forth, a target compiler, tools to have the interactiveness of been on the HW *tethered to the target IMHO would probably be the best solution.
>
> In this view of Forth on a PC *IDE and a tethered system would allow the efforts of the Fort community to focus on building target compilers for each of the platforms they wish to incorporate. Once this happens, it would allow the community and in interest of newcomers to extend the (tools as a collection of vocabulary to help and build the IDE experience ) tools need to help in development of the applications. One of these tools for example would be having the capacity to see the register values as the applications executes, again in a idealized tethered forth, you are executing the extended vocabulary to get the output needed and presenting it on the IDE.
>
> Ideally, this would allow for more repeatability of cross platform compiling the forth code, and it should attract new users that would extend the platform provided collaboration along with commercial backing in a open source effort.
>
> Call me an idealist, but once you are there, the community can further consider how to extend the tethered functionality, like wireless, OTA updates, etc.
>
> Well, that is a thought, and many can choose their own path and that is perfectly fine as we don’t hold the ultimate truth… * i certainly do not * but if anyone is truly interested in helping drive FORTH’s adoption, I hope this could be, not a blueprint of what to consider, but more of a seed of where to lead the discussion.
>
> Forth has a very strong potential to, IMHO, reevaluate how programing is learned for embedded systems, it would give users a better understanding of the underlining HW, it would allow for more efficient programs, great opportunity to build commercial solutions while still gaining the hobbyist’s interest along with the interactiveness and the DSL capabilities of forth naturally has to offer.
>
> Moving to a stack based programing does take effort and application for the programmer, it has taken me about two to three months to really begin to understand the return stack and how to best use it to grasp some of the more advanced ways of implementing forth to solve problems. It’s a fun language once you start, but the fragmentation and the lack of repeatability is the hardest barrier to grasp some of these concepts IMO, specially from those that learn by reading the code, testing it, the making changes to experiment with the reinforcement of expected outcomes *repeatability of the code*.
>
> FWIW, food for thought.
>
> Jose.

Thank you very much for your post.
It summarizes many aspects I have experienced over the years.
I think it is in many ways the mindset of forthers.
I can do better if I write my own Forth ...

I sometimes wonder, if there are more Forth variants
than there are applications using a standard Forth.

In other languages it is very often the IDE that stops people to mess with the language,
as it will mostly not work than with the IDE that is accepted by many.
And which they use to show off their applications .

One example is the Arduino IDE.
How good or bad it is, I cannot judge, but ask google for applications using it
and compare that with the same search regarding Forth applications.

I have just started to play around with Python for fun and as there is a little project.
Thonny IDE I stumbled over, and start using it with the RPI Pico.
THERE IS NO FORTH IDE REALLY THAT I HAVE SEEN TO SUPPORT SIMILAR ASPECTS.
WHY NOT AFTER MORE THAN 50 YEARS ????
OK VFX has something.

Getting started with Forth?
When I started doing some consultancy work for MPE,
I realized how little is there for beginners,
or easily accessible.
And I put myself in this group,
I started a fun project to publish material
together with the people who generated the material.

Now there is my Forth Bookshelf on amazon, containing about 20 Forth books,
as ebook or as print book.
And people still seem to be interested
- 10 years of re-writing, checking, formatting and publishing work.
A lot more work and communication than I had expected, but still fun.
https://www.amazon.co.uk/Juergen-Pintaske/e/B00N8HVEZM%3Fref=dbs_a_mng_rwt_scns_share
It forced me to play with some of them.

The ones I enjoyed most is the FORTH LITE TUTORIAL,
going through many Forth Words, trying to understan, write and try examples on my PC
https://www.amazon.co.uk/gp/product/1717970672/ref=dbs_a_def_rwt_bibl_vppi_i24

and the eFORTH AS ARDUINO SKETCH
https://www.amazon.co.uk/gp/product/1717970672/ref=dbs_a_def_rwt_bibl_vppi_i24
where I later generated the "39 steps" to get started for absolute beginners
https://wiki.forth-ev.de/doku.php/projects:430eforth:start

It is unfortunate, that Forth does not get the recognition it and especially Chuck deserves..
But look forward to Forth Day in November, where Greenarrays will bring us hopefully good news.

On 6/11/2022 11:12 pm, jem...@gmail.com wrote:
> One of the most interesting things about Forth is the lack of collaboration with in a community to excel and promote the language, while I see lots of individual efforts, lots of great intentions, it’s this lack of collaboration that creates greater fragmentation and in the end and a deterrent reason for new uptake in the language IMO.

IMO Forth is aimed squarely at the experienced individual. Consider Moore himself. It's
the attempts to popularize it that have failed. If one wants a 'batteries included' language,
then IMO look at something like 8th where the developer seems to be catering to users who
a) are happy to go along and b) have faith in what he's doing.

> From an embedded perspective, I firmly believe that FORTH really does have something that should greatly appeal commercial application, provided it is wrapped into a set of tools that enable commercialization and collaboration with in a community. IMHO the is is so much wasted effort into trying to build “ my forth is better than your’s “ with the right intent, yet this does not serve the community to capture new adoption of users or commercial applications.

ISTM embedded is exactly where you've got your experienced individual and the existing
vendors are catering for them with appropriate tools. That said, it's not an Arduino
embedded-for-the-masses where supplied libraries are massively over-protected and users
freak out if their bootloader gets overwritten. Forth is - above all - about extracting
performance, not selling an experience. And that takes individual effort.

On 07/11/2022 2:50, dxforth wrote:
> On 6/11/2022 11:12 pm, jem...@gmail.com wrote:
>> One of the most interesting things about Forth is the lack of
>> collaboration with in a community to excel and promote the language,
>> while I see lots of individual efforts, lots of great intentions, it’s
>> this lack of collaboration that creates greater fragmentation and in
>> the end and a deterrent reason for new uptake in the language IMO.
>
> IMO Forth is aimed squarely at the experienced individual.  Consider
> Moore himself.  It's
> the attempts to popularize it that have failed.  If one wants a
> 'batteries included' language,
> then IMO look at something like 8th where the developer seems to be
> catering to users who
> a) are happy to go along and b) have faith in what he's doing.

I approve this message.

On Monday, November 7, 2022 at 6:11:20 AM UTC+1, Ron AARON wrote:
> On 07/11/2022 2:50, dxforth wrote:
> > On 6/11/2022 11:12 pm, jem...@gmail.com wrote:
> >> One of the most interesting things about Forth is the lack of
> >> collaboration with in a community to excel and promote the language,
> >> while I see lots of individual efforts, lots of great intentions, it’s
> >> this lack of collaboration that creates greater fragmentation and in
> >> the end and a deterrent reason for new uptake in the language IMO.
> >
> > IMO Forth is aimed squarely at the experienced individual. Consider
> > Moore himself. It's
> > the attempts to popularize it that have failed. If one wants a
> > 'batteries included' language,
> > then IMO look at something like 8th where the developer seems to be
> > catering to users who
> > a) are happy to go along and b) have faith in what he's doing.
> I approve this message.

So do I, I never it said this has to be an Arduino for the masses, I said, here is an idea that could bring two factors as outcomes:
- Remove the fragmentation to improve repeatability. * I can take most an code in C and make it behave as advertise, something that does not happen easily in Forth.
- Unison of a community would drive adoption. Spend a day on this forum and you see what I mean, lots of rhetoric and old unsettled differences seen to take up most of the time in the discussion.

No pain not gain, but gain non the less has to be a factor of predictable outcome and pain no gain is many times the outcome for new comers * myself included.

The outcome is a higher adoption ratio.
When you look say ADA (a lower adoption language in embedded,) sure, early on it had a limited number of targets available, but those in favor of it’s adoption did not build different paths to each target, rather they added the support to enable those targets. * subtle add-ons to target the new platforms, not in the forms of HAL or drivers, you still have to do the heavy lifting and bare-metal write register programing to make things work. And yes, that is a principle IMO that is an important aspect of embedded development and learning path. Very unlike the Arduino framework.

I learned this early when I used the STM32 HAL, wrote code that looked liked it conformed to the HAL, then spent weeks filling errors on the their support site. It’s a lot better now, but I still see issues popping up that the HAL changed and something that previously worked now does not, so I stay aways 100% of the time.

I’m still disappointed that there is no unison in the Forth community to help build up adoption and find truly viable commercial applications for the language. I’m not inferring on the commercialization of the concept of the IDE, but like many other project, funding could be an important thing once it’s adopted commercially viable.

Most here would argue in favor of Forth in the embedded space, so why not make the argument in a directed voice in the way it’s collaborative to help make FORTH greater and leverage the amazing talent of everyone in the Forth Community?

> Moving to a stack based programing does take effort and application for the programmer, it has taken me about two to three months to really begin to understand the return stack and how to best use it to grasp some of the more advanced ways of implementing forth to solve problems. It’s a fun language once you start, but the fragmentation and the lack of repeatability is the hardest barrier to grasp some of these concepts IMO, specially from those that learn by reading the code, testing it, the making changes to experiment with the reinforcement of expected outcomes *repeatability of the code*.

I personally did not find the return stack to be difficult to understand
or manipulate, but I would recommended this video by Samuel Falvo for
anyone that does:

https://www.youtube.com/watch?v=mvrE2ZGe-rs

He goes through a lot of things and he uses the return stack for control
flow towards the end.

On Thursday, November 10, 2022 at 3:49:37 PM UTC+1, shtps wrote:
> He goes through a lot of things and he uses the return stack for control
> flow towards the end.
Although my own compiler (4tH) does allow it, I'm not quite a fan of manipulating
the control stack for flow control. First, any word called has its own return address
on the TORS. Usually, you have to take it off do do stuff and put it on later in order
not to break things. IMHO this results in very murky code. Second, it's not portable.
compilers may use a different mechanism to do flow control.

Can't say I never used it, but I'm hesitant to do it - and only as a last resort. I'd rather
inline such code - since at least then it remains WITHIN a definition.

That doesn't mean I never use the return stack for my own purposes - quite the opposite.
It's a useful temporary storage. A technique I often use is to store constant terms there
- so they can be fetched with a single R@. It's quite useful when implementing routines
with LOTS of parameters. You store the more constant ones on the return stack, TORS
is perfect for stuff that RARELY changes - like "R> 1+ >R".

For that reason 4tH supports R@, R'@ and R"@. They act like a kind of R/O registers. And
it doesn't cause much overhead, since they're equivalent (in 4tH) to I, I' and J.

Hans Bezemer

On Tuesday, December 6, 2022 at 3:37:53 PM UTC+5:30, Hans Bezemer wrote:
> On Thursday, November 10, 2022 at 3:49:37 PM UTC+1, shtps wrote:
> > He goes through a lot of things and he uses the return stack for control
> > flow towards the end.
> Although my own compiler (4tH) does allow it, I'm not quite a fan of manipulating
> the control stack for flow control. First, any word called has its own return address
> on the TORS. Usually, you have to take it off do do stuff and put it on later in order
> not to break things. IMHO this results in very murky code. Second, it's not portable.
> compilers may use a different mechanism to do flow control.
>
> Can't say I never used it, but I'm hesitant to do it - and only as a last resort. I'd rather
> inline such code - since at least then it remains WITHIN a definition.
>
> That doesn't mean I never use the return stack for my own purposes - quite the opposite.
> It's a useful temporary storage. A technique I often use is to store constant terms there
> - so they can be fetched with a single R@. It's quite useful when implementing routines
> with LOTS of parameters. You store the more constant ones on the return stack, TORS
> is perfect for stuff that RARELY changes - like "R> 1+ >R".
>
> For that reason 4tH supports R@, R'@ and R"@. They act like a kind of R/O registers. And
> it doesn't cause much overhead, since they're equivalent (in 4tH) to I, I' and J.
>
> Hans Bezemer
https://www.quickbookintegration.com