lisp and tcl driving me bonkers
gavino
Jerry Avins
> I might try forth again
Thanks for sharing.
--
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������
gavino
I really wish to learn to program but hate the boooks sofar.
Can forth if I read startign and thinking forth do file manipulation
on linux as well as sorting and input output easily? What about
moving file among machines and reading file on remote machines?
Jerry Avins
You probably want Lua or something similar. Whatever language you settle
on, you'll have to learn its details, Hand waving won't do.
Jerry
Bruce McFarling
> I might try forth again
Python? Maybe you can find an APL interpreter implemented as a Python
control?
gavino
gavino
gavino
not interested in oo progrmaming
w_a_x_man
> anytime!
>
> I really wish to learn to program but hate the boooks sofar.
>
> Can forth if I read startign and thinking forth do file manipulation
> on linux as well as sorting and input output easily?
Why not give us an example of a sorting task that you want to perform?
Elizabeth D Rather
Starting Forth and Thinking Forth were written before file manipulation
words were added to Forth, and so will be no helpd on that score.
What books have you read?
Regardless of what books you have, though, you will not learn to program
from any books unless you have a Forth system and actually write some
programs. You cannot learn programming from books any more than you can
learn swimming from books.
Get a copy of gForth for Linux and start writing some code. It has a
good tutorial with it.
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."
==================================================
John Passaniti
> You probably want Lua or something similar. Whatever language you settle
> on, you'll have to learn its details, Hand waving won't do.
I have mixed feelings about recommending Lua for a beginner. Lua
isn't difficult to learn, does function well as a scripting language,
has good training documentation, and is supported by a great
community. However, Lua's roots and main use are in being an embedded
scripting language. That is, it is most commonly used as a language
that one embeds into an application to provide high-level
programmability for that application. Think of the role JavaScript
has in a web browser or that AutoLisp has in AutoCAD and that's the
kind of role Lua most often has. It's only been fairly recently that
pre-packaged binaries for most major operating systems were even
available; previously, you needed to install Lua by getting the source
code and compiling it. That was a bit of a barrier for novices.
I know the knee-jerk reaction in this newsgroup for gavino will be to
set him up with a Forth, point him at the online version of Starting
Forth or Elizabeth Rather's books, and say good luck. The problem
with that is that when someone like gavino says they want to learn how
to program, they aren't thinking of the same thing the rest of us
are. Forth is a language that rides close to the hardware, and
provides little abstraction or safety nets. For most of us, we see
the power in such a language as being that we can have complete
visibility and control and can build up to what we need. But that
doesn't seem to be what gavino wants.
Note the questions gavino asked:
> Can forth if I read startign and thinking forth do file manipulation
> on linux as well as sorting and input output easily? What about
> moving file among machines and reading file on remote machines?
What he wants is a language that provides some high-level abstractions
and algorithms for him to stitch together his applications. He's not
going to want a language where he's reading and writing physical
memory, building up data structures from raw pointers, manually
managing allocated memory, and writing core algorithms (for example
sorting) by himself. Or at least, he isn't going to want any of that
*yet*. He's going to want to program at a very high level of
abstraction-- not build up those abstractions. He's going to want
rich libraries-- not writing his own.
Once he gets the knack of seeing how to turn his ideas into working
code at that level, he can start to dive deeper. Yes, that's a top-
down approach, but in my experience novices want to start at a high-
level and if their interests dictate, they'll dive deeper. If not,
they'll be happy where they are. And that's fine.
One day, I'd like to see a language built on top of Forth that
provided very high-level abstractions (such as those found in
scripting languages) and rich libraries. Such a language would allow
someone like gavino to start with something relatively easy and then
dive down to Forth as needed. But there has never been much interest
in that here in comp.lang.forth. If it isn't the snobbery of thinking
that using a scripting language isn't "real" programming, it's
thinking that Forth *is* scripting. Factor might be a stepping stone
towards what I'm talking about, but it's not quite there.
John Passaniti
> Python? Maybe you can find an APL interpreter implemented as a Python
> control?
Odd. Python doesn't have a notion of controls, and I can't imagine a
language with a strong mathematical basis like APL would be appealing
to a novice like gavino.
What exactly are you suggesting for him?
John Passaniti
> not interested in oo progrmaming
Why not? If you don't understand programming, what makes you sure you
aren't interested in object orientation in programming?
Why don't you start by learning what terms actually mean, and then
worrying about if you're interested in them or not?
Marcel Hendrix
[..]
> I know the knee-jerk reaction in this newsgroup for gavino will be to
> set him up with a Forth, point him at the online version of Starting
> Forth or Elizabeth Rather's books, and say good luck.
Knee-jerk? Forth? I am sure most readers of this group were rather
thinking of a spasmodic reaction of their lower-leg part, preferably
sheeted in a iron-plated leather contraption, aimed at a prominent but
conventionally hidden and firmly cushioned part of Gavino's lower fat
bulk-storage regions, aimed to launch said approximation of an
answering-machine dual in the general direction of the newsgroup
hosting the worst monstrosity cloaking as a scripting language they
could think of, thereby hoping to vastly increase the IQ level of both
CLF and said newsgroup.
-marcel
Jerry Avins
You know Lua far better than I, and your judgment is usually sound. Note
that no one has so far recommended Forth to gavino.
...
w_a_x_man
> John Passaniti <john.passan...@gmail.com> writes Re: lisp and tcl driving me bonkers
Are you fluent in any "scripting" (i.e., high-level) language?
Or is your IQ so near gavino's that you attempt to use a low-level
embedded toilet-flushing language for high-level programming?
Richard Owlett
> [snip]
> Or is your IQ so near gavino's that you attempt to use a low-level
> embedded toilet-flushing language for high-level programming?
You are making yourself look more than a little ...
Check out top hits of www.google.com/search?q=Marcel+Hendrix
gavino
ok
-a java program produces a file
-the file lists 7000 active movies for a movie site, with full path 7
directoy deep, with final directory containing the movie and a control
file
-the file server has 11000 movies, some old, some out of date, some in
limbo
-The 7000 list is unreliable because the java content management
system is not fully trustable and due to old inputs by operators, each
listed movie must be tested for actual existance
-the 7000 title must be synced to a remote server accessible through
ssh
John Passaniti
> > Why not give us an example of a sorting task that you want to perform?
>
> ok
> -a java program produces a file
> -the file lists 7000 active movies for a movie site, with full path 7
> directoy deep, with final directory containing the movie and a control
> file
> -the file server has 11000 movies, some old, some out of date, some in
> limbo
> -The 7000 list is unreliable because the java content management
> system is not fully trustable and due to old inputs by operators, each
> listed movie must be tested for actual existance
> -the 7000 title must be synced to a remote server accessible through
> ssh
I'm sure the devil is in the details, but what you describe sounds
like it would take anyone with a basic knowledge of shell utilities
(such as find, sort, uniq, etc.), basic scripting languages, and
common applications like rsync no more than an hour to design,
implement, and test. If it took longer, it's because there are
important details you're leaving out. For example, you mention a
control file. If that's a binary file generated by serializing a Java
class, then you might have to first write a Java utility to dump out
the control file as text so that it's easier to work with.
Why you think Forth has any great strength dealing with problems like
this is beyond me. If this is an example of the kind of work you need
to do, then put the Forth books away and look instead at both
stringing together shell utilities, scripting languages, and common
applications. You'll get your work done in the short term, get a
better understanding of "how to program", and then know both where
Forth is awesome-terrific and where Forth sucks and should be
avoided. Your problem in comp.lang.forth seems to revolve around you
not understanding that programming languages exist to solve certain
kinds of problems very well, but not all problems equally well. Use
the right tool for the job. Don't assume that because Forth can do
some things very well, that it does *all* things well. And the same
is true for most every language.
W. James
I don't use Unix, so I won't consider the remote-server issue.
Using Ruby:
# Path where files must exist.
MUST_EXIST_HERE = "c:/vid"
# A routine to remove paths from filenames.
def strip_path filename
filename.sub( %r{^.*/}, "" )
end
## Get list of 7000 movie files.
## Assumes name of file with the 7000 movies is given on command-line.
list = gets(nil).strip.split( /\s*\n\s*/ )
# Remove the path, leaving bare filenames.
# (The exclamation mark after "map" indicates that the operation is
# performed in place---the original list is changed.)
list.map!{|s| strip_path(s) }
## Remove control files, assuming extension is ".cnt".
list.reject!{|s| s.match( /\.cnt$/ ) }
# Keep only files that exist.
list = list.select{|f| File.exists?( MUST_EXIST_HERE + "/" + f ) }
puts list.sort
puts
puts "Found #{ list.size } valid files."
--
gavino
I did solve it in bash shell in under an hour, which is mt strong
suit.
I gave the deatails because someone asked.
Ok what areas does forth excel in?
gavino
>
> - Show quoted text -
fair enough, but keeping the proper files on the remote server is the
task.
gavino
iq 154
gavino
> John Passaniti <john.passan...@gmail.com> writes Re: lisp and tcl driving me bonkers
lower fat bulk storage regions?
hmm
gavino
APL does seem interesting.
to bad no free interpreter eh
gavino
> gavino wrote:
> > anytime!
>
> > I really wish to learn to program but hate the boooks sofar.
>
> > Can forth if I read startign and thinking forth do file manipulation
> > on linux as well as sorting and input output easily? What about
> > moving file among machines and reading file on remote machines?
>
> Starting Forth and Thinking Forth were written before file manipulation
> words were added to Forth, and so will be no helpd on that score.
>
> What books have you read?
>
> Regardless of what books you have, though, you will not learn to program
> from any books unless you have a Forth system and actually write some
> programs. You cannot learn programming from books any more than you can
> learn swimming from books.
>
> Get a copy of gForth for Linux and start writing some code. It has a
> good tutorial with it.
>
> Cheers,
> Elizabeth
>
> --
> ==================================================
> Elizabeth D. Rather (US & Canada) 800-55-FORTH
> FORTH Inc. +1 310.999.6784
> 5959 West Century Blvd. Suite 700
>
> "Forth-based products and Services for real-time
> applications since 1973."
> ==================================================
Thank you for a civilized answer. I feel I must carry a shield in
here. No douvt my own fault I tend to talk too much and ask too many
questions.
ron
> APL does seem interesting.
> to bad no free interpreter eh
Not true. http://cosy.com/CoSy/ is an APL variant written ... in
Reva Forth.
Richard Owlett
Did you bother looking on Google?
No evidence!
Bruce McFarling
> APL does seem interesting.
> to bad no free interpreter eh
Bruce McFarling
> On Dec 4, 11:00 pm, Bruce McFarling <agil...@netscape.net> wrote:
> > Python? Maybe you can find an APL interpreter implemented as a Python
> > control?
> Odd. Python doesn't have a notion of controls,
Sorry, Python/PyGTK and APL implemented as a GTK control.
Don't see any free APL's implemented as GTK controls, so that'd be
gavino's first project. After he's got that up and running and then
wants to know how Forth can control it too, be controlled by it, talk
to it over pipes, etc, why, he could come back here and ask.
Richard Owlett
Twit claims IQ > 150
make him search
Jerry Avins
Steatopyga.
Bruce McFarling
John Passaniti
> I did solve it in bash shell in under an hour, which is mt strong
> suit.
> I gave the deatails because someone asked.
> Ok what areas does forth excel in?
You've been here in comp.lang.forth, writing endless "can Forth do X"
messages. And in virtually every one of those messages, I or someone
else has told you, repeatedly, that Forth's primary domain is in
embedded systems. For you to ask what areas Forth excels in tells me
that you aren't reading our responses to you. So you're not just
wasting our time, but you're wasting *your* time, asking the same damn
question over and over, only replacing different things for X.
You aren't serious. Goodbye.
gavino
I looked in your moms closet!
gavino
I have a big colon pipe full of stuff I wana donate to you.
gavino
154
gavino
>
> - Show quoted text -
nope won't google it!
gavino
Man you are unhappy. I suggest having some ice cream.
ron
> You aren't serious. Goodbye.
No, he's Russian and merely misspelled his name: govno
Jerry Avins
Is your IQ too high for a dictionary?
�����������������������������������������������������������������������
Jerry Avins
...
>>> Steatopyga.
gavino wrote:
>> nope won't google it!
>
> Is your IQ too high for a dictionary?
Also, steatopygia.
Bruce McFarling
You feel the need to correct "claims IQ > 150" to "154". If
intelligence is not the shortfall there, its somewhere else.
W. James
Since the IQ test that you took was purchased at Wal-Mart, you must
understand that the resulting number is highly inflated.
--
Bernd Paysan
> You've been here in comp.lang.forth, writing endless "can Forth do X"
> messages. And in virtually every one of those messages, I or someone
> else has told you, repeatedly, that Forth's primary domain is in
> embedded systems.
But that doesn't mean Forth can't do web servers or GUIs. The problem I
have with gavino's question like "can your web server do xxx" is that
xxx usually isn't even remotely an operation of the web server itself.
Like "can your web server do a wiki/paypal?" - No web-server in the
world can do a wiki/paypal all by itself, it needs a web application for
that.
I use Forth for all kinds of things, and most is outside the embedded
system stuff. I *also* use Forth sometimes in embedded systems, but I
wouldn't say that Forth is only good for that. The world's biggest
Forth program (CCS) is outside the embedded system field, even though it
runs on "modest" hardware nowadays that you can use it on your netbook
while standing on the construction site (it's probably only so because
Willem's team failed to add bloat fast enough, while Stephen made VFX
run faster on the same hardware). But it's a planning tool, it's
something a Microsoft-centric person would probably implement based on
Excel, Access, and Project (and fail).
Back in the days when Perl was the text manipulation language du jour, I
thought that Forth wasn't very good at text processing, until I had to
take over a Perl script and maintain it - i.e. get the bugs out so that
it could process our Verilog netlists without manual intervention. I
tweaked it for a week or two, and then gave up and rewrote the entire
program in Forth - which took a day or two. The Forth program didn't
use regexps, but then it also didn't fail when unexpected characters
turned up in the Verilog symbols.
We also migrated our Emacs-Lisp script for converting the primitives
file in Gforth to C code to Forth (plus the parser generator gray), and
it was a good idea to do that - not only are those days past where we
had to adapt the script for whatever new Emacs version comes out, but it
became easier to maintain and improve.
A lot more people do PIC assembler in embedded computing than Forth.
They are apparently happy with this really crazy and limiting
instruction set, and don't want to learn anything else.
Forth's problem is that it's too different. In the embedded world,
where assembler with crazy and limiting instruction sets are common,
Forth had gained some standing, but most of that is gone now - C is more
"traditional".
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Bruce McFarling
> The Forth program didn't
> use regexps, but then it also didn't fail when unexpected characters
> turned up in the Verilog symbols.
Yes, this was an original target for "Text Sliders" pattern matching -
using process based text matching rather than expression based text
matching, which is a more comfortable basis for building up a text
matching dictionary.
When I came back to it, I saw that the *process* for a lazy pattern
match was to go back to the last repeatable match that succeeded and
try it again, until the final result was a match or exhaustion of the
string, and for a greedy pattern match do it as many times as worked,
and on failure go back and roll the match back on until it succeeded.
So a stack of structures with an xt for the repeatable action, number
of successful repetitions, and index at last success. So the original
( base edge current status )
turns into ( base edge ) with the current position and status in the
top structure on the slider stack.
I have no idea what the efficiency of the pattern matching will be
when a pattern is compiled and run, but for downloading web pages of
streaming anime site and sniffing out their host streaming server
links, the web access is likely to be the main bottleneck in any
event.
gavino
lol
gavino
some people use uncommon words to be impressive, I find it tedious at
times, since its such an obvious look at me meaneuver
gavino
just making fun of the lunacy
gavino
No it was by a professor when I was like 14, and I scored 154.
gavino
I find the part about you replacing the perl scripts without using
regular expression VERY interesting. How did you do that? and it was
less buggy since no crazy behavior when a special character showed up?
AWESOME
gavino
Woa! awesome ! I really want to learn enough forth to use this.
Elizabeth D Rather
There's nothing stopping you. And if you make a serious effort, you'll
find you get more respect here.
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."
==================================================
Jerry Avins
...
> some people use uncommon words to be impressive, I find it tedious at
> times, since its such an obvious look at me meaneuver
There is no other word I know that expresses that meaning. A little
knowledge of Greek makes the meaning clear.
�����������������������������������������������������������������������
Jerry Avins
Stop talking. Start doing.
Bruce McFarling
Download the evaluation versions of Swiftforth or VFX, work through
Starting Forth, which you can download free at ...
http://www.forth.com/starting-forth/index.html
... and then Forth Application Techniques (Amazon US has it for under
$20 new), but if you finish Starting Forth you'll have ample to get
started.
ron
> Yes, this was an original target for "Text Sliders" pattern matching -
> using process based text matching rather than expression based text
Is the code available? FWIW, I simply have a wrapper for the PCRE
library in Reva, so I can just reuse all I already know about
regexes. But regexes aren't always the solution ...
W. James
> I had to
> take over a Perl script and maintain it - i.e. get the bugs out so
> that it could process our Verilog netlists without manual
> intervention.
Please give sample input and output.
--
Bruce McFarling
I'll want to see that the fixed work in the wild before putting the
code up, but once its working on finding specific types of links in
the various ways that various bootleg leech streaming groups put them
up, I'll of course post it.
I put up what I had back when, but it was a dead end as far as mixing
lazy and greedy pattern matching, and by the time I gave up on trying
to fix it, I wasn't doing any research or hobby project that needed
pattern matching anymore. So I just came back to it recently. But
grades went in on Friday, and there's nothing higher priority than
this research project until the meetings in the New Year.
John Passaniti
I really wish this newsgroup could get past this. Forth is a general-
purpose programming language. It can do *anything* that is
computable.
The same is true for COBOL, but I don't see significant scientific
calculation being done with it. The same is true of Perl, but where
is the effort to write a complete operating system in it? Where are
the enterprise-level database systems written in Postscript and why
don't you see the game programming community taking awk to the next
level?
Every language-- including Forth-- has strengths and weaknesses in
different problem domains. Those strengths and weaknesses come both
from the language itself and the community that supports it. And yes,
you'll find marginal use of *every* language in *every* problem
domain. People do this for a variety of reasons:
1. They don't know of a better language for the problem domain, or
are weak in that language.
2. They enjoy the challenge of pushing a language into areas where it
isn't used.
3. They are a "one trick pony" and recast all problems in their
favorite language.
4. They don't mind building up the infrastructure needed to support
the problem.
5. They are engaging in geek humor.
6. They are blazing a trail that others don't see.
The anecdotal and incidental use of Forth in areas other than embedded
systems doesn't take away from Forth's roots or from where Forth is
most often used. Characterizing Forth as an embedded systems language
is a statement reflecting it's dominate use; it's abilities as a
general-purpose language don't limit it to embedded systems, but it
doesn't have any special capabilities (or support) that makes it
unusually well-suited for other problem domains.
That can of course change. When Perl first came out, it was primarily
a souped-up version of awk that had features that made it useful for
system scripting and report generation. Then when the web started to
take off, the Perl community started to come out with loads of code to
support that kind of work. And some years later, the bioinformatics
community came out with loads of code to support their efforts. And
although the Perl language changed a bit, it wasn't really the
language that enabled Perl to move into the web and bioinformatics
domains. It was the community, contributing code that made hard
things easy, sharing experience, and allowing further bootstrapping of
the community.
Forth could do the same. FLAG might contribute to that.
> I use Forth for all kinds of things, and most is outside the embedded
> system stuff. I *also* use Forth sometimes in embedded systems, but I
> wouldn't say that Forth is only good for that.
I didn't say Forth was only good for embedded systems. Citing Forth's
dominate problem domain is embedded systems doesn't mean it can't be
used elsewhere-- appropriate or inappropriately.
> The world's biggest
> Forth program (CCS) is outside the embedded system field, even though it
> runs on "modest" hardware nowadays that you can use it on your netbook
> while standing on the construction site (it's probably only so because
> Willem's team failed to add bloat fast enough, while Stephen made VFX
> run faster on the same hardware). But it's a planning tool, it's
> something a Microsoft-centric person would probably implement based on
> Excel, Access, and Project (and fail).
Or not fail. I know this is hard to believe, but there are real
people who are adept at things you aren't, and who can make things
work that you can't. There are entire classes of programmers who do
nothing but script together applications and get real, actual work
done. And they often do it better, because they aren't programmers in
the traditional sense, but experts in the problem domain who have
learned how to automate what they know.
Yes, writing this isn't fashionable in comp.lang.forth. The crowd
here, in general, persists in two destructive beliefs. The first is
that solutions written in Forth are somehow automatically better than
anything else. The second is that unless you're flying inches above
the metal, you aren't really programming. Good luck with that.
> Back in the days when Perl was the text manipulation language du jour, I
> thought that Forth wasn't very good at text processing, until I had to
> take over a Perl script and maintain it - i.e. get the bugs out so that
> it could process our Verilog netlists without manual intervention. I
> tweaked it for a week or two, and then gave up and rewrote the entire
> program in Forth - which took a day or two. The Forth program didn't
> use regexps, but then it also didn't fail when unexpected characters
> turned up in the Verilog symbols.
Yes, this isn't the first time you've described your inability to
construct reliable Perl programs. What exactly are we supposed to
take away from such statements? That you're brilliant, and if you
can't make your Perl code work, then nobody can?
Here's what I take away: You aren't proficient in Perl, and instead
of increasing your proficiency in it, you instead decided to rewrite
it in a language you were proficient in. Or alternatively, you
started with an application that was ill-suited to Perl (probably
because a previous "one trick pony" thought they could solve every
problem with regular expressions), and you recoded to something more
suited to the problem. Or maybe the real issue here is that Perl was
likely a fine language for the problem, but the previous author of the
script didn't know how to use regular expressions well and you weren't
much better, both leading to poorly constructed, overly-greedy or
overly-general regular expressions that accepted unexpected
characters.
I'm a poor carpenter, but am good at working with metal. So when I
decided to handle a home improvement project that involved fixing a
step, I tried initially slapping some wood together to strengthen the
step, but that failed. I then later decided to go with what I knew
and fashioned a metal bracket that solved the problem, which still
works today. I solved the problem, but didn't go off declaring that
my metal bracket was a better solution. I know that if I had better
carpentry skills, I might have been able to do the job just fine.
> We also migrated our Emacs-Lisp script for converting the primitives
> file in Gforth to C code to Forth (plus the parser generator gray), and
> it was a good idea to do that - not only are those days past where we
> had to adapt the script for whatever new Emacs version comes out, but it
> became easier to maintain and improve.
That's the miracle of bootstrapping. And as long as you have an older
version of gforth available, you're fine.
But regardless, that's good to know. So when the rest of us are faced
with the same class of problem, we know that someone else once had
success using Forth. But here's a question that never gets asked here
in comp.lang.forth: How many people *aren't* successful in using
Forth for such problems (or any other problem). Shouldn't an informed
evaluation of the worth of a programming language for solving problems
include not just a litany of where Forth worked, but where it failed?
Or is Forth just so fabulous that success is automatic?
But back to the claim-- so let me see if I get this straight--
converting primitives encoded in a particular Forth-friendly format
was easier in Forth? Color me shocked. That's almost as shocking as
when someone announces a FFI to C that uses C prototypes to drive the
interfaces. Then when you look closer, you see that what a C
programmer would actually write...
int* whatever(char* something, int another);
...has to be converted to this...
int * whatever ( char * something , int another ) ;
Or something similar. And the same thing happens a lot in other
applications where Forth is used to parse other languages: More often
than not, the other language is first normalized into a form that is
nice for Forth such as adding strategic whitespace.
> A lot more people do PIC assembler in embedded computing than Forth.
> They are apparently happy with this really crazy and limiting
> instruction set, and don't want to learn anything else.
When all you have is a hammer...
> Forth's problem is that it's too different.
No, Forth as a language has no problem. And it's not different at
all-- it's a pretty traditional and conservative, explicit,
imperative, procedural language. It *was* different from most of the
other languages it competed with back when it was new, but these days,
the idea of an interactive and interpreted language that compiles down
to an efficient internal representation isn't exactly new.
The only thing about Forth that is different is the community and the
kind of support that community provides. That is indeed different,
and that is why Forth is where it is today.
Bernd Paysan
Sorry, this is too long ago, and of course the netlists we massaged back
then were all company secrets. The whole project with all scripts,
data, and whatever went to some backup tape which is in some dusty
cellar. The original Perl script somehow survived, the Forth
replacement didn't.
What it basically did was to read a Verilog netlist, store the verilog
modules in a hash table, and do some changes, like replacing 0s and 1s
with logic0 and logic1 cells - of course that needs adding a wire
declaration. Or unfolding wire busses, since the place&route program
didn't like that, either. And assignments - nets with different names
connected straight together - all those nets had to be replaced with the
one and only net, the left hand side of the assignment. Finally, it
dumped out the modified netlist. Part of the problem this script had
was that it used regexps to search and replace net names, while net
names typically contain regexp meta-characters, like "bus[5]". It also
confused instance names with net names, as it only looked for symbols,
and didn't know the context.
So a sample input would be like this:
module foo(a, b, c);
input a;
input b;
output c;
wire x;
wire x2;
wire y;
assign x = x2;
AND blabla(a, x, c);
OR3 foobar(1'b0, b, y, x2);
endmodule
and the output should look like
module foo(a, b, c);
input a;
input b;
output c;
wire x;
wire y;
wire gnd;
LOGIC0 gnd0(gnd);
AND blabla(a, x, c);
OR3 foobar(gnd, b, y, x);
endmodule
The script soon became obsolete, because the next version of the
place&route tool could handle the netlists the synthesis tool generated.
Richard Owlett
> On Dec 18, 12:48 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
>> But that doesn't mean Forth can't do web servers or GUIs.
>
> I really wish this newsgroup could get past this. Forth is a general-
> purpose programming language. It can do *anything* that is
> computable.
*SNIP* trivialities
Forth is "Turing Complete".
All else is nonsense !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
;/
Jerry Avins
> John Passaniti wrote:
>> On Dec 18, 12:48 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
>>> But that doesn't mean Forth can't do web servers or GUIs.
>>
>> I really wish this newsgroup could get past this. Forth is a general-
>> purpose programming language. It can do *anything* that is
>> computable.
>
> *SNIP* trivialities
>
> Forth is "Turing Complete".
So are Cobol and GW BASIC.
Bernd Paysan
> On Dec 18, 12:48 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
>> But that doesn't mean Forth can't do web servers or GUIs.
>
> I really wish this newsgroup could get past this. Forth is a general-
> purpose programming language. It can do *anything* that is
> computable.
But that's not the question. The question is rather: Is it good at
doing those other things? And I tell you: yes it is. At least for me.
And I'm far away from the one-pony-trick kind of person.
> 4. They don't mind building up the infrastructure needed to support
> the problem.
Indeed. I don't mind that. As long as the benefit from building my own
infrastructure is bigger than the effort.
> The anecdotal and incidental use of Forth in areas other than embedded
> systems doesn't take away from Forth's roots or from where Forth is
> most often used. Characterizing Forth as an embedded systems language
> is a statement reflecting it's dominate use; it's abilities as a
> general-purpose language don't limit it to embedded systems, but it
> doesn't have any special capabilities (or support) that makes it
> unusually well-suited for other problem domains.
I doubt Forth *is* dominantly used in embedded systems. It's a fringe
language, there, as well, and embedded systems are a small section of
the whole programming world. And Forth *does* have special capabilities
that makes it more suitable for other domains than mainstream languages,
especially the extensibility. Yes, there are other fringe languages
like the Lisp family, which are also very extensible. No problems with
that. It's the mainstream languages which aren't extensible enough, and
it's good to see that some of them are catching up.
> Or not fail. I know this is hard to believe, but there are real
> people who are adept at things you aren't, and who can make things
> work that you can't.
Those people who write programs in Excel+Access+Project+VBA usually
deliver very poorly written programs. Their field of expertise is in a
different area - it's *not* programming. Therefore, as long as the
program stays trivial, these tools are probably good enough.
But the last time people in my company had problems with such an
Excel+VBA program, they desperately asked me for help (knowing that I
hate this stuff, but also knowing that I would find a solution), and I
indeed could help - the original programmer used a hidden sheet as "date
conversion function", and the table was only filled up to a certain
date. I suggested filling in the dates needed for the next report, and
telling the guy when he's back from holiday, that he should use Excel's
date functions instead of his self-made table.
> There are entire classes of programmers who do
> nothing but script together applications and get real, actual work
> done. And they often do it better, because they aren't programmers in
> the traditional sense, but experts in the problem domain who have
> learned how to automate what they know.
I've just spent the last week traveling over to UK to tell such a
problem-domain expert how to do the last part of his problem-domain
specific task - testers. Unlike you, this guy doesn't claim he's better
in his problem domain than me.
> Yes, this isn't the first time you've described your inability to
> construct reliable Perl programs.
I haven't constructed the program, I have taken over maintenance after
the coworker who wrote it left. I spent two weeks on improving
reliability, and after the two weeks, it worked *somewhat more* reliable
than before (these are not two working weeks, it's just using the
script, and whenever I had a problem, trying to fix it). After these
two weeks, I gave up wasting more time. Perl and regexps were *not*
appropriate to the problem at hand, because it required something more
like a parser.
> What exactly are we supposed to
> take away from such statements? That you're brilliant, and if you
> can't make your Perl code work, then nobody can?
I just say it wasn't worth the time spent. It did take a lot less time
to throw the Perl program away and rewrite something more appropriate
from scratch, using a parser approach, not a regexp approach. I decided
to use a language where I know how to write a simple parser.
Since it now was my choice which programming language to choose, and you
know my dislike of Perl, it's no wonder I didn't choose Perl. The good
worker doesn't blame his tools, as tool choice is part of the job. I
did succeed with my tool of choice. I also recommended replacing the
synthesis tool with a more capable one so that the hack of rewriting the
netlist wasn't necessary any longer - and I made the investigation which
tool to chose, and found one which not too costly (instead of bitching
about the bad tool as my ex-coworkers did).
> Or alternatively, you
> started with an application that was ill-suited to Perl (probably
> because a previous "one trick pony" thought they could solve every
> problem with regular expressions), and you recoded to something more
> suited to the problem.
Indeed. Most of the Perl programs I've seen are such stuff. As Perl
became out of fashion, this stuff seems to disappear - or replaced by
similarly sloppy programs in more fashionable programming languages like
PHP. I however still have a coworker who uses awk for all that stuff.
His programs have the same fundamental problems, but at least nobody
argues that awk is a good general purpose language, and he never spends
more than a few hours to write those scripts, or try to achieve too
complex stuff.
>> We also migrated our Emacs-Lisp script for converting the primitives
>> file in Gforth to C code to Forth (plus the parser generator gray),
>> and it was a good idea to do that - not only are those days past
>> where we had to adapt the script for whatever new Emacs version comes
>> out, but it became easier to maintain and improve.
>
> That's the miracle of bootstrapping. And as long as you have an older
> version of gforth available, you're fine.
Or, as it used to be before, an older version of Emacs. That was a lot
worse ;-).
> But back to the claim-- so let me see if I get this straight--
> converting primitives encoded in a particular Forth-friendly format
> was easier in Forth?
The primitives aren't coded in a particular Forth-friendly format. If
we had decided to go with Forth right from start, the format would look
differently, and we wouldn't need gray as parser generator to handle it.
This format was designed to be particularly Emacs-lisp-friendly.
> Color me shocked. That's almost as shocking as
> when someone announces a FFI to C that uses C prototypes to drive the
> interfaces. Then when you look closer, you see that what a C
> programmer would actually write...
>
> int* whatever(char* something, int another);
>
> ...has to be converted to this...
>
> int * whatever ( char * something , int another ) ;
prim might look like this, but
dup (x--x x)
works as good as
dup ( x -- x x )
That's thanks to the parser generator. If it was written with Forth in
mind, it would probably look like
c-code dup ( x -- x x )
/* embedded C code when necessary */
end-code
or so, not treat tab as special syntactic element, and strictly require
the spaces around "(", ")", and "--".
>> Forth's problem is that it's too different.
>
> No, Forth as a language has no problem. And it's not different at
> all-- it's a pretty traditional and conservative, explicit,
> imperative, procedural language.
The people who like to stay with PIC assemblers tell me it is too
different - either PIC assembler or something mainstream like C, but not
that weird RPN stuff. Sorry, Forth as a language has that problem.
Being different is a problem in general.
W. James
Well, I don't understand the "LOGIC0 gnd0(gnd);" part, so I will just
attempt to handle the assignments.
data = "
module foo(a, b, c);
input a;
input b;
output c;
wire x;
wire x2;
wire y;
assign x = x2;
AND blabla(a, x, c);
OR3 foobar(1'b0, b, y, x2);
endmodule
"
data.gsub!(
%r{
^(module \s+ \w+ \( .*? \) ; \s* \n )
( .*? )
^(endmodule)
}xm
){
head, text, tail = $~.captures
declarations = text.scan( %r{^\s*(\w+)\s+(\w+);} )
puts "Declarations:"
p declarations
assignments =
Hash[ *text.scan( %r{^\s*assign\s+(\w+)\s*=\s*(\w+);} ).map{|x|
x.reverse}.flatten ]
puts "Assignments:"
p assignments
declarations.reject!{|x| assignments.include?( x.last ) }
puts "Declarations taking assignments into account:"
p declarations
logic = text.scan( %r{^\s*[A-Z]+[A-Z\d]*\s+\w+\(.*?\);\s*\n} )
logic.map!{|str|
str.sub( %r{\(.*\)} ){|s|
s.gsub( %r{[\w']+} ){|token| assignments[ token ] or token }
}
}
head +
declarations.map{|a,b| " #{a} #{b};\n"}.join +
logic.join +
tail
}
puts data
=== output ===
Declarations:
[["input", "a"], ["input", "b"], ["output", "c"], ["wire", "x"],
["wire", "x2"], ["wire", "y"]]
Assignments:
{"x2"=>"x"}
Declarations taking assignments into account:
[["input", "a"], ["input", "b"], ["output", "c"], ["wire", "x"],
["wire", "y"]]
module foo(a, b, c);
input a;
input b;
output c;
wire x;
wire y;
AND blabla(a, x, c);
OR3 foobar(1'b0, b, y, x);
endmodule
--
Anton Ertl
>John Passaniti wrote:
>> But back to the claim-- so let me see if I get this straight--
>> converting primitives encoded in a particular Forth-friendly format
>> was easier in Forth?
>
>The primitives aren't coded in a particular Forth-friendly format. If
>we had decided to go with Forth right from start, the format would look
>differently, and we wouldn't need gray as parser generator to handle it.
>This format was designed to be particularly Emacs-lisp-friendly.
And when I converted the Elisp script into a Forth script, the format
was changed slightly to make writing the parser easier. Hmm, looking at
http://www.complang.tuwien.ac.at/viewcvs/cgi-bin/viewcvs.cgi/gforth/Attic/primitives?r1=1.5&r2=1.6
it seems that only the comment syntax changed.
>prim might look like this, but
>
>dup (x--x x)
>
>works as good as
>
>dup ( x -- x x )
>
>That's thanks to the parser generator. If it was written with Forth in
>mind, it would probably look like
>
>c-code dup ( x -- x x )
>/* embedded C code when necessary */
>end-code
Yes. Or, looking at libcc.fs, maybe:
primitive + n1 n2 -- n
\c n = n1+n2;
end-prim
or somesuch. I wonder why I did not go for that at the time when we
switched to Forth. I guess that I did not want to change the input
file that much.
>not treat tab as special syntactic element
That's gone (IIRC it went away when I introduced the parentheses
around the stack effect). The empty line to terminate a primitive is
another thing that we probably would not do if we used the Forth
parser.
- 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 2009: http://www.euroforth.org/ef09/
Bernd Paysan
> Well, I don't understand the "LOGIC0 gnd0(gnd);" part, so I will just
> attempt to handle the assignments.
Good start - like all regexp-based code, it's easy to start, but
difficult to finish. Does your code work, when instances are split over
more than one line, or does \(.*?\) stop at the end of the line (in my
pcre manual, . doesn't match the newline by default, and therefore would
choke at all multi-line instances)? Would it handle x[2] as well as x2,
or does it choke on the regexp meta-characters - you use gsub, is the
expanded parameter you give it interpreted as string or as regexp?
I'm not good enough in Ruby to decide, but these where the first two
obvious problems the Perl program had back then. This problem really
requires a parser that can parse Verilog netlists, and the approach of
taking a few small examples is doomed - you are not applying it on small
example netlists in the end. You'll find that all characters are valid
in a Verilog symbol when it starts with \ - the termination letter then
is the black. A symbol like "\foo#(bar=11)[3] " is valid syntax, and
generated on synthesis e.g. for blocks with parameters and iterations,
and you are *not* allowed to replace the bar inside with something else,
when you are supposed to replace all other "bar"s by "foo".
Bernd Paysan
> Would it handle x[2] as well as
> x2, or does it choke on the regexp meta-characters - you use gsub, is
> the expanded parameter you give it interpreted as string or as regexp?
Ok, tested, and it failed as expected:
Try this data:
module foo(a, b, c);
input a;
input b;
output c;
wire x;
wire y;
wire [2:0] z;
assign x2 = z[2];
assign x = x2;
AND blabla(a, x, c);
OR2 \foo(x2) (b, y, z[2]);
OR3 foobar1(1'b0, b, y, z[2]);
OR3 foobar2(1'b0, b, y,
x2);
endmodule
outputs
Declarations:
[["input", "a"], ["input", "b"], ["output", "c"], ["wire", "x"],
["wire", "y"]]
Assignments:
{"x2"=>"x"}
Declarations taking assignments into account:
[["input", "a"], ["input", "b"], ["output", "c"], ["wire", "x"],
["wire", "y"]]
module foo(a, b, c);
input a;
input b;
output c;
wire x;
wire y;
AND blabla(a, x, c);
OR2
oo(x) (b, y, z[2]);
OR3 foobar1(1'b0, b, y, z[2]);
endmodule
It fails to replace the z[2] (even after fixing the bug that prevents it
from recognizing the assignment line with the z[2] in it), and it
completely swallows the multi-line foobar2 instance. It also swallows
the wire z bus declaration. It converts the \foo(x2) symbol into a
formfeed followed by oo(x).
I hope this illustrates my point - writing robust programs in regexp-
based scripting languages is far from trivial. If you want to process
something like a Verilog netlist, you first need to study the syntax of
that file format, and then you write a parser for that syntax. It is
more initial work, but since you are then prepared against all possible
valid inputs, you won't fail in a subtle way when your input suddenly
contains unexpected stuff.
Doug Hoffman
> On Dec 18, 12:48 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
>
> > But that doesn't mean Forth can't do web servers or GUIs.
>
> I really wish this newsgroup could get past this. Forth is a general-
> purpose programming language. It can do *anything* that is
> computable.
[ big snip ]
John,
That was a very clear, thoughtful, and coherent post that really nails
some important issues IMHO. Forth is (can be) what *we* make of it.
-Doug