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

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

DurexForth v1.5.0

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

Contents

  DurexForth v1.5.0 Johan Kotlinski <kotlinski@gmail.com> - 2016-01-04 15:08 -0800
    Re: DurexForth v1.5.0 hughaguilar96@gmail.com - 2016-01-04 20:54 -0800
      Re: DurexForth v1.5.0 Johan Kotlinski <kotlinski@gmail.com> - 2016-01-05 00:48 -0800
        Re: DurexForth v1.5.0 rickman <gnuarm@gmail.com> - 2016-01-05 04:40 -0500
          Re: DurexForth v1.5.0 Johan Kotlinski <kotlinski@gmail.com> - 2016-01-05 02:53 -0800
            Re: DurexForth v1.5.0 rickman <gnuarm@gmail.com> - 2016-01-05 09:19 -0500
              Re: DurexForth v1.5.0 Chris Curl <ccurl609@gmail.com> - 2016-01-05 08:44 -0800
                Re: DurexForth v1.5.0 rickman <gnuarm@gmail.com> - 2016-01-05 11:53 -0500
                  Re: DurexForth v1.5.0 Chris Curl <ccurl609@gmail.com> - 2016-01-05 10:28 -0800
                    Re: DurexForth v1.5.0 rickman <gnuarm@gmail.com> - 2016-01-05 14:12 -0500
                      Re: DurexForth v1.5.0 Paul Rubin <no.email@nospam.invalid> - 2016-01-05 11:16 -0800
                        Re: DurexForth v1.5.0 rickman <gnuarm@gmail.com> - 2016-01-05 14:58 -0500
                          Re: DurexForth v1.5.0 Paul Rubin <no.email@nospam.invalid> - 2016-01-05 12:03 -0800
                            Re: DurexForth v1.5.0 rickman <gnuarm@gmail.com> - 2016-01-05 15:10 -0500
                              Re: DurexForth v1.5.0 Paul Rubin <no.email@nospam.invalid> - 2016-01-05 12:36 -0800
                                Re: DurexForth v1.5.0 rickman <gnuarm@gmail.com> - 2016-01-05 16:34 -0500
                      Re: DurexForth v1.5.0 Johan Kotlinski <kotlinski@gmail.com> - 2016-01-05 13:42 -0800
                        Re: DurexForth v1.5.0 hughaguilar96@gmail.com - 2016-01-05 16:40 -0800
                          Re: DurexForth v1.5.0 Johan Kotlinski <kotlinski@gmail.com> - 2016-01-05 18:13 -0800
                            Re: DurexForth v1.5.0 "Elizabeth D. Rather" <erather@forth.com> - 2016-01-05 16:27 -1000
                            Re: DurexForth v1.5.0 Paul Rubin <no.email@nospam.invalid> - 2016-01-05 18:59 -0800
                              Re: DurexForth v1.5.0 Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-01-05 22:47 -0800
                                Re: DurexForth v1.5.0 "Elizabeth D. Rather" <erather@forth.com> - 2016-01-05 21:37 -1000
                                  Re: DurexForth v1.5.0 Paul Rubin <no.email@nospam.invalid> - 2016-01-06 00:14 -0800
                                    Re: DurexForth v1.5.0 Ron Aaron <rambamist@gmail.com> - 2016-01-06 10:32 +0200
                                      Re: DurexForth v1.5.0 Paul Rubin <no.email@nospam.invalid> - 2016-01-06 00:42 -0800
                                        Re: DurexForth v1.5.0 Ron Aaron <rambamist@gmail.com> - 2016-01-06 11:02 +0200
                                          Re: DurexForth v1.5.0 Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-01-06 01:51 -0800
                                            Re: DurexForth v1.5.0 Ron Aaron <rambamist@gmail.com> - 2016-01-06 12:02 +0200
                                      Re: DurexForth v1.5.0 Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-01-06 10:46 +0000
                                        Re: DurexForth v1.5.0 Ron Aaron <rambamist@gmail.com> - 2016-01-06 12:49 +0200
                                        Re: DurexForth v1.5.0 Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-01-06 03:12 -0800
                                          Re: DurexForth v1.5.0 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-06 18:21 +0000
                                            Re: DurexForth v1.5.0 Johan Kotlinski <kotlinski@gmail.com> - 2016-01-06 22:57 -0800
                                              Re: DurexForth v1.5.0 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-07 08:47 +0000
                                      Re: DurexForth v1.5.0 Coos Haak <chforth@hccnet.nl> - 2016-01-06 13:39 +0100
                                        Re: DurexForth v1.5.0 Ron Aaron <rambamist@gmail.com> - 2016-01-06 14:45 +0200
                                  Re: DurexForth v1.5.0 Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-06 12:48 +0000
                                  Re: DurexForth v1.5.0 Syd Rumpo <usenet@nononono.co.uk> - 2016-01-07 11:09 +0000
                                Re: DurexForth v1.5.0 hughaguilar96@gmail.com - 2016-01-06 22:57 -0800
          Re: DurexForth v1.5.0 no.top.post@gmail.com - 2016-01-14 12:45 +0000
    Re: DurexForth v1.5.0 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-05 10:37 +0000
      Re: DurexForth v1.5.0 Johan Kotlinski <kotlinski@gmail.com> - 2016-01-05 03:08 -0800
    Re: DurexForth v1.5.0 Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2016-01-06 12:22 +0100
      Re: DurexForth v1.5.0 Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-06 13:08 +0000
    Re: DurexForth v1.5.0 Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-07 03:14 -0500

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#44606

Johan Kotlinski <kotlinski@gmail.com> writes:
> c d f would cause some bad surprises when programming in HEX.

Lol, I got caught by that recently.  I had HEX in a certain part of my
program because I needed output in base 16.  Then I tried to switch back
to decimal by typing DEC, which seemed to work fine, though the rest of
the program didn't work because I figured it needed more debugging.  It
took me a while to remember that the base change word was DECIMAL and
that DEC had been interpreted as the hex constant I'd usually write as
$0DEC.  Heh.

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

#44611

miercuri, 6 ianuarie 2016, 04:59:19 UTC+2, Paul Rubin a scris:
> Johan Kotlinski <kotlinski@gmail.com> writes:
> > c d f would cause some bad surprises when programming in HEX.
> 
> Lol, I got caught by that recently.  I had HEX in a certain part of my
> program because I needed output in base 16.  Then I tried to switch back
> to decimal by typing DEC, which seemed to work fine, though the rest of
> the program didn't work because I figured it needed more debugging.  It
> took me a while to remember that the base change word was DECIMAL and
> that DEC had been interpreted as the hex constant I'd usually write as
> $0DEC.  Heh.

base'd number input is so confusing that I never used it and in my 
system I just didn't implement it. I have a BASE but only for output.
Not having the BASE for input is my "invention" but overall I saw a lot
of advices of not using the base for input and using only formatted
numbers.

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

#44612

On 1/5/16 8:47 PM, Raimond Dragomir wrote:
> miercuri, 6 ianuarie 2016, 04:59:19 UTC+2, Paul Rubin a scris:
>> Johan Kotlinski <kotlinski@gmail.com> writes:
>>> c d f would cause some bad surprises when programming in HEX.
>>
>> Lol, I got caught by that recently.  I had HEX in a certain part of my
>> program because I needed output in base 16.  Then I tried to switch back
>> to decimal by typing DEC, which seemed to work fine, though the rest of
>> the program didn't work because I figured it needed more debugging.  It
>> took me a while to remember that the base change word was DECIMAL and
>> that DEC had been interpreted as the hex constant I'd usually write as
>> $0DEC.  Heh.
>
> base'd number input is so confusing that I never used it and in my
> system I just didn't implement it. I have a BASE but only for output.
> Not having the BASE for input is my "invention" but overall I saw a lot
> of advices of not using the base for input and using only formatted
> numbers.

One of the major places where BASE-base input is useful is, of course, 
interpreting source files, where drivers etc. need to specify addresses 
and other parameters in hex. BASE is a Forth-specific concept, for some 
reason, but it is truly wonderful and one of Chuck's best ideas. Worth 
learning.

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]

#44613

"Elizabeth D. Rather" <erather@forth.com> writes:
> One of the major places where BASE-base input is useful is, of course,
> interpreting source files, where drivers etc. need to specify
> addresses and other parameters in hex. BASE is a Forth-specific
> concept, for some reason, but it is truly wonderful and one of Chuck's
> best ideas. Worth learning.

It seems like troublesome and unnecessary statefulness to me.  Better to
just use prefixes: $123A already works and is perfectly clear and not a
problem to type, so I'd be satisfied with it.  Similarly HEX.  prints a
number in hex, etc.

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

#44614

On 01/06/2016 10:14, Paul Rubin wrote:
> It seems like troublesome and unnecessary statefulness to me.  Better to
> just use prefixes: $123A already works and is perfectly clear and not a
> problem to type, so I'd be satisfied with it.  Similarly HEX.  prints a
> number in hex, etc.

That's true, but if for example you want to print base36 (e.g. for
password generation or some other purpose) it is convenient to be able
to do something like:

: base36 \ n -- s
	36 base
	swap >s
	swap base drop ;

(that's the 8th variant, where 'base' is a word which sets the base and
returns the old one, but ANS Forth wouldn't be too different)

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

#44615

Ron Aaron <rambamist@gmail.com> writes:
> : base36 \ n -- s
> 	36 base
> 	swap >s
> 	swap base drop ;

Yecch.  I'd rather have a word like

  : xb. ( n b -- ) ... ; \ print n in base b

If you wanted a lot of base-36 printing you could define

  : b36 ( n -- )  36 xb. ;

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

#44616

On 01/06/2016 10:42, Paul Rubin wrote:
> Ron Aaron <rambamist@gmail.com> writes:
>> : base36 \ n -- s
>> 	36 base
>> 	swap >s
>> 	swap base drop ;
> 
> Yecch.  I'd rather have a word like
> 
>   : xb. ( n b -- ) ... ; \ print n in base b
> 
> If you wanted a lot of base-36 printing you could define
> 
>   : b36 ( n -- )  36 xb. ;

Why "yecch"?  If the '36' is painful you could certainly factor it out,
but how important is that?

The word I presented converts the number to a string, it doesn't print it.

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

#44617

miercuri, 6 ianuarie 2016, 11:03:13 UTC+2, Ron Aaron a scris:
> On 01/06/2016 10:42, Paul Rubin wrote:
> > Ron Aaron <rambamist@gmail.com> writes:
> >> : base36 \ n -- s
> >> 	36 base
> >> 	swap >s
> >> 	swap base drop ;
> > 
> > Yecch.  I'd rather have a word like
> > 
> >   : xb. ( n b -- ) ... ; \ print n in base b
> > 
> > If you wanted a lot of base-36 printing you could define
> > 
> >   : b36 ( n -- )  36 xb. ;
> 
> Why "yecch"?  If the '36' is painful you could certainly factor it out,
> but how important is that?
> 
> The word I presented converts the number to a string, it doesn't print it.

Ron, your example is about OUTPUT conversion, not INPUT conversion.
You "print" the number in memory (in a string) not on an output device,
so it is still an output conversion.
And as I said, I admit that for an output conversion having base is usefull,
only for input conversion is confusing.

Lets give a "standard" forth implementation for it:
: base36 \ n -- s
  base @ 36 base !
  swap >s
  swap base ! ;

This is possible in my system. My BASE is only for output conversions
(in forth terminology: "pictured numeric output") :D.

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

#44618

On 06/01/2016 11:51, Raimond Dragomir wrote:

> Ron, your example is about OUTPUT conversion, not INPUT conversion.
> You "print" the number in memory (in a string) not on an output device,
> so it is still an output conversion.
> And as I said, I admit that for an output conversion having base is usefull,
> only for input conversion is confusing.
> 
> Lets give a "standard" forth implementation for it:
> : base36 \ n -- s
>   base @ 36 base !
>   swap >s
>   swap base ! ;
> 
> This is possible in my system. My BASE is only for output conversions
> (in forth terminology: "pictured numeric output") :D.

Ah.  Well for input conversion you just need to set the base
  36 base drop
... input some number in base36 ...
  decimal

In 8th, 'base' affects numeric input as well as output, so you can
easily input weird bases if you want.  Admittedly, I've never really had
to do that, and I also prefer the 'prefix' notation, e.g. "$fe" or
"0xfe" rather than using 'hex' and 'decimal', but that's just a matter
of taste.

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

#44619

On Wed, 6 Jan 2016 10:32:34 +0200
Ron Aaron <rambamist@gmail.com> wrote:

> (that's the 8th variant, where 'base' is a word which sets the
> base and returns the old one, but ANS Forth wouldn't be too
> different)

I'm a bit dyslexic, read too fast, and get easily confused.
That you change the meaning of a word I am familiar with might
be the start of a pile of reasons for avoiding 8th.

Jan Coombs. 
-- 
"You can't confuse me, that's _my_ job"  John Doty

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

#44620

On 01/06/2016 12:46, Jan Coombs wrote:
> On Wed, 6 Jan 2016 10:32:34 +0200
> Ron Aaron <rambamist@gmail.com> wrote:
> 
>> (that's the 8th variant, where 'base' is a word which sets the
>> base and returns the old one, but ANS Forth wouldn't be too
>> different)
> 
> I'm a bit dyslexic, read too fast, and get easily confused.
> That you change the meaning of a word I am familiar with might
> be the start of a pile of reasons for avoiding 8th.

Perhaps.  But I should think that the lack of "create... does>" would
slow you down enough to make you read the docs and sample code first...

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

#44621

miercuri, 6 ianuarie 2016, 12:46:11 UTC+2, Jan Coombs a scris:
> On Wed, 6 Jan 2016 10:32:34 +0200
> Ron Aaron <rambamist@gmail.com> wrote:
> 
> > (that's the 8th variant, where 'base' is a word which sets the
> > base and returns the old one, but ANS Forth wouldn't be too
> > different)
> 
> I'm a bit dyslexic, read too fast, and get easily confused.
> That you change the meaning of a word I am familiar with might
> be the start of a pile of reasons for avoiding 8th.
> 
> Jan Coombs. 
> -- 
> "You can't confuse me, that's _my_ job"  John Doty

8th's base it's quite interesting:
base \ new -- old

It's actually simpler to use:

8th:                 forth:
   36 base              base @ 36 base !
   ...                  ...
   base drop            base !

or
   36 base >r           base @ >r 36 base !
   ...                  ...
   r> base drop         r> base !

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

#44639

Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>8th's base it's quite interesting:
>base \ new -- old
>
>It's actually simpler to use:
>
>8th:                 forth:
>   36 base              base @ 36 base !
>   ...                  ...
>   base drop            base !
>
>or
>   36 base >r           base @ >r 36 base !
>   ...                  ...
>   r> base drop         r> base !

Gforth (with quotations):

[: ... ;] 36 base-execute

The major advantage of this is not the brevity, but that it restores
BASE even if the quotation is left through an exception (e.g., when
the user types ^C).

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#44652

On Wednesday, January 6, 2016 at 7:24:31 PM UTC+1, Anton Ertl wrote:
> Gforth (with quotations):
> 
> [: ... ;] 36 base-execute
> 
> The major advantage of this is not the brevity, but that it restores
> BASE even if the quotation is left through an exception (e.g., when
> the user types ^C).

It might be a nice function, but in the end using it is just another convention that people can choose to follow or not, so it is more like a band-aid over the fundamental problem that BASE is a writable global variable.

Johan

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

#44656

Johan Kotlinski <kotlinski@gmail.com> writes:
>On Wednesday, January 6, 2016 at 7:24:31 PM UTC+1, Anton Ertl wrote:
>> Gforth (with quotations):
>> 
>> [: ... ;] 36 base-execute
>> 
>> The major advantage of this is not the brevity, but that it restores
>> BASE even if the quotation is left through an exception (e.g., when
>> the user types ^C).
>
>It might be a nice function, but in the end using it is just another convention that people can choose to follow or not, so it is more like a band-aid over the fundamental problem that BASE is a writable global variable.

Sure, you can still shoot yourself in the foot by changing BASE, but,
in the spirit of Forth, BASE-EXECUTE does not try to eliminate that
possibility.  It just offers a safer way to deal with it (contrary to
the spirit of Forth?).

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#44623

Op Wed, 6 Jan 2016 10:32:34 +0200 schreef Ron Aaron:

> On 01/06/2016 10:14, Paul Rubin wrote:
>> It seems like troublesome and unnecessary statefulness to me.  Better to
>> just use prefixes: $123A already works and is perfectly clear and not a
>> problem to type, so I'd be satisfied with it.  Similarly HEX.  prints a
>> number in hex, etc.
> 
> That's true, but if for example you want to print base36 (e.g. for
> password generation or some other purpose) it is convenient to be able
> to do something like:
> 
>: base36 \ n -- s
> 	36 base
> 	swap >s
> 	swap base drop ;
> 
> (that's the 8th variant, where 'base' is a word which sets the base and
> returns the old one, but ANS Forth wouldn't be too different)

This confuses me, what stack push is meant with >s ?

groet Coos

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

#44624

On 01/06/2016 14:39, Coos Haak wrote:

> This confuses me, what stack push is meant with >s ?

>s \ x -- s

It takes an item (of {most} any kind) and converts to its string
representation.  In this case, a number is converted to a string.

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

#44625

"Elizabeth D. Rather" <erather@forth.com> writes:

>On 1/5/16 8:47 PM, Raimond Dragomir wrote:
>> miercuri, 6 ianuarie 2016, 04:59:19 UTC+2, Paul Rubin a scris:
>>> Johan Kotlinski <kotlinski@gmail.com> writes:
>>>> c d f would cause some bad surprises when programming in HEX.
>>>
>>> Lol, I got caught by that recently.  I had HEX in a certain part of my
>>> program because I needed output in base 16.  Then I tried to switch back
>>> to decimal by typing DEC, which seemed to work fine, though the rest of
>>> the program didn't work because I figured it needed more debugging.  It
>>> took me a while to remember that the base change word was DECIMAL and
>>> that DEC had been interpreted as the hex constant I'd usually write as
>>> $0DEC.  Heh.
>>
>> base'd number input is so confusing that I never used it and in my
>> system I just didn't implement it. I have a BASE but only for output.
>> Not having the BASE for input is my "invention" but overall I saw a lot
>> of advices of not using the base for input and using only formatted
>> numbers.

>One of the major places where BASE-base input is useful is, of course,
>interpreting source files, where drivers etc. need to specify addresses
>and other parameters in hex. BASE is a Forth-specific concept, for some
>reason, but it is truly wonderful and one of Chuck's best ideas. Worth
>learning.

It is a pity that E is used for exponents instead of _ in floating point
numbers.

Floating point hex numbers are great, because they allow to communicate
data exactly in readable form.

If I ever add floating point to ciforth, I'll make sure that they can
be represented in hex.

My ideal Forth dialect would have:
  if it starts with a digit it is a number (so 2SWAP -> DSWAP )
  (if it contains i it is complex else)
  if it contains _ it is float else
  if it contains . it is double else
  it is single.

  Examples:
  HEX 12EF.78_13
  and:
  1i1

>Cheers,
>Elizabeth
-- 
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]

#44660

On 06/01/2016 07:37, Elizabeth D. Rather wrote:
> On 1/5/16 8:47 PM, Raimond Dragomir wrote:
>> miercuri, 6 ianuarie 2016, 04:59:19 UTC+2, Paul Rubin a scris:
>>> Johan Kotlinski <kotlinski@gmail.com> writes:
>>>> c d f would cause some bad surprises when programming in HEX.
>>>
>>> Lol, I got caught by that recently.  I had HEX in a certain part of my
>>> program because I needed output in base 16.  Then I tried to switch back
>>> to decimal by typing DEC, which seemed to work fine, though the rest of
>>> the program didn't work because I figured it needed more debugging.  It
>>> took me a while to remember that the base change word was DECIMAL and
>>> that DEC had been interpreted as the hex constant I'd usually write as
>>> $0DEC.  Heh.
>>
>> base'd number input is so confusing that I never used it and in my
>> system I just didn't implement it. I have a BASE but only for output.
>> Not having the BASE for input is my "invention" but overall I saw a lot
>> of advices of not using the base for input and using only formatted
>> numbers.
>
> One of the major places where BASE-base input is useful is, of course,
> interpreting source files, where drivers etc. need to specify addresses
> and other parameters in hex. BASE is a Forth-specific concept, for some
> reason, but it is truly wonderful and one of Chuck's best ideas. Worth
> learning.
>
> Cheers,
> Elizabeth

1-

I think it was his worst idea, and have never used it since falling foul 
of it.  Ambiguity about the value of a number has no place in Forth, the 
base is part of the number and should always be included, not specified 
in some other place.

I would perhaps make an exception for decimal, but any other number must 
always include its base.  This can also improve code readability - a 
clearly hex number is likely an address, a clearly binary number is 
likely a bit mask.

Likewise when printing a number - .hex .bin etc are so much clearer and 
are in line with the Forth philosophy of typing the operator and not the 
data.

Cheers
-- 
Syd

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

#44653

On Tuesday, January 5, 2016 at 11:47:27 PM UTC-7, Raimond Dragomir wrote:
> miercuri, 6 ianuarie 2016, 04:59:19 UTC+2, Paul Rubin a scris:
> > Johan Kotlinski <kotlinski@gmail.com> writes:
> > > c d f would cause some bad surprises when programming in HEX.
> > 
> > Lol, I got caught by that recently.  I had HEX in a certain part of my
> > program because I needed output in base 16.  Then I tried to switch back
> > to decimal by typing DEC, which seemed to work fine, though the rest of
> > the program didn't work because I figured it needed more debugging.  It
> > took me a while to remember that the base change word was DECIMAL and
> > that DEC had been interpreted as the hex constant I'd usually write as
> > $0DEC.  Heh.
> 
> base'd number input is so confusing that I never used it and in my 
> system I just didn't implement it. I have a BASE but only for output.
> Not having the BASE for input is my "invention" but overall I saw a lot
> of advices of not using the base for input and using only formatted
> numbers.

I never change BASE and allow source-code to be interpreted. The only exception is when I have a section of source-code that contains only constants all of which are in a different base. I change BASE for that section only. This may be a table of constants being comma'd into an array, or it may be a series of CONSTANT definitions. It would almost never include colon words or other Forth code.

So, I disagree with Raimond --- I wouldn't outlaw the use of a different BASE for input --- I would just advise the user to do this only for sections of source-code that contain only constants, but not do this for source-code that contains code. 

There are a lot of things that are a bad idea, but shouldn't necessarily be outlawed --- in the real world, we have the marijuana issue --- I think that outlawing mota is a big mistake, but I also advise people to not smoke mota or at least to do so only in moderation.

The subject of changing BASE for input was discussed already here:
https://groups.google.com/forum/#!topic/comp.lang.forth/tLZLCc02gmk%5B1-25%5D

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web