Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #33871 > unrolled thread
| Started by | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| First post | 2014-10-13 18:15 +0200 |
| Last post | 2014-11-08 20:42 -0800 |
| Articles | 20 on this page of 60 — 16 participants |
Back to article view | Back to comp.lang.forth
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 3 of 3 — ← Prev page 1 2 [3]
| From | "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> |
|---|---|
| Date | 2014-10-21 01:47 -0400 |
| Subject | Re: The magical number seven |
| Message-ID | <op.xn2fouj4mk81un@localhost> |
| In reply to | #34040 |
On Mon, 20 Oct 2014 18:19:05 -0400, Elizabeth D. Rather <erather@forth.com> wrote: > 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. > A programming paradigm can force type checking which prevents certain types of bad programming, i.e., you're "forced" to not do that. So, what prevents a paradigm from being implemented which would prohibit all bad implementations? I think the only real issue is that many, many possible combinations of programming elements would need to be tested or proved to ensure that no "bad" programs could result, intentional or otherwise. That may be a daunting task or even not doable with humanity's current intellectual and computational resources. But, if we could reach that point, then we can be reasonably assured that programmers are "forced" to only write good programs. The paradigm simply won't allow for bad ones. Of course, all of this would go against the nature of those who prefer Forth to other languages. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-10-20 20:31 -1000 |
| Subject | Re: The magical number seven |
| Message-ID | <NaSdnSZVRbNQYNjJnZ2dnUU7-TWdnZ2d@supernews.com> |
| In reply to | #34046 |
On 10/20/14 7:47 PM, Rod Pemberton wrote: > On Mon, 20 Oct 2014 18:19:05 -0400, Elizabeth D. Rather > <erather@forth.com> wrote: >> 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. >> > > A programming paradigm can force type checking which prevents certain > types of bad programming, i.e., you're "forced" to not do that. So, what > prevents a paradigm from being implemented which would prohibit all bad > implementations? I think the only real issue is that many, many possible > combinations of programming elements would need to be tested or proved > to ensure that no "bad" programs could result, intentional or otherwise. > That may be a daunting task or even not doable with humanity's current > intellectual and computational resources. But, if we could reach that > point, then we can be reasonably assured that programmers are "forced" > to only write good programs. The paradigm simply won't allow for bad > ones. Of course, all of this would go against the nature of those who > prefer Forth to other languages. The fundamental flaw with most of the "bad" programs I've encountered is bad design. This may be either failure to think through and document all the relevant design issues, or think through appropriate implementation methodologies, or just plain "slash and burn" programming techniques. The important thing is for the programmer(s) to (a) understand the problem, (b) have a coherent approach to addressing it, and (c) have a dedication to producing the cleanest and most transparent possible solution to the requirements. I don't know of any compiler that can "enforce" this. 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]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-10-21 09:06 +0000 |
| Subject | Re: The magical number seven |
| Message-ID | <54462208$0$15892$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #34047 |
In article <NaSdnSZVRbNQYNjJnZ2dnUU7-TWdnZ2d@supernews.com>, Elizabeth D. Rather <erather@forth.com> wrote: <SNIP> > >The fundamental flaw with most of the "bad" programs I've encountered is >bad design. This may be either failure to think through and document all >the relevant design issues, or think through appropriate implementation >methodologies, or just plain "slash and burn" programming techniques. You are the second person I know off who uses the term "slash and burn" w.r.t. programming. The other person was me, as in "slash and burn maintenance". This means that in maintaining a program with a feature that doesn't work, you remove the feature, and all its auxiliary words. If any of those auxiliary words support a feature that isn't used, remove them anyway, and that feature as well. Then do some refactoring and/or redesigning and maybe reinstall the original feature. In adding a feature that doesn't fit the design, redesign and remove before adding. More often than not, after a redesign I discovered that adding the feature was a mere couple of lines. Where did you get the term? For me slash and burn suggest that you're not afraid of removing largish parts of a program. Too many programmers consider the old program code as sacred, and dare not tough it, unless it is soooo obviously wrong. > >The important thing is for the programmer(s) to (a) understand the >problem, (b) have a coherent approach to addressing it, and (c) have a >dedication to producing the cleanest and most transparent possible >solution to the requirements. I don't know of any compiler that can >"enforce" this. Right. > >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." >================================================== -- 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]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-10-21 08:47 -1000 |
| Subject | Re: The magical number seven |
| Message-ID | <ytSdnS8Hm4vYN9vJnZ2dnUU7-fGdnZ2d@supernews.com> |
| In reply to | #34051 |
On 10/20/14 11:06 PM, Albert van der Horst wrote: > In article <NaSdnSZVRbNQYNjJnZ2dnUU7-TWdnZ2d@supernews.com>, > Elizabeth D. Rather <erather@forth.com> wrote: > <SNIP> >> >> The fundamental flaw with most of the "bad" programs I've encountered is >> bad design. This may be either failure to think through and document all >> the relevant design issues, or think through appropriate implementation >> methodologies, or just plain "slash and burn" programming techniques. > > You are the second person I know off who uses the term "slash and > burn" w.r.t. programming. > The other person was me, as in "slash and burn maintenance". > This means that in maintaining a program with a feature that doesn't > work, you remove the feature, and all its auxiliary words. If any of > those auxiliary words support a feature that isn't used, remove them > anyway, and that feature as well. Then do some refactoring and/or > redesigning and maybe reinstall the original feature. > In adding a feature that doesn't fit the design, redesign and remove > before adding. More often than not, after a redesign I discovered that > adding the feature was a mere couple of lines. > > Where did you get the term? For me slash and burn suggest that you're > not afraid of removing largish parts of a program. > Too many programmers consider the old program code as sacred, > and dare not tough it, unless it is soooo obviously wrong. To me, "slash and burn" just means throwing code at a problem without careful thought and design. In maintenance, the scenario you describe is kind of the opposite, if you mean that the new version is a carefully-conceived re-design replacing an ill-conceived hack. >> The important thing is for the programmer(s) to (a) understand the >> problem, (b) have a coherent approach to addressing it, and (c) have a >> dedication to producing the cleanest and most transparent possible >> solution to the requirements. I don't know of any compiler that can >> "enforce" this. > > Right. 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]
| From | "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> |
|---|---|
| Date | 2014-10-22 02:21 -0400 |
| Subject | Re: The magical number seven |
| Message-ID | <op.xn4bxdjkmk81un@localhost> |
| In reply to | #34065 |
On Tue, 21 Oct 2014 14:47:33 -0400, Elizabeth D. Rather <erather@forth.com> wrote: > To me, "slash and burn" just means throwing code at a problem without > careful thought and design. Some problems may be too difficult to comprehend or easily quantify. In that case, "shotgunning" can be very effective in narrowing the scope of the problem to something manageable, solveable, or identifiable. It's especially useful in debugging. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2014-10-21 10:29 +0200 |
| Subject | Re: The magical number seven (was: Tiny regular expressions code) |
| Message-ID | <544618fd$0$2923$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #34038 |
Rod Pemberton wrote: Where Elizabeth took the trouble of addressing most issues (thank you for that, I couldn't have explained it as well as you did!) There are a few points left for me. > 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? I agree, it doesn't happen all the time, but at crucial moments I'm glad GOTO is there. In Forth the VERY occasional "R> DROP" will do the same thing and due to the nice CATCH some GOTO's are eliminated as well. I for one, have to agree structured programming is a real boon, given the ordeal I had to go through porting TEONW. http://thebeezspeaks.blogspot.nl/2011/02/how-to-reheat-30-year-old-spaghetti.html >> (with other claims of OO broken down by reality as well); > Interesting. I have papers in my posession saying that OO neither gives rise to much reuse nor are a real productivity boost, neither when developing nor when maintaining. >> - 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? Sure. First OO isn't optional. Second, I love table-oriented-programming (I think my 4tH is best equipped for that) and Java makes that impossible by the sheer horror of using function pointers. I even avoid USING Java programs as much as I can, because even from a user standpoint they're a pain in the neck. Different Java versions, frequent crashing, pages of errors that make it impossible to find out what went wrong and if you can possibly fix it. BTW, there are many pages of Java complaints all over the web - more than Forth related ;-) Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-10-21 11:34 +0200 |
| Subject | Re: The magical number seven (was: Tiny regular expressions code) |
| Message-ID | <m259al$hgi$1@online.de> |
| In reply to | #34050 |
Hans Bezemer wrote: >> 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? > Sure. First OO isn't optional. Second, I love table-oriented-programming > (I think my 4tH is best equipped for that) and Java makes that impossible > by the sheer horror of using function pointers. The classes are actually tables of function pointers, so as long as you use names to index into these tables, use a class in Java to implement that. Of course, when you use numbers to index, it's awful, because you can't do that. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-10-26 04:41 -0500 |
| Subject | Re: The magical number seven |
| Message-ID | <E_2dnel_Evp_XNHJnZ2dnUU7-SmdnZ2d@supernews.com> |
| In reply to | #34050 |
Hans Bezemer <the.beez.speaks@gmail.com> wrote: > Sure. First OO isn't optional. Second, I love table-oriented- > programming (I think my 4tH is best equipped for that) and Java > makes that impossible by the sheer horror of using function > pointers. What's the problem with function pointers? You can certainly create arrays of references to functional objects, and they can do the same thing. > I even avoid USING Java programs as much as I can, because even from a user > standpoint they're a pain in the neck. Different Java versions, frequent > crashing, pages of errors that make it impossible to find out what went > wrong and if you can possibly fix it. BTW, there are many pages of Java > complaints all over the web - more than Forth related ;-) That's rather inevitable. Java is the second most-used (or perhaps most-used, depending on whose survey you believe) programming language. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2014-10-26 12:07 +0100 |
| Subject | Re: The magical number seven |
| Message-ID | <544cd583$0$2951$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #34154 |
Andrew Haley wrote: > What's the problem with function pointers? You can certainly create > arrays of references to functional objects, and they can do the same > thing. Working around anything to get what you want is always a bad design paradigm. > That's rather inevitable. Java is the second most-used (or perhaps > most-used, depending on whose survey you believe) programming > language. I boiled it down to three so I'm doing fine in that department. Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-10-26 13:58 -0500 |
| Subject | Re: The magical number seven |
| Message-ID | <jLqdneO_q9_02dDJnZ2dnUU7-bednZ2d@supernews.com> |
| In reply to | #34156 |
Hans Bezemer <the.beez.speaks@gmail.com> wrote: > Andrew Haley wrote: > >> What's the problem with function pointers? You can certainly create >> arrays of references to functional objects, and they can do the same >> thing. > > Working around anything to get what you want is always a bad design > paradigm. Huh? What is being "worked around"? Functional objects are Java's equivalent. If you really want an array of functions, that's how you do it. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-10-20 16:34 -0700 |
| Subject | Re: The magical number seven (was: Tiny regular expressions code) |
| Message-ID | <8a73e669-2a2c-4528-980e-ab85bb92605b@googlegroups.com> |
| In reply to | #34031 |
On Monday, October 20, 2014 8:25:50 AM UTC-7, The Beez wrote: > 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). Getting back to the subject of regular expressions, have you tried your regexp on the "Alien Alphabet" problem in that thread that I mentioned? For the most part, I don't like regular expressions, and would prefer to use a technique like I used in that problem. OTOH, a lot of people like regular expressions, and they are a big part of all the major scripting languages --- if you are doing a lot of text pattern-matching, they may make simplify the work and be worthwhile. I used AWK a long time ago, and it worked pretty well.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-10-26 04:33 -0500 |
| Subject | Re: The magical number seven |
| Message-ID | <8tydneBGaJWbXdHJnZ2dnUU7-SWdnZ2d@supernews.com> |
| In reply to | #34031 |
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". > - 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); Indeed; like Forth, good OO requires good taste. > - And what Java is concerned, well, we all know too well what's wrong with > Java, don't we. Do we? Why Java, in particular? It's just a (very successful) OO language, and it is extremely conservatively designed, or at least it was. Granted, it has over the years accreted a lot of features beyond its original design -- but so has the langauge we know and love. :-) > 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? Why not? Forth is designed to reduce the cost of factoring almost to zero. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2014-10-26 12:12 +0100 |
| Subject | Re: The magical number seven |
| Message-ID | <544cd697$0$2951$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #34153 |
Andrew Haley wrote: > Indeed; like Forth, good OO requires good taste. Oh no. The major error here is that OO is a design technique - not a programming paradigm. You use it only when it's appropriate. Applying it to every problem is asking for trouble. And indeed it does. But at always, programmers are superstitious people, believing in holy men and holy books. And where believe comes in, facts disappear. Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-10-26 04:24 -0500 |
| Subject | Re: The magical number seven |
| Message-ID | <8tydneZGaJV7INHJnZ2dnUU7-SWdnZ2d@supernews.com> |
| In reply to | #34028 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> >>> (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. And where, pray, do I use that as a definition of "well-factored"? > 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 accept that point. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl (Marcel Hendrix) |
|---|---|
| Date | 2014-10-19 17:10 +0200 |
| Message-ID | <17931816938433@frunobulax.edu> |
| In reply to | #34011 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes Re: Tiny regular expressions code
>> Hans Bezemer <the.beez.speaks@gmail.com> writes:
> 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").
Removing the locals *and* removing the stack noise does not seem to
lead to a much easier algorithm (although the max. number of
lines / word is now 8). There is quite obvious similarity between
the words in the local-less variant, but I don't see how to exploit it.
A state machine and goto's may be a better idea in this case.
-marcel
-- -------------------------
ANEW -regexpr
0 [IF]
DEFER (matchhere) ( $1 $2 -- bool )
: (match*) LOCALS| c n2 a2 n1 a1 | ( $1 $2 char -- bool )
BEGIN
a1 n1 a2 n2 (matchhere) IF TRUE EXIT ENDIF
n1 0= IF FALSE EXIT ENDIF
a1 c@ '.' = a1 c@ c = OR 0= IF FALSE EXIT ENDIF
a1 n1 1 /string TO n1 TO a1
AGAIN ;
: (match?) LOCALS| c n2 a2 n1 a1 | ( $1 $2 char -- bool )
a1 n1 a2 n2 (matchhere) IF TRUE EXIT ENDIF
n1 0= IF FALSE EXIT ENDIF
a1 c@ '.' = a1 c@ c = OR 0= IF FALSE EXIT ENDIF
a1 n1 1 /string a2 n2 (matchhere) ;
:NONAME 0 LOCALS| c n2 a2 n1 a1 | ( $1 $2 -- bool )
n2 0= IF TRUE EXIT ENDIF
a2 c@ TO c a2 char+ c@ '*' = \ if not, does it equal a '*'
IF a2 n2 2 /string TO n2 TO a2
a1 n1 a2 n2 c (match*) EXIT
ENDIF \ otherwise, does it equal a '?'
a2 char+ c@ '?' =
IF a2 n2 2 /string TO n2 TO a2
a1 n1 a2 n2 c (match?) EXIT
ENDIF \ otherwise, does it equal a '$'
c '$' = n2 1 = AND IF n1 0= EXIT ENDIF \ and is it the last character?
n1 0= IF FALSE EXIT ENDIF
c '.' = c a1 c@ = OR 0= IF FALSE EXIT ENDIF
a1 n1 1 /string a2 n2 1 /string (matchhere) ; IS (matchhere)
: match LOCALS| n2 a2 n1 a1 | ( $1 $2 -- bool )
n2 IF a2 c@ '^' = IF a1 n1 a2 n2 1 /string (matchhere) ENDIF
ELSE BEGIN
a1 n1 a2 n2 (matchhere) IF TRUE EXIT ENDIF
n1 0= IF FALSE EXIT ENDIF
a1 n1 1 /string TO n1 TO a1
AGAIN
ENDIF ;
[ELSE]
CREATE $1$2 #256 5 * CELLS ALLOT $1$2 VALUE ptr
: +level ( char a1 n1 a2 n2 -- ) 5 CELLS +TO ptr ptr 2 CELL[] d! ptr d! ptr 4 CELL[] ! ;
: -level ( -- ) -5 CELLS +TO ptr ;
: reset ( $1 $2 -- ) $1$2 TO ptr -level 2>r 2>r 0 2r> 2r> +level ;
: a1 ( -- addr ) ptr @ ; : n1 ( -- n ) ptr CELL+ @ ; : $1 ( -- a1 n1 ) ptr d@ ;
: a2 ( -- addr ) ptr 2 CELL[] @ ; : n2 ( -- n ) ptr 3 CELL[] @ ; : $2 ( -- a2 n2 ) ptr 2 CELL[] d@ ;
: c ( -- char ) ptr 4 CELL[] @ ;
: shorten$1 ( u -- ) $1 ROT /string ptr d! ;
: shorten$2 ( u -- ) $2 ROT /string ptr 2 CELL[] d! ;
DEFER (matchhere) ( -- bool )
: (match*) ( char -- bool )
$1 $2 +level
BEGIN
(matchhere) IF -level TRUE EXIT ENDIF
n1 0= IF -level FALSE EXIT ENDIF
a1 c@ '.' = a1 c@ c = OR 0= IF -level FALSE EXIT ENDIF
1 shorten$1
AGAIN ;
: (match?) ( char -- bool )
$1 $2 +level
(matchhere) IF -level TRUE EXIT ENDIF
n1 0= IF -level FALSE EXIT ENDIF
a1 c@ '.' = a1 c@ c = OR 0= IF -level FALSE EXIT ENDIF
1 shorten$1 (matchhere) -level ;
:NONAME ( -- bool )
a2 c@ $1 $2 +level
n2 0= IF -level TRUE EXIT ENDIF
a2 char+ c@ '*' = IF 2 shorten$2 c (match*) -level EXIT ENDIF
a2 char+ c@ '?' = IF 2 shorten$2 c (match?) -level EXIT ENDIF
c '$' = n2 1 = AND IF -level n1 0= EXIT ENDIF
n1 0= IF -level FALSE EXIT ENDIF
c '.' = c a1 c@ = OR 0= IF -level FALSE EXIT ENDIF
1 shorten$1 1 shorten$2 (matchhere) -level ; IS (matchhere)
: match ( $1 $2 -- bool )
reset
n2 IF a2 c@ '^' = IF 1 shorten$2 (matchhere) ENDIF
ELSE BEGIN
(matchhere) IF -level TRUE EXIT ENDIF
n1 0= IF -level FALSE EXIT ENDIF
1 shorten$1
AGAIN
ENDIF ;
[THEN]
cr s" 0,9" s" ^0,?9$" match . .( -1)
cr s" 0:9" s" ^0,?9$" match . .( 0)
cr s" 09" s" ^0,?9$" match . .( -1)
cr s" 009" s" ^0,?9$" match . .( 0)
cr s" 0,,9" s" ^0,?9$" match . .( 0)
cr s" 0,,9" s" ^0,*9$" match . .( -1)
cr s" 0,,9" s" ^0*9$" match . .( 0)
cr
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2014-10-18 16:02 +0200 |
| Message-ID | <5442728e$0$2890$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #33980 |
Hans Bezemer wrote:
This code is exactly the same as the previous posting. I just wondered if my
skills had grown enough in eight years that I could come up with something
a bit less murky. I remember the discussion in c.l.f at the time and nobody
was able to produce something *WITHOUT LOCALS* that tickled me enough to
adopt it.
So I tried to produce something more transparent. It's a bit paranoid about
the length of the wildcard string (and subsequent fetches) but being
paranoid doesn't mean they're not out to get you ;-)
Surprisingly, (on 4tH) it's not compiling to less instructions than the
previous version.
---8<---
: chop 1- swap char+ swap ; ( a n -- a+1 n-1)
: (w@) dup 0> if over c@ else dup then ;
: 4drop 2drop 2drop ; ( n1 n2 n3 n4 --)
\ current char matches or equals '?'
: (match-or-?) ( a1 n1 wa1 wa1 -- a2 n2 wa2 wn2 f)
2>r over c@ 2r> rot >r (w@) dup [char] ? = swap r> = or
dup >r if 2>r chop 2r> chop then r> \ increment pointers on match
;
\ wildcard routine
: match-wild ( a n wa wa -- f)
begin
>r over r> swap \ we still have a string?
while
(w@) [char] * <> \ wildcard character unequal to '*'?
while \ if so, try to match character
(match-or-?) 0= if 4drop false exit then
repeat \ if not, exit and return false
[UNDEFINED] 4TH# [IF] then [THEN] 2dup 2dup 2>r 2>r
\ set up temporary pointers
begin
>r over r> swap \ we still have a string?
while
(w@) [char] * = \ wildcard character equals '*'?
if \ if so, drop temporary values
2r> 2r> 4drop chop dup 0> \ chop wildcard string, exit if done
if 2dup 2>r 2over chop 2>r else 4drop true exit then
else \ if not, save new temporary values
(match-or-?) 0= \ try to match character
if 4drop 2r> 2r@ 2over chop 2>r then
then \ if no match, restore values
repeat 2nip 2r> 2r> 4drop \ drop string and temporary values
\ get rid of superfluous '*'
begin dup 0> while over c@ [char] * = while chop repeat
[UNDEFINED] 4TH# [IF] then [THEN] nip 0> 0=
; \ wildcard string should be empty now
---8<---
s" 123abcd_efg" s" *abc*ef*" match-wild . -1 ok
Hans Bezemer
s" abracadabra" s" ?b*r?" match-wild . cr -1
ok
s" pArka" s" *a" match-wild . cr -1
ok
s" parka" s" *a" match-wild . cr -1
ok
s" park" s" *a*" match-wild . cr -1
ok
s" a" s" a" match-wild . cr -1
ok
s" aardvark" s" a*" match-wild . cr -1
ok
0 dup s" *" match-wild . cr cr -1
ok
ok
s" argh" s" a" match-wild . cr 0
ok
s" ba" s" a" match-wild . cr 0
ok
s" badger" s" a*" match-wild . cr 0
ok
s" park" s" *a" match-wild . cr 0
ok
s" perk" s" *a*" match-wild . cr 0
ok
s" abracadabr" s" ?b*r?" match-wild . cr 0
ok
s" abracadabzr" s" ?b*r?" match-wild . cr depth . 0
0 ok
[toc] | [prev] | [next] | [standalone]
| From | josv@planet.nl |
|---|---|
| Date | 2014-10-18 07:50 -0700 |
| Message-ID | <ca2f10c0-4d77-4763-99ac-3e82d5c8203b@googlegroups.com> |
| In reply to | #34007 |
On 18 oktober 2014 16:00:48 UTC+2 The Beez wrote: > Hans Bezemer wrote: >> May be this is more appropriate for you: > This code is exactly the same as the previous posting. [...] Thank's Hans, match-wild is exactly what I was looking for and works fine. I did not like Dr.dobb's tool at all. For chop I defined: : chop 1 /string ; ( a n -- a+1 n-1) Jos
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2014-10-18 17:27 +0200 |
| Message-ID | <5442865c$0$2865$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #33871 |
If people are interested, here is the 4tH code (containing plenty of
4tH-isms) which is enhanced by:
- escaping characters
- predefined sets (prefixed by %, see code)
- + and ?
So it is capable of doing this:
---8<---
s" 0,9" s" ^0,?9$" match-reg . cr
s" 0:9" s" ^0,?9$" match-reg . cr
s" 09" s" ^0,?9$" match-reg . cr
s" 009" s" ^0,?9$" match-reg . cr
s" 0,,9" s" ^0,?9$" match-reg . cr cr
s" abcdefg" s" abcdefg$" match-reg . cr
s" ababababab" s" ab*a$" match-reg . cr
s" aaaaaaaaba" s" a*ba$" match-reg . cr
s" aaaaaabac" s" ab*a$" match-reg . cr
s" abbd" s" ab*d$" match-reg . cr
s" abbde" s" ab*d$" match-reg . cr cr
s" -1234.56" s" -?%9+\.?%9*$" match-reg . cr
s" -1234" s" -?%9+\.?%9*$" match-reg . cr
s" 1234.56" s" -?%9+\.?%9*$" match-reg . cr
s" 1234" s" -?%9+\.?%9*$" match-reg . cr
s" 1234.ab" s" -?%9+\.?%9*$" match-reg . cr
s" 1234,23" s" ^-?%9+\.?%9*$" match-reg . cr
s" PRExyz23" s" ^PRE.*23$" match-reg . cr
s" -.23" s" ^-?%9+\.?%9*$" match-reg . cr depth .
---8<---
Maybe someone is interested to make an ANS version out of this. I'm good ;-)
Hans Bezemer
P.S. :TOKEN xxx yyy ; equals :NONAME yyy ; constant xxx
---8<---
: break? ?do over i c@ = if 0= leave then loop nip ;
---8<---
: IS-ASCII ( char -- flag ) 128 < ;
: IS-PRINT ( char -- flag ) DUP IS-ASCII SWAP BL 1- - 0> AND ;
: IS-WHITE ( char -- flag ) [CHAR] ! - 0< ;
: IS-DIGIT ( char -- flag ) [CHAR] 0 - MAX-N AND 10 < ;
: IS-LOWER ( char -- flag ) [CHAR] a - MAX-N AND 26 < ;
: IS-UPPER ( char -- flag ) [CHAR] A - MAX-N AND 26 < ;
: IS-ALPHA ( char -- flag ) BL OR IS-LOWER ;
: IS-ALNUM ( char -- flag ) DUP IS-ALPHA SWAP IS-DIGIT OR ;
: IS-XML ( char -- flag ) 0 S| <>&"'| BOUNDS DO OVER I C@ = OR LOOP
NIP ;
: IS-HTML ( char -- flag ) DUP IS-XML SWAP IS-PRINT 0= OR ;
---8<---
-1 constant NULL ( NULL pointer)
defer key=
:token string-key >r 2dup r@ @c count compare 0= r> swap ;
:token num-key over over @c = ;
: row ( x a1 n1 xt -- x a2 f)
is key= >r ( x a)
begin ( x a)
dup @c NULL <> dup ( x a f f)
while ( x a f)
drop key= dup 0= ( x a f -f)
while ( x a f)
drop r@ cells + ( x a)
repeat ( x a)
[UNDEFINED] 4TH# [IF] then [THEN]
r> drop ( x a f)
;
---8<---
\ Regular Expressions by Brian W. Kernighan and Rob Pike
\ Believed to be in the public domain
\ 4th version by J.L. Bezemer, 2014
[UNDEFINED] match-req [IF]
[UNDEFINED] 2over [IF] include lib/anscore.4th [THEN]
[UNDEFINED] row [IF] include lib/row.4th [THEN]
[UNDEFINED] is-ascii [IF] include lib/istype.4th [THEN]
[UNDEFINED] break? [IF] include lib/breakq.4th [THEN]
defer (matchhere)
128 +constant +cmd
char ^ +cmd constant (^) \ all special commands
char ? +cmd constant (?)
char * +cmd constant (*)
char + +cmd constant (+)
char $ +cmd constant ($)
char . +cmd constant (.)
char 9 +cmd constant (9)
char a +cmd constant (@)
char A +cmd constant (a)
char # +cmd constant (#)
char & +cmd constant (&)
char _ +cmd constant (_)
create (eq?) \ is it equal?
(.) , ' is-ascii , \ equivalent to .
(9) , ' is-digit , \ equivalent to [0-9]
(@) , ' is-lower , \ equivalent to [a-z]
(a) , ' is-upper , \ equivalent to [A-Z]
(#) , ' is-alpha , \ equivalent to [a-zA-Z]
(&) , ' is-alnum , \ equivalent to [a-zA-Z0-9]
(_) , ' is-white , \ whitespace
NULL , \ if a set execute, otherwise compare
does> 2 num-key row if nip cell+ @c execute else drop = then ;
\ some helper words
: (crunch) 1- over over over char+ -rot cmove ;
: (cmd!) over dup c@ +cmd swap c! ; ( a n -- a n)
: (contains?) 2>r c@ false 2r> bounds break? ;
\ prepare regular expression
: (prepare) ( a1 n1 -- a1 n2)
over swap \ save string address
begin
dup \ any characters left?
while \ if so, does it contain
over s" ^$?*+." (contains?) \ a metacharacter?
if (cmd!) \ if so, set command bit
else dup 1 > \ string length at least two?
if over c@ [char] \ = \ if it contains an escape
if (crunch) \ ignore the next character
else \ otherwise, if it is marked as
over c@ [char] % = \ a set, set the command bit
if over char+ s" 9aA#&_" (contains?) if (crunch) (cmd!) then then
then
then
then chop \ next character
repeat drop over - \ calculate new length
;
\ match zero or more times
: (match*) ( a n ra rn c --f)
begin
>r 2over 2over (matchhere) if r> drop 2drop 2drop true exit then
2over if c@ r@ (eq?) else dup xor then r> swap
while \ character equals text?
>r 2>r chop 2r> r> \ if so, match again
repeat drop 2drop 2drop false \ clean up, return false
;
\ match zero or one time
: (match?) ( a n ra rn c --f)
>r 2over 2over (matchhere) if r> drop 2drop 2drop true exit then
2over if c@ r> (eq?) else r> drop dup xor then
if 2>r chop 2r> (matchhere) else 2drop 2drop false then
;
\ match one or more times
: (match+) ( a n ra rn c --f)
>r 2over if c@ r@ (eq?) if 2>r chop 2r> r> (match*) exit then else drop
then
2drop 2drop r> dup xor \ check one character then
; \ perform (match*)
create (special?) \ all special characters
(*) , ' (match*) ,
(?) , ' (match?) ,
(+) , ' (match+) ,
NULL ,
does> 2 num-key row \ if special character
if \ execute it
cell+ @c >r drop over c@ >r chop chop r> r> execute true
else \ otherwise drop values
drop drop false \ and return false
then
;
:noname ( a n ra rn -- f)
dup if \ regular expression a null string?
over char+ c@ (special?) if exit then
over c@ ($) = over 1 = and \ otherwise does it equal a '$'
if \ and is it the last character?
2drop nip 0= exit \ is so, check length of text
else \ finally, check if any text left
2over \ and if character matches
if c@ >r over c@ r> swap (eq?) if chop 2>r chop 2r> recurse exit then
else drop then false \ if so recurse, otherwise quit
then \ and return false
else
true \ zero length regular expression
then >r 2drop 2drop r> \ clean up and exit
; is (matchhere) \ assign to DEFER (we got 'em)
: match-reg ( a n ra rn --f)
(prepare) dup if over c@ (^) = if chop (matchhere) exit then then
begin \ if caret, chop it
2over 2over (matchhere) if 2drop 2drop true exit then
>r over r> swap \ match characters
while \ until no more text
2>r chop 2r> \ chop text
repeat 2drop 2drop false \ clean up
;
[DEFINED] 4TH# [IF]
hide (matchhere)
hide +cmd
hide (^)
hide (?)
hide (*)
hide (+)
hide ($)
hide (.)
hide (9)
hide (@)
hide (a)
hide (#)
hide (&)
hide (_)
hide (eq?)
hide (match*)
hide (match?)
hide (match+)
hide (prepare)
hide (special?)
hide (crunch)
hide (cmd!)
hide (contains?)
[THEN]
[THEN]
---8<---
[toc] | [prev] | [next] | [standalone]
| From | the_gavino_himself <visphatesjava@gmail.com> |
|---|---|
| Date | 2014-11-08 19:24 -0800 |
| Message-ID | <53853a20-3610-4f61-b8bf-3318cd96df21@googlegroups.com> |
| In reply to | #33871 |
On Monday, October 13, 2014 9:13:06 AM UTC-7, The Beez wrote: > Short intermission from all the clashes here, sorry for the inconvenience, > but I used Forth for some CODING. You may fry me for the code quality > later, but this is a tiny regular expression parser, based on an article by > Kernighan and Pike > (http://www.drdobbs.com/architecture-and-design/regular-expressions/184410904). > > It features ^, $, * and . but I added ? as well (zero or one). This is some > stuff that was left lying around as an intermediate stage for a similar 4tH > library (which is cleaner and more capable), but I thought, may be it is of > use/interest to someone, why throw it away. > > Knock yourselves out ;-) > > Hans Bezemer > > ---8<--- > \ Regular Expressions by Brian W. Kernighan and Rob Pike > \ Believed to be in the public domain > > defer (matchhere) > > : (match*) ( a n ra rn c --f) > begin > >r 2over 2over (matchhere) if r> drop 2drop 2drop true exit then > 2over if c@ dup [char] . = swap r@ = or else dup xor then r> swap > while \ character equals text? > >r 2>r 1 /string 2r> r> \ if so, match again > repeat > drop 2drop 2drop false \ clean up, return false > ; > > : (match?) ( a n ra rn c --f) > >r 2over 2over (matchhere) if r> drop 2drop 2drop true exit then > 2over if c@ dup [char] . = swap r> = or else r> dup xor then > if 2>r 1 /string 2r> (matchhere) else 2drop 2drop false then > ; \ character equals text? > > :noname ( a n ra rn -- f) > dup if \ regular expression a null string? > over char+ c@ dup [char] * = \ if not, does it equal a '*' > if \ if so, call (match*) > drop over c@ >r 2 /string r> (match*) exit > else \ otherwise, does it equal a '?' > [char] ? = > if \ if so, call (match?) > over c@ >r 2 /string r> (match?) exit > else \ otherwise does it equal a '$' > over c@ [char] $ = over 1 = and > if \ and is it the last character? > 2drop nip 0= exit \ is so, check length of text > else \ finally, check if it char matches > 2over 0<> >r c@ >r over c@ dup > [char] . = swap r> = or r> and > if 1 /string 2>r 1 /string 2r> recurse exit then false > then \ if so recurse, otherwise quit > then > then > else > true \ zero length regular expression > then >r 2drop 2drop r> \ clean up and exit > ; is (matchhere) \ assign to DEFER (we got 'em) > > : match ( a n ra rn --f) > dup if over c@ [char] ^ = if 1 /string (matchhere) exit then then > begin \ if caret, chop it > 2over 2over (matchhere) if 2drop 2drop true exit then > >r over r> swap \ match characters > while \ until no more text > 2>r 1 /string 2r> \ chop text > repeat 2drop 2drop false \ clean up > ; > > s" 0,9" s" ^0,?9$" match . .s cr > s" 0:9" s" ^0,?9$" match . .s cr > s" 09" s" ^0,?9$" match . .s cr > s" 009" s" ^0,?9$" match . .s cr > s" 0,,9" s" ^0,?9$" match . .s cr cr > ---8<--- bravo
[toc] | [prev] | [next] | [standalone]
| From | the_gavino_himself <visphatesjava@gmail.com> |
|---|---|
| Date | 2014-11-08 20:42 -0800 |
| Message-ID | <0829f605-b8a8-4b6f-af54-4f3eec1d0957@googlegroups.com> |
| In reply to | #33871 |
On Monday, October 13, 2014 9:13:06 AM UTC-7, The Beez wrote: > Short intermission from all the clashes here, sorry for the inconvenience, > but I used Forth for some CODING. You may fry me for the code quality > later, but this is a tiny regular expression parser, based on an article by > Kernighan and Pike > (http://www.drdobbs.com/architecture-and-design/regular-expressions/184410904). > > It features ^, $, * and . but I added ? as well (zero or one). This is some > stuff that was left lying around as an intermediate stage for a similar 4tH > library (which is cleaner and more capable), but I thought, may be it is of > use/interest to someone, why throw it away. > > Knock yourselves out ;-) > > Hans Bezemer > > ---8<--- > \ Regular Expressions by Brian W. Kernighan and Rob Pike > \ Believed to be in the public domain > > defer (matchhere) > > : (match*) ( a n ra rn c --f) > begin > >r 2over 2over (matchhere) if r> drop 2drop 2drop true exit then > 2over if c@ dup [char] . = swap r@ = or else dup xor then r> swap > while \ character equals text? > >r 2>r 1 /string 2r> r> \ if so, match again > repeat > drop 2drop 2drop false \ clean up, return false > ; > > : (match?) ( a n ra rn c --f) > >r 2over 2over (matchhere) if r> drop 2drop 2drop true exit then > 2over if c@ dup [char] . = swap r> = or else r> dup xor then > if 2>r 1 /string 2r> (matchhere) else 2drop 2drop false then > ; \ character equals text? > > :noname ( a n ra rn -- f) > dup if \ regular expression a null string? > over char+ c@ dup [char] * = \ if not, does it equal a '*' > if \ if so, call (match*) > drop over c@ >r 2 /string r> (match*) exit > else \ otherwise, does it equal a '?' > [char] ? = > if \ if so, call (match?) > over c@ >r 2 /string r> (match?) exit > else \ otherwise does it equal a '$' > over c@ [char] $ = over 1 = and > if \ and is it the last character? > 2drop nip 0= exit \ is so, check length of text > else \ finally, check if it char matches > 2over 0<> >r c@ >r over c@ dup > [char] . = swap r> = or r> and > if 1 /string 2>r 1 /string 2r> recurse exit then false > then \ if so recurse, otherwise quit > then > then > else > true \ zero length regular expression > then >r 2drop 2drop r> \ clean up and exit > ; is (matchhere) \ assign to DEFER (we got 'em) > > : match ( a n ra rn --f) > dup if over c@ [char] ^ = if 1 /string (matchhere) exit then then > begin \ if caret, chop it > 2over 2over (matchhere) if 2drop 2drop true exit then > >r over r> swap \ match characters > while \ until no more text > 2>r 1 /string 2r> \ chop text > repeat 2drop 2drop false \ clean up > ; > > s" 0,9" s" ^0,?9$" match . .s cr > s" 0:9" s" ^0,?9$" match . .s cr > s" 09" s" ^0,?9$" match . .s cr > s" 009" s" ^0,?9$" match . .s cr > s" 0,,9" s" ^0,?9$" match . .s cr cr > ---8<--- beez what about web programming in forth?
[toc] | [prev] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | comp.lang.forth
csiph-web