Andrew Haley <andrew29@[EMAIL PROTECTED]
> wrote:
> William James <w_a_x_man@[EMAIL PROTECTED]
> wrote:
> > Since this problem takes so little time for the computer to solve,
> > the amount of time needed to write the program is infinitely more
> > im****tant. Making the program as fast as possible is simply a
> > waste of human effort.
>
> > A shorter program:
>
> > $names = IO.read("names.txt").scan(/[A-Z]+/).sort
>
> > sum = 0
> > $names.each_with_index do |name,i|
> > sum += i.succ * name.split('').
> > inject(0){|n,c| n + c[0] - ?A + 1}
> > end
> > p sum
>
> Mmm, gforth doesn't like this. I can't think of any Forth system that
> would. You wouldn't be posting off-topic, would you?
For each repetitive sort of problem, we eventually build Forth tools
that handle the repetitive part and let us concentrate on the parts that
change. Ruby comes with a set of tools like that. So Ruby could give us
hints about the sort of tools that are useful for the sort of repetitive
problems that Ruby is good at. We might want to have the same tools, or
simplified factored fragments of them, or some different approach. Or we
couild decide that Forth is not good for that sort of thing and use some
language that already provides lots of comfy tools.
A while ago I was looking at how to build a particular string tool, and
he wrote some Ruby code that easily did what I wanted that tool to do,
and then he trivially implemented the tool too -- which looked useless
given the tools Ruby already had. So if I want to do things that
primarily involve manipulating strings then one approach would be to
learn Ruby and use that instead. Maybe it would be easier to adapt Ruby
for the things I use Forth for than the other way around, or find a way
to get them to cooperate closely and then I could use both languages at
the same time and debug my code in both together.
Oh well. We don't mind useing RPN, or a data stack, or weak typing. A
few limitations that don't actually limit us are no big problem. I had
the idea that we could handle strings with no garbage collection if we
used rubber-band memory and accepted a few limitations. The idea is, you
accept as many buffers as you want but at any given time you have one
single extendable buffer that can have an indefinite length. It
currently ends at HERE and the currently-executing routine can extend it
as desired. You can make as many scratch buffers as you want at or
beyond HERE and you can ALLOT the memory for them. You can call other
routines that treat one of your buffers as the one that has indefinite
length. At the end of your routine you can append data to the extendable
string, and -ALLOT to release your scratch buffers, and you're done.
It's a sort of string stack. There aren't any big complications unless
you need to extend two strings with the same routine.
I wrote up an example that used a simple version of this. It worked just
fine. The clf commenters said they didn't want to have to deal with that
limitation. They wanted some more complex string package that would be
easier to use. But you don't find out how easy the simple approach is
until you use it.
|
