Re: On modules

I always considered P::RD as a very good excercise for brain, for understanding parsing techniques in general: excellent documentation, excellent tuturial, very deep.
I never thought of practical use of it namely due to its inefficiency.

As another advice, as long as you're deep in parsers, you may consider looking into Haskell: as autrijus showed us all with his marvellous Pugs perl6 implementation, Haskell is extremely good at this.

But be warned: haskell is very hard to start playing with :)

Comment on Re: On modules

Replies are listed 'Best First'.
Re^2: On modules by samizdat (Vicar) on Aug 18, 2005 at 17:22 UTC
Actually, this latest version is written (shhh!) in Ruby. My group is collectively evaluating Ruby and looking for situations in which to test it. Since the SPICE parser is basically an exercise in logical abstraction, it was ideal. Haskell is free with FreeBSD, so I'll take a gander there, too. :) More tools and understanding are always Good Things. As 5mi11er suggested, my understanding of the problem space has evolved, and P::RD was an important step along that way.	[reply]
Re^2: On modules by samizdat (Vicar) on Aug 18, 2005 at 18:14 UTC
When I was a much younger programmer and had the time to delve into the details, I spent a lot of time reading books about LISP implementation and its underlying theory. Alonzo Church's Lambda Calculus was part of that research. I drove my math profs nuts because none of the rest of the class was prepared to go there, but they wanted to and did. We got a lot of interesting conversation accomplished, but the rest of the class was left very confused and the syllabus didn't get completed. ;) The nice thing about Perl (or Ruby, for that matter) is that one can do functional programming in it as well as imperative programming. One can look at objects, or one can look at the transition methods and data transformation and information flow. It's all a matter of the level of data abstraction that you model, and the actual language used is immaterial to the understanding embedded in your model. Haskell does seem to be a very clean way of expressing abstractions. Perhaps, for my parser/equation solver, it would be very suitable. The next stage of our project is to use my solver in conjuction with the analog simulators and statistical correlative software, and that's an iterative situation more suited to the imperative, input-driven nature of a general-purpose language. Looking at the statelessness of it (Haskell), I can see that that would help us were we to be looking at clustering the solution, but I think that there are enough equations to run with that any real cluster processor I could run this on would be happy solving the equations separately, as there are more equations to solve than there would likely be CPU nodes.	[reply]