Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #48085 > unrolled thread
| Started by | Marek Brunda <marekb@phoenics.org> |
|---|---|
| First post | 2016-06-13 13:41 -0700 |
| Last post | 2016-06-26 22:41 -1000 |
| Articles | 16 on this page of 116 — 28 participants |
Back to article view | Back to comp.lang.forth
Is it sill FORTH ? Marek Brunda <marekb@phoenics.org> - 2016-06-13 13:41 -0700
Re: Is it sill FORTH ? crc <charles.childers@gmail.com> - 2016-06-13 13:57 -0700
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-13 15:18 -0700
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-13 15:34 -0700
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-13 15:37 -0700
Re: Is it sill FORTH ? Paul Rubin <no.email@nospam.invalid> - 2016-06-13 15:45 -0700
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-13 15:54 -0700
Re: Is it sill FORTH ? Coos Haak <chforth@hccnet.nl> - 2016-06-14 01:41 +0200
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-13 16:48 -0700
Re: Is it sill FORTH ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-14 03:24 -0500
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-14 02:53 -0700
Re: Is it sill FORTH ? Coos Haak <chforth@hccnet.nl> - 2016-06-14 01:53 +0200
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-13 17:25 -0700
Re: Is it sill FORTH ? Marek Brunda <marekb@phoenics.org> - 2016-06-13 22:23 -0700
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-14 03:13 -0400
VALUE Lars Brinkhoff <lars.spam@nocrew.org> - 2016-06-14 09:17 +0200
Re: Is it sill FORTH ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-14 03:51 -0500
Re: Is it sill FORTH ? Marek Brunda <marekb@phoenics.org> - 2016-06-14 02:45 -0700
Re: Is it sill FORTH ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-15 04:21 -0500
Re: Is it sill FORTH ? Brad Eckert <hwfwguy@gmail.com> - 2016-08-05 21:02 -0700
Re: Is it sill FORTH ? "Elizabeth D. Rather" <erather@forth.com> - 2016-08-05 21:48 -1000
Re: Is it sill FORTH ? missycurl@gmail.com - 2016-08-06 05:37 -0700
Re: Is it sill FORTH ? humptydumpty <ouatubi@gmail.com> - 2016-08-06 06:37 -0700
Re: Is it sill FORTH ? Cecil Bayona <cbayona@cbayona.com> - 2016-08-06 08:53 -0500
Re: Is it sill FORTH ? humptydumpty <ouatubi@gmail.com> - 2016-08-06 07:18 -0700
Re: Is it sill FORTH ? humptydumpty <ouatubi@gmail.com> - 2016-08-06 07:40 -0700
Re: Is it sill FORTH ? "Elizabeth D. Rather" <erather@forth.com> - 2016-08-06 15:07 -1000
Re: Is it sill FORTH ? hughaguilar96@gmail.com - 2016-08-06 19:14 -0700
Re: Is it sill FORTH ? Chris Curl <ccurl609@gmail.com> - 2016-08-07 10:38 -0700
Re: Is it sill FORTH ? "Elizabeth D. Rather" <erather@forth.com> - 2016-08-07 20:57 -1000
Re: Is it sill FORTH ? Roelf Toxopeus <rt4all@nothishetnet.nl> - 2016-08-08 22:20 +0200
Re: Is it sill FORTH ? "Elizabeth D. Rather" <erather@forth.com> - 2016-08-08 12:14 -1000
Re: Is it sill FORTH ? hughaguilar96@gmail.com - 2016-08-09 00:29 -0700
Re: Is it sill FORTH ? hughaguilar96@gmail.com - 2016-08-06 19:30 -0700
Re: Is it sill FORTH ? Chris Curl <ccurl609@gmail.com> - 2016-08-07 07:42 -0700
Re: Is it sill FORTH ? hughaguilar96@gmail.com - 2016-08-07 13:34 -0700
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-08-08 16:13 -0400
Re: Is it sill FORTH ? Cecil Bayona <cbayona@cbayona.com> - 2016-08-08 15:36 -0500
Re: Is it sill FORTH ? jim.brakefield@ieee.org - 2016-08-06 06:28 -0700
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-08-08 16:42 -0400
Re: Is it sill FORTH ? "Elizabeth D. Rather" <erather@forth.com> - 2016-08-08 12:31 -1000
Re: Is it sill FORTH ? Paul Rubin <no.email@nospam.invalid> - 2016-08-08 16:38 -0700
Re: Is it sill FORTH ? mhx@iae.nl - 2016-08-08 22:49 -0700
Re: Is it sill FORTH ? Paul Rubin <no.email@nospam.invalid> - 2016-08-08 23:43 -0700
Re: Is it sill FORTH ? "Elizabeth D. Rather" <erather@forth.com> - 2016-08-08 22:16 -1000
Re: Is it sill FORTH ? JUERGEN <epldfpga@aol.com> - 2016-08-09 03:54 -0700
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-14 03:42 -0700
Re: Is it sill FORTH ? Marek Brunda <marekb@phoenics.org> - 2016-06-14 04:58 -0700
Re: Is it sill FORTH ? Mark Wills <markwills1970@gmail.com> - 2016-06-14 05:04 -0700
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-13 19:22 -0400
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-14 05:22 -0700
Re: Is it sill FORTH ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-14 12:41 +0000
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-14 06:30 -0700
Re: Is it sill FORTH ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-14 14:21 +0000
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-14 13:21 -0400
Re: Is it sill FORTH ? Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-06-14 17:45 -0400
Re: Is it sill FORTH ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-14 10:55 -0500
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-13 16:38 -0700
Re: Is it sill FORTH ? Paul Rubin <no.email@nospam.invalid> - 2016-06-13 16:41 -0700
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-14 03:54 -0700
Re: Is it sill FORTH ? Paul Rubin <no.email@nospam.invalid> - 2016-06-14 08:14 -0700
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-14 13:24 -0400
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-14 11:03 -0700
Re: Is it sill FORTH ? Paul Rubin <no.email@nospam.invalid> - 2016-06-14 12:42 -0700
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-14 13:28 -0700
Re: Is it sill FORTH ? Paul Rubin <no.email@nospam.invalid> - 2016-06-14 13:42 -0700
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-14 14:47 -0700
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-14 19:37 -0400
Re: Is it sill FORTH ? Marek Brunda <marekb@phoenics.org> - 2016-06-14 17:01 -0700
Re: Is it sill FORTH ? Marek Brunda <marekb@phoenics.org> - 2016-06-14 17:06 -0700
Re: Is it sill FORTH ? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-06-15 07:57 +0200
Re: Is it sill FORTH ? "Elizabeth D. Rather" <erather@forth.com> - 2016-06-15 16:12 +0200
Re: Is it sill FORTH ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-15 03:20 -0500
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-14 20:20 -0400
Re: Is it sill FORTH ? Marek Brunda <marekb@phoenics.org> - 2016-06-14 17:33 -0700
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-14 21:21 -0400
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-14 19:57 -0700
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-14 23:03 -0400
Re: Is it sill FORTH ? Paul Rubin <no.email@nospam.invalid> - 2016-06-14 20:31 -0700
Re: Is it sill FORTH ? pahihu <pahihu@gmail.com> - 2016-06-15 01:36 -0700
Re: Is it sill FORTH ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-18 12:54 +0000
Re: Is it sill FORTH ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-18 13:28 +0000
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-18 07:17 -0700
Re: Is it sill FORTH ? lawrencedo99@gmail.com - 2016-06-18 18:31 -0700
Re: Is it sill FORTH ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-25 14:55 +0000
Re: Is it sill FORTH ? lawrencedo99@gmail.com - 2016-06-25 19:58 -0700
Re: Is it sill FORTH ? hughaguilar96@gmail.com - 2016-06-18 21:14 -0700
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-14 19:32 -0400
Re: Is it sill FORTH ? Paul Rubin <no.email@nospam.invalid> - 2016-06-14 17:13 -0700
Re: Is it sill FORTH ? Marek Brunda <marekb@phoenics.org> - 2016-06-14 17:21 -0700
Re: Is it sill FORTH ? Paul Rubin <no.email@nospam.invalid> - 2016-06-14 18:36 -0700
Re: Is it sill FORTH ? "Elizabeth D. Rather" <erather@forth.com> - 2016-06-15 16:06 +0200
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-15 06:36 -0700
Re: Is it sill FORTH ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-15 09:20 -0500
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-15 10:55 -0700
Re: Is it sill FORTH ? Paul Rubin <no.email@nospam.invalid> - 2016-06-15 11:07 -0700
Re: Is it sill FORTH ? "Elizabeth D. Rather" <erather@forth.com> - 2016-06-15 16:20 +0200
Re: Is it sill FORTH ? mhx@iae.nl - 2016-06-15 11:19 -0700
Re: Is it sill FORTH ? hughaguilar96@gmail.com - 2016-06-14 22:10 -0700
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-15 01:33 -0400
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-14 19:31 -0400
Re: Is it sill FORTH ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-14 11:15 +0000
Re: Is it sill FORTH ? Mark Wills <markwills1970@gmail.com> - 2016-06-14 05:02 -0700
Re: Is it sill FORTH ? Julian Fondren <julian.fondren@gmail.com> - 2016-06-15 01:44 -0700
Re: Is it sill FORTH ? Julian Fondren <ayrnieu@gmail.com> - 2016-06-15 08:31 -0700
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-15 17:10 -0700
Re: Is it sill FORTH ? Bernd Paysan <bernd.paysan@gmx.de> - 2016-08-05 01:09 +0000
Re: Is it sill FORTH ? hughaguilar96@gmail.com - 2016-06-14 00:55 -0700
Re: Is it sill FORTH ? "Elizabeth D. Rather" <erather@forth.com> - 2016-06-14 16:15 +0200
Re: Is it sill FORTH ? hughaguilar96@gmail.com - 2016-06-15 15:43 -0700
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-15 17:03 -0700
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-15 22:36 -0400
Re: Is it sill FORTH ? Mat <dambere@web.de> - 2016-06-26 04:14 -0700
Re: Is it sill FORTH ? Coos Haak <chforth@hccnet.nl> - 2016-06-26 14:50 +0200
Re: Is it sill FORTH ? lawrencedo99@gmail.com - 2016-06-26 18:58 -0700
Re: Is it sill FORTH ? "Elizabeth D. Rather" <erather@forth.com> - 2016-06-26 22:41 -1000
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-06-14 19:31 -0400 |
| Message-ID | <njq453$23g$2@dont-email.me> |
| In reply to | #48156 |
On 6/14/2016 2:03 PM, krishna.myneni@ccreweb.org wrote: > I believe you are misstating the problem. Suppose you do have a hardware status register at address 0008. Then, it's perfectly reasonable to define an address constant as follows: > > 0008 CONSTANT HW_STATUS > > The issue is not about writing to the status register -- it is about remapping the register. If the system is configurable during run time so that the register can be mapped to a different address, say 001E, then changing the value of HW_STATUS makes sense. Sure, you can do it with VALUE instead of CONSTANT. So why would you use CONSTANT rather than VALUE? I don't follow. If the register can be remapped, then clearly it is *not* a constant. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-06-14 11:15 +0000 |
| Message-ID | <2016Jun14.131554@mips.complang.tuwien.ac.at> |
| In reply to | #48087 |
krishna.myneni@ccreweb.org writes:
>I find this behavior disturbing, unless there was a specific word/directive=
> to switch on inlining of constants or other specific compilation behavior.=
You can get the traditional fig-Forth-like behaviour for this kind of
usage on every standard system by defining
: constant create , does> @ ;
before defining any constants.
> Not sure if the behavior is consistent with ANS Forth
It is. A program that applies >BODY to a constant is not a standard
program, so the standard does not specify what happens when you store
to the address that >BODY produces. Also, if you look at the
specification of CONSTANT
<http://forth-standard.org/standard/core/CONSTANT>:
|CONSTANT
|( x "<spaces>name" -- )
|
|Skip leading space delimiters. Parse name delimited by a space. Create
|a definition for name with the execution semantics defined below.
|
|name is referred to as a "constant".
|
|name Execution:
|( -- x )
|
|Place x on the stack.
there is nothing there to suggest that you can change the constant.
Contrast this to the specification of VALUE
<http://forth-standard.org/standard/core/VALUE>:
|VALUE
|( x "<spaces>name" -- )
|
|Skip leading space delimiters. Parse name delimited by a space. Create
|a definition for name with the execution semantics defined below, with
|an initial value equal to x.
|
|name is referred to as a "value".
|
|name Execution:
|( -- x )
|
|Place x on the stack. The value of x is that given when name was
|created, until the phrase x TO name is executed, causing a new value
|of x to be assigned to name.
|
|TO name Run-time:
|( x -- )
|
|Assign the value x to name.
(This is the Forth-2012 variant, see
<https://www.complang.tuwien.ac.at/forth/dpans-html/dpans6.htm#6.2.2405>
for the Forth-94 variant, which is the same as far as the changability
is concerned).
>but it looks like i=
>t could lead to portability problems.
Gforth has had this behaviour since release 0.7.0 in 2008, and if my
memory serves me well (it not always does), this is the first
complaint about it, and it's not clear if the present complaint has
anything to do with an existing program. In any case, either there is
not much use of this traditional feature in existing code, or people
have learned how to get the behaviour they expect by redefining
CONSTANT.
Looking at a few Forth systems (VFX, SwiftForth, Gforth) they behave
remarkably similar. I gave them the following:
5 constant x \ ok
' x >body @ . \ 5 ok
: foo x ; \ ok
7 ' x >body ! \ ok
x . \ 7 ok
foo . \ 5 ok
and they all produced the output shown in the comments. So, in these
systems, >BODY works on constants, and you can change the constant,
but such a change does not extend to earlier compilations of the
constant. I guess the users of VFX and SwiftForth also did not
complain about this behaviour, or it would have been fixed.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2016-06-14 05:02 -0700 |
| Message-ID | <d2b9365e-fd3c-4651-aa46-f6871456eb7f@googlegroups.com> |
| In reply to | #48086 |
On Monday, 13 June 2016 21:58:01 UTC+1, crc wrote: > On Monday, June 13, 2016 at 4:41:08 PM UTC-4, Marek Brunda wrote: > > Gforth example session: > > > > 0 constant foo ok > > > > foo . 0 ok > > > > : bar foo ; ok > > > > bar . 0 ok > > > > 1234 ' foo >body ! ok > > > > foo . 1234 ok > > > > bar . 0 ok ( WTF? ) > > > > see bar > > > > : bar > > 0 ; ok ( OMG! ) > > > > Can anybody explain this? > > > gforth is inlining the constant: > 0 constant foo ok > see foo > 0 Constant foo > ok > : bar foo ; ok > see bar > : bar > 0 ; ok > > When you change foo, it doesn't affect the words defined using it since the constant value was inlined. Agree. It's in-lining it. I don't like because what was actually compiled does not match what the programmer *asked* to be compiled: : bar foo ; To me, the above says "please compile a reference to foo in this here definition of bar". GForth says "Nah I'll give you LIT 0. Ooh aren't I clever?" VFX does the same.
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-06-15 01:44 -0700 |
| Message-ID | <db9c76df-3e1f-4bc9-89fd-dcbd0a53b646@googlegroups.com> |
| In reply to | #48135 |
On Tuesday, June 14, 2016 at 7:02:10 AM UTC-5, Mark Wills wrote: > > Agree. It's in-lining it. I don't like because what was actually compiled > does not match what the programmer *asked* to be compiled: > > : bar foo ; > > To me, the above says "please compile a reference to foo in this here > definition of bar". > > GForth says "Nah I'll give you LIT 0. Ooh aren't I clever?" > > VFX does the same. OK. The user could've explicitly requested this behavior with: : bar [ foo ] literal ; A more common example of explicit inlining like that is with literal math, especially with units: : ten-million-times ( -- ) [ 1e7 f>s ] literal 0 do it loop ; : illuminate ( a -- ) [ 10 cells ] literal + on ; I bet though that it is more common, in the presence of an optimizing compiler, to drop the explicit compile-time calculation, and instead write: : ten-million-times ( -- ) [ 1e7 f>s ] literal 0 do it loop ; : illuminate ( a -- ) 10 cells + on ; knowing that the former example wouldn't be optimized to a literal, but that the latter will -- on a specific Forth. The portability cost is only that another Forth might run the code a bit slower; it won't behave differently. -- Julian
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <ayrnieu@gmail.com> |
|---|---|
| Date | 2016-06-15 08:31 -0700 |
| Message-ID | <2de8511d-273b-4458-8261-871d2507e966@googlegroups.com> |
| In reply to | #48185 |
On Wednesday, June 15, 2016 at 3:44:58 AM UTC-5, Julian Fondren wrote: > I bet though that it is more common, in the presence of an optimizing compiler, > to drop the explicit compile-time calculation, and instead write: > > : ten-million-times ( -- ) [ 1e7 f>s ] literal 0 do it loop ; > > : illuminate ( a -- ) 10 cells + on ; > > knowing that the former example wouldn't be optimized to a literal, but that > the latter will -- on a specific Forth. The portability cost is only that > another Forth might run the code a bit slower; it won't behave differently. > > > -- Julian To complete the thought, that last statement isn't true. lina64: AMDX86 ciforth 5.3.0 : x 2 CELLS . ; OK x 16 OK : 4* 4 * ; OK ' 4* ' CELLS 3 CELLS MOVE OK x 8 OK lina's a forth in which, if I change headers of the dictionary or the bodies of previously defined words, I should expect changes in the behavior of more recently defined words. There are people who think that Forths that support the above code and that CONSTANT changing code are 'real Forths' as opposed to other 'fake Forths' that would inline the definition CELLS or that would compile it and a literal parameter into a literal. It is more Forth-like to want a certain dictionary structure with a certain number of layers of indirection where everything works out the same way that it did in the examples of Starting Forth. The only alternative given to us is a weak, vague, standardized Forth-a-like which gives all the power to vendors who then build a fence in their systems that you, the lowly programmer, are not to cross. So that nobody here thinks that I'm talking about them, I'll just say that I'm thinking specifically of Mark V. Manning IV. I don't agree. I don't think it's any forthier to seek out a particular implementation with its particular guarantees of subtle behavior, no matter how much time passes. Rather, the forthy thing seems to be to seek efficiency and effectiveness, even to the point of having to abandon or to make compromises about less important system behavior like whether CONSTANTs can be changed. "I have to tell an optimizer to tip toe around certain words, but as a result everything is 20% faster? OK, sure. My programs are now usually 20% faster than those of the guy who can't be bothered edit his code to change a CONSTANT to a VALUE when his needs change." Forth has become smaller and faster and closer to the machine. There are also no fences in ANS systems that prevent you from discovering and using systems words or taking advantage of implementation details. You can still learn the details of a particular Forth system and write code that works particularly well with it. If there'd ever been an era when all Forths were Starting Forth compatible then maybe it could be said something has been lost, but from what I hear that was never the case. Forth standards did not overturn a lingua franca; they produced it. It is now possible to take your all-the-world-is-gforth code and document its environmental dependencies and make it easy for someone to port it. That was not possible before. It is now possible to write deliberately generic code that should run the same on anything. That was not possible before. It is still possible to write code only caring that it works for a particular system on a particular architecture for particular customers. And some behaviors like mutable constants will be seen in such cases. (Or, "it is now easier", "that was much harder". Whatever.) -- Julian
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2016-06-15 17:10 -0700 |
| Message-ID | <6df316a5-aa02-4f76-85da-574effb572dc@googlegroups.com> |
| In reply to | #48193 |
On Wednesday, June 15, 2016 at 10:31:18 AM UTC-5, Julian Fondren wrote: ... > There are people who think that Forths that support the above code and > that CONSTANT changing code are 'real Forths' as opposed to other 'fake > Forths' that would inline the definition CELLS or that would compile it > and a literal parameter into a literal. It is more Forth-like to want a > certain dictionary structure with a certain number of layers of > indirection where everything works out the same way that it did in the > examples of Starting Forth. The only alternative given to us is a weak, > vague, standardized Forth-a-like which gives all the power to vendors who > then build a fence in their systems that you, the lowly programmer, are > not to cross. > > So that nobody here thinks that I'm talking about them, I'll just say that > I'm thinking specifically of Mark V. Manning IV. > > I don't agree. I don't think it's any forthier to seek out a particular > implementation with its particular guarantees of subtle behavior, no > matter how much time passes. Rather, the forthy thing seems to be to seek > efficiency and effectiveness, even to the point of having to abandon or to > make compromises about less important system behavior like whether > CONSTANTs can be changed. > > "I have to tell an optimizer to tip toe around certain words, but as a > result everything is 20% faster? OK, sure. My programs are now usually > 20% faster than those of the guy who can't be bothered edit his code to > change a CONSTANT to a VALUE when his needs change." > > Forth has become smaller and faster and closer to the machine. There are > also no fences in ANS systems that prevent you from discovering and using > systems words or taking advantage of implementation details. You can > still learn the details of a particular Forth system and write code that > works particularly well with it. > > If there'd ever been an era when all Forths were Starting Forth compatible > then maybe it could be said something has been lost, but from what I hear > that was never the case. Forth standards did not overturn a lingua > franca; they produced it. It is now possible to take your > all-the-world-is-gforth code and document its environmental dependencies > and make it easy for someone to port it. That was not possible before. > It is now possible to write deliberately generic code that should run the > same on anything. That was not possible before. It is still possible to > write code only caring that it works for a particular system on a > particular architecture for particular customers. And some behaviors > like mutable constants will be seen in such cases. > > (Or, "it is now easier", "that was much harder". Whatever.) > > I tend to agree with most of what you say, I think, but I have to chew on it ... maybe for quite a long time. Krishna
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-08-05 01:09 +0000 |
| Message-ID | <no0ovd$ms7$4@dont-email.me> |
| In reply to | #48135 |
Am Tue, 14 Jun 2016 05:02:08 -0700 schrieb Mark Wills: > Agree. It's in-lining it. I don't like because what was actually > compiled does not match what the programmer *asked* to be compiled: > > : bar foo ; > > To me, the above says "please compile a reference to foo in this here > definition of bar". That's what a VALUE is for... CONSTANT means it's not going to change again. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-06-14 00:55 -0700 |
| Message-ID | <b058585f-e470-4d64-860a-a6a9007400c2@googlegroups.com> |
| In reply to | #48085 |
On Monday, June 13, 2016 at 1:41:08 PM UTC-7, Marek Brunda wrote: > Gforth example session: > > 0 constant foo ok > > foo . 0 ok > > : bar foo ; ok > > bar . 0 ok > > 1234 ' foo >body ! ok > > foo . 1234 ok > > bar . 0 ok ( WTF? ) > > see bar > > : bar > 0 ; ok ( OMG! ) > > Can anybody explain this? >BODY is only supposed to be used on CREATE DOES> words. I don't use CREATE DOES> at all, and hence don't use >BODY either. The problem with CREATE DOES> is that you are typically comma'ing constants in after the CREATE, but there is no standard way to declare them to be non-mutable so you have to fetch them out at run-time which is inefficient. Also, with >BODY it is possible to change these values, but this may screw everything up if they are supposed to be non-mutable --- for example, an array size is supposed to be non-mutable and you can't just change this because the array was allotted for that size and this isn't changing. Anyway --- just ignore CREATE DOES> and >BODY altogether --- for examples on how to define arrays, see 1ARRAY etc. and ARY in the novice-package.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-06-14 16:15 +0200 |
| Message-ID | <MfidnSO-TNf3jP3KnZ2dnUU78LvNnZ2d@supernews.com> |
| In reply to | #48085 |
On 6/13/16 10:41 PM, Marek Brunda wrote: > Gforth example session: > > 0 constant foo ok > > foo . 0 ok > > : bar foo ; ok > > bar . 0 ok > > 1234 ' foo >body ! ok > > foo . 1234 ok > > bar . 0 ok ( WTF? ) > > see bar > > : bar > 0 ; ok ( OMG! ) > > Can anybody explain this? > You have had several correct explanations. I'd like to offer a little historical background. Prior to ANS Forth, there were assumptions about how a Forth compiler worked. Forth83 mandated a 16-bit, indirect-threaded implementation. By the time the ANS Forth committee began work in the late 80's, 32-bit processors were becoming dominant, and the use of ROM and other non-writable program stores was getting common. As a result, the ANS Forth TC decided early on that its objective would be to mandate semantics (behavior), *not* implementation. That was a profound change, but one that most programmers have applauded over the years. Among the results is that many optimizations are in use, from in-lining CONSTANTs (as in this discussion) to full compilers that generate optimized machine-code. Modern Forths can be much, much faster than ever before. In addition, implementations for ROM/Flash/RAM environments are common. In olden times, CONSTANT was a word that would deliver a value, and the assumption was that it would be changed rarely, if ever. ANS Forth segregates that concept into two words: CONSTANT names a permanent, *immutable* named value, while VALUE provides a *changeable* named value. CONSTANTs can be in non-writable memory or compiled in place. It is perfectly ok for an implementation to provide a "classical" CONSTANT, and some still do, but a program that depends upon it will not work on many modern Forths. It is unfortunate, in a way, that Starting Forth was so clever and appealing, because it leads people to expect that Forth is an implementation, not a specification of behavior. But the 2nd ed. of Starting Forth was 30 years ago, and ANS Forth was 20 years ago. Forth has evolved like everything else in the computer world. Forth systems are faster, more powerful, have more facilities (host OS files, many other extensions), and run on the most modern platforms. It would be helpful for you to read some of the explanatory appendices to the current standard, Forth 2012 at https://forth-standard.org/standard/words. They compare the current standard to previous ones, and explain many of the decisions made. I hope this helps. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-06-15 15:43 -0700 |
| Message-ID | <e4736f9c-44a5-4a07-a6e6-83aab2f594c8@googlegroups.com> |
| In reply to | #48145 |
On Tuesday, June 14, 2016 at 7:15:08 AM UTC-7, Elizabeth D. Rather wrote: > Prior to ANS Forth, there were assumptions about how a Forth compiler > worked. Forth83 mandated a 16-bit, indirect-threaded implementation. By > the time the ANS Forth committee began work in the late 80's, 32-bit > processors were becoming dominant, and the use of ROM and other > non-writable program stores was getting common. As a result, the ANS > Forth TC decided early on that its objective would be to mandate > semantics (behavior), *not* implementation. That was a profound change, > but one that most programmers have applauded over the years. Having both VARIABLE and VALUE is redundant, because they both provide a way to define a global cell variable. Pointless redundancy, of course, is one of the many reasons why Charles Moore described ANS-Forth as being 100x more complicated than necessary. In practice, most Forth programmer will use either VARIABLE or VALUE but not the other. 1.) Forth traditionalists use VARIABLE because it is a lot more robust. The address can be passed as a parameter. Also, it is a lot more consistent because @ and ! can be used on any address. The address might have been provided by VARIABLE or it might have been provided by ALLOCATE (typically the pointer to a struct). 2.) C programmers use VALUE because it allows them to write Forth like an RPN-version of C. Then they complain that there is no & in Forth that allows them to obtain the address of their VALUEs. For the most part, whenever I see VALUE being used in a Forth program I know that the program was written by a C programmer and it is almost certainly going to be garbage. I ignore VALUE completely, and I suspect that almost all Forth programmers do also --- VALUE is really useless --- VALUE is cruft that will be discarded in Straight Forth. One of the major reasons why ANS-Forth was a failure was that ANS-Forth standardized implementation rather than behavior. ANS-Forth defined local variables to be like VALUE in that they are assigned with TO and there is no way to obtain their address. This was done because nobody at Forth Inc. knew how to write an optimizing compiler. They made locals like VALUE so the locals could be stored in registers. They didn't understand that an analytic optimizing compiler can have locals be like variables that are accessed with @ and ! and it can yet store thsee locals in registers anyway. Realistically, you can't store all of your locals in registers because there aren't enough registers. The locals are stored in a local-frame and they do have addresses. The locals can temporarily be held in registers however --- the analytic optimizer has to keep track of the address on the stack and make sure that it is never passed into a sub-function as a parameter but is only used within the function, in which case the local can be held in a register and the @ and ! compiled as load and store instructions respectively. When Elizabeth Rather wrote ANS-Forth she was standardizing implementation rather than behavior --- she was imposing the incompetence of Forth Inc. on to the entire Forth community --- ANS-Forth is utterly useless and needs to be abandoned if Forth is ever going to succeed.
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2016-06-15 17:03 -0700 |
| Message-ID | <b68dbd26-16d4-4bb1-bd49-093700004951@googlegroups.com> |
| In reply to | #48145 |
On Tuesday, June 14, 2016 at 9:15:08 AM UTC-5, Elizabeth D. Rather wrote: > ... the ANS > Forth TC decided early on that its objective would be to mandate > semantics (behavior), *not* implementation. That was a profound change, > but one that most programmers have applauded over the years. > Including this programmer. Specifying behavior rather than implementation is critical to portability and analyzing a program. However, it should be remembered that specifying behavior too loosely can permit such vastly different implementations that expected features may be lost in the process. > Among the results is that many optimizations are in use, from in-lining > CONSTANTs (as in this discussion) ... The behavior of constants in ANS-Forth is only peripheral to the concern that behavior of words may have been too loosely defined in other cases. As far as constants go, I don't have a problem with ANS Forth. I'm more worried about the idea of loosening behavior to permit portability to very resource-constrained systems, at the expense of reducing the control of the system by Forth users/programmers. For specific domains such as embedded systems, making an extra word set seems like it might have been appropriate. In any case we have had to go back, IIRC, and tighten behavior specs for a couple of words in Forth 200x. That, of course, is to be expected for any standard (or draft standard). > > It is unfortunate, in a way, that Starting Forth was so clever and > appealing, because it leads people to expect that Forth is an > implementation, not a specification of behavior. But the 2nd ed. of > Starting Forth was 30 years ago, and ANS Forth was 20 years ago. Forth > has evolved like everything else in the computer world. Forth systems > are faster, more powerful, have more facilities (host OS files, many > other extensions), and run on the most modern platforms. > IMO, it's generally detrimental to Forth to sacrifice specific behavior which give users more control for the sake of speed. Regards, Krishna
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-06-15 22:36 -0400 |
| Message-ID | <njt3bt$g8j$1@dont-email.me> |
| In reply to | #48207 |
On 6/15/2016 8:03 PM, krishna.myneni@ccreweb.org wrote: > > IMO, it's generally detrimental to Forth to sacrifice specific behavior which give users more control for the sake of speed. Or you could just use the words the way they were intended. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Mat <dambere@web.de> |
|---|---|
| Date | 2016-06-26 04:14 -0700 |
| Message-ID | <f192a8ab-3fcd-4c7e-adcc-a83a37c73efc@googlegroups.com> |
| In reply to | #48085 |
Is it sill FORTH ? NO.
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2016-06-26 14:50 +0200 |
| Message-ID | <1ahztexlg48h2.19bgaqq9zxj41$.dlg@40tude.net> |
| In reply to | #48536 |
Op Sun, 26 Jun 2016 04:14:04 -0700 (PDT) schreef Mat: > Is it sill FORTH ? > > NO. The proper name is Forth. It is not an acronym like BASIC groet Coos
[toc] | [prev] | [next] | [standalone]
| From | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-06-26 18:58 -0700 |
| Message-ID | <a5734a43-8b5f-41c7-a244-8fae014c1836@googlegroups.com> |
| In reply to | #48537 |
On Monday, June 27, 2016 at 12:50:49 AM UTC+12, Coos Haak wrote: > The proper name is Forth. It is not an acronym like BASIC It was supposed to be FOURTH, but the OS only allowed 5-character names, and they had to be all uppercase.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-06-26 22:41 -1000 |
| Message-ID | <ze6dnRRFp7Ape-3KnZ2dnUU7-evNnZ2d@supernews.com> |
| In reply to | #48549 |
On 6/26/16 3:58 PM, lawrencedo99@gmail.com wrote: > On Monday, June 27, 2016 at 12:50:49 AM UTC+12, Coos Haak wrote: > >> The proper name is Forth. It is not an acronym like BASIC > > It was supposed to be FOURTH, but the OS only allowed 5-character names, and they had to be all uppercase. A true historical tidbit, but Forth has been the accepted name for the language since the mid-1970's. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [standalone]
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
Back to top | Article view | comp.lang.forth
csiph-web