Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #36085 > unrolled thread
| Started by | josv@planet.nl |
|---|---|
| First post | 2015-01-28 04:07 -0800 |
| Last post | 2015-02-04 12:54 +0000 |
| Articles | 15 on this page of 75 — 16 participants |
Back to article view | Back to comp.lang.forth
Reducing C, josv@planet.nl - 2015-01-28 04:07 -0800
Re: Reducing C, Mark Wills <markwills1970@gmail.com> - 2015-01-28 05:02 -0800
Re: Reducing C, Howerd <howerdo@yahoo.co.uk> - 2015-01-28 07:42 -0800
Re: Reducing C, josv@planet.nl - 2015-01-28 08:17 -0800
Re: Reducing C, "HAA" <someone@microsoft.com> - 2015-01-29 03:37 +1100
Re: Reducing C, visualforth@rocketmail.com - 2015-01-28 12:53 -0800
Re: Reducing C, humptydumpty <ouatubi@gmail.com> - 2015-01-28 14:03 -0800
Re: Reducing C, humptydumpty <ouatubi@gmail.com> - 2015-01-28 20:39 -0800
Re: Reducing C, humptydumpty <ouatubi@gmail.com> - 2015-01-28 20:51 -0800
Re: Reducing C, josv@planet.nl - 2015-01-29 06:28 -0800
Re: Reducing C, hughaguilar96@gmail.com - 2015-01-29 21:18 -0800
Re: Reducing C, josv@planet.nl - 2015-01-30 05:38 -0800
Re: Reducing C, "Alex McDonald" <blog@rivadpm.com> - 2015-01-30 15:11 +0000
Re: Reducing C, josv@planet.nl - 2015-01-30 08:34 -0800
Re: Reducing C, hughaguilar96@gmail.com - 2015-01-31 20:26 -0800
Re: Reducing C, josv@planet.nl - 2015-02-01 11:16 -0800
Re: Reducing C, "HAA" <someone@microsoft.com> - 2015-02-02 11:03 +1100
Re: Reducing C, "Elizabeth D. Rather" <erather@forth.com> - 2015-02-01 14:13 -1000
Re: Reducing C, hughaguilar96@gmail.com - 2015-02-01 17:22 -0800
Re: Reducing C, hughaguilar96@gmail.com - 2015-02-01 17:36 -0800
Re: Reducing C, "Alex McDonald" <blog@rivadpm.com> - 2015-02-02 11:40 +0000
Re: Reducing C, Mark Wills <markwills1970@gmail.com> - 2015-02-02 05:24 -0800
Netiquette was: Re: Reducing C, albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-02-02 13:40 +0000
Re: Reducing C, "Alex McDonald" <blog@rivadpm.com> - 2015-02-02 15:08 +0000
Politeness, was Re: Reducing C, "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-02-02 19:30 -0500
Re: Politeness, was Re: Reducing C, awegel@arcor.de (Alexander Wegel) - 2015-02-03 01:57 +0100
Re: Politeness, was Re: Reducing C, "Alex McDonald" <blog@rivadpm.com> - 2015-02-03 11:59 +0000
Re: Reducing C, josv@planet.nl - 2015-02-03 02:31 -0800
Re: Reducing C, "Alex McDonald" <blog@rivadpm.com> - 2015-02-03 12:06 +0000
Re: Reducing C, "Alex McDonald" <blog@rivadpm.com> - 2015-02-03 19:47 +0000
Re: Reducing C, josv@planet.nl - 2015-02-03 14:06 -0800
Re: Reducing C, hughaguilar96@gmail.com - 2015-02-03 21:19 -0800
Re: Reducing C, "Alex McDonald" <blog@rivadpm.com> - 2015-02-04 12:10 +0000
Re: Reducing C, hughaguilar96@gmail.com - 2015-02-04 18:22 -0800
Re: Reducing C, hughaguilar96@gmail.com - 2015-02-04 19:04 -0800
Re: Reducing C, stephen@mpeforth.com (Stephen Pelc) - 2015-02-05 11:33 +0000
Re: Reducing C, hughaguilar96@gmail.com - 2015-02-05 19:39 -0800
Re: Reducing C, stephen@mpeforth.com (Stephen Pelc) - 2015-02-06 11:50 +0000
Re: Reducing C, hughaguilar96@gmail.com - 2015-02-06 11:28 -0800
Re: Reducing C, Mark Wills <markwills1970@gmail.com> - 2015-02-05 04:37 -0800
Re: Reducing C, "HAA" <someone@microsoft.com> - 2015-02-06 21:47 +1100
Re: Reducing C, "HAA" <someone@microsoft.com> - 2015-02-13 09:45 +1100
Re: Reducing C, Mark Wills <markwills1970@gmail.com> - 2015-02-13 05:24 -0800
Re: Reducing C, "HAA" <someone@microsoft.com> - 2015-02-15 13:53 +1100
Re: Reducing C, Mark Wills <markwills1970@gmail.com> - 2015-02-16 01:07 -0800
Re: Reducing C, anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-02-16 15:02 +0000
Re: Reducing C, "HAA" <someone@microsoft.com> - 2015-02-19 14:22 +1100
Re: Reducing C, "Alex McDonald" <blog@rivadpm.com> - 2015-02-05 13:18 +0000
Re: Reducing C, josv@planet.nl - 2015-02-05 07:02 -0800
Re: Reducing C, josv@planet.nl - 2015-02-05 07:14 -0800
Re: Reducing C, josv@planet.nl - 2015-02-07 07:12 -0800
Re: Reducing C, josv@planet.nl - 2015-02-04 07:12 -0800
Re: Reducing C, november.nihal@gmail.com - 2015-02-04 09:38 -0800
Re: Reducing C, "Alex McDonald" <blog@rivadpm.com> - 2015-02-04 21:08 +0000
Re: Reducing C, josv@planet.nl - 2015-02-05 06:45 -0800
Re: Reducing C, "Alex McDonald" <blog@rivadpm.com> - 2015-02-06 13:21 +0000
Re: Reducing C, awegel@arcor.de (Alexander Wegel) - 2015-02-05 17:36 +0100
Re: Reducing C, "Alex McDonald" <blog@rivadpm.com> - 2015-02-05 17:06 +0000
Re: Reducing C, awegel@arcor.de (Alexander Wegel) - 2015-02-05 18:17 +0100
Re: Reducing C, "Elizabeth D. Rather" <erather@forth.com> - 2015-02-05 10:40 -1000
Re: Reducing C, hughaguilar96@gmail.com - 2015-02-05 20:25 -0800
Re: Reducing C, "Alex McDonald" <blog@rivadpm.com> - 2015-02-06 11:39 +0000
Re: Reducing C, awegel@arcor.de (Alexander Wegel) - 2015-02-06 12:48 +0100
Re: Reducing C, hughaguilar96@gmail.com - 2015-02-06 17:28 -0800
Re: Reducing C, awegel@arcor.de (Alexander Wegel) - 2015-02-07 12:38 +0100
Re: Reducing C, albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-02-06 14:40 +0000
Re: Reducing C, hughaguilar96@gmail.com - 2015-02-06 18:33 -0800
Re: Reducing C, anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-02-06 13:49 +0000
Re: Reducing C, "Alex McDonald" <blog@rivadpm.com> - 2015-02-06 14:15 +0000
Re: Reducing C, hughaguilar96@gmail.com - 2015-02-03 21:23 -0800
Re: Reducing C, "Alex McDonald" <blog@rivadpm.com> - 2015-02-04 12:41 +0000
Re: Reducing C, "WJ" <w_a_x_man@yahoo.com> - 2015-02-04 18:19 +0000
Re: Reducing C, "WJ" <w_a_x_man@yahoo.com> - 2015-02-04 20:54 +0000
Re: Reducing C, "WJ" <w_a_x_man@yahoo.com> - 2015-02-04 09:41 +0000
Re: Reducing C, "Alex McDonald" <blog@rivadpm.com> - 2015-02-04 12:54 +0000
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-02-05 20:25 -0800 |
| Message-ID | <ff3b3174-a093-4775-9683-75f4cdd3d902@googlegroups.com> |
| In reply to | #36313 |
On Thursday, February 5, 2015 at 1:41:01 PM UTC-7, Elizabeth D. Rather wrote:
> Of course, if you then define another word of any kind, all bets are
> off. On systems that segregate code and data spaces, the next data
> *might* be contiguous, but on systems with intermingled code and data
> they will not.
I was mistaken when I said that the DOES> code would get compiled after the CREATE executes --- I had compile-time and run-time mixed up in my mind.
Still though, in a system that mixes code and data, there is no guarantee that something won't be compiled into the dictionary between LONG$: and ;CHARS. For example:
long$: hey
char H
char E
char Y dup constant the-letter-Y
char !
;chars
If code and data are mixed, the constant is going to get compiled into the CREATE's body, which will mess everything up. My technique of putting the DOES> in ;CHARS isn't necessarily going to work either though. CONSTANT might be defined like this:
: constant ( n -- )
create ,
does> @ ;
If this is true, then the DOES> in ;CHARS will crash --- so there is yet another bug in my program (I will be the one blamed when it crashes).
All of this confusion could have been solved if ANS-Forth would have just stated that code and data have to be separate.
Why would anybody mix code and data together??? Anybody who knows anything about assembly-language should know that this is never done. In every assembly-language, code and data are put in different sections (.text for code, .bss for uninitialized data and .data for initialized data). There are several reasons why this is true:
1.) On the 16-bit x86, code and data had to be in different 64K segments pointed to be CS and DS respectively (although in PolyForth CS and DS were set the same, so code and data could be mixed together, but they were limited to 64K total).
2.) On small computers, code and data are usually in different kinds of memory (EPROM and RAM in the 1980s, or FLASH and RAM now).
3.) On desktop-computers that have only RAM (such as the x86), there are separate code and data caches --- if code and data are intermingled as done in SwiftForth, then you end up with code in the data-cache and data in the code-cache just because they were adjacent in memory --- this is very inefficient.
The fact that you wrote ANS-Forth to allow code and data to be mixed together, makes it obvious that you don't know anything about assembly-language --- anybody with a modicum of experience in assembly-language would know better --- this is the mistake of a total beginner.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-02-06 11:39 +0000 |
| Message-ID | <mb2945$dgt$1@dont-email.me> |
| In reply to | #36319 |
on 06/02/2015 04:25:06, hugh wrote: > On Thursday, February 5, 2015 at 1:41:01 PM UTC-7, Elizabeth D. Rather > wrot e: > > All of this confusion could have been solved if ANS-Forth would have > just s tated that code and data have to be separate. > > Why would anybody mix code and data together??? Anybody who knows > anything about assembly-language should know that this is never done. > In every assem bly-language, code and data are put in different > sections (.text for code, .bss for uninitialized data and .data for > initialized data). There are seve ral reasons why this is true: > 1.) On the 16-bit x86, code and data had to be in different 64K > segments po inted to be CS and DS respectively (although in PolyForth > CS and DS were se t the same, so code and data could be mixed > together, but they were limited to 64K total). > 2.) On small computers, code and data are usually in different kinds > of mem ory (EPROM and RAM in the 1980s, or FLASH and RAM now). > 3.) On desktop-computers that have only RAM (such as the x86), there > are se parate code and data caches --- if code and data are > intermingled as done i n SwiftForth, then you end up with code in the > data-cache and data in the c ode-cache just because they were adjacent > in memory --- this is very ineffi cient. > In the specific case of a native code compiler or STC for an x86 then what you say has some validity. But in an ITC or DTC the code is data. > The fact that you wrote ANS-Forth to allow code and data to be mixed > togeth er, makes it obvious that you don't know anything about > assembly-language - Another tedious ad-hominem doesn't make you right.
[toc] | [prev] | [next] | [standalone]
| From | awegel@arcor.de (Alexander Wegel) |
|---|---|
| Date | 2015-02-06 12:48 +0100 |
| Message-ID | <1lzf9hk.1qv232y1cyqmaoN%awegel@arcor.de> |
| In reply to | #36319 |
<hughaguilar96@gmail.com> wrote: > long$: hey > char H > char E > char Y dup constant the-letter-Y > char ! > ;chars > > If code and data are mixed, the constant is going to get > compiled into the CREATE's body, which will mess everything up. Sure - if you break it, then it's broken. Not even separate code and data would help you with this (do you fathom why?). The point is that you pull (to cite someone absent) this out of your arse in order to make yourself look smart. It's really just mud-flinging. So, go fuck yourself.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-02-06 17:28 -0800 |
| Message-ID | <9fe3e8be-9733-4dff-8ce4-0eb6387e9af2@googlegroups.com> |
| In reply to | #36324 |
On Friday, February 6, 2015 at 4:48:57 AM UTC-7, Alexander Wegel wrote: > <hughaguilar96@gmail.com> wrote: > > > long$: hey > > char H > > char E > > char Y dup constant the-letter-Y > > char ! > > ;chars > > > > If code and data are mixed, the constant is going to get > > compiled into the CREATE's body, which will mess everything up. > > Sure - if you break it, then it's broken. Not even separate code and > data would help you with this (do you fathom why?). In my language, this kind of thing is legal and works fine. All definitions compile into code. These two definitions compile into the same code: char Y constant the-letter-Y : the-letter-Y ( -- n ) [char] Y ; Also, CREATE is defined like this: : create here constant ; I use <BUILDS with DOES> --- CREATE does not work with DOES>. CREATE does not involve <BUILDS at all, so the DOES> in ;CHARS will still match up with the <BUILDS in LONG$: without any problem, even if a CREATE is used between LONG$: and ;CHARS. All definitions go into code memory, and nothing goes into data memory --- the only words that put anything into data memory, are comma and c-comma --- so I have the freedom to define definitions without getting in the way of comma and c-comma. > The point is that you pull (to cite someone absent) this out of your > arse in order to make yourself look smart. It's really just > mud-flinging. So, go fuck yourself. Elizabeth Rather used to praise John Passaniti to the sky. He was her attack-poodle --- he would yap at her enemies, similar to the way that you yap at me --- she would pat him on the head and praise him for this. Passaniti suddenly disappeared. I don't think he disappeared voluntarily though, because he was obviously enjoying himself on comp.lang.forth greatly --- more likely, he got incarcerated in jail or in a psychiatric institution, and he no longer has access to the internet. Now that Passaniti is gone, Elizabeth Rather needs a new attack-poodle. You seem to be applying for the job --- I think that you are fully the equal of Passaniti --- I expect Elizabeth Rather to soon begin praising you in the same way that she praised Passaniti. Make an effort to be more vulgar --- vulgar language is what Elizabeth Rather wants on comp.lang.forth. Also, if you aren't homosexual, then fake it --- Elizabeth Rather wants her attack-poodle to be gay, so she can accuse her enemies (me) of being homophobic. ANS-Forth is a cult --- it is all about getting a pat on the head from the cult leader --- if you are loyal, Elizabeth Rather may even put you on the Forth-200x committee, possibly replacing Stephan Pelc whose loyalty has always been half-hearted at best (in many cases, VFX provides work-arounds for the flaws in ANS-Forth design, causing Forth code written for VFX to be non-standard and vendor-specific).
[toc] | [prev] | [next] | [standalone]
| From | awegel@arcor.de (Alexander Wegel) |
|---|---|
| Date | 2015-02-07 12:38 +0100 |
| Message-ID | <1lzgfsk.oe8gck19d9ipsN%awegel@arcor.de> |
| In reply to | #36341 |
<hughaguilar96@gmail.com> wrote: > On Friday, February 6, 2015 at 4:48:57 AM UTC-7, Alexander Wegel wrote: > > <hughaguilar96@gmail.com> wrote: > > > > > long$: hey > > > char H > > > char E > > > char Y dup constant the-letter-Y > > > char ! > > > ;chars > > > > > > If code and data are mixed, the constant is going to get > > > compiled into the CREATE's body, which will mess everything up. > > > > Sure - if you break it, then it's broken. Not even separate code and > > data would help you with this (do you fathom why?). > > In my language, this kind of thing is legal and works fine. Oh i forgot - you never lose an argument. <shit snipped> You know where you can stick your lies.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-02-06 14:40 +0000 |
| Message-ID | <54d4d271$0$6861$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #36319 |
In article <ff3b3174-a093-4775-9683-75f4cdd3d902@googlegroups.com>, <hughaguilar96@gmail.com> wrote: >On Thursday, February 5, 2015 at 1:41:01 PM UTC-7, >Elizabeth D. Rather wrote: >> Of course, if you then define another word of any >kind, all bets are >> off. On systems that segregate code and data >spaces, the next data >> *might* be contiguous, but on systems with >intermingled code and data >> they will not. > >I was mistaken when I said that the DOES> code >would get compiled after the CREATE executes --- I >had compile-time and run-time mixed up in my mind. > >Still though, in a system that mixes code and data, >there is no guarantee that something won't be >compiled into the dictionary between LONG$: and >;CHARS. For example: > >long$: hey >char H >char E >char Y dup constant the-letter-Y >char ! >;chars > >If code and data are mixed, the constant is going >to get compiled into the CREATE's body, which will >mess everything up. My technique of putting the >DOES> in ;CHARS isn't necessarily going to work >either though. CONSTANT might be defined like this: > >: constant ( n -- ) > create , > does> @ ; > >If this is true, then the DOES> in ;CHARS will >crash --- so there is yet another bug in my program >(I will be the one blamed when it crashes). > >All of this confusion could have been solved if >ANS-Forth would have just stated that code and data >have to be separate. > >Why would anybody mix code and data together??? Mixing code and data is the essence of ai. The ability to do so make LISP and Forth (and assembler) stand out as the most powerful languages. I don't expect you to understand this, but others may. 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]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-02-06 18:33 -0800 |
| Message-ID | <44ebe4e1-c0f4-4496-af5c-c2e9e54fe768@googlegroups.com> |
| In reply to | #36332 |
On Friday, February 6, 2015 at 7:40:51 AM UTC-7, Albert van der Horst wrote: > In article <ff3b3174-a093-4775-9683-75f4cdd3d902@googlegroups.com>, > <hughaguilar96@gmail.com> wrote: > >All of this confusion could have been solved if > >ANS-Forth would have just stated that code and data > >have to be separate. > > > >Why would anybody mix code and data together??? > Mixing code and data is the essence of ai. > The ability to do so make LISP and Forth (and > assembler) stand out as the most powerful languages. > I don't expect you to understand this, but others may. I wasn't going to respond to this, but now I'm bored so I suppose I will --- to a large extent, boredom is the engine that drives comp.lang.forth. In Lisp, source-code is represented as nested lists, and data is also represented as nested lists, so source-code is data --- it is possible to manipulate and generate Lisp source-code in the same way that you would manipulate and generate data. Note however, that this is source-code not machine-code (duh!). It is typical of Wikipedia wind-bags to toss around phrases such as: "the essence of AI." It is also common for Wikipedia editors to not know the difference between source-code and machine-code. So you are obviously a Wikipedia editor. But you have already admitted to being a Wikipedia editor: https://groups.google.com/forum/#!searchin/comp.lang.forth/lc53/comp.lang.forth/qqlp1gZnVic/kjeAwWCaR1MJ Normally, people don't admit to being Wikipedia editors because it is something to be ashamed of --- this is why almost all Wikipedia editors use pseudonyms --- but you seem to not realize that admitting to being a Wikipedia editor will result in nobody ever taking you seriously again (duh!).
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-02-06 13:49 +0000 |
| Message-ID | <2015Feb6.144948@mips.complang.tuwien.ac.at> |
| In reply to | #36309 |
"Alex McDonald" <blog@rivadpm.com> writes:
>The standard says for 3.3.3.2 Contiguous regions;
>
>"CREATE establishes the beginning of a contiguous region of data space,
>whose starting address is returned by the CREATEd definition. This region
>is terminated by compiling the next definition."
>
>and in the appendix A.6.1.1250 DOES> says;
>
>"DOES> effectively ends one definition and begins another as far as local
>variables and control-flow structures are concerned."
>
>The text here is not normative, but I read it to mean that at *** below
>
>: X CREATE , DOES> ( *** ) @ ;
>
>then all bets are off after the DOES> and that the region there is not
>contiguous with the region at CREATE. I read it as 20 X 10 , is not
>guaranteed to generate two contiguos cells containing 20 10.
I have amended your example to
: X CREATE , DOES> ( *** ) @ ;
20 X foo 10 ,
The description in A.6.1.1250 refers to what happens during the
compilation semantics of DOES>. It ends the colon definition started
with ": X", and starts a new one. It does not refer to what happens
at run-time. Note that the sentence before the one you cited refers
to the findability of X, not of FOO.
DOES> does not add a new definition to the dictionary at run-time, so
the run-time semantics of DOES> do not end a contiguous region, and
the FOO starts a contiguous region that contains a cell containing 20
followed by a cell containing 10.
Here's the run-time semantics of DOES>:
|Run-time: ( -- ) ( R: nest-sys1 -- )
|
|Replace the execution semantics of the most recent definition,
|referred to as name, with the name execution semantics given
|below. Return control to the calling definition specified by
|nest-sys1. An ambiguous condition exists if name was not defined with
|CREATE or a user-defined word that calls CREATE.
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-02-06 14:15 +0000 |
| Message-ID | <mb2i9a$gmp$1@dont-email.me> |
| In reply to | #36330 |
on 06/02/2015 13:49:43, wrote: > "Alex McDonald" <blog@rivadpm.com> writes: >>The standard says for 3.3.3.2 Contiguous regions; >> >>"CREATE establishes the beginning of a contiguous region of data space, >>whose starting address is returned by the CREATEd definition. This region >>is terminated by compiling the next definition." >> >>and in the appendix A.6.1.1250 DOES> says; >> >>"DOES> effectively ends one definition and begins another as far as local >>variables and control-flow structures are concerned." >> >>The text here is not normative, but I read it to mean that at *** below >> >>: X CREATE , DOES> ( *** ) @ ; >> >>then all bets are off after the DOES> and that the region there is not >>contiguous with the region at CREATE. I read it as 20 X 10 , is not >>guaranteed to generate two contiguos cells containing 20 10. > > I have amended your example to > >: X CREATE , DOES> ( *** ) @ ; > 20 X foo 10 , > > The description in A.6.1.1250 refers to what happens during the > compilation semantics of DOES>. It ends the colon definition started > with ": X", and starts a new one. It does not refer to what happens > at run-time. Note that the sentence before the one you cited refers > to the findability of X, not of FOO. > > DOES> does not add a new definition to the dictionary at run-time, so > the run-time semantics of DOES> do not end a contiguous region, and > the FOO starts a contiguous region that contains a cell containing 20 > followed by a cell containing 10. > > Here's the run-time semantics of DOES>: > >|Run-time: ( -- ) ( R: nest-sys1 -- ) >| >|Replace the execution semantics of the most recent definition, >|referred to as name, with the name execution semantics given >|below. Return control to the calling definition specified by >|nest-sys1. An ambiguous condition exists if name was not defined with >|CREATE or a user-defined word that calls CREATE. > > - anton Thanks to you & Elizabeth for the clarification.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-02-03 21:23 -0800 |
| Message-ID | <6665537d-fd72-462e-82fc-fa62541b48b6@googlegroups.com> |
| In reply to | #36256 |
On Tuesday, February 3, 2015 at 12:47:02 PM UTC-7, Alex McDonald wrote: > here 'a' 'b' 'c' '!' 4 n2cstring count type It is a good thing that the count (4) was less then 10, as Alex would have needed to take off his shoes otherwise --- and Alex would have failed completely if there had been more than 20 characters.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-02-04 12:41 +0000 |
| Message-ID | <mat3vq$lrv$1@dont-email.me> |
| In reply to | #36260 |
on 04/02/2015 05:23:08, wrote: > On Tuesday, February 3, 2015 at 12:47:02 PM UTC-7, Alex McDonald > > wrote: >> here 'a' 'b' 'c' '!' 4 n2cstring count type > wrote: > > It is a good thing that the count (4) was less then 10, as Alex would > have needed to take off his shoes otherwise --- and Alex would have Less than 10? You've mistaken me for Bart Simpson. > failed completely if there had been more than 20 characters. > Eat my shorts.
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2015-02-04 18:19 +0000 |
| Message-ID | <matnqq$d4h$1@dont-email.me> |
| In reply to | #36256 |
Alex McDonald wrote:
>
> : n2str ( cn ... c1 n -- \ for 0 <= n <= MAX-CHAR )
> \ build string |c1|...|cn| at HERE
> ?dup if
> here swap allot here 1-
> do i c! -1 +loop
> then ;
>
> : n2cstring ( cn ... c1 n -- \ for 0 <= n <= MAX-CHAR )
> dup c, n2str ;
>
> : n2lstring ( cn ... c1 n -- \ for 0 <= n )
> dup , n2str ;
>
> here 0 n2cstring count type
> here 'a' 'b' 'c' '!' 4 n2cstring count type
Gauche Scheme:
(use srfi-42)
(print
(string-ec (: c
" Tsv xivzgfiv wlvhm'g gsrmp gszg gsv xlnkfgvi xzm xlfmg,
hl sv szh gl gvoo gsv xlnkfgvi sld nzmb xszizxgvih sv
rh szmwrmt rg.
Tsv uzxg gszg ANS Fligs rh srh ozmtfztv lu xslrxv gvooh
nv zoo gszg I mvvw gl pmld zylfg ANS Fligs.
Am fogiz kirnrgrev, fogiz xifwv, fogiz xofmpb ozmtfztv
gszg nzpvh kiltiznnrmt ztlmrarmtob wruurxfog.")
(if (char-lower-case? c)
(integer->char
(+ (char->integer #\a) (- (char->integer #\z) (char->integer c))))
c)))
===>
The creature doesn't think that the computer can count,
so he has to tell the computer how many characters he
is handing it.
The fact that ANS Forth is his language of choice tells
me all that I need to know about ANS Forth.
An ultra primitive, ultra crude, ultra clunky language
that makes programming agonizingly difficult.
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2015-02-04 20:54 +0000 |
| Message-ID | <mau0tr$jjk$2@dont-email.me> |
| In reply to | #36281 |
WJ wrote:
> Alex McDonald wrote:
>
> >
> > : n2str ( cn ... c1 n -- \ for 0 <= n <= MAX-CHAR )
> > \ build string |c1|...|cn| at HERE
> > ?dup if
> > here swap allot here 1-
> > do i c! -1 +loop
> > then ;
> >
> > : n2cstring ( cn ... c1 n -- \ for 0 <= n <= MAX-CHAR )
> > dup c, n2str ;
> >
> > : n2lstring ( cn ... c1 n -- \ for 0 <= n )
> > dup , n2str ;
> >
> > here 0 n2cstring count type
> > here 'a' 'b' 'c' '!' 4 n2cstring count type
>
>
> Gauche Scheme:
>
> (use srfi-42)
>
> (print
> (string-ec (: c
> " Tsv xivzgfiv wlvhm'g gsrmp gszg gsv xlnkfgvi xzm xlfmg,
> hl sv szh gl gvoo gsv xlnkfgvi sld nzmb xszizxgvih sv
> rh szmwrmt rg.
>
> Tsv uzxg gszg ANS Fligs rh srh ozmtfztv lu xslrxv gvooh
> nv zoo gszg I mvvw gl pmld zylfg ANS Fligs.
>
> Am fogiz kirnrgrev, fogiz xifwv, fogiz xofmpb ozmtfztv
> gszg nzpvh kiltiznnrmt ztlmrarmtob wruurxfog.")
> (if (char-lower-case? c)
> (integer->char
> (+ (char->integer #\a) (- (char->integer #\z) (char->integer c))))
> c)))
>
> ===>
>
> The creature doesn't think that the computer can count,
> so he has to tell the computer how many characters he
> is handing it.
>
> The fact that ANS Forth is his language of choice tells
> me all that I need to know about ANS Forth.
>
> An ultra primitive, ultra crude, ultra clunky language
> that makes programming agonizingly difficult.
Another way:
(use srfi-13) ;; string-map
(print
(string-map
(^c
(if (char-lower-case? c)
(integer->char
(+ (char->integer #\a) (- (char->integer #\z) (char->integer c))))
c))
" Tsv xivzgfiv wlvhm'g gsrmp gszg gsv xlnkfgvi xzm xlfmg,
hl sv szh gl gvoo gsv xlnkfgvi sld nzmb xszizxgvih sv
rh szmwrmt rg.
Tsv uzxg gszg ANS Fligs rh srh ozmtfztv lu xslrxv gvooh
nv zoo gszg I mvvw gl pmld zylfg ANS Fligs.
Am fogiz kirnrgrev, fogiz xifwv, fogiz xofmpb ozmtfztv
gszg nzpvh kiltiznnrmt ztlmrarmtob wruurxfog."))
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2015-02-04 09:41 +0000 |
| Message-ID | <maspff$csj$1@dont-email.me> |
| In reply to | #36213 |
hughaguilar96@gmail.com wrote:
> On Sunday, February 1, 2015 at 5:13:34 PM UTC-7, Elizabeth D. Rather wrote:
> > On 2/1/15 2:03 PM, HAA wrote:
> > > Storing a few raw numbers is most easily achieved by typing C,
> >
> > Yes, the OP noted that, but thought it was "boring" and was looking for
> > syntactic sugar. IMO none of the offered solutions contribute much
> > except more code.
>
> You have never posted any code on comp.lang.forth except for code examples copied directly out of "Starting Forth" (and you get those wrong most of the time, because you try to do it from memory) --- the reason why you are opposed to "more code" is because you can't write it.
>
> This is a trivial coding challenge --- I was going to let the OP do it himself, but since you have spoken out against the writing of Forth code, I will write it myself:
>
> variable original-depth
>
> : string[ ( -- )
> depth original-depth ! ;
>
> : numbers-count ( -- count )
> depth original-depth @ - ;
>
> : reverse-numbers ( numbers... count -- numbers... )
> 0 ?do I roll loop ;
>
> : good-char? ( n -- flag )
> 256 u< ;
>
> : ]string ( numbers... -- )
> numbers-count >r
> r@ reverse-numbers
> r@ c,
> r> 0 ?do
> dup good-char? 0= abort" *** ]STRING given a bad char ***
> c, loop ;
>
>
> This is a test of the code under VFX:
>
> create hey ok
> string[ char H char E char Y char ! ]string ok
> hey count type HEY! ok
variable b[depth
: b[ depth b[depth ! ;
variable ]b-ptr
: ]b
depth b[depth @ -
dup dup c, allot here ]b-ptr !
0 do
-1 ]b-ptr +!
]b-ptr @ c!
loop
;
create alpha ok
b[ 65 66 67 68 69 70 ]b ok
alpha count type ABCDEF ok
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-02-04 12:54 +0000 |
| Message-ID | <mat4po$oou$1@dont-email.me> |
| In reply to | #36264 |
on 04/02/2015 09:41:02, "WJ" wrote: > hughaguilar96@gmail.com wrote: > >> On Sunday, February 1, 2015 at 5:13:34 PM UTC-7, Elizabeth D. Rather wrote: >> > On 2/1/15 2:03 PM, HAA wrote: >> > > Storing a few raw numbers is most easily achieved by typing C, >> > >> > Yes, the OP noted that, but thought it was "boring" and was looking for >> > syntactic sugar. IMO none of the offered solutions contribute much >> > except more code. >> >> You have never posted any code on comp.lang.forth except for code examples copied directly out of "Starting Forth" (and you get those wrong most of the time, because you try to do it from memory) --- the reason why you are opposed to "more code" is because you can't write it. >> >> This is a trivial coding challenge --- I was going to let the OP do it himself, but since you have spoken out against the writing of Forth code, I will write it myself: >> >> variable original-depth >> >> : string[ ( -- ) >> depth original-depth ! ; >> >> : numbers-count ( -- count ) >> depth original-depth @ - ; >> >> : reverse-numbers ( numbers... count -- numbers... ) >> 0 ?do I roll loop ; >> >> : good-char? ( n -- flag ) >> 256 u< ; >> >> : ]string ( numbers... -- ) >> numbers-count >r >> r@ reverse-numbers >> r@ c, >> r> 0 ?do >> dup good-char? 0= abort" *** ]STRING given a bad char *** >> c, loop ; >> >> >> This is a test of the code under VFX: >> >> create hey ok >> string[ char H char E char Y char ! ]string ok >> hey count type HEY! ok > > variable b[depth >: b[ depth b[depth ! ; > > variable ]b-ptr >: ]b > depth b[depth @ - > dup dup c, allot here ]b-ptr ! > 0 do > -1 ]b-ptr +! > ]b-ptr @ c! > loop > ; > > create alpha ok > b[ 65 66 67 68 69 70 ]b ok > alpha count type ABCDEF ok > > > creat null b[ ]b null count type Kaboom.
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.forth
csiph-web