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

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

Tiny regular expressions code

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

Contents

  Tiny regular expressions code Hans Bezemer <the.beez.speaks@gmail.com> - 2014-10-13 18:15 +0200
    Re: Tiny regular expressions code Hans Bezemer <the.beez.speaks@gmail.com> - 2014-10-13 18:18 +0200
      Re: Tiny regular expressions code Pablo Hugo Reda <pabloreda@gmail.com> - 2014-10-13 09:32 -0700
      Re: Tiny regular expressions code Howerd <howerdo@yahoo.co.uk> - 2014-10-13 11:18 -0700
        Re: Tiny regular expressions code Hans Bezemer <the.beez.speaks@gmail.com> - 2014-10-13 20:36 +0200
          Re: Tiny regular expressions code Howerd <howerdo@yahoo.co.uk> - 2014-10-13 11:53 -0700
    Re: Tiny regular expressions code Hans Bezemer <the.beez.speaks@gmail.com> - 2014-10-13 22:14 +0200
    Re: Tiny regular expressions code mhx@iae.nl (Marcel Hendrix) - 2014-10-13 22:59 +0200
      Re: Tiny regular expressions code Hans Bezemer <the.beez.speaks@gmail.com> - 2014-10-13 23:11 +0200
    Re: Tiny regular expressions code albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-14 09:22 +0000
      Re: Tiny regular expressions code Hans Bezemer <the.beez.speaks@gmail.com> - 2014-10-14 17:43 +0200
        Re: Tiny regular expressions code albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-14 16:27 +0000
          Re: Tiny regular expressions code albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-15 09:48 +0000
            Re: Tiny regular expressions code Hans Bezemer <the.beez.speaks@gmail.com> - 2014-10-15 17:38 +0200
              Re: Tiny regular expressions code albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-16 09:20 +0000
    Re: Tiny regular expressions code josv@planet.nl - 2014-10-17 05:03 -0700
      Re: Tiny regular expressions code Hans Bezemer <the.beez.speaks@gmail.com> - 2014-10-17 17:48 +0200
        Re: Tiny regular expressions code Hans Bezemer <the.beez.speaks@gmail.com> - 2014-10-17 19:20 +0200
          Re: Tiny regular expressions code anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-18 15:43 +0000
            Re: Tiny regular expressions code Hans Bezemer <the.beez.speaks@gmail.com> - 2014-10-18 18:53 +0200
            Re: Tiny regular expressions code hughaguilar96@yahoo.com - 2014-10-18 19:19 -0700
              Re: Tiny regular expressions code Hans Bezemer <the.beez.speaks@gmail.com> - 2014-10-19 14:52 +0200
                Re: Tiny regular expressions code Hans Bezemer <the.beez.speaks@gmail.com> - 2014-10-19 15:25 +0200
                  Re: Tiny regular expressions code Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-19 21:14 +0200
                    Re: Tiny regular expressions code Hans Bezemer <the.beez.speaks@gmail.com> - 2014-10-20 00:17 +0200
                Re: Tiny regular expressions code albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-19 17:10 +0000
                  Re: Tiny regular expressions code Hans Bezemer <the.beez.speaks@gmail.com> - 2014-10-19 19:59 +0200
            Re: Tiny regular expressions code Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-19 09:31 -0500
              The magical number seven (was: Tiny regular expressions code) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-20 09:10 +0000
                Re: The magical number seven (was: Tiny regular expressions code) m.a.m.hendrix@tue.nl - 2014-10-20 03:13 -0700
                  Re: The magical number seven (was: Tiny regular expressions code) mhx@iae.nl (Marcel Hendrix) - 2014-10-20 20:19 +0200
                    Re: The magical number seven Lars Brinkhoff <lars.spam@nocrew.org> - 2014-10-21 08:56 +0200
                      Re: The magical number seven Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-21 11:44 +0200
                    Re: The magical number seven (was: Tiny regular expressions code) Just Ian <superian@gmail.com> - 2014-10-21 07:06 -0700
                      Re: The magical number seven (was: Tiny regular expressions code) mhx@iae.nl (Marcel Hendrix) - 2014-10-21 20:11 +0200
                      Re: The magical number seven Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-26 04:27 -0500
                Re: The magical number seven (was: Tiny regular expressions code) Hans Bezemer <the.beez.speaks@gmail.com> - 2014-10-20 17:28 +0200
                  Re: The magical number seven (was: Tiny regular expressions code) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-20 16:25 +0000
                  Re: The magical number seven (was: Tiny regular expressions code) "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-20 16:36 -0400
                    Re: The magical number seven "Elizabeth D. Rather" <erather@forth.com> - 2014-10-20 12:19 -1000
                      Re: The magical number seven "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-21 01:47 -0400
                        Re: The magical number seven "Elizabeth D. Rather" <erather@forth.com> - 2014-10-20 20:31 -1000
                          Re: The magical number seven albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-21 09:06 +0000
                            Re: The magical number seven "Elizabeth D. Rather" <erather@forth.com> - 2014-10-21 08:47 -1000
                              Re: The magical number seven "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-22 02:21 -0400
                    Re: The magical number seven (was: Tiny regular expressions code) Hans Bezemer <the.beez.speaks@gmail.com> - 2014-10-21 10:29 +0200
                      Re: The magical number seven (was: Tiny regular expressions code) Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-21 11:34 +0200
                      Re: The magical number seven Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-26 04:41 -0500
                        Re: The magical number seven Hans Bezemer <the.beez.speaks@gmail.com> - 2014-10-26 12:07 +0100
                          Re: The magical number seven Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-26 13:58 -0500
                  Re: The magical number seven (was: Tiny regular expressions code) hughaguilar96@yahoo.com - 2014-10-20 16:34 -0700
                  Re: The magical number seven Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-26 04:33 -0500
                    Re: The magical number seven Hans Bezemer <the.beez.speaks@gmail.com> - 2014-10-26 12:12 +0100
                Re: The magical number seven Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-26 04:24 -0500
            Re: Tiny regular expressions code mhx@iae.nl (Marcel Hendrix) - 2014-10-19 17:10 +0200
        Re: Tiny regular expressions code Hans Bezemer <the.beez.speaks@gmail.com> - 2014-10-18 16:02 +0200
          Re: Tiny regular expressions code josv@planet.nl - 2014-10-18 07:50 -0700
    Re: Tiny regular expressions code Hans Bezemer <the.beez.speaks@gmail.com> - 2014-10-18 17:27 +0200
    Re: Tiny regular expressions code the_gavino_himself <visphatesjava@gmail.com> - 2014-11-08 19:24 -0800
    Re: Tiny regular expressions code the_gavino_himself <visphatesjava@gmail.com> - 2014-11-08 20:42 -0800

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

#34016

On Saturday, October 18, 2014 8:47:43 AM UTC-7, Anton Ertl wrote:
> Related to an adjacent discussion: I think that this serves nicely as
> a demonstration that lack of locals does not automatically lead to
> well-factored code (especially if you use 'the magical "seven, plus or
> minus two" words' *maximum* as the definition of "well-factored").

I agree with Anton on this --- I don't write such lengthy Forth with multiple levels of control-structure indentation. The fact that Hans is writing code at all, however, puts him way ahead of the majority of C.L.F. experts who never write any code, so I applaud his effort.

I haven't actually examined Hans' code closely, as regular-expressions aren't something that I'm interested in. The last time that the subject of pattern-matching text came up, was this thread:
https://groups.google.com/forum/#!searchin/comp.lang.forth/google$20codejam/comp.lang.forth/S6vlFRldw44/ikfRkqH7968J
It might be interesting if Hans were to try out his regular-expression code on that problem.

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

#34018

hughaguilar96@yahoo.com wrote:

> On Saturday, October 18, 2014 8:47:43 AM UTC-7, Anton Ertl wrote:
> I agree with Anton on this --- I don't write such lengthy Forth with
> multiple levels of control-structure indentation.
Basically, knowing the rules also implies you know why they're there and
break 'em if they don't make sense. In this case, library code shouldn't
clutter my name space too much and run as fast as possible.

Furthermore, it should still remain to be as maintainable as possible (or
required). The latter is taken care of by keeping the stack diagram pretty
stable: every line starts of with "a n wa wn". That's good enough for me.

> The fact that Hans is 
> writing code at all, however, puts him way ahead of the majority of C.L.F.
> experts who never write any code, so I applaud his effort.
I couldn't agree with you more! That's why I started off this thread
with "Hey, here's some code, instead off simply bashing each others heads
in during some academical discussion or personal vendetta". It's ridiculous
when you compare it with other newsgroups on programming. Like a bunch of
old, fat guys discussing how to get most of the performance out of an
engine or whether a car should be modified or remain original, but NEVER
DRIVE A MILE.

And finally, I find it offending when posing somebodies code as "an example
of bad programming" when there is a SEE.F lying around in his own code for
ages which IMHO is much more horrifying than this snippit. I take that very
personally and shows what a bunch of arrogant snobs have taken over the
discussions here. 

I have the habit of rewriting a bad piece of my own code (like WILDCARD.4TH)
when I come across it - and I have almost 400 libraries to maintain.

If you want to see how well others attacked this particular piece of code,
check
https://groups.google.com/forum/#!searchin/comp.lang.forth/wildcard/comp.lang.forth/hKwBzF_RNWY/BW57ZepUOR4J
You'll see that the initials AE are lacking (as usual), since the person in
particular doesn't make his hands dirty by writing actual code himself and
expose it to the scrutiny of his peers. Let alone write something useful
(in the REAL world) and let others build on it and improve it. That's what
FOSS (gforth is GNU) is all about in the first place - and c.l.f. should be
a forum, a breeding ground for that. But it's not.

From time to time I'm visiting Google group Fignition, where you still find
the hint of the FIG-Forth era of coding - and its' fun, it's what Forth was
and should be.

I use 4tH personally and for work, simply because it gives me an edge. I
crunch out functionality faster than others, because if something is
lacking, I can add it - up to the compiler itself. I did a 64K program in
less than a week. It merged data from half a dozen different sources,
identified the format, checked it, cleaned it up, produced error lists in
binary Excel, punched out a clean .CSV file, ready to be read in and left a
run report which was acceptable for an accountant. When it ran, it did in
about 30 secs what it had taken a grown man 

When I left, they wanted to port the thing to C (or something). I wrote down
the exact specifications (including the code that catered for the zillion
possible date formats it could decipher - from native Excel via "3 letter
code" to ISO) and they found out it would take a good C-programmer 3 months
to replicate.

Did I cut corners here and there? Absolutely. And I can tell you right where
they are and why I cut them. That's the real world. But I'm not there to
write academic papers, I'm there to make a difference and get the job done
within time and budget. And BTW, I'm not a programmer, I'm a service
management consultant who's not afraid to get his hands dirty when the
world needs to be saved. And yes, I do have a few dozens publications on my
name, including Forth related if you really want to know.

So In order to give you all something to criticize and waste a perfect day
again, here's the code I wrote this week. I wrote it in an hour or so to
convert a bunch of SQL statements into a neatly .CSV file so I could match
it against the data dictionary, instead of letting some poor bastard match
the whole 3000 fields by hand. You can see where the "awful regex" code
came in handy.

I hope you all feel very good about yourselves, because "I'm ok and you're
ok" isn't as much fun as "I'm ok and you're an @$$hole".

Hans Bezemer

---8<---
include lib/kpre.4th
include lib/leading.4th
include lib/scanskip.4th
include lib/compare.4th

variable #lines
2048 constant /buffer
/buffer buffer: buffer
64 string tablename

: Usage abort" Usage: extract infile outfile " ;
: Read-file refill ;
: Preprocess 0 #lines ! buffer /buffer source! ." Tablename, fieldname" cr ;
: trimming -leading -trailing ;
: table? 2dup [char] . split 2drop chop tablename place ;

: field?
  over s" SELECT" >r r@ rot r@ compare 0= if r> /string else r> drop then
  trimming bl split trimming 2swap
  trimming bl split trimming 2nip
  s" AS" compare
  if
    ." Suspicious field [" type ." ] at line " #lines ? cr 2drop
  else
    tablename count type ." , " type cr
  then
;

: fields?
  begin
    dup 0>
  while
    [char] , split trimming dup 0> if field? chop else 2drop then
  repeat
;

: Process
  1 #lines +!
  0 parse trimming
  dup if
    2dup s" ^%9%9*\..*$" match-reg if table? else
      2dup s| ^.*".*"%_*as%_*".*".*| match-reg if fields? then
    then
  then 2drop
;

[needs lib/convert.4th]
---8<---

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

#34019

Hans Bezemer wrote:

BTW, fix this one in "prim.fs":

: d2*+ ( ud n -- ud+n c )
   over MINI
   and >r >r 2dup d+ swap r> + swap r> ;

It should be:

: d2*+ ( ud n -- ud+n c )
   over MINI
   and >r >r 2dup d+ r> 0 d+ r> ;

It's been there for ages as well.

Hans Bezemer

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

#34024

Hans Bezemer wrote:

> Hans Bezemer wrote:
> 
> BTW, fix this one in "prim.fs":
> 
> : d2*+ ( ud n -- ud+n c )
>    over MINI
>    and >r >r 2dup d+ swap r> + swap r> ;
> 
> It should be:
> 
> : d2*+ ( ud n -- ud+n c )
>    over MINI
>    and >r >r 2dup d+ r> 0 d+ r> ;
> 
> It's been there for ages as well.

It pobably has stayed there because the recommendation is when you don't 
implement the multiplication and the division in assembler, please at least 
implement d2*+, the support primitive.  And I'm sure this d2*+ has been 
tested in the context it is supposed to be used, and worked there 
(multiplication).  It's just that if you use it for general purpose stuff, 
it won't work.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#34027

Bernd Paysan wrote:
> It pobably has stayed there because the recommendation is when you don't
> implement the multiplication and the division in assembler, please at
> least
> implement d2*+, the support primitive.  And I'm sure this d2*+ has been
> tested in the context it is supposed to be used, and worked there
> (multiplication).  It's just that if you use it for general purpose stuff,
> it won't work.
Well, I didn't. It's used in UM/MOD and UM* definitions afterwards, which
render the wrong results because of it. But (as I always say at work) I
told you, so it's your problem now.

Hans Bezemer

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

#34022

In article <5443b39a$0$2947$e4fe514c@news2.news.xs4all.nl>,
Hans Bezemer  <the.beez.speaks@gmail.com> wrote:
>hughaguilar96@yahoo.com wrote:
>
>> On Saturday, October 18, 2014 8:47:43 AM UTC-7, Anton Ertl wrote:
>> I agree with Anton on this --- I don't write such lengthy Forth with
>> multiple levels of control-structure indentation.
>Basically, knowing the rules also implies you know why they're there and
>break 'em if they don't make sense. In this case, library code shouldn't
>clutter my name space too much and run as fast as possible.
>
>Furthermore, it should still remain to be as maintainable as possible (or
>required). The latter is taken care of by keeping the stack diagram pretty
>stable: every line starts of with "a n wa wn". That's good enough for me.
>
>> The fact that Hans is
>> writing code at all, however, puts him way ahead of the majority of C.L.F.
>> experts who never write any code, so I applaud his effort.
>I couldn't agree with you more! That's why I started off this thread
>with "Hey, here's some code, instead off simply bashing each others heads
>in during some academical discussion or personal vendetta". It's ridiculous
>when you compare it with other newsgroups on programming. Like a bunch of
>old, fat guys discussing how to get most of the performance out of an
>engine or whether a car should be modified or remain original, but NEVER
>DRIVE A MILE.
>
>And finally, I find it offending when posing somebodies code as "an example
>of bad programming" when there is a SEE.F lying around in his own code for
>ages which IMHO is much more horrifying than this snippit. I take that very
>personally and shows what a bunch of arrogant snobs have taken over the
>discussions here.
>
>

If I look at your regular expressions, i've the same feeling as I have
looking at Marcel Hendrix Manx package. "Oh God, he is a really good
programmer." Being a good programmer is, however, not what it is all about.

I couldn't, and wouldn't, try to maintain a package in that style.
I would restructure it first. And with manx I even failed to do that.
(I've rewritten it, and now I can expand it in any direction I want.)

If I look at my regexpression package I see:

1. an emphasis on documentation. Good programmers can keep lots of things
in their head. I can't. This is how *my* r.e. starts:

\---------------------------------------------------
\ Regular expressions in Forth.
\ This package handles only simple regular expressions and replacements.
\ See the words RE-MATCH and RE-REPLACE for usage.
\ The following aspects are handled:
\    1. Compiling ^ (begin only)  $  (end only) and special characters + ? * [ ] < >
\    2. Grouping using ( ) , only for replacement.
\    4. Ranges and inversion of char set (between [ ] ).
\    3. Above characters must be escaped if used as is by \ , making \ a special char.
\    4. Some sets are escaped by \ (\w) , some non-printables are denoted by an
\       escape sequence.
\ 5. It is an error to escape characters that do no denote blank
\       space, are not special, nor are denoting a set, However ^ - $
\       etc. may be escaped where they are not special.

\ Implementation notes:
\ * Usually regular expressions are compiled into a buffer consisting of
\   tokens followed by strings or characters in some format.
\   We follow the same here, except that tokens are execution tokens.
\ * No attempt is done at reentrant code.
\ * \d \s \w etc. can be handled by just adding sets

\ Data structures :
\   a char set is a bit set, with a bit up for the matching character.
\   a string is a regular string variable (so with a cell count).


\---------------------------------------------------

2. An emphasis on structure and data structures.
I'm a bit mathematical inclined. If the structures aren't right
I get nowhere.

3. Simple basic definitions.
You can find the occasional IF within a loop, or chained IF's.
If it gets more complicated then that, my debugging skills
fall short.

4. Comprehensive tests.
If it works, that's nothing. You must be able to change it.
If it still works, that's nothing. You must be able to be
sure that it still works.

By the way. Anton Ertl is a fine programmer. I've looked at his
solution for the Ants euler problem. And he has improved on my
"yet another prime counting program" with a keen eye for
efficiency.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#34023

Albert van der Horst wrote:

> If I look at your regular expressions, i've the same feeling as I have
> looking at Marcel Hendrix Manx package. "Oh God, he is a really good
> programmer." Being a good programmer is, however, not what it is all
> about.
Agreed. But I don't think we disagree much here. Keep reading, I think I
agree on virtually every point you address. I do, however, take my work and
skills quite serious.
 
> I couldn't, and wouldn't, try to maintain a package in that style.
> I would restructure it first. And with manx I even failed to do that.
> (I've rewritten it, and now I can expand it in any direction I want.)
First, every programmer I know has his own style. Having seen a lot of
programs - as you have, I presume - I can only say there are a lot of
styles. Having done maintenance on programs I did not write, I see good
style and bad style. Good style doesn't mean it's my style. I always try to
keep the style and conventions of the original programmer (if I can), I
can't rework every program to meet my style. But maintenance IS (agreed)
the main thing. Having done maintenance on my uBasic interpreter, my
preprocessor and other non-trivial (what I consider non-trivial) programs,
I don't feel I'm lacking too much in that department.

> 1. an emphasis on documentation. Good programmers can keep lots of things
> in their head. I can't. This is how *my* r.e. starts:
I'm not the kind of programmer who tries to cram his documentation into his
programs. I do, however, have one of the highest scores where comments are
concerned (pull the code and read from column 40 forward) and I have about
600 pages documenting my compiler on almost every subject possible. That's
over 2(!) gForth manuals. Anders gezegd, ik voel me nog steeds niet echt
aangesproken. 

> By the way. Anton Ertl is a fine programmer. I've looked at his
> solution for the Ants euler problem. And he has improved on my
> "yet another prime counting program" with a keen eye for
> efficiency.
Quoting from a person I respect: "Oh God, he is a really good
programmer." Being a good programmer is, however, not what it is all
about.

Hans Bezemer

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

#34020

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> 
> Related to an adjacent discussion: I think that this serves nicely as
> a demonstration that lack of locals does not automatically lead to
> well-factored code

I must have missed that claim.

> (especially if you use 'the magical "seven, plus or minus two"
> words' *maximum* as the definition of "well-factored").

Which no-one does, AFAIK.  I'm surprised you didn't know the reference
from Thinking Forth, but here's the Wikipedia entry:

   "The Magical Number Seven, Plus or Minus Two: Some Limits on Our
   Capacity for Processing Information" is one of the most highly
   cited papers in psychology. It was published in 1956 by the
   cognitive psychologist George A. Miller of Princeton University's
   Department of Psychology in Psychological Review. It is often
   interpreted to argue that the number of objects an average human
   can hold in working memory is 7 +- 2. This is frequently referred to
   as Miller's Law.

Andrew.

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

#34028 — The magical number seven (was: Tiny regular expressions code)

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> 
>> Related to an adjacent discussion: I think that this serves nicely as
>> a demonstration that lack of locals does not automatically lead to
>> well-factored code
>
>I must have missed that claim.

I am not surprised.

BTW, my comment was not a criticism of Hans Bezemer's code, but on the
claim outlined above.  I have not looked closely enough at the problem
or the code to make any well-founded critique of the code.  That's why
I put special emphasis on the following formalistic criterion for
"well-factored"):

>> (especially if you use 'the magical "seven, plus or minus two"
>> words' *maximum* as the definition of "well-factored").
>
>Which no-one does, AFAIK.

You did:

|>>But, IMO, any word which is much longer than than the magical "seven,
|>>plus or minus two" words may well be in need of some attention.
|> 
|> You would unfactor a three-word definition?
|
|No: the "seven, plus or minus two" is a *maximium*.

<GNKdnUPWhZo1RN3JnZ2dnUU7-eOdnZ2d@supernews.com> 

>I'm surprised you didn't know the reference
>from Thinking Forth

What makes you think I didn't know it?  I just don't find the
connection drawn to Miller's result at all convincing.  The only
interesting part in Thinking Forth about this is:

|An informal examination of one of Moore's applications shows that he
|averages seven references, including both words and numbers, per
|definition.

If he considered 7 a maximum, he apparently also considered it a
minimum (or he would not arrive at an average of 7).  A histogram
would be more interesting, and I am sure that he did not limit himself
to 7 or 9 references maximum.  I wonder whether :, <name> and ; are
included in the count of references.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

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

#34029 — Re: The magical number seven (was: Tiny regular expressions code)

On Monday, October 20, 2014 11:57:18 AM UTC+2, Anton Ertl wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> 
> >Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
[..]
>> An informal examination of one of Moore's applications shows that he
>> averages seven references, including both words and numbers, per
>> definition.

I'll have a look in 'Footsteps in an empty valley' and/or the Weasel 
manual (full kernel), tonight. This should be easy to (dis)prove.

-marcel

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

#34034 — Re: The magical number seven (was: Tiny regular expressions code)

m.a.m.hendrix@tue.nl writes Re: The magical number seven (was: Tiny regular expressions code)
[..]
>> >Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
[..]
>> An informal examination of one of Moore's applications shows that he
>> averages seven references, including both words and numbers, per
>> definition.

> I'll have a look in 'Footsteps in an empty valley' and/or the Weasel 
> manual (full kernel), tonight. This should be easy to (dis)prove.

'Footsteps in an empty valley'

-DIGIT \ 27 words
NUMBER \ 53 words
WORD   \ 48 words
QUIT   \ 14 words
BAUD   \ 17 words
SPACES \ 13 words 
M/MOD  \ 10 words
FILL   \ 15 words
SCAN   \ 12 words
THRU   \ 12 words
]      \ 46 words
@      \ 11 words ( optimized)

( here I stopped )

I can't find any trace of words that are obviously factored out of larger
definitions. All words perform a definite function.
Not all words have a stack picture. No words have empty stack pictures. Only
the data stack is commented, input stream and rack are not.

I counted ':', "name" and ';' as words.

The listing I used for counting was the  metacompiler for the NOVIX.
I didn't count the very long optimizer words (50 .. 72 words, 
unfactored :-), and also not artefacts of metacompiling like : @ @ ; .

-marcel

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

#34048 — Re: The magical number seven

mhx@iae.nl (Marcel Hendrix) writes:
> -DIGIT \ 27 words
> NUMBER \ 53 words
> WORD   \ 48 words
> QUIT   \ 14 words
> BAUD   \ 17 words
> SPACES \ 13 words 
> M/MOD  \ 10 words
> FILL   \ 15 words
> SCAN   \ 12 words
> THRU   \ 12 words
> ]      \ 46 words
> @      \ 11 words ( optimized)
> ( here I stopped )

There are many shorter words.  I get an average of 8.7.

Histogram:

 1 ******************
 2 *****************************
 3 *********************
 4 ********************
 5 ************
 6 ****************
 7 ***********
 8 **********
 9 *****
10 *******
11 ***
12 ***
13 **
14 *
15 *****
16 **
17 **
18 *
19 **
20 **
21 **
22 *
23 *
24 **
25 *
27 *
29 *
30 *
32 *
34 *
38 *
43 **
47 *
60 **
67 *

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

#34053 — Re: The magical number seven

Lars Brinkhoff wrote:
> There are many shorter words.  I get an average of 8.7.
> 
> Histogram:
> 
>  1 ******************
>  2 *****************************
>  3 *********************
>  4 ********************
>  5 ************
>  6 ****************
>  7 ***********
>  8 **********
>  9 *****
> 10 *******
> 11 ***
> 12 ***
> 13 **
> 14 *
> 15 *****
> 16 **
> 17 **
> 18 *
> 19 **
> 20 **
> 21 **
> 22 *
> 23 *
> 24 **
> 25 *
> 27 *
> 29 *
> 30 *
> 32 *
> 34 *
> 38 *
> 43 **
> 47 *
> 60 **
> 67 *

The histogram is much more useful here: It's a long tail statistics. 
Apparently, the pressure is towards very small words, and ~80% of the words 
are "well factored".  20% aren't, and it looks like they need half of the 
source code space.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#34057 — Re: The magical number seven (was: Tiny regular expressions code)

Marcel Hendrix said:
 
> 'Footsteps in an empty valley'

> -DIGIT \ 27 words
> NUMBER \ 53 words
> WORD   \ 48 words

(etc) 

> I can't find any trace of words that are obviously factored out of larger
> definitions. All words perform a definite function.
> Not all words have a stack picture. No words have empty stack pictures. Only
> the data stack is commented, input stream and rack are not.

By coincidence, I was looking at 'Footsteps..' recently. As well as the comment from someone else that if you include the shorter words, the average is seven-ish, I don't think anyone would claim cmFORTH to be anything other than a quick hack to see if the hardware works. 

Who can forget the splitting of control structures between words, for example? I think it was MAX and MIN that jumped into the middle of the other, but it could have been any similar comparison words.

Amongst the problems with the Novix was that it was released with cmFORTH as the leading software.

> and also not artefacts of metacompiling like : @ @ ; .

I would say that's not an artefact, that's because on the hardware, the definition of '@' is '@'! Without that and the other similar ones, you couldn't use any of the primitive words interactively.

  Ian

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

#34064 — Re: The magical number seven (was: Tiny regular expressions code)

Just Ian <superian@gmail.com> wrote Re: The magical number seven (was: Tiny regular expressions code)

> Marcel Hendrix said:

>> 'Footsteps in an empty valley'

>> -DIGIT \ 27 words
>> NUMBER \ 53 words
>> WORD   \ 48 words

[..]

> By coincidence, I was looking at 'Footsteps..' recently. As well as the comment
> from someone else that if you include the shorter words, the average is seven-ish, 
> I don't think anyone would claim cmFORTH to be anything other 
> than a quick hack to see if the hardware works.

I should be obvious from my post that I am convinced that [TOPIC] is not 
illustrated by 'Footsteps ... .'  I listed the reasons in the OP. For all 
other purposes Lars has provided the histogram and exact (hopefully) count (applause!)

Seven words is not a lot, and IMO it is obvious Charles Moore is not writing such 
short definitions out of principle. I'm pretty sure that e.g. -DIGIT, NUMBER 
and WORD have comparable word counts on small systems by other authors.

> Who can forget the splitting of control structures between words, for example? 
> I think it was MAX and MIN that jumped into the middle of the other, but it 
> could have been any similar comparison words.
[..]

Why the party trick when he just needed 'a quick hack to see if the hardware 
works?' 

>> and also not artefacts of metacompiling like : @ @ ; .

> I would say that's not an artefact, that's because on the hardware, the def
> inition of '@' is '@'! Without that and the other similar ones, you couldn't 
> use any of the primitive words interactively.

Maybe 'artefact' is a wrong choice of word.
I consider ": @ @ ;" atypical when the intention is to get a feeling
for how normal well-factored Forth code should look. Anybody would (need to)
write it like that.

-marcel

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

#34152 — Re: The magical number seven

Just Ian <superian@gmail.com> wrote:
> 
> Amongst the problems with the Novix was that it was released with
> cmFORTH as the leading software.

That's true.  Novix polyFORTH was fantastic to use and had very good
metacompiling capabilities, but was rather expensive.  cmFORTH was a
PITA.  Shame.

Andrew.

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

#34031 — Re: The magical number seven (was: Tiny regular expressions code)

Anton Ertl wrote:
> BTW, my comment was not a criticism of Hans Bezemer's code, but on the
> claim outlined above.  I have not looked closely enough at the problem
> or the code to make any well-founded critique of the code.  That's why
> I put special emphasis on the following formalistic criterion for
> "well-factored"):
After having vented my anger (an consequently get it out of my system) and
having read the entire thread I think I owe you a mild apology, because I
believe you sincerely didn't mean to put my code down as "a particular
example of bad programming" (I know you didn't exactly state that, but that
was how I read it). 

However, being an oldtimer down here and having ported and read lots of
programs with C-size definitions, I was taken off guard why this particular
not-too-interesting piece of code (I wrote it in an hour or so) had to be
singled out.

But my two cents to the discussion, I don't think that ANY programming
paradigm is able to enforce "writing good code". 
- I think that forcing Python users to indent properly may have given more
rise to hard to trace bugs than anything else;
- Some loop constructs are better handled by GOTO than forcing people into
structured programming;
- And the best of all, OO has given rise to "lasagna code" instead of
getting in the land of reliable code (with other claims of OO broken down
by reality as well);
- And what Java is concerned, well, we all know too well what's wrong with
Java, don't we.

So, when Forth poses no particular limits on the size of a definition
(especially now we miss the measure of a "screen") I don't know why anyone
should be surprised why long definitions come to be. If we do
our "factoring" thing, it will emerge the most WITH applications or BETWEEN
libraries. Needless to say that where libraries are concerned, these words
will be very low level - since the functionality of libraries can differ
greatly.

On top of that, if the API doesn't really enforce to expose a lot of
symbols, factoring will greatly depend on patterns. Lots of algorithms
however, involve lots of loops and ifs and have very few patterns that have
to be (or can reasonably can be) factored out. In other words, yes, you can
take out pieces, but what's the use when they're referred to only ONCE?

Hans Bezemer

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

#34033 — Re: The magical number seven (was: Tiny regular expressions code)

Hans Bezemer <the.beez.speaks@gmail.com> writes:
>On top of that, if the API doesn't really enforce to expose a lot of
>symbols, factoring will greatly depend on patterns. Lots of algorithms
>however, involve lots of loops and ifs and have very few patterns that have
>to be (or can reasonably can be) factored out. In other words, yes, you can
>take out pieces, but what's the use when they're referred to only ONCE?

As Andrew Haley writes, for understanding and for testing; also, for
changing.  However, to truly become helpful for that, the factors need
to implement identifiable concepts, and Andrew Haley and I differ in
what we consider "identifiable concepts".

As for "referred only ONCE": what may be referred only once now may be
referred more often if you factor well.  And it's hard to predict what
will be reused and what will not.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

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

#34038 — Re: The magical number seven (was: Tiny regular expressions code)

On Mon, 20 Oct 2014 11:28:00 -0400, Hans Bezemer  
<the.beez.speaks@gmail.com> wrote:

> But my two cents to the discussion, I don't think that ANY programming
> paradigm is able to enforce "writing good code".

People are able to master the ability to solve complicated math and
physic problems.  Are you saying people are unable to represent the
solution process for solving such problems as a verifiably correct
programming paradigm?

> - I think that forcing Python users to indent properly may have given  
> more rise to hard to trace bugs than anything else;

I know very little about Python.  So, I can accept that as true, for now.

Contrarily, I understand that indenting in languages, like C, which don't
require it improves readability immensely.  From my experience in other
languages, I believe improved readability reduces certain coding errors.

> - Some loop constructs are better handled by GOTO than forcing people  
> into structured programming;

I've used structured programming since I first learned how to program a
little over three decades ago.  GOTO is completely unecessary.  So, under
what circumstances do you believe your claim to be true?

> - And the best of all, OO has given rise to "lasagna code" instead of
> getting in the land of reliable code

I agree.

> (with other claims of OO broken down by reality as well);

Interesting.

> - And what Java is concerned, well, we all know too well what's wrong  
> with Java, don't we.

Other than Java not having pointers, I don't know what you're talking
about.  Of course, I'm familiar with C but not Java.  Could you explain?


Rod Pemberton

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

#34040 — Re: The magical number seven

On 10/20/14 10:36 AM, Rod Pemberton wrote:
> On Mon, 20 Oct 2014 11:28:00 -0400, Hans Bezemer
> <the.beez.speaks@gmail.com> wrote:
>
>> But my two cents to the discussion, I don't think that ANY programming
>> paradigm is able to enforce "writing good code".
>
> People are able to master the ability to solve complicated math and
> physic problems.  Are you saying people are unable to represent the
> solution process for solving such problems as a verifiably correct
> programming paradigm?

That isn't what he said. Of course people can write good programs. What 
he said is that a programming paradigm cannot *force* them to. People 
can (and do) write bad programs in any language.

>> - I think that forcing Python users to indent properly may have given
>> more rise to hard to trace bugs than anything else;
>
> I know very little about Python.  So, I can accept that as true, for now.
>
> Contrarily, I understand that indenting in languages, like C, which don't
> require it improves readability immensely.  From my experience in other
> languages, I believe improved readability reduces certain coding errors.

Of course. Indenting that conveys meaning always improves readability. 
Again, the key word here is "forcing".

>> - Some loop constructs are better handled by GOTO than forcing people
>> into structured programming;
>
> I've used structured programming since I first learned how to program a
> little over three decades ago.  GOTO is completely unecessary.  So, under
> what circumstances do you believe your claim to be true?

Arbitrary GOTOs are unnecessary, I agree. I think what he means is that 
sometimes it is necessary to be able to branch out of a loop.

>> - And the best of all, OO has given rise to "lasagna code" instead of
>> getting in the land of reliable code
>
> I agree.

There are applications that naturally lend themselves to OO programming, 
and others that don't. The notion that OO is a panacea for all 
programming problems is a fallacy.

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]

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

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

csiph-web