Re: [dev] Lexers and parsers 2

2010-08-12 Thread Antoni Grzymala
Antoni Grzymala dixit (2010-08-12, 18:54): > > If you name it 'calc.noam' and type: > > > > echo '(+ 1 2 (+ 3 4) (+ 5 6) 7)' | calc.noam > > I'm sorry, but looking at the above I just couldn't notice the > Greenspun's Tenth Rule of Programming :) s/notice/not notice/ – or whatever, dunno. Whe

Re: [dev] Lexers and parsers 2

2010-08-12 Thread Antoni Grzymala
Maurí­cio CA dixit (2010-08-12, 00:10): > If you name it 'calc.noam' and type: > > echo '(+ 1 2 (+ 3 4) (+ 5 6) 7)' | calc.noam I'm sorry, but looking at the above I just couldn't notice the Greenspun's Tenth Rule of Programming :) -- [a]

[dev] Lexers and parsers 2

2010-08-11 Thread Maurí­cio CA
Hi, all, Some time ago, I asked your sugestions on what should be a parser we could use for shell scripting: http://lists.suckless.org/dev/0908/0822.html Now I would like to show you this tool I wrote. It does exactly what was discussed in those messages, i.e., it's something like yacc that c

Re: [dev] Lexers and parsers

2009-08-20 Thread Maurício
I'm not actually facing a very specific problem. (Well, I am, but it's easy to solve without a parser.) I just have seen many situations where such parser could be usefull. I'll try some examples. (1) You have a programming language you want to write a compiler for. You write a grammar for it. To

Re: [dev] Lexers and parsers

2009-08-20 Thread David Tweed
On Thu, Aug 20, 2009 at 1:37 PM, Kurt H Maier wrote: > On Thu, Aug 20, 2009 at 3:43 AM, David Tweed wrote: [snipped] > No matter how hard you try, I'm not going to turn this into a pissing > match.  Just keep in mind you're not the only one in the world -- or > even on this list -- who turns out m

Re: [dev] Lexers and parsers

2009-08-20 Thread pancake
Can you expose a practical example of this? Maybe taking use cases as design roots we can catch a better idea of how to implement this or how to solve the problem you are facing. --pancake Maurício wrote: (2/2 - I believe these messages didn't went to the list. Sorry if they actually did.) (.

Re: [dev] Lexers and parsers

2009-08-20 Thread Maurício
(2/2 - I believe these messages didn't went to the list. Sorry if they actually did.) (...) If you had such "shell yacc", how would you like it to be or behave? (...) So the important thing is being able to whip something up quickly; this isn't parser "specs" that's going to be carefully deve

Re: [dev] Lexers and parsers

2009-08-20 Thread Maurício
(1/2 - I believe these messages didn't went to the list. Sorry if they actually did.) I've always been a fan of using the unix text input and output to connect simple tools to achieve complex results, but I think there's a missing piece in the tool set: parsers. There are *many* ways you coul

Re: [dev] Lexers and parsers

2009-08-20 Thread Kurt H Maier
On Thu, Aug 20, 2009 at 3:43 AM, David Tweed wrote: > I'm comparing the viewpoint that you're going to whip up one-off > parsers by piping in inputs and patterns and piping out output versus > a setup where you assemble the input into a file, quite probably using > piping, and then run on that. IMO

Re: [dev] Lexers and parsers

2009-08-20 Thread David Tweed
On Wed, Aug 19, 2009 at 6:18 PM, Kurt H Maier wrote: > On Wed, Aug 19, 2009 at 11:49 AM, David Tweed wrote: >> what would be most effective in tracking >> down the inevitable problems when there's a bug in the user input >> and/or mismatched input, particularly if it happens in the middle of a >> p

Re: [dev] Lexers and parsers

2009-08-19 Thread carmen
> > what would be most effective in tracking > > down the inevitable problems when there's a bug in the user input > > and/or mismatched input, particularly if it happens in the middle of a > > pipe process: how are you going to report which part of the input i'm liking Parsec ( http://research.m

Re: [dev] Lexers and parsers

2009-08-19 Thread Kurt H Maier
On Wed, Aug 19, 2009 at 11:49 AM, David Tweed wrote: > what would be most effective in tracking > down the inevitable problems when there's a bug in the user input > and/or mismatched input, particularly if it happens in the middle of a > pipe process: how are you going to report which part of the

Re: [dev] Lexers and parsers

2009-08-19 Thread David Tweed
On Tue, Aug 18, 2009 at 1:27 AM, Maurício wrote: > I've been thinking on how to implement such tool. Since I'm > not a really good developer, I thought about asking people for > sugestions. If you had such "shell yacc", how would you like it > to be or behave? Would BNF be okay, or would you expect

Re: [dev] Lexers and parsers

2009-08-18 Thread pancake
ed to ease these tasks to the programmer. But yeah, it is a funny piece of code. But I was thinking in something written in less than 200LOC of C. Premysl Hruby wrote: On (18/08/09 13:31), pancake wrote: Date: Tue, 18 Aug 2009 13:31:59 +0200 From: pancake To: dev mail list Subject: Re: [d

Re: [dev] Lexers and parsers

2009-08-18 Thread Premysl Hruby
On (18/08/09 13:31), pancake wrote: > Date: Tue, 18 Aug 2009 13:31:59 +0200 > From: pancake > To: dev mail list > Subject: Re: [dev] Lexers and parsers > User-Agent: Thunderbird 2.0.0.22 (X11/20090608) > List-Id: dev mail list > > What about implementing a suckless fort

Re: [dev] Lexers and parsers

2009-08-18 Thread pancake
Jack Woehr wrote: Maurício wrote: If you had such "shell yacc", how would you like it to be or behave? Like Forth, the simplest parser ever invented. What about implementing a suckless forth? retroforth is minimal, but definetively not suckless ;) it can be useful for parsing code, scripting

Re: [dev] Lexers and parsers

2009-08-17 Thread Jack Woehr
Maurício wrote: If you had such "shell yacc", how would you like it to be or behave? Like Forth, the simplest parser ever invented. -- Jack J. Woehr# «'I know what "it" means well enough, when I find http://www.well.com/~jax # a thing,' said the Duck: 'it's generally a frog or http:

[dev] Lexers and parsers

2009-08-17 Thread Maurício
(I'm asking this here because you share my view on how software should be. Please warn me if this is off-topic.) I've always been a fan of using the unix text input and output to connect simple tools to achieve complex results, but I think there's a missing piece in the tool set: parsers. There