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

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

2012 rc2: LOCALS|

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

Contents

  2012 rc2: LOCALS| darktjm@gmail.com - 2014-02-11 18:49 -0800
    Re: 2012 rc2: LOCALS| "Elizabeth D. Rather" <erather@forth.com> - 2014-02-11 17:05 -1000
      Re: 2012 rc2: LOCALS| darktjm@gmail.com - 2014-02-11 20:26 -0800
        Re: 2012 rc2: LOCALS| "Elizabeth D. Rather" <erather@forth.com> - 2014-02-11 19:18 -1000
    Re: 2012 rc2: LOCALS| anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-12 09:45 +0000
      Re: 2012 rc2: LOCALS| darktjm@gmail.com - 2014-02-12 18:13 -0800
        Re: 2012 rc2: LOCALS| Mark Wills <markrobertwills@yahoo.co.uk> - 2014-02-13 00:39 -0800
          Re: 2012 rc2: LOCALS| Elizabeth D Rather <erather@forth.com> - 2014-02-12 22:56 -1000
        Re: 2012 rc2: LOCALS| anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-13 09:06 +0000
        Re: 2012 rc2: LOCALS| stephenXXX@mpeforth.com (Stephen Pelc) - 2014-02-13 12:44 +0000
          2012 rc2: REPLACES/SUBSTITUTES darktjm@gmail.com - 2014-02-13 14:19 -0800

#28323 — 2012 rc2: LOCALS|

Hello,

A comment on the forth-rc2 document:

I was going to post this to the 200x list, but my Yahoo account has long expired due to inactivity, and I refuse to sign up for a new account if entering a mobile phone number is required.

LOCALS| still says "up to eight", even though the limit has been
raised to 16.  I assume this is unintentional.  In fact, I was always
wondering why the implementation can support more than 8 locals, but
LOCALS| is fixed to 8.  Perhaps this should be raised to "16, or more
with an environmental dependency on a larger number of supported locals".

[toc] | [next] | [standalone]

#28325

On 2/11/14 4:49 PM, darktjm@gmail.com wrote:
> Hello,
>
> A comment on the forth-rc2 document:
>
> I was going to post this to the 200x list, but my Yahoo account has long expired due to inactivity, and I refuse to sign up for a new account if entering a mobile phone number is required.
>
> LOCALS| still says "up to eight", even though the limit has been
> raised to 16.  I assume this is unintentional.  In fact, I was always
> wondering why the implementation can support more than 8 locals, but
> LOCALS| is fixed to 8.  Perhaps this should be raised to "16, or more
> with an environmental dependency on a larger number of supported locals".

Systems are not restricted to 8 locals, but applications that need more 
have a dependency. That is, you may develop your application on a Forth 
that supports 20 locals, and you use all 20. This will work just fine on 
all Forth systems that support at least 20 locals (assuming your other 
requirements are met. Systems are required to document whether they 
support locals and if so, how many, and you are required to document how 
many you require if it's more than 8.

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]

#28326

On Tuesday, February 11, 2014 9:05:57 PM UTC-6, Elizabeth D. Rather wrote:
> Systems are not restricted to 8 locals, but applications that need more 
> 
> have a dependency. That is, you may develop your application on a Forth 
> 
> that supports 20 locals, and you use all 20. This will work just fine on 
> 
> all Forth systems that support at least 20 locals (assuming your other 
> 
> requirements are met. Systems are required to document whether they 
> 
> support locals and if so, how many, and you are required to document how 
> 
> many you require if it's more than 8.

Right.  I'm only complaining about the "eight", really.  Forth 200x requires 16 locals, so the wording needs to change.  However, I'm also also like to make what you said clear, by changing the wording to make the fact that more are permitted.  As written, it sounds like allowing more than that number makes the word non-compliant.  In fact, the wording for {: contains no hard limits, but instead defers to the introductory material, which says pretty much what you said.  In other words, that "up to eight" is written like an unnecessary additional restriction.

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

#28327

On 2/11/14 6:26 PM, darktjm@gmail.com wrote:
> On Tuesday, February 11, 2014 9:05:57 PM UTC-6, Elizabeth D. Rather wrote:
>> Systems are not restricted to 8 locals, but applications that need more
>>
>> have a dependency. That is, you may develop your application on a Forth
>>
>> that supports 20 locals, and you use all 20. This will work just fine on
>>
>> all Forth systems that support at least 20 locals (assuming your other
>>
>> requirements are met. Systems are required to document whether they
>>
>> support locals and if so, how many, and you are required to document how
>>
>> many you require if it's more than 8.
>
> Right.  I'm only complaining about the "eight", really.  Forth 200x requires 16 locals, so the wording needs to change.  However, I'm also also like to make what you said clear, by changing the wording to make the fact that more are permitted.  As written, it sounds like allowing more than that number makes the word non-compliant.  In fact, the wording for {: contains no hard limits, but instead defers to the introductory material, which says pretty much what you said.  In other words, that "up to eight" is written like an unnecessary additional restriction.
>

Ah, good point. Should be changed to "at least eight."

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]

#28328

darktjm@gmail.com writes:
>Hello,
>
>A comment on the forth-rc2 document:
>
>I was going to post this to the 200x list, but my Yahoo account has long expired due to inactivity, and I refuse to sign up for a new account if entering a mobile phone number is required.

I don't think you need a Yahoo account for sending mail to the list,
but I am not really up to data on this.  Anyway, several committee members also read here, so 

>LOCALS| still says "up to eight", even though the limit has been
>raised to 16.  I assume this is unintentional.

Not quite sure about that.  I don't remember if we discussed it, but
maybe we have and just decided not to touch LOCALS|.

Any existing programs that use LOCALS| will work as they worked
before.  Any new programs or programs that get more locals in the
course of maintenance can (and IMO should) use {: instead.

That being said, if a system supports 16 locals, I doubt LOCALS| will
support fewer locals on that system (if the system implements
LOCALS|).

On the meta level, it was a mistake (in Forth-94) to put the limit in
two places.  We did not repeat this mistake in the definition of {:.

>In fact, I was always
>wondering why the implementation can support more than 8 locals, but
>LOCALS| is fixed to 8.

A standard program (without environmental dependences) cannot use more
than 8 locals.  What a system does when you write a LOCALS| definition
with more than 8 locals is up to the system.  Many things in the
standard work that way: It describes what a standard program looks
like and how a stanard system behaves when it encounters a standard
program, but does not say anything about non-standard programs.

- 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 2013: http://www.euroforth.org/ef13/

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

#28352

On Wednesday, February 12, 2014 3:45:20 AM UTC-6, Anton Ertl wrote:
> On the meta level, it was a mistake (in Forth-94) to put the limit in
> 
> two places.  We did not repeat this mistake in the definition of {:.

I had a longer response, but it really just comes down to this:  rather than propagating that mistake, why not use the new standard to correct it?  I figured changing "eight" to "sixteen" would be non-controversial.  I figured that dropping the separate but non-equal limit entirely, leaving it up to the max limit for locals as described in the introductory material would be at most a tiny bit controversial.  Neither change affects working '94 programs.

Sorry I even brought it up, especially so close to the comment deadline, and even more especially since I don't really care about or use locals, personally.  I'm glad I decided against bringing up a more controversial objection, like the fact that I believe SUBSTITUTE is dangerous and worthless without additional (and therefore non-portable) support.

p.s.

> I don't think you need a Yahoo account for sending mail to the list,

My email was rejected, stating that I had to be a member of the group.  Last time I checked, admittedly years ago when my account was still active, you needed to have a Yahoo account to be a member of a Yahoo group.  I suppose there may be a way around it somehow, but I don't know it and don't feel like trying it, since comp.lang.forth works, mostly.

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

#28364

Seems to me it would make more sense to specify a *minimum* number of locals. Why restrict a system implementer by specifying the maximum? Doesn't make sense to me.

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

#28369

On 2/12/2014 10:39 PM, Mark Wills wrote:
> Seems to me it would make more sense to specify a *minimum* number of locals. Why restrict a system implementer by specifying the maximum? Doesn't make sense to me.
>

I agree.

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]

#28371

darktjm@gmail.com writes:
>On Wednesday, February 12, 2014 3:45:20 AM UTC-6, Anton Ertl wrote:
>> On the meta level, it was a mistake (in Forth-94) to put the limit in
>>=20
>> two places.  We did not repeat this mistake in the definition of {:.
>
>I had a longer response, but it really just comes down to this:  rather tha=
>n propagating that mistake, why not use the new standard to correct it?

Nobody wrote a proposal on it.

>I'm glad I decided against bringing up a more controversial objecti=
>on, like the fact that I believe SUBSTITUTE is dangerous and worthless with=
>out additional (and therefore non-portable) support.

If you believe that, why not bring it up?  The worst that can happen
is that you will be flamed.  Alternatively, we may find that
SUBSTITUTE is indeed deficient, or we may show you how to use it
safely and worthy in it's current form.

- 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 2013: http://www.euroforth.org/ef13/

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

#28379

On Wed, 12 Feb 2014 18:13:25 -0800 (PST), darktjm@gmail.com wrote:

>I'm glad I decided against bringing up a more controversial objecti=
>on, like the fact that I believe SUBSTITUTE is dangerous and worthless with=
>out additional (and therefore non-portable) support.

Well, we've been using a similar notation for the last 15 years, and
it does not generate any tech support problems. DO let us know why
it is dangerous.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#28391 — 2012 rc2: REPLACES/SUBSTITUTES

On Thursday, February 13, 2014 3:06:27 AM UTC-6, Anton Ertl wrote:
> Thomas J. Moore writes:
> 
> >I'm glad I decided against bringing up a more controversial objecti=
> 
> >on, like the fact that I believe SUBSTITUTE is dangerous and worthless with=
> 
> >out additional (and therefore non-portable) support.
> 
> 
> 
> If you believe that, why not bring it up?  The worst that can happen
> 
> is that you will be flamed.  Alternatively, we may find that
> 
> SUBSTITUTE is indeed deficient, or we may show you how to use it
> 
> safely and worthy in it's current form.

Very well.  Against my better judgement, and for the second time (blasted Google Groups interface lost my first try, so I probably forgot some things this time), I will.  Feel free to flame me, or tell me why my objections are unjustified.  However, my 'net access is spotty at best, and comp.lang.forth is not always on my list of visits, so replies may be few and far between.

Keep in mind that I do not object with the *idea* of the feature, just the implementation.

On Thursday, February 13, 2014 6:44:15 AM UTC-6, Stephen Pelc wrote:
> Well, we've been using a similar notation for the last 15 years, and
> 
> it does not generate any tech support problems. DO let us know why
> 
> it is dangerous.
> 

Does your similar notation also use a global, shared, append-only replacement list?  That particular aspect is what I object to the most.  The danger is in accidental information leakage.  It's a security breach waiting to happen.  Of course you can try to remember to clear out all replacements after each use, but that is a pain in the ass (and therefore not likely to happen in real life).  The append-only part means that it's also a memory leak in progress.  As written, replacements may *never* be deleted, presumably unless the feature itself is somehow deleted (and maybe not even then, as in the case of Hans Bezemer's ALLOCATE version).

The sort of support I was talking about was the ability to use separate replacement lists (including list creation and deletion), delete and query replacements (although deletion can be accomplished by assigning %name% to name and neither is as important if separate replacement lists are allowed).  You could add a replacement-list-id data type, and have words to create and delete them, and either have a "current replacement list" variable (which defaults to some implementation-created default list for convenience) or pass in the replacement list ID to REPLACES and SUBSTITUTES.  This (using the "current list" since I can't just change the defined interface) is the only way I could see implementing the feature as designed while providing some implementation-dependent sanity.  However, since the standard apparently requires that replacements live forever, even that compromise violates the standard.

In fact, although I consider the numeric version described in the proposal's Usage section to be even less safe (although it can be tamed by at least adding the number of substitutions as a parameter), I think something similar is the best route.  Instead of a global list, always pass in the replacements, either directly on the stack (namen nlenn repln repllenn .. name1 nlen1 repl1 rlen1 n) or as one or more arrays of addr/len pairs (e.g. name-list-addr repl-list-addr n ).  This covers both of my objections above:  replacements are never reused (unless the application wants to), and storage of name and replacement text strings is entirely under control of the application.  Since no copies are made of static strings, this is also more efficient (except for lookup perhaps, but you could require the lists be sorted by name).  This eliminates the REPLACES word (although something similar could be provided to assist in managing the lists in the array version, e.g. REPLACES ( name text name-list-addr repl-list-addr n -- ) would locate name in the name-list and store text in the associated repl-list position), and if efficient lookup is required, something like SORT-REPLACEMENTS ( name-list-addr repl-list-addr n -- ) would do the sort for you (or a more generic sort routine for general usage).

That is not my only objection to the feature, though.  For example, there should be a way to find out if a replacement was not made.  This could either be via a separate output from SUBSTITUTE, or via a separate word (e.g. ?SUBSTITUTE) that only substitutes up to the first unfound name, and returns both the replacement text so far and the pointer to the unfound name.

Also, the documentation requirements are too lax.  The implementation should at least document any limits on names and replacement text, and the standard should also require minimum limits (e.g. the same minima as definition words for the names and 255 chars for the replacement text).  The implementation should also specify the lifetime of replacements (and any interaction with other language features, such as FORGET and MARKER).  I suppose the standard might place some restrictions on that as well.

Also, I have a few issues with the wording in SUBSTITUTE: "Substitution occurs left to right from the start of c-addr1 in one pass and is non-recursive."  -- This sounds like an unimportant implementation detail.  Drop the "occurs left to right from the start of c-addr1 in one pass and" part.  I believe "non-recursive" covers what you meant to say with "in one pass".

Also, although it is covered in the section's "Ambiguous conditions", mention the fact that giving the same buffer for input and output is an ambiguous condition in the text for SUBSTITUTE itself.  Also, alter the ambiguous condition from "are the same" to "overlap".

That's about all I can remember for now.  Sorry for bringing up objections on features that have been in the standard since 2011 (apparently), but I didn't even know about the 200x standard until I was looking for something recently for a Forth I am implementing right now.  Also, sorry about not providing a sample implementation that implements some of the ideas above or a formal revision to the text, but it's not really close enough to the top of my priority list right now to spend that much time on it.

[toc] | [prev] | [standalone]

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

csiph-web