wmb@MITCH.ENG.SUN.COM (08/21/90)
> > CREATE (and other words) can be easily refactored as "take next word from > > input stream then invoke $CREATE" which takes a string argument. THis > > means that strings would have to be standardized. (Are you listening > > ANSI dudes?). > > Agreed! HERE! HERE! :-) Of course, this implies that EACH of those "other words" will need string versions too, i.e. $: $VARIABLE $CONSTANT $CODE and any other defining words that are present in one's system. Furthermore, user's would be advised, for consistency's sake, to make 2 versions of every CREATE ... DOES> word. In retrospect, I think it would be better if the CREATE forms (as opposed to the $CREATE form) did not exist. But that is water under the bridge. From where we stand today, the QUOTE-TO solution as given by Robert Berkey is probably the best way out of the jam. QUOTE-TO allows you pass a stack string to an existing defining word, e.g. " FOOBAR" ' CREATE QUOTE-TO Mitch
peter@ficc.ferranti.com (Peter da Silva) (08/24/90)
In article <9008230617.AA28712@ucbvax.Berkeley.EDU> wmb%MITCH.ENG.SUN.COM@SCFVM.GSFC.NASA.GOV writes: > Of course, this implies that EACH of those "other words" will need string > versions too, i.e. $: $VARIABLE $CONSTANT $CODE and any other defining > words that are present in one's system. You mean like in STOIC? I'm not sure that's the right way to factor them. Better would be a word that created an anonymous thing (I'd say "object" but that has connotations I'm not interested in for this discussion), and a word that names an object: : ... ; foo define 3 variable bar define ... -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
wmb@MITCH.ENG.SUN.COM (08/24/90)
MB> Of course, this implies that EACH of those "other words" will need string MB> versions too, i.e. $: $VARIABLE $CONSTANT $CODE and any other defining MB> words that are present in one's system. PDS> I'm not sure that's the right way to factor them. Better would be a word PDS> that created an anonymous thing ... and a word that names an object: PDS> : ... ; foo define 3 variable bar define I agree, your way is better. I was pointing out the implications of the $CREATE solution to show its weakness. The problem with your solution (shall we call it the "PostScript way"?) is that it's hard to get there from Forth. It's not hard to implement nor is it technically flawed; it's just that it would be hard to obtain consensus on such a scheme within the Forth community. I think that the QUOTE-TO solution (e.g. " foo" ' : quote-to ) is the best solution that could have a chance of being widely accepted in the Forth community. Mitch
dwp@willett.pgh.pa.us (Doug Philips) (08/24/90)
In <9008230617.AA28712@ucbvax.Berkeley.EDU>, wmb@MITCH.ENG.SUN.COM writes: > > > CREATE (and other words) can be easily refactored as "take next word from > > > input stream then invoke $CREATE" which takes a string argument. > > Of course, this implies that EACH of those "other words" will need string > versions too, i.e. $: $VARIABLE $CONSTANT $CODE and any other defining > words that are present in one's system. Furthermore, user's would be > advised, for consistency's sake, to make 2 versions of every CREATE ... > DOES> word. I think you are right about "EACH of those 'other words'". I'm not sure I agree with new words. If the new words only used $CREATE DOES>, then the user(s) of the new words could prefix them with a WORD (or whatever is appropriate for leaving on the stack what $CREATE expects). > In retrospect, I think it would be better if the CREATE forms (as opposed > to the $CREATE form) did not exist. But that is water under the bridge. Agreed. On both counts. > From where we stand today, the QUOTE-TO solution as given by Robert Berkey > is probably the best way out of the jam. QUOTE-TO allows you pass a stack > string to an existing defining word, e.g. > > " FOOBAR" ' CREATE QUOTE-TO Boy, that sounds really familiar. Was it written up anywhere (FD, etc?)? [The obvious question: Can QUOTE-TO be done in BASIS/dpANS-Forth?] -Doug --- Preferred: ( dwp@willett.pgh.pa.us OR ...!{sei,pitt}!willett!dwp ) Daily: ...!{uunet,nfsun}!willett!dwp [last resort: dwp@vega.fac.cs.cmu.edu] --- Preferred: ( dwp@willett.pgh.pa.us OR ...!{sei,pitt}!willett!dwp ) Daily: ...!{uunet,nfsun}!willett!dwp [last resort: dwp@vega.fac.cs.cmu.edu]
wmb@MITCH.ENG.SUN.COM (08/24/90)
> > " FOOBAR" ' CREATE QUOTE-TO > > Boy, that sounds really familiar. Was it written up anywhere (FD, etc?)? Robert Berkey discussed it at length on this newsgroup, in reference to a discussion about whether or not LMI Forth allows the setting of the variables >IN and BLK to affect the input stream. I believ that an implementation is on GEnie somewhere. > [The obvious question: Can QUOTE-TO be done in BASIS/dpANS-Forth?] Yes, because the input stream mechanism is precisely defined. The implementation isn't particularly pretty, because the dpANS input stream mechanism mostly looks like the traditional (i.e. too many visible nuts and bolts) Forth input stream. Mitch
peter@ficc.ferranti.com (Peter da Silva) (08/25/90)
In article <9008241529.AA27873@ucbvax.Berkeley.EDU> wmb%MITCH.ENG.SUN.COM@SCFVM.GSFC.NASA.GOV writes: > The problem with your solution (shall we call it the "PostScript way"?) Sure :-> > is that it's hard to get there from Forth. It's not hard to implement > nor is it technically flawed; it's just that it would be hard to obtain > consensus on such a scheme within the Forth community. Well, that's not really much of a problem. If I ever get back into forth I'll just implement it whenever I do a project and watch the screaming begin. I'll probably also implement passive objects just to irritate everyone else. (if you think I'm somewhat disillusioned with the Forth community, you're damn right) -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
dwp@willett.pgh.pa.us (Doug Philips) (08/29/90)
In <=NE50E5@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: > I'm not sure that's the right way to factor them. Better would be a word > that created an anonymous thing (I'd say "object" but that has connotations > I'm not interested in for this discussion), and a word that names an object: > > : ... ; foo define > 3 variable bar define I agree, the mapping between an name and a behaviour seems cleanest if the mapping is independant of how both are specified. Having different mapping functions: : VARIABLE CONSTANT ARRAY ( etc... ) that be can be built from the more general mechanism is OK with me. However, those specific mapping functions convey semantic information above and beyound a mere mapping. Whether or not you find the specific mapping functions (don't forget CREATE DOES> and its variants) sufficent depends on what you are doing. Doug --- Preferred: ( dwp@willett.pgh.pa.us OR ...!{sei,pitt}!willett!dwp ) Daily: ...!{uunet,nfsun}!willett!dwp [last resort: dwp@vega.fac.cs.cmu.edu]
dwp@willett.pgh.pa.us (Doug Philips) (08/29/90)
In <9008241529.AA27873@ucbvax.Berkeley.EDU>, wmb@MITCH.ENG.SUN.COM writes:
MB> Of course, this implies that EACH of those "other words" will need string
MB> versions too, i.e. $: $VARIABLE $CONSTANT $CODE and any other defining
MB> words that are present in one's system.
PDS> I'm not sure that's the right way to factor them. Better would be a word
PDS> that created an anonymous thing ... and a word that names an object:
PDS> : ... ; foo define 3 variable bar define
MB> I agree, your way is better. I was pointing out the implications of the
MB> $CREATE solution to show its weakness.
I'm glad you did. If I were to start over I would not make a bunch of
$<FOO> words from which to build the traditional <FOO> words.
MB> The problem with your solution (shall we call it the "PostScript way"?)
MB> is that it's hard to get there from Forth. It's not hard to implement
MB> nor is it technically flawed; it's just that it would be hard to obtain
MB> consensus on such a scheme within the Forth community.
As we have seen with the X3J14 effort, its hard to get consensus about
ANYTHING in the Forth community.
MB> I think that the QUOTE-TO solution (e.g. " foo" ' : quote-to )
MB> is the best solution that could have a chance of being widely accepted
MB> in the Forth community.
Sigh. Here we go adding more band-aids and scotch tape to shore up a flawed
system. Well, at least it would likely be more portable than starting from
scratch.
-Doug
---
Preferred: ( dwp@willett.pgh.pa.us OR ...!{sei,pitt}!willett!dwp )
Daily: ...!{uunet,nfsun}!willett!dwp [last resort: dwp@vega.fac.cs.cmu.edu]