What's right with FORTH and wrong with c.l.f.
Richard Owlett
What is so right with Forth that it *OVERRIDES* ALL negative comments?
Obviously the : ; pair.
What other language morphs to match the "real" world so well in a such
well defined manner?
What's wrong with c.l.f. ?
/begin *RANT*
A close relative of N.I.H. Syndrome.
e g
I'm interested in a variety of problems ranging from subsets of speech
recognition to sources of GPS errors and their significance.
What do they have in common?
Someone else has compiled raw data. It's available in ASCII format.
That requires me to parse it.
I doubt anyone would claim string handling as a Forth forte.
I've quit asking questions on c.l.f. as typical answer has been
"DON'T DO THAT"
/end *RANT*
Marcel Hendrix
[..]
> e g
> I'm interested in a variety of problems ranging from subsets of speech
> recognition to sources of GPS errors and their significance.
> What do they have in common?
> Someone else has compiled raw data. It's available in ASCII format.
> That requires me to parse it.
> I doubt anyone would claim string handling as a Forth forte.
> I've quit asking questions on c.l.f. as typical answer has been
> "DON'T DO THAT"
I doubt that anybody has discouraged you to solve the *problem*.
They probably advised you to solve it in a way that does not involve
(a specific way of) string handling. E.g. if the input is
12 apestaart 3456 kippekot 18 hondehok -771
the numbers can be fetched by string parsing and >NUMBER.
But also with
: apestaart ; : kippekot ; : hondehok ; PARSE-NAME EVALUATE
Without specific details it is not easy to give advise.
-marcel
bria...@rogers.com
I have created a set of string handling words that let me do BASIC
style string manipulation. My goal was to prove it could be done
without to much trouble. I end up using the words quite a bit in my
projects, just because it's so simple. It is a little old fashioned in
that it uses Pascal style strings. The string functions are re-
entrant because of a string stack gluing them together. I have never
changed it for ANS strings but I have tested it somewhat on gForth 6
and Win32Forth.
Since my email address is exposed here. If you send me a note I can
send you some files
I also used the string words to create a replica of some Python string
functions that I call MONTY. (very bad PUN)
BF
Jonah Thomas
> I'm interested in a variety of problems ranging from subsets of speech
>
> recognition to sources of GPS errors and their significance.
>
> What do they have in common?
> Someone else has compiled raw data. It's available in ASCII format.
> That requires me to parse it.
> I doubt anyone would claim string handling as a Forth forte.
>
> I've quit asking questions on c.l.f. as typical answer has been
>
> "DON'T DO THAT"
My experience has been somewhat different.
Various people are interested in string hasndling with Forth. In general
each of them prefers his own methods, but I've seen them compare notes
and learn from each other.
I don't see much common practice. Each different string package is,
well, different. None of them is particularly simple, partly because
they do complicated things. I haven't seen one that seems particularly
forthy to me.
The only people who say don't do it are people who prefer other
languages. Why try to play catch-up with Forth, when it would be easier
to just use *my-favorite-language* instead. And if you just want quick
results in the short run, that's probably the way to go.
So if you have raw data in ASCII format and you want to do something
special with it in Forth, one possibility is to notice what you want to
do, and build words that do it, and then give them good names, and
finally use some other language to put your names into the data file at
just the right places so they do what you want. One traditional trick
was to store single-cell data with , and put a comma after each item you
want to store. Sometimes the only massaging you'd need was to get spaces
between the existing commas and the numbers.
If you just want quick results with the data you have today, it's bound
to be easier to use some simple language that does strings well to
change the files into a format you can use, than to invent a good string
package.
The point of managing strings with Forth has got to be that you'll do it
better than it gets done elsewhere. You have to believe you can invent a
better string package than the guys who have 40 years experience with
other languages, or it probably isn't worth doing. Re-inventing the
wheel is fine, but why re-invent the transmission? Do a whole lot of
work and get something that's no better than what you could get
off-the-shelf?
Elizabeth Rather has pointed out an approach that's likely to work for
that. You start with an application that needs some string manipulation,
and you solve it from scratch. Then do it again with a second
application, and a third. After awhile you'll see common patterns and
you'll develop generally-useful approaches. The tools that have been
generally useful become a string package. Other people will not be used
to these simple tools and they'll have to learn how to use them. If
enough others figure it out and like how it works, then eventually
they'll spread. (This is not exactly what she said. She described how
Chuck does things, and I extrapolated from it.)
There's the problem that if you're on a tight deadline you probably
don't want to spend much time developing string handling from scratch.
And if there's no deadline you're likely to be desultory about it. I've
done a little bit along these lines but without much urgency. Here's one
thing I picked up from Marcel -- he rewrote a string word very simply,
using locals and a DO LOOP . He used BOUNDS to convert the loop
parameters from ( ca len ) to ( ca+len+1 ca ) and his loop was simpler.
I found the word was easier for me with other approaches when I did it
that way too. Make the inputs ( ca+len+1 ca xt) instead of ( ca len xt )
. I had been jockeying things around so I could use /STRING but with (
ca' ca ) instead of ( ca len ) I only needed to change one item instead
of two and /STRING wasn't needed. So in my spare-time no-deadline slow
project I'll look at the ( ca' ca ) format and see whether I get any
general disadvantages from it compared to ( ca len ).
There's an old story where a sword-teacher was asked which was more
important, speed or strength or agility etc. And he told a story about
some people who were dancing to a drumbeat, and the drummer was dancing
too. He asked who would be best at dancing to the time. The students
agreed that the drummer could match his own timing better than anyone
else could. The winning swordsman was the one who could get the
initiative. In the same way, a Forth string package that's supposed to
do the same thing as an existing string package can hardly be a whole
lot better. If string.c is the goal you're trying to achieve, how do you
make string.f be more like string.c than string.c is?
So I think once you've built a half a dozen applications that use string
handling from scratch, you might notice you have a good way to handle
strings without garbage collection. That to my mind would be better than
finding several good ways to do garbage collection. YMMV.
Marcel Hendrix
[..]
> E.g. if the input is
> 12 apestaart 3456 kippekot 18 hondehok -771
> the numbers can be fetched by string parsing and >NUMBER.
> But also with
> : apestaart ; : kippekot ; : hondehok ; PARSE-NAME EVALUATE
Free associations .. Would it be nice to have a special type of VOCABULARY
which does *not* insist on a direct string match, but accepts
patterns (vectored FIND)? We could then define not only
words with names, but also words with names that match a certain
pattern. Let's say we can do that with "::" instead of ":".
VOCABULARY myapp myapp DEFINITIONS
S" [a-zA-Z]+" :: ( noop ) ;
PREVIOUS DEFINITIONS
( you must be careful not to leave myapp in the normal search order :-)
12 apestaart 3456 kippekot 18 hondehok -771
would now be equivalent to
12 3456 18 -771
Or
VOCABULARY myapp myapp DEFINITIONS
S" ," :: ( noop ) ;
S~ "[a-zA-Z]+"~ :: last-name 1- 1/STRING 2DUP $CREATE ( magic1 ) , ( magic2 ) , ;
PREVIOUS DEFINITIONS
.. where last-name ( -- c-addr u ) returns the matched pattern. This allows
"HARRY","MAGDA"
.. to become Forth words. Magic1 adds strings to a sorted list,
returning the new head, and magic2 returns n based on some formula.
Must try this in my copious spare-time.
-marcel
Marcel Hendrix
> VOCABULARY myapp myapp DEFINITIONS
> S" ," :: ( noop ) ;
> S~ "[a-zA-Z]+"~ :: last-name 1- 1/STRING 2DUP $CREATE ( magic1 ) , ( magic2 ) , ;
> PREVIOUS DEFINITIONS
should be
VOCABULARY myapp myapp DEFINITIONS
S" ," :: ( noop ) ;
S~ "[a-zA-Z]+"~ :: last-name 1- 1 /STRING 2DUP $CREATE ( magic1 ) , 2DUP ( magic2 ) , ;
PREVIOUS DEFINITIONS
Sorry,
-marcel
The Beez'
> Someone else has compiled raw data. It's available in ASCII format.
> That requires me to parse it.
> I doubt anyone would claim string handling as a Forth forte.
string handling is one of the strengths of Forth. Some feats I've done
in 4tH (my Forth):
- Parsing Cisco XML files without any extra (external) libs;
- Patching 4tH source files with extra commands without adding any
special markers;
- Eliza (I've not been the only one), text adventure game.
I've equivalents of Basic string handling (start/count), ZX string
handling (start/end), but I rarely seem to use them. /STRING. 1-, CHOP
and BOUNDS are much handier tools in everyday use. And yes, I got
equivalents for substring replacement and substring deletion as well.
Parsing files is unmatched in Forth/4tH. Much easier and versatile
than e.g. C.
I'd never believe for twenty years I'd say this but I do.
Hans
Jonah Thomas
> I've equivalents of Basic string handling (start/count), ZX string
> handling (start/end), but I rarely seem to use them. /STRING. 1-, CHOP
> and BOUNDS are much handier tools in everyday use. And yes, I got
> equivalents for substring replacement and substring deletion as well.
> Parsing files is unmatched in Forth/4tH. Much easier and versatile
> than e.g. C.
The weakness I see is concatenating strings. You can use ALLOCATE and
depend on the system that provides ALLOCATE to do decent garbage
collection. Or you can copy both strings at HERE and trust you'll be
able to -ALLOT the space at the right time.
If the point is to send the string to a file or a pipe etc, you don't
have to concatenate strings, just send all the parts in the right order.
You can get by sending the first part as soon as you know it, and then
you don't have to keep track of it.
If you find a method to do the needed work that's low-overhead for the
hardware (or low overhead for the Forth virtual machine, even if it
isn't the most efficient on the real hardware) then it's likely to wind
up conceptually simple too. Simple methods, simple ideas. It won't be as
easy to use as the string packages that let you do *anything* without
any consideration for how it's done. But it's likely to fit well into
the rest of the Forth toolbox.
Would Forth programmers put up with that? We already do things that need
to be arranged just so, that other languages make easier. Is there any
justification for one more of those?
You can eliminate all stack noise by using locals in every definition.
Put the input parameters into locals. Whenever you generate a stack item
that you don't DROP , put it into a local too. No stack noise at all.
You could get rid of the stack words. Is there any advantage to writing
so the stack is easy to use, when you can get results just as good by
using locals all the time? There's an art to writing Forth so things
mostly appear on the stack when they're needed without much stack noise.
But why go to that trouble when locals will put things wherever you want
with no thought required? Similarly, why accept a simple string package
that requires you to think, when you can have a complicated one that
does everything you want behind your back and gives you results with no
thought required?
Albert van der Horst
Richard Owlett <row...@atlascomm.net> wrote:
>{Grasshopper, capitalization in subject line significant :}
>
>What is so right with Forth that it *OVERRIDES* ALL negative comments?
>
>Obviously the : ; pair.
>What other language morphs to match the "real" world so well in a such
>well defined manner?
>
>
>What's wrong with c.l.f. ?
>
>/begin *RANT*
>A close relative of N.I.H. Syndrome.
>
>e g
>I'm interested in a variety of problems ranging from subsets of speech
>recognition to sources of GPS errors and their significance.
>
>What do they have in common?
>Someone else has compiled raw data. It's available in ASCII format.
>That requires me to parse it.
>I doubt anyone would claim string handling as a Forth forte.
There are basically two possibilities.
1 It is simple. Get by with static allocation and $@ $! $C+ $^ $/
2 It is largish. You will find that a dedicated string packet for
the task is a small part of the task, and less work than coercing
and studying a large packet with a lot you don't need.
Even if it is largish, using perl, awk or sed as a preprocessor
may be the appropriate way for your problem.
>I've quit asking questions on c.l.f. as typical answer has been
>
>"DON'T DO THAT"
You get that answer if you pose abstract questions.
Forth is very good, but only at answering concrete questions.
The concrete answer may very well be "use awk, not Forth".
Part of the consequence is that Forth is a toolkit, where you
have to choose, is that you get a feeling for when a tool is not
appropriate.
>
>/end *RANT*
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Albert van der Horst
Looks like my PREFIX idea pushed over the edge.
In this way a reader looses all foothold to understand the code.
Compare with perl. How arcane it may be, you will always know what
is interpreted, and what is interpreting code.
A library for generating tables indexed by regexp's may be a
great idea, building it into Forth is not.
>
>Must try this in my copious spare-time.
You'll think it over, and find better things to do :-)
>-marcel
Groetjes Albert
Albert van der Horst
<SNIP>
> 12 apestaart 3456 kippekot 18 hondehok -771
Do I see a slight influence of my style of names in examples ?
:-)
<SNIP>
Anton Ertl
>The weakness I see is concatenating strings.
Yes, that's one of the few things that I define beyond what the
standard provides. Here's what I have used lately:
: s+ { addr1 u1 addr2 u2 -- addr u }
u1 u2 + allocate throw { addr }
addr1 addr u1 move
addr2 addr u1 + u2 move
addr u1 u2 +
;
: append { addr1 u1 addr2 u2 -- addr u }
addr1 u1 u2 + dup { u } resize throw { addr }
addr2 addr u1 + u2 move
addr u ;
S+ is for the case where the concatenated string should be newly
allocated. APPEND is for the case where the first string is ALLOCATEd
and can be freed in the process. Both words return ALLOCATEd strings.
A typical usage is:
[ libtool-command s" --silent --mode=compile gcc -I " s+
s" includedir" getenv append ] sliteral
s" -O -c " s+ lib-filename 2@ append s" .c -o " append
lib-filename 2@ append s" .lo" append ( c-addr u )
2dup system drop free throw $? abort" libtool compile failed"
I.e., first you create an ALLOCATEd string with S+, then you APPEND to
it, then you use it (in SYSTEM this time), and finally you FREE it.
If I don't have to worry about FREEing, I can just use S+ everywhere.
All of that is not particularly efficient, though.
The other set of string words I use now and then is for comparison:
: str= ( c-addr1 u1 c-addr2 u2 -- f ) \ gforth
compare 0= ;
: string-prefix? ( c-addr1 u1 c-addr2 u2 -- f ) \ gforth
\G Is @var{c-addr2 u2} a prefix of @var{c-addr1 u1}?
tuck 2>r min 2r> str= ;
: str< ( c-addr1 u1 c-addr2 u2 -- f ) \ gforth
compare 0< ;
I don't compare strings that often, but when I do, usually one of
these words fits.
These words are defined in compat/strcomp.fs, so they can be used on
any standard system.
>If the point is to send the string to a file or a pipe etc, you don't
>have to concatenate strings, just send all the parts in the right order.
>You can get by sending the first part as soon as you know it, and then
>you don't have to keep track of it.
I have been thinking lately about enhancing Forth with pipes/streams.
This would not just allow to use multiple hardware threads, it could
also help with some of the usual problems by introducing a new way of
factoring: Factor your computation into filters that talk to each
other.
For string concatenation, one could pipe the substrings to a filter
that just generates the full string; or one could pipe it to a filter
that outputs the individual characters as a stream (that would be a
stream representation of the string), which could then be piped into
other components.
- 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 2008: http://www.complang.tuwien.ac.at/anton/euroforth/ef08.html
Bruce McFarling
> The weakness I see is concatenating strings. You can use ALLOCATE and
> depend on the system that provides ALLOCATE to do decent garbage
> collection. Or you can copy both strings at HERE and trust you'll be
> able to -ALLOT the space at the right time.
> If the point is to send the string to a file or a pipe etc, you don't
> have to concatenate strings, just send all the parts in the right order.
> You can get by sending the first part as soon as you know it, and then
> you don't have to keep track of it.
However, if you are going to be doing further processing on the
string, that's when you need it.
The shuttlepad I am working on off and on is:
"S" for source string or else for substring string, or else for string
stack (your pick)
"T" for target string
STR>S ( ca u -- ) reset S, copy ( ca u ) into substring buffer
STR>T ( ca u -- ) reset T, copy ( ca u ) into target buffer
T>S ( -- ) reset S, copy contents of T into substring buffer
S>T ( -- ) reset T, copy contents of S into target buffer
split-S ( xt -- ) split contents of S into indexed substrings using
xt, which has
semantics of ( ca1 u1 -- ca2 u2 ) ca1 u1 is a remainder string, ca2 is
the address
following the end of the substring at the head of the remainder sring,
u2 is the
length of the substring separator
>concat$ ( ca u -- ) concatenaion seperator
T+STR ( ca u -- ) concatenates the STR (standard text representation)
on stack with T
+T ( i -- ) concatenates the i'th substring with T
John Passaniti
> [...]
> But why go to that trouble when locals will put things wherever you want
> with no thought required? Similarly, why accept a simple string package
> that requires you to think, when you can have a complicated one that
> does everything you want behind your back and gives you results with no
> thought required?
Questions like this stem from an underlying assumption that all
programming is the same. Embedded systems, game programming, web
programming, desktop applications, database applications, casual
scripting, system tools, and so on... all the same. Same needs, same
priorities, same methodologies, same constraints, same same same.
Wrong wrong wrong. Why accept a simple string package? Because in some
contexts, that's exactly what you need. You need explicit and direct
control. You need efficiency. You need a lack of abstraction. Why
then are there complicated string packages? Because sometimes strings
are not the problem you're trying to solve. Because sometimes you're
more than willing to put up with underlying complexity and implicit
mechanisms because it makes expression of the algorithm clearer.
Because sometimes you would prefer to be out playing with your kids than
worrying about the efficiency of a string package that accounts for less
than 1% of your program's runtime and memory footprint.
What I see in comp.lang.forth are people who come from a limited
perspective-- for example embedded systems. That's what they know.
That's their world. And so when someone who comes from a completely
different perspective-- say someone who writes web applications using
scripting languages-- the embedded systems people say "you should do this."
And the opposite happens. You see a handful of people here who think
Forth is pointless and that high-level scripting languages are the way
to go. They show the same limited perspective. Ask the guys who think
Ruby is spiffy keen to run Ruby on a 8-bit microcontroller with 4k of
ROM and 2k of RAM. Ask the guys who rely on non-deterministic garbage
collection in their languages to handle hard real-time requirements.
And yes, there is overlap. I think my high-level application work
benefits from an awareness of the underlying machine. And I think my
low-level systems work benefits from an awareness of higher-level
abstractions. Everyone can learn from each other. But where there is
no learning and no value is when conversations veer into absolutism and
a denial that context matters.
Jonah Thomas
> Jonah Thomas wrote:
> > But why go to that trouble when locals will put things wherever you
> > want with no thought required? Similarly, why accept a simple string
> > package that requires you to think, when you can have a complicated
> > one that does everything you want behind your back and gives you
> > results with no thought required?
>
> Questions like this stem from an underlying assumption that all
> programming is the same. Embedded systems, game programming, web
> programming, desktop applications, database applications, casual
> scripting, system tools, and so on... all the same. Same needs, same
> priorities, same methodologies, same constraints, same same same.
>
> Wrong wrong wrong. Why accept a simple string package? Because in
> some contexts, that's exactly what you need. You need explicit and
> direct control. You need efficiency. You need a lack of abstraction.
> Why
> then are there complicated string packages? Because sometimes strings
>
> are not the problem you're trying to solve. Because sometimes you're
> more than willing to put up with underlying complexity and implicit
> mechanisms because it makes expression of the algorithm clearer.
So Forth might benefit from both approaches. Simple low-overhead string
functions for the occasions those are useful, and something that
imitates a complex easy-to-use string package for the times when string
performance is not an issue. When dealing with strings is less than 1%
of the problem, why call in another language to do that? So, both could
be useful.
I'm interested in the possibility you might perhaps get the best of both
worlds. Start with a simple system that's very good at getting low-level
results simply, and it might lead to a more complete system that isn't
as complicated as people now prefer. That would be a win, if the reality
turned out that way. I don't know enough to be sure it couldn't. At some
point there's a minimum complexity you can't reduce, and attempts to get
rid of that only shift it around. But I don't know where that minimum
level is. Maybe some of the things people think are essential for
intermediate results aren't actually essential after all.
Stephen Pelc
(Anton Ertl) wrote:
>: append { addr1 u1 addr2 u2 -- addr u }
> addr1 u1 u2 + dup { u } resize throw { addr }
> addr2 addr u1 + u2 move
> addr u ;
Be very afraid! APPEND is used with different semantics in other
systems, e.g.
: append \ caddr len dest --
where dest is a counted string in a buffer.
>If I don't have to worry about FREEing, I can just use S+ everywhere.
Urk! Eeek! I expect applications to run non-stop for months and
years.
Stephen
--
Stephen Pelc, steph...@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
Dick van Oudheusden
[..]
> What do they have in common?
> Someone else has compiled raw data. It's available in ASCII format.
> That requires me to parse it.
The forth foundation library has a text parsing module
(http://ffl.dvoudheusden.net/docs/tis.html) built upon a
dynamic text string module (http://ffl.dvoudheusden.net/docs/
str.html).
Dick
Bruce McFarling
> What do they have in common?
> Someone else has compiled raw data. It's available in ASCII format.
> That requires me to parse it.
> I doubt anyone would claim string handling as a Forth forte.
However, parsing data in ASCII format *is* a Forth forte.
Indeed, one reason that there are fewer string handling resources in
Forth than in so many other languages is that for so many tasks that
are viewed as "string handling tasks" in other languages, Forth has
simpler, more direct ways to accomplish the objective, so there are
fewer people who need that toolkit.
Then add on top the lack of a de facto library management standard,
and on top of that the fact that for those who only need to do a
specific, people with a distinct set of concrete string tasks can
solve it from scratch with tools like those in TOOL2002. If that is
auxiliary to their main task, then once its solved, they may rarely
need to revisit it. So instead of investing the time and effort into
learning and importing a general purpose string handling toolkit and
than using 5% of it, they build a much simpler special purpose string
handling toolkit and use 100% of it.
Aleksej Saushev
> On Apr 30, 5:14 pm, Richard Owlett <rowl...@atlascomm.net> wrote:
>> What do they have in common?
>> Someone else has compiled raw data. It's available in ASCII format.
>> That requires me to parse it.
>> I doubt anyone would claim string handling as a Forth forte.
>
> However, parsing data in ASCII format *is* a Forth forte.
But the world is not ASCII, and this brings Forth to failure.
> Then add on top the lack of a de facto library management standard,
> and on top of that the fact that for those who only need to do a
> specific, people with a distinct set of concrete string tasks can
> solve it from scratch with tools like those in TOOL2002. If that is
> auxiliary to their main task, then once its solved, they may rarely
> need to revisit it. So instead of investing the time and effort into
> learning and importing a general purpose string handling toolkit and
> than using 5% of it, they build a much simpler special purpose string
> handling toolkit and use 100% of it.
And thus reinventing the same wheel 100 times, instead of reusing
the library written once years ago.
--
BECHA...
CKOPO CE3OH...
Marc Olschok
> Bruce McFarling <agi...@netscape.net> writes:
>
> > On Apr 30, 5:14 pm, Richard Owlett <rowl...@atlascomm.net> wrote:
> >> What do they have in common?
> >> Someone else has compiled raw data. It's available in ASCII format.
> >> That requires me to parse it.
> >> I doubt anyone would claim string handling as a Forth forte.
> >
> > However, parsing data in ASCII format *is* a Forth forte.
>
> But the world is not ASCII, and this brings Forth to failure.
Perhaps the word "контексте" might be worth noting.
>
> > Then add on top the lack of a de facto library management standard,
> > and on top of that the fact that for those who only need to do a
> > specific, people with a distinct set of concrete string tasks can
> > solve it from scratch with tools like those in TOOL2002. If that is
> > auxiliary to their main task, then once its solved, they may rarely
> > need to revisit it. So instead of investing the time and effort into
> > learning and importing a general purpose string handling toolkit and
> > than using 5% of it, they build a much simpler special purpose string
> > handling toolkit and use 100% of it.
>
> And thus reinventing the same wheel 100 times, instead of reusing
> the library written once years ago.
Well, what if it is another wheel each time?
Marc
Bruce McFarling
> Aleksej Saushev <a...@inbox.ru> wrote:
> > > On Apr 30, 5:14 pm, Richard Owlett <rowl...@atlascomm.net> wrote:
> > >> Someone else has compiled raw data. It's available in ASCII format.
...
> > But the world is not ASCII,
... Clearly, the part of the world Richard Owlett describes is ...
> > and this brings Forth to failure.
... therefore this following claim, irrespective of its validity
or invalidity in other problem domains, is naught but red herring
here.
> > > Then add on top the lack of a de facto library management standard,
> > > and on top of that the fact that for those who only need to do a
> > > specific, people with a distinct set of concrete string tasks can
> > > solve it from scratch with tools like those in TOOL2002. If that is
> > > auxiliary to their main task, then once its solved, they may rarely
> > > need to revisit it. So instead of investing the time and effort into
> > > learning and importing a general purpose string handling toolkit and
> > > than using 5% of it, they build a much simpler special purpose string
> > > handling toolkit and use 100% of it.
> > And thus reinventing the same wheel 100 times, instead of reusing
> > the library written once years ago.
Yes, I agree with you here that this *may well be an advantage* ...
instead of staying with the same compromises, same mistakes, and
oftentimes a quite obsolete set of assumptions, in, as you put
it so eloquently "a library written once years ago", this approach
means that the small portion that is actually needed can be
written precisely in tune with the needs of the moment.
It is, as you imply, often a useful thing to keep working
at reinventing the wheel until you get it right.
And further, as Marc notes:
> Well, what if it is another wheel each time?
... which is that 5% that is used out of the library may not be
the same 5% each time, and rather than having a Swiss Army knife
toolkit that does so many different things to a certain extent
that it does nothing very well, this does offer the opportunity
to craft the tool to the precise needs of the moment.
However, even if I follow the strong implication of your statement,
Aleksej, that it is often desirable to write the code from scratch,
I still must insist that having that library would be handy for RAD.
Anton Ertl
>On Thu, 01 May 2008 15:28:43 GMT, an...@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>: append { addr1 u1 addr2 u2 -- addr u }
>> addr1 u1 u2 + dup { u } resize throw { addr }
>> addr2 addr u1 + u2 move
>> addr u ;
>
>Be very afraid! APPEND is used with different semantics in other
>systems, e.g.
Yes, if it's a simple word, it's likely to have already been used for
other purposes elsewhere. This was not intended as a proposal; I
probably would have tried STR+ and STR-APPEND for a proposal.
>>If I don't have to worry about FREEing, I can just use S+ everywhere.
>
>Urk! Eeek! I expect applications to run non-stop for months and
>years.
Easy: <http://www.complang.tuwien.ac.at/forth/garbage-collection.zip>
Or you can worry about FREEing and use (a suitably renamed) APPEND.
Richard Owlett
Thanks. I'm going to have to take a close look.
You have a broken link on http://ffl.dvoudheusden.net/docs/
The link to "manual" is http://ffl.dvoudheusden.net/docs/manual.html
I believe that should be http://ffl.wikidot.com/
Richard Owlett
> On Apr 30, 5:14 pm, Richard Owlett <rowl...@atlascomm.net> wrote:
>
>>What do they have in common?
>>Someone else has compiled raw data. It's available in ASCII format.
>>That requires me to parse it.
>>I doubt anyone would claim string handling as a Forth forte.
>
>
> However, parsing data in ASCII format *is* a Forth forte.
>
> Indeed, one reason that there are fewer string handling resources in
> Forth than in so many other languages is that for so many tasks that
> are viewed as "string handling tasks" in other languages, Forth has
> simpler, more direct ways to accomplish the objective, so there are
> fewer people who need that toolkit.
The more I think about my current pet project, that is very true.
Although the data is much more modern, its format reflects historical
standard Hollerith cards.
P.S. very familiar with an 026
dang it, only wanted to dup thru col 44 not 46
Aleksej Saushev
> Aleksej Saushev <as...@inbox.ru> wrote:
>> Bruce McFarling <agi...@netscape.net> writes:
>>
>> > On Apr 30, 5:14 pm, Richard Owlett <rowl...@atlascomm.net> wrote:
>> >> What do they have in common?
>> >> Someone else has compiled raw data. It's available in ASCII format.
>> >> That requires me to parse it.
>> >> I doubt anyone would claim string handling as a Forth forte.
>> >
>> > However, parsing data in ASCII format *is* a Forth forte.
>>
>> But the world is not ASCII, and this brings Forth to failure.
>
> Perhaps the word "контексте" might be worth noting.
I doubt it, even in the context of ASCII Forth isn't good at parsing,
regular language isn't a problem, but even for that language you have
to hardcode your parser, instead of reusing regular expressions.
(Even Delphi programmers do it!)
When it comes to more complex grammars, I start being afraid,
that Forth BNF parsers are too unusable even for hardcore
Forth hacker. The famous one-screener is purely conceptual ("toy"),
I don't remember, if I have ever seen any example of its usage,
as for others, I don't remember sample code for it either.
To be successful in any field there should be documentation and
sample code, or at least the very little sing of code usage.
I don't observe any. I may be wrong here, since it's been quite
a long time since I checked, but I'm not optimistic.
Maybe, if anyone could point to documentation and sample code
for BNF parser, I could try using it again, though I'm not that
optimistic.
>> > Then add on top the lack of a de facto library management standard,
>> > and on top of that the fact that for those who only need to do a
>> > specific, people with a distinct set of concrete string tasks can
>> > solve it from scratch with tools like those in TOOL2002. If that is
>> > auxiliary to their main task, then once its solved, they may rarely
>> > need to revisit it. So instead of investing the time and effort into
>> > learning and importing a general purpose string handling toolkit and
>> > than using 5% of it, they build a much simpler special purpose string
>> > handling toolkit and use 100% of it.
>>
>> And thus reinventing the same wheel 100 times, instead of reusing
>> the library written once years ago.
>
> Well, what if it is another wheel each time?
It is even worse. Dealing with a dozen of non-standard kinds of
screws is a nightmare, it causes only one and the single wish:
to cram all these screws up those engineers' asses.
The same is appicable to software developers, that suppose the world
is Mac or the world is (Debian) Linux, and ship bundled Boehm GC or
libtool, without any thought about their correctness or portability.
Claiming after that, that their package works (and works correctly!)
on any BSD and even Solaris.
--
BECHA...
CKOPO CE3OH...
Aleksej Saushev
> On May 2, 2:20 pm, Marc Olschok <nob...@nowhere.invalid> wrote:
>> Aleksej Saushev <a...@inbox.ru> wrote:
>
>> > > On Apr 30, 5:14 pm, Richard Owlett <rowl...@atlascomm.net> wrote:
>
>> > > Then add on top the lack of a de facto library management standard,
>> > > and on top of that the fact that for those who only need to do a
>> > > specific, people with a distinct set of concrete string tasks can
>> > > solve it from scratch with tools like those in TOOL2002. If that is
>> > > auxiliary to their main task, then once its solved, they may rarely
>> > > need to revisit it. So instead of investing the time and effort into
>> > > learning and importing a general purpose string handling toolkit and
>> > > than using 5% of it, they build a much simpler special purpose string
>> > > handling toolkit and use 100% of it.
>
>> > And thus reinventing the same wheel 100 times, instead of reusing
>> > the library written once years ago.
>
> Yes, I agree with you here that this *may well be an advantage* ...
> instead of staying with the same compromises, same mistakes, and
> oftentimes a quite obsolete set of assumptions, in, as you put
> it so eloquently "a library written once years ago", this approach
> means that the small portion that is actually needed can be
> written precisely in tune with the needs of the moment.
>
> It is, as you imply, often a useful thing to keep working
> at reinventing the wheel until you get it right.
Low rate of code reuse reduces any utility of this to ashes:
each new developer is forced to start from ground level and
repeat mistakes of previous generations over and over again.
I think, the the whole Forth community would benefit much from
simple project: overview of that famous Taygeta archive.
It will cut Forth proponents down to size, and probably force
them to think about the high quality of software, they're so
much proud of.
> And further, as Marc notes:
>> Well, what if it is another wheel each time?
>
> ... which is that 5% that is used out of the library may not be
> the same 5% each time, and rather than having a Swiss Army knife
> toolkit that does so many different things to a certain extent
> that it does nothing very well, this does offer the opportunity
> to craft the tool to the precise needs of the moment.
>
> However, even if I follow the strong implication of your statement,
> Aleksej, that it is often desirable to write the code from scratch,
> I still must insist that having that library would be handy for RAD.
The rapid development is another frequent point of Forth proponents,
let's see: string processing, list processing (if you sacrifice
performance to speed of development, if not, add balanced trees
and/or other more complex structures), networking, database
connection (even simple one, Berkeley-style). Pretty many of
usual things, you have to deal with _from_scratch_. And this is
all basic stuff, you don't need to take care of, if you have
ready libraries. In Forth communities I've seen only one way
to close the gap: through FFI to C-written libraries.
(Right, there's ColdForth, so what? How can I run it?
Just to check, that it works. Any simulator?
I am not satisfied with UDP-only approach of colorForth either.
Besides that, colorForth presents many other impediments to its
usage, i.e. complete absense of interoperability.)
You tell me about 5% of usage, my estimation is higher, 10% at least,
if you exclude analogues of strcat/strcpy crap (right, I live in
the post-"rm -rf /" world). Anyway, I take your estimation, let
it be 5%.
What do these "5%" include? Memory consumption, right?
Memory is cheap these days, and when it isn't, you can go and
remove unused definitions by hands, if you don't have tools for
this purpose (C, C++, FORTRAN have them, and I don't even know,
how precisely they're invoked, "it just works"). Anton doesn't
bother dealing with memory leaks, and I guess, he doesn't
most of the time.
What else? Nothing significant, I'm afraid.
Now what the _lack_ of these "5%" include.
If you have source for previous projects, you're seaching,
cutting and pasting, searching for dependencies and catching
bugs from various incompatibilities. That's if you try to get
the work done in reasonable time, _provided_ you _do_ have
reusable parts in your previous projects.
If you don't have the source, you're searching for appropriate
library in C, C++, FORTRAN, any other compiled language, trying
to design reasonable interface in Forth and fighting bugs and
deficiencies in FFI. Provided --- again!--- you want to get the
work done in reasonable time, even wasting time on FFI and
interface design.
If the only source you have is in interpreted language, like
Python, Scheme, Lisp, any other, you have to translate it into
Forth or deploy some weird construction with IPC. Thus you fight
with two languages and, optionally, IPC, wasting your time on
anything rather than the problem itself.
Designing good interface takes from one day to a week,
translating, even mechanically, may take much longer.
The last resort, roll your own solution from scratch,
for sufficiently complex library, even provided you're ten times
more productive, this may well mean wasting of monthes.
_This_ is the price you pay for not having those "5%".
--
BECHA...
CKOPO CE3OH...
Aleksej Saushev
...
> If you don't have the source, you're searching for appropriate
> library in C, C++, FORTRAN, any other compiled language, trying
> to design reasonable interface in Forth and fighting bugs and
> deficiencies in FFI. Provided --- again!--- you want to get the
> work done in reasonable time, even wasting time on FFI and
> interface design.
I've forgottent to note.
With C, C++, FORTRAN, you don't even think about those 95% of
wasted space because:
1. You have a linker, which "just sits there and _works_",
removing unreferenced parts of the code.
2. You have shared libraries, which you run _anyway_, since they
are part of the system or common used components, like desktop
environment, or networking services.
And you don't think about FFI, since you have plenty of the code
in native language and tools to interface to the other ones,
which follow the _standard_ platform ABI (C, C++), or the
_common_ one (FORTRAN). That you have to design FFI yourself,
thus including it in the number of missing facilities, is simply
yet another incarnation of the same problem.
Elizabeth D Rather
...
> I think, the the whole Forth community would benefit much from
> simple project: overview of that famous Taygeta archive.
> It will cut Forth proponents down to size, and probably force
> them to think about the high quality of software, they're so
> much proud of.
The Taygeta archive is mostly a relic of the hobbyist era of Forth (the
80's). AFAIK, in 35 years of successful Forth programming, no one at
FORTH, Inc. has used it. So, I'm not sure what your point is.
...
>
> The rapid development is another frequent point of Forth proponents,
> let's see: string processing, list processing (if you sacrifice
> performance to speed of development, if not, add balanced trees
> and/or other more complex structures), networking, database
> connection (even simple one, Berkeley-style). Pretty many of
> usual things, you have to deal with _from_scratch_. And this is
> all basic stuff, you don't need to take care of, if you have
> ready libraries. In Forth communities I've seen only one way
> to close the gap: through FFI to C-written libraries.
Well, that's a very specific list of desiderata, obviously for a
particular class of applications. It is appropriate, as John Passiniti
frequently observes, to chose a language that's a good match for your
application domain. Forth might or might not be it; that's no fault of
Forth, no one language is ideal for all application domains.
In the world I work in, embedded systems, we need none of the features
on your list. In the past, you've deprecated embedded systems
programming, but the fact is there are far, far more microcontrollers in
use in embedded systems than all the PCs and mainframes in the world (a
typical new car has over 100, for example). In embedded systems, you
need easy and intimate access to hardware features and I/O under
development, extremely low overhead I/O and interrupt handling, and (in
most cases) low memory requirements. Forth excels at all this.
And all the Forths adapted for Windows and *nix hosted platforms do
feature easy mechanisms for calling C or other subroutines, so their
users have the same access to libraries as anyone else.
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."
==================================================
Marc Olschok
> Marc Olschok <nob...@nowhere.invalid> writes:
>
> > Aleksej Saushev <as...@inbox.ru> wrote:
> >> Bruce McFarling <agi...@netscape.net> writes:
> >>
> >> > On Apr 30, 5:14 pm, Richard Owlett <rowl...@atlascomm.net> wrote:
> >> >> What do they have in common?
> >> >> Someone else has compiled raw data. It's available in ASCII format.
> >> >> That requires me to parse it.
> >> >> I doubt anyone would claim string handling as a Forth forte.
> >> >
> >> > However, parsing data in ASCII format *is* a Forth forte.
> >>
> >> But the world is not ASCII, and this brings Forth to failure.
> >
> > Perhaps the word "контексте" might be worth noting.
>
> I doubt it, even in the context of ASCII Forth isn't good at parsing,
> regular language isn't a problem, but even for that language you have
> to hardcode your parser, instead of reusing regular expressions.
> (Even Delphi programmers do it!)
Most likely a Forth programmer will happily hardcode a special purpose
parser adapted to the structure of the data, in the same way as he
would build a special solution adapted to some other problem.
I cannot speak from experience here because I do not have any serious
parsing problems where code size is an issue (usually sed and awk are
good enough for me).
Who surely will be glad that it is only software.
But I was actually thinking not just of different implementations
of the same task (along different ways) but instead of implementation
of different (but specialized) tasks. For this, using some already
written general library might involve adapting it to the specific
requirements. The programmer will then try to guess, if this is more
work than writing a new implementation from scratch.
Marc
Dick van Oudheusden
> Dick van Oudheusden wrote:
> > On 30 apr, 23:14, Richard Owlett <rowl...@atlascomm.net> wrote:
> > [..]
>
>
> The link to "manual" ishttp://ffl.dvoudheusden.net/docs/manual.html
> I believe that should behttp://ffl.wikidot.com/
Thanks, I fixed the link.
Dick
Stephen Pelc
wrote:
>When it comes to more complex grammars, I start being afraid,
>that Forth BNF parsers are too unusable even for hardcore
>Forth hacker. The famous one-screener is purely conceptual ("toy"),
>I don't remember, if I have ever seen any example of its usage,
>as for others, I don't remember sample code for it either.
>To be successful in any field there should be documentation and
>sample code, or at least the very little sing of code usage.
>I don't observe any. I may be wrong here, since it's been quite
>a long time since I checked, but I'm not optimistic.
VFX Forth for Windows and Linux provide an extended version
of Brad Rodriguez code. Brad's code was well documented.
We have used it many times, and the Windows resource script
compiler is implemented using the BNF parser.
Aleksej Saushev
From what I hear around, Forth is abandoned in favour of mixture
of C and assembly. You are in minority, but this minority happens
everywhere.
> And all the Forths adapted for Windows and *nix hosted platforms
> do feature easy mechanisms for calling C or other subroutines,
> so their users have the same access to libraries as anyone else.
I doubt that either.
It is a miracle, if you transparently create NUL-terminated strings
from pointer-counter pairs, and get the latter from the former at
the same ease. And I don't believe in such miracles.
--
BECHA...
CKOPO CE3OH...
Aleksej Saushev
> Aleksej Saushev <as...@inbox.ru> wrote:
>> Marc Olschok <nob...@nowhere.invalid> writes:
>>
>> > Aleksej Saushev <as...@inbox.ru> wrote:
>> >> Bruce McFarling <agi...@netscape.net> writes:
>> >>
>> >> > On Apr 30, 5:14 pm, Richard Owlett <rowl...@atlascomm.net> wrote:
>> >> >> What do they have in common?
>> >> >> Someone else has compiled raw data. It's available in ASCII format.
>> >> >> That requires me to parse it.
>> >> >> I doubt anyone would claim string handling as a Forth forte.
>> >> >
>> >> > However, parsing data in ASCII format *is* a Forth forte.
>> >>
>> >> But the world is not ASCII, and this brings Forth to failure.
>> >
>> > Perhaps the word "контексте" might be worth noting.
>>
>> I doubt it, even in the context of ASCII Forth isn't good at parsing,
>> regular language isn't a problem, but even for that language you have
>> to hardcode your parser, instead of reusing regular expressions.
>> (Even Delphi programmers do it!)
>
> Most likely a Forth programmer will happily hardcode a special purpose
> parser adapted to the structure of the data, in the same way as he
> would build a special solution adapted to some other problem.
In Forth land programmer does the job of lexer and parser.
How does your statement align with "1x" and other Forth buzzwords?
Hardcoding is called so, because it is _hard_ to code (among others,
it is hard to maintain too, if possible at all, which suits more
"write-only" attribute of Forth).
> I cannot speak from experience here because I do not have any serious
> parsing problems where code size is an issue (usually sed and awk are
> good enough for me).
And when your awk/sed scripts with sh glue code become too slow?
What will you do?
JFYI, one of Google Summer of Code projects this year is
rewriting a set of such sh+awk+sed in C.
Have you ever tried to support a collection of the code?
Like that, that comes from various GNU and near-GNU sources.
Many sloppy programmers don't use libraries, they prefer shipping
their own versions. I.e. there're dozens of MD5 implementations,
hundreds of base-64 and UU encoding-decoding routines around.
Sometimes those developers just cut and paste the code.
Now what happens, if one innocent soul finds a bug in the
library of one project, especially if it is design bug.
This bug gets fixed in one or another projects, but stays in
others. Just like broken gene. From now on you can't be sure,
that that bug will never manifest itself.
Maybe the word "anti-pattern" is known to you. Once you find
anti-pattern in your code, and fix several its incarnations,
you become unsure, that you really have found and fixed all of
them, especially when you use archives and import others' code.
--
BECHA...
CKOPO CE3OH...
Marc Olschok
> Marc Olschok <nob...@nowhere.invalid> writes:
>
> > Aleksej Saushev <as...@inbox.ru> wrote:
> >> Marc Olschok <nob...@nowhere.invalid> writes:
> >>
> >> > Aleksej Saushev <as...@inbox.ru> wrote:
> >> >> Bruce McFarling <agi...@netscape.net> writes:
> >> I doubt it, even in the context of ASCII Forth isn't good at parsing,
> >> regular language isn't a problem, but even for that language you have
> >> to hardcode your parser, instead of reusing regular expressions.
> >> (Even Delphi programmers do it!)
> >
> > Most likely a Forth programmer will happily hardcode a special purpose
> > parser adapted to the structure of the data, in the same way as he
> > would build a special solution adapted to some other problem.
>
> In Forth land programmer does the job of lexer and parser.
>
> How does your statement align with "1x" and other Forth buzzwords?
what does it mean?
Anyway, I hope that my statements are better than buzzwords.
We already agreed before that the preference for "writing from the ground up"
might be more popular with Forth programmers. Why should parsing and handling
of strings in general be an exception?
> Hardcoding is called so, because it is _hard_ to code (among others,
> it is hard to maintain too, if possible at all, which suits more
> "write-only" attribute of Forth).
The word-play on "hard coding" may have some thruth in it.
But as said before the decision wether to hand-craft a solution
to some specific task (which might not be easily reused for different
tasks) or to adapt some general solution to the current need is influenced
by many factors.
>
> > I cannot speak from experience here because I do not have any serious
> > parsing problems where code size is an issue (usually sed and awk are
> > good enough for me).
>
> And when your awk/sed scripts with sh glue code become too slow?
> What will you do?
I do not know yet, so far this has not happened.
I might try to learn enough about lex+bison in order to build a solution
with these. Or I might use some existing libraries. As long as I do not
have to program in it, I do not mind using C. Also I might rethink
my solution.
>[...]
I agree that this could be the worst of two worlds.
>
> Now what happens, if one innocent soul finds a bug in the
> library of one project, especially if it is design bug.
> This bug gets fixed in one or another projects, but stays in
> others. Just like broken gene. From now on you can't be sure,
> that that bug will never manifest itself.
This should be avoided by proper naming. Of course it should
rarely ever be necessary to literally incorporate e.g. package A
into package B. The obvious solution is to list package A as a
requirement for B, so that updates and corrections can be done
at the approriate place.
Marc
John Passaniti
>> And all the Forths adapted for Windows and *nix hosted platforms
>> do feature easy mechanisms for calling C or other subroutines,
>> so their users have the same access to libraries as anyone else.
>
> I doubt that either.
>
> It is a miracle, if you transparently create NUL-terminated strings
> from pointer-counter pairs, and get the latter from the former at
> the same ease. And I don't believe in such miracles.
A subroutine call is a miracle? For years, I've never had any problem
passing string literals between programming languages. All you have to
do is choose a representation that makes everyone happy:
[count] [text] [0]
When I want to pass this string to a language like C, I point to [text]
and the null at the end keeps the usual library routines happy-- it
doesn't see the leading count. When I want to pass this string to a
language like Forth, I either point to [text] and dereference [count],
or I point to [count] as appropriate. It doesn't see the null terminator.
Bruce McFarling
> > ... which is that 5% that is used out of the library may not be
> > the same 5% each time, and rather than having a Swiss Army knife
> > toolkit that does so many different things to a certain extent
> > that it does nothing very well, this does offer the opportunity
> > to craft the tool to the precise needs of the moment.
> > However, even if I follow the strong implication of your statement,
> > Aleksej, that it is often desirable to write the code from scratch,
> > I still must insist that having that library would be handy for RAD.
> The rapid development is another frequent point of Forth proponents,
> let's see: string processing, list processing (if you sacrifice
> performance to speed of development, if not, add balanced trees
> and/or other more complex structures), networking, database
> connection (even simple one, Berkeley-style). Pretty many of
> usual things, you have to deal with _from_scratch_.
Well, not have to. However, as appealing an argument as you present
for doing it from scratch, I continue to argue that a common library
oversight system to support easier contribution into and easier
borrowing from common libraries of the above is superior to what you
are sketching here.
And what you argue here is not quite true ... certainly I can see from
your perspective, where the ideal to strive for is reinventing the
wheel each time, that you might idealize the position of Forth to be
one where everyone reinvents the wheel all the time. However, Forth
actually falls well short of your ideal in that regard. Many people
who use Forth on a regular basis enjoy quite substantial existing
libraries of Forth source for quite a range of functions, which come
bundled with the Forth compilers from the main Forth compiler vendors.
However, you are quite accurate in one regard. It *is* far easier to
escape the straightjacket of general regular *expressions*, and
process regular textual patterns directly, when you have a situation
that enough people were required to re-invent the same wheel enough
times to avoid that particular cul-de-sac. Good catch on that one.
> _This_ is the price you pay for not having those "5%".
So its fortunate that "not having that 5%" is mere hyperbole ... your
ideal of a Forth programmer inventing everything from scratch, as
opposed to reality.
Stephen Pelc
wrote:
>> And all the Forths adapted for Windows and *nix hosted platforms
>> do feature easy mechanisms for calling C or other subroutines,
>> so their users have the same access to libraries as anyone else.
>
>I doubt that either.
Why? Which Forths have you surveyed? I have ten non-MPE systems
that I survey regularly.
>It is a miracle, if you transparently create NUL-terminated strings
>from pointer-counter pairs, and get the latter from the former at
>the same ease. And I don't believe in such miracles.
Ah, the one true way to handle strings! Every Windows/Unix Forth
that I have looked at also has a wordset for zero-terminated
strings and wrappers for common operations.
If you really mean that the "free" or "Open Source" Forths
have not caught up with the commercial Forths, then say so.
Hand-waving is not good enough. Give me examples and numbers,
and I'll consider them. Show me better ways to do things in
Forth, and I'll be grateful.
astrobe
> I've equivalents of Basic string handling (start/count), ZX string
> handling (start/end), but I rarely seem to use them.
Where did you pick that 'ZX' name for (start/end) strings?
Amicalement,
Astrobe
Alex McDonald
Exactly how Win32forth does it. Some string operators also append
silent nulls; there are very few cases where an explicit +null is
required, but +null is there if needed.
Without call support, most hosted Forths would be blind and dumb.
--
Regards
Alex McDonald
Aleksej Saushev
> Aleksej Saushev <as...@inbox.ru> wrote:
>> Marc Olschok <nob...@nowhere.invalid> writes:
>>
>> > Aleksej Saushev <as...@inbox.ru> wrote:
>> >> Marc Olschok <nob...@nowhere.invalid> writes:
>> >>
>> >> > Aleksej Saushev <as...@inbox.ru> wrote:
>> >> >> Bruce McFarling <agi...@netscape.net> writes:
>>[...]
>> >> I doubt it, even in the context of ASCII Forth isn't good at parsing,
>> >> regular language isn't a problem, but even for that language you have
>> >> to hardcode your parser, instead of reusing regular expressions.
>> >> (Even Delphi programmers do it!)
>> >
>> > Most likely a Forth programmer will happily hardcode a special purpose
>> > parser adapted to the structure of the data, in the same way as he
>> > would build a special solution adapted to some other problem.
>>
>> In Forth land programmer does the job of lexer and parser.
>>
>> How does your statement align with "1x" and other Forth buzzwords?
> _____________________________________^^^_
> what does it mean?
Ever heard of "1x Programming"?
> Anyway, I hope that my statements are better than buzzwords.
What makes you think so? Have you ever tried to align your words
with practice around you? Or do you assume, that being ignorant
of life around you protects you from making the same mistakes?
> We already agreed before that the preference for "writing from the ground up"
> might be more popular with Forth programmers. Why should parsing and handling
> of strings in general be an exception?
Togda pochemu ty pisheshj po-anglijski, prichjom dovoljno gramotno?
Why do you write in grammatically correct English then, rather
than inventing your own way? Isn't it strange? You solve regular
life problems in common English, but you don't solve programming
tasks in common Forth, you tend to invent your _own_ domain language
rather.
>> Hardcoding is called so, because it is _hard_ to code (among others,
>> it is hard to maintain too, if possible at all, which suits more
>> "write-only" attribute of Forth).
>
> The word-play on "hard coding" may have some thruth in it.
> But as said before the decision wether to hand-craft a solution
> to some specific task (which might not be easily reused for different
> tasks) or to adapt some general solution to the current need is influenced
> by many factors.
Right. But the domain of those problems stabilized long ago. In C, which
started _later_ you have basic string primitives (string.h, strings.h),
not-so-basic string parsing tools (regex.h), even more complex tools
(LEX, YACC), all for long time now. In Forth, which entered same area
in 1980s-90s, you hardly have analogue of string.h/strings.h in common use.
I don't take embedded area, though the presence of HTTP server in electronic
teapot isn't uncommon these days.
>> > I cannot speak from experience here because I do not have any serious
>> > parsing problems where code size is an issue (usually sed and awk are
>> > good enough for me).
>>
>> And when your awk/sed scripts with sh glue code become too slow?
>> What will you do?
>
> I do not know yet, so far this has not happened.
> I might try to learn enough about lex+bison in order to build a solution
> with these. Or I might use some existing libraries. As long as I do not
> have to program in it, I do not mind using C. Also I might rethink
> my solution.
How are you going to work with LEX and YACC (bison is just GNU version of it)
without programming in C? Are you going to do that in Java or SML/OCaml
with their versions of respective tools?
Please, if you say "should be", provide examples in support.
I assure you, that seeking for examples and protecting from
counter-examples brings up more issues, that prevent you from
saying such an easy "should."
How are you going to label library that provides calculation of MD5
digests? Why should I call my "libmd5" a "lib_all_my_names_here_md5"?
Why should I install it under /usr/local/lib/my-project rather than
/usr/local/lib, or even more simple /usr/lib or /lib? Am I not going
to reuse it in other my packages?
Or are you going to rename functions? It may provide bug-to-bug
compatibility, but how do you know which one does what?
Do you propose adding version numbers to it?
How does it align with simple "md5(string)" and "md5_2(acc, string)"?
> Of course it should
> rarely ever be necessary to literally incorporate e.g. package A
> into package B. The obvious solution is to list package A as a
> requirement for B, so that updates and corrections can be done
> at the approriate place.
"Should?" Must!
--
BECHA...
CKOPO CE3OH...
Marc Olschok
> Marc Olschok <nob...@nowhere.invalid> writes:
>
> > Aleksej Saushev <as...@inbox.ru> wrote:
> >> Marc Olschok <nob...@nowhere.invalid> writes:
> >>
> >> > Aleksej Saushev <as...@inbox.ru> wrote:
> >> >> Marc Olschok <nob...@nowhere.invalid> writes:
> >> >>
> >> >> > Aleksej Saushev <as...@inbox.ru> wrote:
> >> >> >> Bruce McFarling <agi...@netscape.net> writes:
> >>[...]
> >> >> I doubt it, even in the context of ASCII Forth isn't good at parsing,
> >> >> regular language isn't a problem, but even for that language you have
> >> >> to hardcode your parser, instead of reusing regular expressions.
> >> >> (Even Delphi programmers do it!)
> >> >
> >> > Most likely a Forth programmer will happily hardcode a special purpose
> >> > parser adapted to the structure of the data, in the same way as he
> >> > would build a special solution adapted to some other problem.
> >>
> >> In Forth land programmer does the job of lexer and parser.
> >>
> >> How does your statement align with "1x" and other Forth buzzwords?
> > _____________________________________^^^_
> > what does it mean?
>
> Ever heard of "1x Programming"?
No.
>
> > Anyway, I hope that my statements are better than buzzwords.
>
> What makes you think so? Have you ever tried to align your words
> with practice around you? Or do you assume, that being ignorant
> of life around you protects you from making the same mistakes?
I might be ignorant about life around _you_, but I am quite aware
of life around me. So far I am happy with solving those problems
I have instead of those I do not have.
>
> > We already agreed before that the preference for
> > "writing from the ground up"
> > might be more popular with Forth programmers.
> > Why should parsing and handling
> > of strings in general be an exception?
>
> Togda pochemu ty pisheshj po-anglijski, prichjom dovoljno gramotno?
>
> Why do you write in grammatically correct English then, rather
> than inventing your own way?
Because the disadvantage of being less widely understood would
outweigh the advantage of any personal grammar of English.
Also the established grammar is usually sufficient for what I
want to express.
> Isn't it strange? You solve regular
> life problems in common English, but you don't solve programming
> tasks in common Forth, you tend to invent your _own_ domain language
> rather.
Not strange at all. Common language is good enough for common problems.
But extension of language and building of special domain languages happens
all the time. Also, the invention of a special domain language does not
mean that the grammar of the base language is rebuild from scratch.
>
> >> Hardcoding is called so, because it is _hard_ to code (among others,
> >> it is hard to maintain too, if possible at all, which suits more
> >> "write-only" attribute of Forth).
> >
> > The word-play on "hard coding" may have some thruth in it.
> > But as said before the decision wether to hand-craft a solution
> > to some specific task (which might not be easily reused for different
> > tasks) or to adapt some general solution to the current need is influenced
> > by many factors.
>
> Right. But the domain of those problems stabilized long ago. In C, which
> started _later_ you have basic string primitives (string.h, strings.h),
> not-so-basic string parsing tools (regex.h), even more complex tools
> (LEX, YACC), all for long time now. In Forth, which entered same area
> in 1980s-90s, you hardly have analogue of string.h/strings.h in common use.
I agree with you. The need for consolidation and unification of
different (incompatible) language extensions is only felt when the
particular domain is important enough to the user base. Without this
pressure, it does not happen and the different variant coexist.
It happens in natural languages too, see e.g.
<http://www.philhist.uni-augsburg.de/lehrstuehle/germanistik/\
sprachwissenschaft/medien/umfrage_regionalersprachgebrauch/Broetchen.jpg>
>[...]
> >> > I cannot speak from experience here because I do not have any serious
> >> > parsing problems where code size is an issue (usually sed and awk are
> >> > good enough for me).
> >>
> >> And when your awk/sed scripts with sh glue code become too slow?
> >> What will you do?
> >
> > I do not know yet, so far this has not happened.
> > I might try to learn enough about lex+bison in order to build a solution
> > with these. Or I might use some existing libraries. As long as I do not
> > have to program in it, I do not mind using C. Also I might rethink
> > my solution.
>
> How are you going to work with LEX and YACC without programming in C?
> Are you going to do that in Java or SML/OCaml
> with their versions of respective tools?
This would depend on how involved the work is. Given my preferences, I
would most likely prefer tools from SML or Prolog. But I do not know
yet, as I said before, so far all my parsing tasks have been trivial.
>[...]
It depends on the situation. Suppose that I have some project where
for some reason I use a foreign library.
(a) if I did not change anything then I might even use the original name.
But as not bug repair may not result in a change of version number in the
original library, I would perhaps attach a time stamp, e.g. rename
libmd5 to libmd5-20080512 or similar.
(b) if I changed anything, then I would use a different name, e.g. change
libmd5 to libmd5_whatever and also make it quite clear that my version
is different from the original one and document the changes.
It is vital that the prospective user is never in the dark about
what he is acually using.
Anyway, the best solution is to avoid the problem altogether by
referencing to the foreign library instead of including it.
>
> > Of course it should
> > rarely ever be necessary to literally incorporate e.g. package A
> > into package B. The obvious solution is to list package A as a
> > requirement for B, so that updates and corrections can be done
> > at the approriate place.
>
> "Should?" Must!
The phrase "Of course it must rarely ever be necessary to ..." is
not in my bag of English. Anyway, I know what you mean and sympathize
with it.
Marc
pml5...@gmail.com
> {Grasshopper, capitalization in subject line significant :}
>
> What is so right with Forth that it *OVERRIDES* ALL negative comments?
>
> Obviously the : ; pair.
Actually, I've been doing occasional work on a Forth variant with a
different compiler/interpreter that doesn't even have that, but has a
Reverse Polish naming approach. The basic idea, before syntactic
sugar, is that it compiles left to right in the usual way, building up
anonymous secondaries. Any unrecognised token terminates the current
anonymous secondary and is assigned as its name, and a new anonymous
secondary starts. At the end of the source string the final anonymous
secondary is closed off and run. Before syntactic sugar, ANY source is
valid!
This loses a lot of what most Forths are aiming for, like the other
defining words and maybe even immediate words, but I was just
testbedding something that doesn't need or want them anyway, so
workarounds are good enough there. For further details, see
http://users.beagle.com.au/peterl/furphy.html. (One possible variant:
terminate all anonymous secondaries with branches back to the
beginning so they default to infinite loops, and provide a conditional
return as the only essential explicit control construct.) P.M.Lawrence.
Jonah Thomas
> Actually, I've been doing occasional work on a Forth variant with a
> different compiler/interpreter that doesn't even have that, but has a
> Reverse Polish naming approach. The basic idea, before syntactic
> sugar, is that it compiles left to right in the usual way, building up
> anonymous secondaries. Any unrecognised token terminates the current
> anonymous secondary and is assigned as its name, and a new anonymous
> secondary starts. At the end of the source string the final anonymous
> secondary is closed off and run. Before syntactic sugar, ANY source is
> valid!
Interesting! I wonder if John Doty has seen this. Or Chuck Moore.
There's a radical simplicity to it.
> This loses a lot of what most Forths are aiming for, like the other
> defining words and maybe even immediate words, but I was just
> testbedding something that doesn't need or want them anyway, so
> workarounds are good enough there.
> For further details, see
> http://users.beagle.com.au/peterl/furphy.html.
> (One possible variant:
> terminate all anonymous secondaries with branches back to the
> beginning so they default to infinite loops, and provide a conditional
> return as the only essential explicit control construct.)
> P.M.Lawrence.
I'm troubled by what you call "false friends", commands that have the
same name as Forth commands but radically different actions. If you
implement it in Forth that looks like it invites problems, and it
shouldn't be too hard to make new names. But a quick look at your Pygmy
code did show new names.
It always seemed to me that Forth could be used like a functional
language, at least in talking-dog style. ("You complain that he doesn't
speak well, but it's remarkable he can talk at all.") Avoid variables
etc and you can mostly avoid side effects. Often composition of
functions is simple. If you don't mind strict evaluation then
z = f(x);
y = z * z;
becomes
: f ( ? -- z )
??? ;
: y ( z -- z^2 )
DUP * ;
: y(f)
f y ;
And of course recursion is available etc.
But you're taking it a lot further.
pml5...@gmail.com
.
.
> I'm troubled by what you call "false friends", commands that have the
> same name as Forth commands but radically different actions. If you
> implement it in Forth that looks like it invites problems, and it
> shouldn't be too hard to make new names. But a quick look at your Pygmy
> code did show new names.
The question coming up there, pretty much the reason I am testbedding,
is to see whether it makes more sense to end up with a distinct
functional language a la Joy, only put together bottom up to find
implementation issues, or to find a useful word set for Forth that
would make it easier to code functionally in that. For a new language,
you're anyway going to get false friends for non-Forthers who come to
it if you try to be too Forth-like, so it's best to seek "natural"
approaches - natural in terms of the new language - and warn Forthers
that it is NOT Forth. But yes, if I end up with a word set for Forth,
I agree that there should be distinct word names. P.M.Lawrence.
John Doty
> pml5...@gmail.com wrote:
>
>> Actually, I've been doing occasional work on a Forth variant with a
>> different compiler/interpreter that doesn't even have that, but has a
>> Reverse Polish naming approach. The basic idea, before syntactic
>> sugar, is that it compiles left to right in the usual way, building up
>> anonymous secondaries. Any unrecognised token terminates the current
>> anonymous secondary and is assigned as its name, and a new anonymous
>> secondary starts. At the end of the source string the final anonymous
>> secondary is closed off and run. Before syntactic sugar, ANY source is
>> valid!
If I'd known about this, I would have used this approach to bootstrap
LSE64. It's basically a primitive assembly language for a Forth VM.
Simple and clean. However, I wouldn't want to program anything complex
in it.
A programming language designer I knew long ago made the point that you
want a decent "Hamming distance" between syntactically correct programs:
otherwise you'll waste lots of time chasing down trivial typos.
Mostly you don't need a primitive assembler for programming by human
beings: a macro assembler is more useful. Traditional Forth is
essentially a rather kludgy macro assembler for the Forth VM. It would
help to clean this up, but to make the power of the Forth VM more
accessible to users we also need a real general purpose language for it,
I think.
>
> Interesting! I wonder if John Doty has seen this. Or Chuck Moore.
> There's a radical simplicity to it.
Yeah, but I got very busy. My VLSI customer surprised me by asking for
another design iteration (the last one met requirements, but they want
even more). And I got handed another electronic design job on a short fuse.
And now, a very big astronomy project is starting, and two additional
proposals have won funding. Forth is looking pretty unattractive now, as
all of my projects are moving from concept to implementation, and the
challenge is more human communication than anything else. Forth's great
for trying things on the bench, but it's lousy for communicating ideas
to a large team.
Out of all the speculation about my personal life that people on this
group have attempted to avoid facing the points I make, you are the only
one who got something right: I sometimes get too busy to bother with
newsgroups.
>
>> This loses a lot of what most Forths are aiming for, like the other
>> defining words and maybe even immediate words, but I was just
>> testbedding something that doesn't need or want them anyway, so
>> workarounds are good enough there.
>
>> For further details, see
>> http://users.beagle.com.au/peterl/furphy.html.
>
>> (One possible variant:
>> terminate all anonymous secondaries with branches back to the
>> beginning so they default to infinite loops, and provide a conditional
>> return as the only essential explicit control construct.)
>> P.M.Lawrence.
>
> I'm troubled by what you call "false friends", commands that have the
> same name as Forth commands but radically different actions.
Compare "THEN" in traditional Forth to "THEN" in English or in other
programming languages. Forth has a long history of abusing familiar
symbols, so I can't see how you can object here.
> If you
> implement it in Forth that looks like it invites problems, and it
> shouldn't be too hard to make new names. But a quick look at your Pygmy
> code did show new names.
>
>
> It always seemed to me that Forth could be used like a functional
> language, at least in talking-dog style. ("You complain that he doesn't
> speak well, but it's remarkable he can talk at all.") Avoid variables
> etc and you can mostly avoid side effects. Often composition of
> functions is simple. If you don't mind strict evaluation then
>
> z = f(x);
> y = z * z;
>
> becomes
>
> : f ( ? -- z )
> ??? ;
>
> : y ( z -- z^2 )
> DUP * ;
>
> : y(f)
> f y ;
>
> And of course recursion is available etc.
>
> But you're taking it a lot further.
--
John Doty, Noqsi Aerospace, Ltd.
http://www.noqsi.com/
--
History teaches that logical consistency is neither sufficient nor
necessary to establish practical, real world truth. Those who attempt to
use logic for that purpose are abusing it.