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
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]
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
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
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
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.)
(.
(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
(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
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
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
> > 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
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
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
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
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
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
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:
(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
18 matches
Mail list logo