Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #140809 > unrolled thread

Propagating results from callbacks?

Back to article view | Back to comp.lang.c

Contents

  Propagating results from callbacks? luser droog <luser.droog@gmail.com> - 2019-02-08 16:32 -0800
    Re: Propagating results from callbacks? luser droog <luser.droog@gmail.com> - 2019-02-08 17:08 -0800
      Re: Propagating results from callbacks? luser droog <luser.droog@gmail.com> - 2019-02-09 20:01 -0800
        Re: Propagating results from callbacks? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-10 15:21 +0000
          Re: Propagating results from callbacks? luser droog <luser.droog@gmail.com> - 2019-02-10 12:59 -0800
            Re: Propagating results from callbacks? luser droog <luser.droog@gmail.com> - 2019-02-10 13:49 -0800
              Re: Propagating results from callbacks? fir <profesor.fir@gmail.com> - 2019-02-10 14:14 -0800
                Re: Propagating results from callbacks? fir <profesor.fir@gmail.com> - 2019-02-12 00:31 -0800
                  Re: Propagating results from callbacks? fir <profesor.fir@gmail.com> - 2019-02-12 00:45 -0800
                  Re: Propagating results from callbacks? luser droog <luser.droog@gmail.com> - 2019-02-12 14:30 -0800
                    Re: Propagating results from callbacks? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-12 23:56 +0000
                      Re: Propagating results from callbacks? Reinhardt Behm <rbehm@hushmail.com> - 2019-02-13 12:54 +0800
                        Re: Propagating results from callbacks? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-13 11:16 +0000
                        Re: Propagating results from callbacks? Andrew Smallshaw <andrews@sdf.org> - 2019-02-13 15:41 +0000
                      Re: Propagating results from callbacks? fir <profesor.fir@gmail.com> - 2019-02-13 03:02 -0800
                        Re: Propagating results from callbacks? fir <profesor.fir@gmail.com> - 2019-02-13 03:30 -0800
                          Re: Propagating results from callbacks? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-13 11:48 +0000
                            Re: Propagating results from callbacks? fir <profesor.fir@gmail.com> - 2019-02-13 03:59 -0800
                              Re: Propagating results from callbacks? fir <profesor.fir@gmail.com> - 2019-02-13 04:10 -0800
                                Re: Propagating results from callbacks? fir <profesor.fir@gmail.com> - 2019-02-13 04:29 -0800
                                  Re: Propagating results from callbacks? fir <profesor.fir@gmail.com> - 2019-02-13 04:40 -0800
                            Re: Propagating results from callbacks? Bart <bc@freeuk.com> - 2019-02-13 12:08 +0000
                              Re: Propagating results from callbacks? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-13 14:40 +0000
                                Re: Propagating results from callbacks? Bart <bc@freeuk.com> - 2019-02-13 14:54 +0000
                                  Re: Propagating results from callbacks? David Brown <david.brown@hesbynett.no> - 2019-02-13 16:12 +0100
                                    Re: Propagating results from callbacks? fir <profesor.fir@gmail.com> - 2019-02-13 10:00 -0800
                                      Re: Propagating results from callbacks? fir <profesor.fir@gmail.com> - 2019-02-13 10:49 -0800
                                        Re: Propagating results from callbacks? fir <profesor.fir@gmail.com> - 2019-02-13 11:08 -0800
                                        Re: Propagating results from callbacks? Bart <bc@freeuk.com> - 2019-02-13 19:10 +0000
                                          Re: Propagating results from callbacks? fir <profesor.fir@gmail.com> - 2019-02-13 12:31 -0800
                                            Re: Propagating results from callbacks? fir <profesor.fir@gmail.com> - 2019-02-13 13:24 -0800
                                          Re: Propagating results from callbacks? fir <profesor.fir@gmail.com> - 2019-02-13 12:40 -0800
                                            Re: Propagating results from callbacks? fir <profesor.fir@gmail.com> - 2019-02-13 13:06 -0800
                                        Re: Propagating results from callbacks? David Brown <david.brown@hesbynett.no> - 2019-02-13 20:33 +0100
                                  Re: Propagating results from callbacks? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-13 15:49 +0000
            Re: Propagating results from callbacks? luser droog <luser.droog@gmail.com> - 2019-02-12 15:19 -0800
              Re: Propagating results from callbacks? luser droog <luser.droog@gmail.com> - 2019-02-12 19:02 -0800
                Re: Propagating results from callbacks? luser droog <luser.droog@gmail.com> - 2019-02-13 11:26 -0800
                  Re: Propagating results from callbacks? luser droog <luser.droog@gmail.com> - 2019-02-13 16:09 -0800
                    Re: Propagating results from callbacks? luser droog <luser.droog@gmail.com> - 2019-02-14 15:41 -0800
                      Re: Propagating results from callbacks? luser droog <luser.droog@gmail.com> - 2019-02-14 16:42 -0800
    Re: Propagating results from callbacks? fir <profesor.fir@gmail.com> - 2019-02-10 05:14 -0800

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#140924

W dniu środa, 13 lutego 2019 13:29:12 UTC+1 użytkownik fir napisał:
> W dniu środa, 13 lutego 2019 13:10:50 UTC+1 użytkownik fir napisał:
> > W dniu środa, 13 lutego 2019 12:59:49 UTC+1 użytkownik fir napisał:
> > > W dniu środa, 13 lutego 2019 12:48:21 UTC+1 użytkownik Ben Bacarisse napisał:
> > > > fir <profesor.fir@gmail.com> writes:
> > > > <cut>
> > > > > having separate minus would make things easier and clearer here (also
> > > > > this shorter minus you would be obliged always keep to number as its
> > > > > liek part of number even nearly like just a sign bit so you could only
> > > > > wrote "-23" but never "- 23")
> > > > 
> > > > It's never right to make it easy for the compiler writer at the expense
> > > > of the programmer.  And here there is /no/ cost at all to the compiler
> > > > writer.  The compiler must be able to parse '+42', '- + 42', '- -12' and
> > > > so on, so you save nothing in the parser logic by adding a special form
> > > > of negative literal.
> > > > 
> > > well, i dont know what you mean by 'save in parser logic' but i may sae something in gramatic - i mean
> > > 
> > > 1) you can maybe express more when using those 2 types of minuses
> > > 
> > one though imo important (if not very important) example is in expressions like
> > 
> > 23 21 -27 7 92 -92 0 76 -29 03 82
> > 
> > this is just a vector or just block of values, say bytes for example
> > 
> > you could for example use it to initialise some array, structure, pass it to function or something (many cases)
> > 
> > this form is nice as its pure, you dont need commas (,)
> > 
> > the problem is here if you use - like in above also just like subtraction operator this simply will not work (unles eventually adding some other rules like -3 is a part of value where - 3 is a subtraction)
> > 
> > this example as i said is in some way very important, and imo it would be better that it would just work (it is really needed imo it to be worked)
> > 
> > this workaround with adding spaces, or maybe 
> > 
> > 23 21 (-27) 7 92 (-92) 0 76 (-29) 03 82
> > 
> yet other option would be (just to mention)
> 
>  23 21 0-27 7 92 0-92 0 76 0-29 03 82
> 
> but as i said this feels like wourkarounds imo, those two above also have its consequences (one like steals syntax (?, well maybe not, but makes bloat) the second looks a bit archaic 
> 
> 
> this first with spaces would destroy (or disturb) present c rules
> 
> > will also work but it feels like workarounds

some remark:

if i would want to 'enable' those 'pure vectors' (pure vector expressions, without commas) and this is imo for sure (or almost for sure) a need then thiose 2 ways above (-92) and 0-92 would work, you would only want to get shorter minus to spare a bit of bloat (and get it eventually more proper way as i said)

those non-comma vectors are needed imo

[toc] | [prev] | [next] | [standalone]

#140918

On 13/02/2019 11:48, Ben Bacarisse wrote:
> fir <profesor.fir@gmail.com> writes:
> <cut>
>> having separate minus would make things easier and clearer here (also
>> this shorter minus you would be obliged always keep to number as its
>> liek part of number even nearly like just a sign bit so you could only
>> wrote "-23" but never "- 23")
> 
> It's never right to make it easy for the compiler writer at the expense
> of the programmer.  And here there is /no/ cost at all to the compiler
> writer.  The compiler must be able to parse '+42', '- + 42', '- -12' and
> so on, so you save nothing in the parser logic by adding a special form
> of negative literal.

Not with a language like C. With a simpler language you might to use 
integer constants without all the machinery that can reduce an 
arbitrarily complex constant expression.

In that case, you will expect to be able to write negative values.

This can be done by detecting the special case of a hyphen, at the start 
of a term, followed by an integer constant (necessarily positive, and 
this will likely be done in the parser rather than tokeniser).

You don't need a special character for the minus sign, unless you do 
want to do this within the tokeniser. Although this will make using the 
language harder if you have to stop every few seconds to enter a special 
unicode character.

But if that reduction machinery needs to be in place anyway, then as you 
say there is little point.

[toc] | [prev] | [next] | [standalone]

#140932

Bart <bc@freeuk.com> writes:

> On 13/02/2019 11:48, Ben Bacarisse wrote:
>> ... And here there is /no/ cost at all to the compiler
>> writer.  The compiler must be able to parse '+42', '- + 42', '- -12' and
>> so on, so you save nothing in the parser logic by adding a special form
>> of negative literal.
>
> Not with a language like C.

Yes, I was talking about C.  This is, after all, comp.lang.c.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#140934

On 13/02/2019 14:40, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
> 
>> On 13/02/2019 11:48, Ben Bacarisse wrote:
>>> ... And here there is /no/ cost at all to the compiler
>>> writer.  The compiler must be able to parse '+42', '- + 42', '- -12' and
>>> so on, so you save nothing in the parser logic by adding a special form
>>> of negative literal.
>>
>> Not with a language like C.
> 
> Yes, I was talking about C.  This is, after all, comp.lang.c.

But clearly fir wasn't.

[toc] | [prev] | [next] | [standalone]

#140936

On 13/02/2019 15:54, Bart wrote:
> On 13/02/2019 14:40, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 13/02/2019 11:48, Ben Bacarisse wrote:
>>>> ... And here there is /no/ cost at all to the compiler
>>>> writer.  The compiler must be able to parse '+42', '- + 42', '- -12'
>>>> and
>>>> so on, so you save nothing in the parser logic by adding a special form
>>>> of negative literal.
>>>
>>> Not with a language like C.
>>
>> Yes, I was talking about C.  This is, after all, comp.lang.c.
> 
> But clearly fir wasn't.
> 

When is anything fir writes "clear" ?

I was under the impression that he has been talking about C - or perhaps
his own "extended C" variant.

[toc] | [prev] | [next] | [standalone]

#140948

W dniu środa, 13 lutego 2019 16:12:47 UTC+1 użytkownik David Brown napisał:
> On 13/02/2019 15:54, Bart wrote:
> > On 13/02/2019 14:40, Ben Bacarisse wrote:
> >> Bart <bc@freeuk.com> writes:
> >>
> >>> On 13/02/2019 11:48, Ben Bacarisse wrote:
> >>>> ... And here there is /no/ cost at all to the compiler
> >>>> writer.  The compiler must be able to parse '+42', '- + 42', '- -12'
> >>>> and
> >>>> so on, so you save nothing in the parser logic by adding a special form
> >>>> of negative literal.
> >>>
> >>> Not with a language like C.
> >>
> >> Yes, I was talking about C.  This is, after all, comp.lang.c.
> > 
> > But clearly fir wasn't.
> > 
> 
> When is anything fir writes "clear" ?
> 
> I was under the impression that he has been talking about C - or perhaps
> his own "extended C" variant.

i am talking about 1) C 2) C spirit 2) future of C 

C spirit is like back behind C and C is simply only a branch of whole affair

[toc] | [prev] | [next] | [standalone]

#140951

W dniu środa, 13 lutego 2019 19:00:20 UTC+1 użytkownik fir napisał:
> W dniu środa, 13 lutego 2019 16:12:47 UTC+1 użytkownik David Brown napisał:
> > On 13/02/2019 15:54, Bart wrote:
> > > On 13/02/2019 14:40, Ben Bacarisse wrote:
> > >> Bart <bc@freeuk.com> writes:
> > >>
> > >>> On 13/02/2019 11:48, Ben Bacarisse wrote:
> > >>>> ... And here there is /no/ cost at all to the compiler
> > >>>> writer.  The compiler must be able to parse '+42', '- + 42', '- -12'
> > >>>> and
> > >>>> so on, so you save nothing in the parser logic by adding a special form
> > >>>> of negative literal.
> > >>>
> > >>> Not with a language like C.
> > >>
> > >> Yes, I was talking about C.  This is, after all, comp.lang.c.
> > > 
> > > But clearly fir wasn't.
> > > 
> > 
> > When is anything fir writes "clear" ?
> > 
> > I was under the impression that he has been talking about C - or perhaps
> > his own "extended C" variant.
> 
> i am talking about 1) C 2) C spirit 2) future of C 
> 
> C spirit is like back behind C and C is simply only a branch of whole affair

besides, if someone wanna proof that it is "on c" (though all this talk if it is on c or not is like donkey depressing bartc style whan he goes donkey) it is on some 'internals on c' (showing that "-" in c plays twofold role and there are some issues related to that - so it 
is about c

[toc] | [prev] | [next] | [standalone]

#140953

W dniu środa, 13 lutego 2019 19:49:54 UTC+1 użytkownik fir napisał:
> W dniu środa, 13 lutego 2019 19:00:20 UTC+1 użytkownik fir napisał:
> > W dniu środa, 13 lutego 2019 16:12:47 UTC+1 użytkownik David Brown napisał:
> > > On 13/02/2019 15:54, Bart wrote:
> > > > On 13/02/2019 14:40, Ben Bacarisse wrote:
> > > >> Bart <bc@freeuk.com> writes:
> > > >>
> > > >>> On 13/02/2019 11:48, Ben Bacarisse wrote:
> > > >>>> ... And here there is /no/ cost at all to the compiler
> > > >>>> writer.  The compiler must be able to parse '+42', '- + 42', '- -12'
> > > >>>> and
> > > >>>> so on, so you save nothing in the parser logic by adding a special form
> > > >>>> of negative literal.
> > > >>>
> > > >>> Not with a language like C.
> > > >>
> > > >> Yes, I was talking about C.  This is, after all, comp.lang.c.
> > > > 
> > > > But clearly fir wasn't.
> > > > 
> > > 
> > > When is anything fir writes "clear" ?
> > > 
> > > I was under the impression that he has been talking about C - or perhaps
> > > his own "extended C" variant.
> > 
> > i am talking about 1) C 2) C spirit 2) future of C 
> > 
> > C spirit is like back behind C and C is simply only a branch of whole affair
> 
> besides, if someone wanna proof that it is "on c" (though all this talk if it is on c or not is like donkey depressing bartc style whan he goes donkey) it is on some 'internals on c' (showing that "-" in c plays twofold role and there are some issues related to that - so it 
> is about c

not to say bartc is so bad but he simply goes donkey to much as on his possibilities which is depressing and loss of the level

[toc] | [prev] | [next] | [standalone]

#140954

On 13/02/2019 18:49, fir wrote:

> depressing bartc

Don't go there.

> it is on some 'internals on c' (showing that "-" in c plays twofold role

So does +

So does *

So does .

So does ,

So does :

So does &

  and there are some issues related to that - so it
> is about c
> 

If it's about C, then all these issues have been solved otherwise the 
language wouldn't work.

[toc] | [prev] | [next] | [standalone]

#140964

W dniu środa, 13 lutego 2019 20:10:57 UTC+1 użytkownik Bart napisał:
> On 13/02/2019 18:49, fir wrote:
> 
> > depressing bartc
> 
> Don't go there.
> 
lol, this is main issue whan talking to you.. youre very depressing, so i wouldnt say 'dont go anywhere but here' - one way to ignore you or try to mend you ;c watched by how you act the ignoring my grant me a better mood but its your loss imo (as you will loose chance to repair your usenet ways)

[toc] | [prev] | [next] | [standalone]

#140967

W dniu środa, 13 lutego 2019 21:31:38 UTC+1 użytkownik fir napisał:
> W dniu środa, 13 lutego 2019 20:10:57 UTC+1 użytkownik Bart napisał:
> > On 13/02/2019 18:49, fir wrote:
> > 
> > > depressing bartc
> > 
> > Don't go there.
> > 
> lol, this is main issue whan talking to you.. youre very depressing, so i wouldnt say 'dont go anywhere but here' - one way to ignore you or try to mend you ;c watched by how you act the ignoring my grant me a better mood but its your loss imo (as you will loose chance to repair your usenet ways)

otherwise you may be not mendable, just like hodgin

[toc] | [prev] | [next] | [standalone]

#140965

W dniu środa, 13 lutego 2019 20:10:57 UTC+1 użytkownik Bart napisał:
> 
> > it is on some 'internals on c' (showing that "-" in c plays twofold role
> 
> So does +
> 
> So does *
> 
> So does .
> 
> So does ,
> 
> So does :
> 
> So does &
> 

not really i see the difference in what i name in my compiler as atomistation, those above you will just atomise as operators when "-" may be both oparator sometimes and part of nomber in other cases, those above not works like that
(dots "." may be part of numbers or possibly some identifiers, but dont act like normal operators then, afiar  )

the differences here ar somewhat subtle and im not in a mood to focus on it so much to catch and explain more on this now..so maybe some other day ;c

[toc] | [prev] | [next] | [standalone]

#140966

W dniu środa, 13 lutego 2019 21:41:49 UTC+1 użytkownik fir napisał:
> W dniu środa, 13 lutego 2019 20:10:57 UTC+1 użytkownik Bart napisał:
> > 
> > > it is on some 'internals on c' (showing that "-" in c plays twofold role
> > 
> > So does +
> > 
> > So does *
> > 
> > So does .
> > 
> > So does ,
> > 
> > So does :
> > 
> > So does &
> > 
> 
> not really i see the difference in what i name in my compiler as atomistation, those above you will just atomise as operators when "-" may be both oparator sometimes and part of nomber in other cases, those above not works like that
> (dots "." may be part of numbers or possibly some identifiers, but dont act like normal operators then, afiar  )
> 
> the differences here ar somewhat subtle and im not in a mood to focus on it so much to catch and explain more on this now..so maybe some other day ;c

the difference may be that when doing that atomistations the rules in c was wuite simple (like label is always only alphanumeric and not diigit at first position, (positive) numbers are concise mostly digits though may be one dot, may be f or don end and so on)

this minus used for numbers i remember as only one and indeed somewhat special and unplesant complication as it may be "-       7" with amount of spaces and also dependant overally on context where it is present, rest of atomistation was far more strightforward (and it will also be strightforward if not duplicate minus sign in two separate roles)

[toc] | [prev] | [next] | [standalone]

#140957

On 13/02/2019 19:49, fir wrote:
> W dniu środa, 13 lutego 2019 19:00:20 UTC+1 użytkownik fir napisał:
>> W dniu środa, 13 lutego 2019 16:12:47 UTC+1 użytkownik David Brown napisał:
>>> On 13/02/2019 15:54, Bart wrote:
>>>> On 13/02/2019 14:40, Ben Bacarisse wrote:
>>>>> Bart <bc@freeuk.com> writes:
>>>>>
>>>>>> On 13/02/2019 11:48, Ben Bacarisse wrote:
>>>>>>> ... And here there is /no/ cost at all to the compiler
>>>>>>> writer.  The compiler must be able to parse '+42', '- + 42', '- -12'
>>>>>>> and
>>>>>>> so on, so you save nothing in the parser logic by adding a special form
>>>>>>> of negative literal.
>>>>>>
>>>>>> Not with a language like C.
>>>>>
>>>>> Yes, I was talking about C.  This is, after all, comp.lang.c.
>>>>
>>>> But clearly fir wasn't.
>>>>
>>>
>>> When is anything fir writes "clear" ?
>>>
>>> I was under the impression that he has been talking about C - or perhaps
>>> his own "extended C" variant.
>>
>> i am talking about 1) C 2) C spirit 2) future of C
>>
>> C spirit is like back behind C and C is simply only a branch of whole affair
> 
> besides, if someone wanna proof that it is "on c" (though all this talk if it is on c or not is like donkey depressing bartc style whan he goes donkey) it is on some 'internals on c' (showing that "-" in c plays twofold role and there are some issues related to that - so it
> is about c
> 

What can I say?  That makes it /perfectly/ clear what you are talking 
about.  I can't imagine how there could have been a confusion.

[toc] | [prev] | [next] | [standalone]

#140944

Bart <bc@freeuk.com> writes:

> On 13/02/2019 14:40, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 13/02/2019 11:48, Ben Bacarisse wrote:
>>>> ... And here there is /no/ cost at all to the compiler
>>>> writer.  The compiler must be able to parse '+42', '- + 42', '- -12' and
>>>> so on, so you save nothing in the parser logic by adding a special form
>>>> of negative literal.
>>>
>>> Not with a language like C.
>>
>> Yes, I was talking about C.  This is, after all, comp.lang.c.
>
> But clearly fir wasn't.

Really?  I find it hard to tell.  If he was not talking about C, my
remarks are irrelevant.  Other languages may well require the compiler
to make distinction that he seemed to find so awkward.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#140890

On Sunday, February 10, 2019 at 2:59:45 PM UTC-6, luser droog wrote:
> On Sunday, February 10, 2019 at 9:21:20 AM UTC-6, Ben Bacarisse wrote:
> > 
> > I wasn't able to comment because I was not sure what you were trying to
> > do.  And I still don't know how this should scale.  Are you trying to
> > implement parsing combinators in general, or is the goal to write a
> > parsing framework and you started looking at combinators as just one
> > possible technique?
> 
> Hmm. I'm experiencing some difficulty answering that question. I've been
> interested in parsing techniques for many years, and implemented a few
> in the context of writing interpreters. But I've been turning my attention
> more to compilers and despite the ubiquitous advice to use existing tools
> like flex and bison I really want to write it all myself.
> 
> Consequently I'm pretty fixated on the Parser Combinators because it seems
> to offer all the things I want: simple enough to implement by hand, 
> the grammar is expressed in regular code instead of an external file in
> a special format, -- I typed a comma but not thinking of a third reason --
> sigh.
> 
> So, I'm kind of at a halfway point. The combinators I've written seem to
> be working. They scan the string and return appropriate success or failure
> indications. The problem I'm having appears to be more in realm of API 
> design. How can I make my "parser action(parser,callback,user_pointer)"
> function more useful to the calling code.
> 
> I'm trying to write a regex package that uses the parsers to scan the
> regular expression string and also uses constructors to build a new
> parser to serve as the output FSA. This seemed to me like a good test 
> of the functionality of the API. 
> 

I went back to my dynamic scripted prototype (PostScript) and have made
some progress by having a list for each "level" of the grammar and the
action code can append its structure to the appropriate list. Operators
can fetch the last item, modify it, and append the replacement.

One of the hurdles I've encountered is somewhat "conceptual" in that
all the Parser Combinators I've written in either language are recursively
defined and thus cannot easily be printed out for inspection by naive means.
So I have to do a lot more "thinking" rather than just tweaking the
debugging output. Lol.

[toc] | [prev] | [next] | [standalone]

#140895

On Tuesday, February 12, 2019 at 5:19:16 PM UTC-6, luser droog wrote:
> On Sunday, February 10, 2019 at 2:59:45 PM UTC-6, luser droog wrote:
> > On Sunday, February 10, 2019 at 9:21:20 AM UTC-6, Ben Bacarisse wrote:
> > > 
> > > I wasn't able to comment because I was not sure what you were trying to
> > > do.  And I still don't know how this should scale.  Are you trying to
> > > implement parsing combinators in general, or is the goal to write a
> > > parsing framework and you started looking at combinators as just one
> > > possible technique?
> > 
> > Hmm. I'm experiencing some difficulty answering that question. I've been
> > interested in parsing techniques for many years, and implemented a few
> > in the context of writing interpreters. But I've been turning my attention
> > more to compilers and despite the ubiquitous advice to use existing tools
> > like flex and bison I really want to write it all myself.
> > 
> > Consequently I'm pretty fixated on the Parser Combinators because it seems
> > to offer all the things I want: simple enough to implement by hand, 
> > the grammar is expressed in regular code instead of an external file in
> > a special format, -- I typed a comma but not thinking of a third reason --
> > sigh.
> > 
> > So, I'm kind of at a halfway point. The combinators I've written seem to
> > be working. They scan the string and return appropriate success or failure
> > indications. The problem I'm having appears to be more in realm of API 
> > design. How can I make my "parser action(parser,callback,user_pointer)"
> > function more useful to the calling code.
> > 
> > I'm trying to write a regex package that uses the parsers to scan the
> > regular expression string and also uses constructors to build a new
> > parser to serve as the output FSA. This seemed to me like a good test 
> > of the functionality of the API. 
> > 
> 
> I went back to my dynamic scripted prototype (PostScript) and have made
> some progress by having a list for each "level" of the grammar and the
> action code can append its structure to the appropriate list. Operators
> can fetch the last item, modify it, and append the replacement.
> 

Another hurdle is when the grammar has a recursion.

The regex grammar I have working in postscript now is

  meta = [+*?]
  char = [^+*?.()]
  atom = ( '.' |
           '(' expression ')' |
           char )
  factor = atom meta?
  term   = factor +
  expression = term ( '|' term ) *

and I have callbacks hooked onto the 3 subcases of
atom, on meta, on term, and on expression. The atom
callbacks append to atom-list, term to term-list,
and expression to expr-list. If there are just single
"global" lists, then problems arise when the parser
goes into branches like the inner expression in atom.

At first I had the callback on term scoop up everything
in atom-list and append to term-list. But it could grab
the wrong things if there are several branches being 
worked on. I see 2 possible solutions. Either the 
quantifiers need to count how many sub-matches they find
and report this number to the callback so it can scoop
the right number of things; or, we need to introduce a
new "scope" at the recursive step where atom calls 
expression, ie. save all the lists and work on new lists
until the expression production returns.

I have the second solution working in PostScript. Just
wrapped the expression function with a "thunk" which
pushes a new dictionary and makes new empty lists.
I'm not sure which way will prove easier in C, or something
else entirely. Getting numbers out of the quantifiers
feels like a really useful thing to have.

[toc] | [prev] | [next] | [standalone]

#140955

On Tuesday, February 12, 2019 at 9:02:49 PM UTC-6, luser droog wrote:
> 
> Another hurdle is when the grammar has a recursion.
> 
> The regex grammar I have working in postscript now is
> 
>   meta = [+*?]
>   char = [^+*?.()]
>   atom = ( '.' |
>            '(' expression ')' |
>            char )
>   factor = atom meta?
>   term   = factor +
>   expression = term ( '|' term ) *
> 
> and I have callbacks hooked onto the 3 subcases of
> atom, on meta, on term, and on expression. The atom
> callbacks append to atom-list, term to term-list,
> and expression to expr-list. If there are just single
> "global" lists, then problems arise when the parser
> goes into branches like the inner expression in atom.
> 
> At first I had the callback on term scoop up everything
> in atom-list and append to term-list. But it could grab
> the wrong things if there are several branches being 
> worked on. I see 2 possible solutions. 

I've thought of a third way. The way the callback on meta
works is by taking one item off of the atom-list, transforming
it, and appending the replacement back on the atom-list.
So for something like collecting up all the terms in an
'expression', I could put a hook on the inner, repeated 'term'
and there should be exactly 2 things for it to combine.

I can do the same with the factors in a term if I rewrite 
term as

  term = factor ( factor )*

so that there's an inner, repeated one to hook onto.

[toc] | [prev] | [next] | [standalone]

#140970

On Wednesday, February 13, 2019 at 1:26:34 PM UTC-6, luser droog wrote:
> On Tuesday, February 12, 2019 at 9:02:49 PM UTC-6, luser droog wrote:
> > 
> > Another hurdle is when the grammar has a recursion.
> > 
> > The regex grammar I have working in postscript now is
> > 
> >   meta = [+*?]
> >   char = [^+*?.()]
> >   atom = ( '.' |
> >            '(' expression ')' |
> >            char )
> >   factor = atom meta?
> >   term   = factor +
> >   expression = term ( '|' term ) *
> > 
> > and I have callbacks hooked onto the 3 subcases of
> > atom, on meta, on term, and on expression. The atom
> > callbacks append to atom-list, term to term-list,
> > and expression to expr-list. If there are just single
> > "global" lists, then problems arise when the parser
> > goes into branches like the inner expression in atom.
> > 
> > At first I had the callback on term scoop up everything
> > in atom-list and append to term-list. But it could grab
> > the wrong things if there are several branches being 
> > worked on. I see 2 possible solutions. 
> 
> I've thought of a third way. The way the callback on meta
> works is by taking one item off of the atom-list, transforming
> it, and appending the replacement back on the atom-list.
> So for something like collecting up all the terms in an
> 'expression', I could put a hook on the inner, repeated 'term'
> and there should be exactly 2 things for it to combine.
> 
> I can do the same with the factors in a term if I rewrite 
> term as
> 
>   term = factor ( factor )*
> 
> so that there's an inner, repeated one to hook onto.

That did the trick! Here's what it looks like nice
Inspired by that song from the Mikado, I made a little list.


$ cat pcomb/pc4re.c
#include <stdio.h>
#include <stdlib.h>
#include "pc4re.h"

typedef struct plist *plist;
struct plist {
  parser it;
  plist next;
};
define_new_function_for_( plist )

int noprintf(char *f,...){return 0;}

void ppush( plist *pl, parser p ){ *pl = new_plist( (struct plist){ p, *pl } ); }
parser ppop( plist *pl ){ parser p; return  !*pl ? NULL : (p = (*pl)->it, *pl = (*pl)->next, p); }

void build_dot( void *p, char *s ){ plist *r = p; noprintf(".\n"); ppush( r, any() ); }
void build_char( void *p, char *s ){ plist *r = p; noprintf("%c\n", *s); ppush( r, term( *s ) ); }
void build_meta( void *p, char *s){ plist *r = p;
  noprintf("%c\n", *s);
  parser x = ppop( r );
  switch(*s){
  case '?': ppush( r, maybe( x ) ); break;
  case '+': ppush( r, some( x ) ); break;
  case '*': ppush( r, many( x ) ); break;
  }
}
void build_factors( void *p, char *s){
  plist *r = p;
  parser y = ppop( r );
  parser x = ppop( r );
  ppush( r , sequence( x, y ) );
}
void build_terms( void *p, char *s){
  plist *r = p;
  parser y = ppop( r );
  parser x = ppop( r );
  ppush( r, alternate( x, y ) );
}

parser regex( char *re ){
  static parser p = NULL;
  plist r = NULL;
  if(  !p  ){
    parser dot       = term('.');
    parser meta = char_class("?+*");
    parser or_  = term('|');
    parser character = any();
    parser atom = alternaten(2, (parser[]){
          action( dot, build_dot, &r),
          action( character, build_char, &r)
        });
    parser factor = sequence( atom, maybe( action( meta, build_meta, &r ) ) );
    parser term = sequence( factor, many( action( factor, build_factors, &r ) ) );
    parser expression = sequence( term, many( sequence( or_, action( term, build_terms, &r ) ) ) );
    p = expression;
  }
  return  parse( p, re ) ? noprintf("x\n"), r->it : 0;
}



The full set of files at the current commit can be downloaded with this link:
https://github.com/luser-dr00g/pcomb/archive/master.zip

[toc] | [prev] | [next] | [standalone]

#141055

On Wednesday, February 13, 2019 at 6:09:52 PM UTC-6, luser droog wrote:
> On Wednesday, February 13, 2019 at 1:26:34 PM UTC-6, luser droog wrote:
> > On Tuesday, February 12, 2019 at 9:02:49 PM UTC-6, luser droog wrote:
> > > 
> > > Another hurdle is when the grammar has a recursion.
> > > 
> > > The regex grammar I have working in postscript now is
> > > 
> > >   meta = [+*?]
> > >   char = [^+*?.()]
> > >   atom = ( '.' |
> > >            '(' expression ')' |
> > >            char )
> > >   factor = atom meta?
> > >   term   = factor +
> > >   expression = term ( '|' term ) *
> > > 
> > > and I have callbacks hooked onto the 3 subcases of
> > > atom, on meta, on term, and on expression. The atom
> > > callbacks append to atom-list, term to term-list,
> > > and expression to expr-list. If there are just single
> > > "global" lists, then problems arise when the parser
> > > goes into branches like the inner expression in atom.
> > > 
> > > At first I had the callback on term scoop up everything
> > > in atom-list and append to term-list. But it could grab
> > > the wrong things if there are several branches being 
> > > worked on. I see 2 possible solutions. 
> > 
> > I've thought of a third way. The way the callback on meta
> > works is by taking one item off of the atom-list, transforming
> > it, and appending the replacement back on the atom-list.
> > So for something like collecting up all the terms in an
> > 'expression', I could put a hook on the inner, repeated 'term'
> > and there should be exactly 2 things for it to combine.
> > 
> > I can do the same with the factors in a term if I rewrite 
> > term as
> > 
> >   term = factor ( factor )*
> > 
> > so that there's an inner, repeated one to hook onto.
> 
> That did the trick! Here's what it looks like nice
> Inspired by that song from the Mikado, I made a little list.
> 
> 

A few further problems arose but the new commit is now producing the
same (working) results as the PostScript prototype. Adding the 
recursive case to atom

        '(' expression ')'

meant forward defining the expression parser, so I needed a new
empty() function to allocate a struct parser which can be embedded
and have its contents filled in later.

Then, everything ran smoothly but gave failing results for all but
the simplest regexes I tried. So, the obvious difference was the PS
version had an inverse char class function and used it to exclude
all the meta chars and parens from matching in the character parser.

And as a final touch I capitalized all the named parsers like Atom, 
Dot, Expression, etc to make the code easier to read. Incidentally,
doing the same might have made the previous paragraph easier to read
lol.

In any case, a more reasonably working version is available at the
current commit, "Thursday Afternoon".

https://github.com/luser-dr00g/pcomb/archive/master.zip

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web