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 1 of 3  [1] 2 3  Next page →

#140809 — Propagating results from callbacks?

Howdy gang. I've gotten myself into trouble/painted self into a
corner with some (relatively) simple C code. 

I'm trying to make a regular expression input for my parser 
combinators. That is, I'm trying to write a function which 
takes a string as input and interprets the regular expression
contained in the string and yields a parser that performs the
same semantics as the regular expression when run.

To start, here's the API of the parser combinators.

$ cat pc4.h
typedef struct parser *parser;
typedef struct result *result;
typedef result (*handler)( parser, char *);
typedef void (*callback)( void *payload, char *match );

struct parser { 
  handler test; 
  parser a, b; 
  int c; 
  callback f;
  void *payload;
}; 

struct result { 
  result next; 
  int length_matched; 
}; 

#define Types(_) \
  _(parser)      \
  _(result)
#define new_function_for_(type) \
  type new_##type ( struct type input );
Types( new_function_for_ )
#undef new_function_for_

// Parsing actions return result lists
result parse( parser p, char *input );


// Constructors build parsers
parser fails();
parser succeeds();
parser term( int c );
parser alternate( parser a, parser b );
parser sequence( parser a, parser b );
parser char_class( char *str );
parser string( char *str );
parser maybe( parser a );
parser many( parser a );
parser some( parser a );
parser sequencen( int n, parser *pp );
parser alternaten( int n, parser *pp );

parser action( parser a, callback f, void *payload );



So, using action() lets me attach a callback to the parser tree 
which will receive the matching string and the extra void* when
that parser is run and matches.

Keeping it simple for now, I want to handle just the simplest
elements in the regex: literal characters and dot '.'.

So, the problem code is the following. Specifically I don't see
any good way to returns the results of these callbacks. Maybe 
I'm "trying too hard" or just in the wrong head space. But any
suggestions appreciated. 


void build_dot( void *p, char *s ){
  parser x = any();
  // return x?
}

void build_char( void *p, char *s ){
  parser x = term( *s );
  // return x?
}

parser regex( char *re ){
  static parser p = NULL;
  if(  !p  )
    p = alternaten(2, (parser[]){
          action( term( '.' ), build_dot, NULL),
          action( any(), build_char, NULL)
        });
  return  parse( p, re );
}


So that's the problem spot isolated.  Here is the
full file. The regex() function itself is attempting
to return the wrong pointer type, but the correct thing
to do there is the same question again: how can I arrange
to propagate the results from the callbacks?


$ cat pc4.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#include "pc4.h"

result parse_fail( parser p, char *input );
result parse_succeed( parser p, char *input );
result parse_term( parser p, char *input );
result parse_any( parser p, char *input );
result parse_alternate( parser p, char *input );
result parse_sequence( parser p, char *input );

result last_result( result r );
static void amend_lengths( result r, int length );
static result parse_sequence_next( result r, parser p, char *input );



#define new_function_for_(type)                            \
  type new_##type ( struct type input ){                   \
    type local = calloc( sizeof *local, 1 );               \
    return  local  ?  ( *local = input ), local  :  local; \
  }

Types( new_function_for_ )


/* entry point to the parser tree */
result parse( parser p, char *input ){
  return  p->test( p, input );
}



/* handlers for the nodes */

/* * leaf nodes */

result parse_fail( parser p, char *input ){
  return  NULL;
}

result parse_succeed( parser p, char *input ){ 
  return  new_result( (struct result){ .next = NULL, .length_matched = 0 } );
}

result parse_term( parser p, char *input ){ 
  return  *input == p->c  ?
    new_result( (struct result){ .next = NULL, .length_matched = 1 } )  :  NULL; 
} 

result parse_any( parser p, char *input ){
  return  new_result( (struct result){ .next = NULL, .length_matched = 1 } );
}

/* * branch nodes */
const int short_circuit_alternate = 1;

/* append to the results of the left branch
   the results of the right branch */
result parse_alternate( parser p, char *input ){ 
  result r = parse( p->a, input ); 
  if(  r  )
    return  (short_circuit_alternate ? 0 : (last_result( r )->next = parse( p->b, input ))),
            r; 
  else
    return  parse( p->b, input ); 
}

/* call left branch, process any results */
result parse_sequence( parser p, char *input ){ 
  return  parse_sequence_next( parse( p->a, input ), p, input ); 
} 

/* for each result of left branch, offset input by length matched,
   and try right branch, adding the left length to any results of 
   right branch */
static result parse_sequence_next( result ra, parser p, char *input ){ 
  if(  ! ra  )  return  NULL; 
  result rb = parse( p->b, input + ra->length_matched ); 
  if(  rb  ){ 
    amend_lengths( rb, ra->length_matched ); 
    return  last_result( rb )->next = parse_sequence_next( ra->next, p, input ), rb; 
  } else  return  parse_sequence_next( ra->next, p, input ); 
} 


result last_result( result r ){
  return  r->next  ?  last_result( r->next )  :  r;
}

static void amend_lengths( result r, int length ){ 
  if(  r  )  r->length_matched += length; 
  if(  r->next  )  amend_lengths( r->next, length ); 
} 


/* constructors */

/* *  "axioms" */
parser fails(){     return  new_parser( (struct parser){ .test = parse_fail    } ); }
parser succeeds(){  return  new_parser( (struct parser){ .test = parse_succeed } ); }

parser term( int c ){
  return  new_parser( (struct parser){ .test = parse_term, .c = c } );
}

parser any(){
  return  new_parser( (struct parser){ .test = parse_any } );
}

parser alternate( parser a, parser b ){
  return  new_parser( (struct parser){ .test = parse_alternate, .a = a, .b = b } );
}

parser sequence( parser a, parser b ){
  return  new_parser( (struct parser){ .test = parse_sequence, .a = a, .b = b } );
}

/* *  "theorems" */
parser char_class( char *str ){
  return  *str  ?  alternate( term( *str ), char_class( str + 1 ) )  :  fails();
}

parser string( char *str ){
  return  *str  ?  sequence( term( *str ), string( str + 1 ) )  :  succeeds();
}

parser maybe( parser a ){
  return  new_parser( (struct parser){ .test = parse_alternate, .a = a, .b = succeeds() } );
}

parser many( parser a ){
  parser q = new_parser( (struct parser){ .test = parse_sequence, .a = a } );
  parser r = new_parser( (struct parser){ .test = parse_alternate, .a = q, .b = succeeds() } );
  q->b = r;
  return r;
}

parser some( parser a ){
  parser q = new_parser( (struct parser){ .test = parse_sequence, .a = a } );
  parser r = new_parser( (struct parser){ .test = parse_alternate, .a = q, .b = succeeds() } );
  q->b = r;
  return q;
}

parser sequencen( int n, parser *pp ){
  return  n  ?  sequence( *pp, sequencen( n-1, pp+1 ) )
             :  succeeds();
}


parser alternaten( int n, parser *pp ){
  return  n  ?  alternate( *pp, alternaten( n-1, pp+1 ) )
             :  fails();
}

//char *strndup(char*s,size_t n){char *r = malloc(n+1); if (r) memcpy(r,s,n),r[n]=0; return r;}

result parse_action( parser p, char *input ){
  result r = parse( p->a, input );
  if (r) p->f( p->payload, strndup( input, r->length_matched ) );
  return  r;
}

parser action( parser pa, callback f, void *payload ){
  return  new_parser( (struct parser){ .test = parse_action, .a = pa, .f = f, .payload = payload } );
}



void build_dot( void *p, char *s ){
  parser x = any();
  // return x?
}

void build_char( void *p, char *s ){
  parser x = term( *s );
  // return x?
}

parser regex( char *re ){
  static parser p = NULL;
  if(  !p  )
    p = alternaten(2, (parser[]){
          action( term( '.' ), build_dot, NULL),
          action( any(), build_char, NULL)
        });
  return  parse( p, re );
}

[toc] | [next] | [standalone]

#140811

On Friday, February 8, 2019 at 6:32:48 PM UTC-6, luser droog wrote:
> Howdy gang. I've gotten myself into trouble/painted self into a
> corner with some (relatively) simple C code. 
> 
> I'm trying to make a regular expression input for my parser 
> combinators. That is, I'm trying to write a function which 
> takes a string as input and interprets the regular expression
> contained in the string and yields a parser that performs the
> same semantics as the regular expression when run.
> 
> To start, here's the API of the parser combinators.
> 
[snip]
> 
> 
> So, using action() lets me attach a callback to the parser tree 
> which will receive the matching string and the extra void* when
> that parser is run and matches.
> 
> Keeping it simple for now, I want to handle just the simplest
> elements in the regex: literal characters and dot '.'.
> 
> So, the problem code is the following. Specifically I don't see
> any good way to returns the results of these callbacks. Maybe 
> I'm "trying too hard" or just in the wrong head space. But any
> suggestions appreciated. 
> 
[snip]
> 
> So that's the problem spot isolated.  Here is the
> full file. The regex() function itself is attempting
> to return the wrong pointer type, but the correct thing
> to do there is the same question again: how can I arrange
> to propagate the results from the callbacks?
> 
[snip]
> 
> 
> void build_dot( void *p, char *s ){
>   parser x = any();
>   // return x?
> }
> 
> void build_char( void *p, char *s ){
>   parser x = term( *s );
>   // return x?
> }
> 
> parser regex( char *re ){
>   static parser p = NULL;
>   if(  !p  )
>     p = alternaten(2, (parser[]){
>           action( term( '.' ), build_dot, NULL),
>           action( any(), build_char, NULL)
>         });
>   return  parse( p, re );
> }

Thanks, Duckies! I think I figured it out.
I think this should do it. But it's pretty ugly IMO.

void build_dot( void *p, char *s ){
  parser x = any();
  parser *r = p;
  *r = x;
  // return x?
}

void build_char( void *p, char *s ){
  parser x = term( *s );
  parser *r = p;
  *r = x;
  // return x?
}

parser regex( char *re ){
  static parser p = NULL;
  static parser r;
  if(  !p  )
    p = alternaten(2, (parser[]){
          action( term( '.' ), build_dot, &r),
          action( any(), build_char, &r)
        });
  return  parse( p, re ), r;
}

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

#140825

On Friday, February 8, 2019 at 7:08:15 PM UTC-6, luser droog wrote:

> Thanks, Duckies! I think I figured it out.
> I think this should do it. But it's pretty ugly IMO.
> 
> void build_dot( void *p, char *s ){
>   parser x = any();
>   parser *r = p;
>   *r = x;
>   // return x?
> }
> 
> void build_char( void *p, char *s ){
>   parser x = term( *s );
>   parser *r = p;
>   *r = x;
>   // return x?
> }
> 
> parser regex( char *re ){
>   static parser p = NULL;
>   static parser r;
>   if(  !p  )
>     p = alternaten(2, (parser[]){
>           action( term( '.' ), build_dot, &r),
>           action( any(), build_char, &r)
>         });
>   return  parse( p, re ), r;
> }


I still wouldn't mind other points of view. This seems like
a pale victory so far. It isn't clear to me how to scale it.

I've looked at bit at Tree Meta for inspiration. In Tree Meta
all tokens when parsed are pushed onto a stack. Then the 
larger grammatical parts pop the parts they need, build a
tree node and push the node.

Or I could somehow collect the results and add it to my result
struct. This also seems to need some kind of annotations to 
indicate which parser nodes are tokens and which are larger
grammatical constructs which should become nodes of the AST.

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

#140828

luser droog <luser.droog@gmail.com> writes:
<snip>
> I still wouldn't mind other points of view. This seems like
> a pale victory so far. It isn't clear to me how to scale it.

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?

> I've looked at bit at Tree Meta for inspiration. In Tree Meta
> all tokens when parsed are pushed onto a stack. Then the 
> larger grammatical parts pop the parts they need, build a
> tree node and push the node.

That sounds like the classic shift/reduce parsing algorithm with not
much in common with the combinator technique.  Is Tree Meta the old
(1960s) TREE-META compiler-compiler?

> Or I could somehow collect the results and add it to my result
> struct. This also seems to need some kind of annotations to 
> indicate which parser nodes are tokens and which are larger
> grammatical constructs which should become nodes of the AST.

Combinator parsers are usually lazy.  That's how you get the
backtracking.  I've not studied your C code, but in general you'll
probably either need some sort of list result, or better yet, a "thunk"
implemented in C.

(Sorry that this is all so vague, but it's a big topic and I don't know
where you want to go with it.)

-- 
Ben.

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

#140838

On Sunday, February 10, 2019 at 9:21:20 AM UTC-6, Ben Bacarisse wrote:
> luser droog <luser.droog@gmail.com> writes:
> <snip>
> > I still wouldn't mind other points of view. This seems like
> > a pale victory so far. It isn't clear to me how to scale it.
> 
> 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've looked at bit at Tree Meta for inspiration. In Tree Meta
> > all tokens when parsed are pushed onto a stack. Then the 
> > larger grammatical parts pop the parts they need, build a
> > tree node and push the node.
> 
> That sounds like the classic shift/reduce parsing algorithm with not
> much in common with the combinator technique.  Is Tree Meta the old
> (1960s) TREE-META compiler-compiler?

Yes, exactly, the one used by Doug Engelbart, extended from the earlier
work of Val Shorre. 

Hmm. I'm wonder whether it would be nicer/easier to use the PCs just
for lexing and maybe shift/reduce or other algo for actual parsing.

> > Or I could somehow collect the results and add it to my result
> > struct. This also seems to need some kind of annotations to 
> > indicate which parser nodes are tokens and which are larger
> > grammatical constructs which should become nodes of the AST.
> 
> Combinator parsers are usually lazy.  That's how you get the
> backtracking.  I've not studied your C code, but in general you'll
> probably either need some sort of list result, or better yet, a "thunk"
> implemented in C.
> 
> (Sorry that this is all so vague, but it's a big topic and I don't know
> where you want to go with it.)

Many possible goals pop into my imagination when I think about this
stuff: a short, readable my_scanf() function without UB on integer
overflow; portable, simple regex powers, maybe an implementation of
grep(1) in <100 lines; a one-file compiler for the language specified
in the 1974 C manual (pre K&R); and of course, step 3 is profit!

Does all that make sense? I have some parser combinators. I have an
action() function which lets me attach additional code to be executed
at certain points in the parsing process. But the function I've provided
doesn't seem to offer enough features for my "client" code, the regex
builder. I probably ought to have shown the regex stuff in a separate
file to better clarify the API boundary. It's a somewhat artificial
boundary of course, since I'm on both sides of the line. But,.. I feel
like I'm explaining in circles. 

I've tried to write the code so that it doesn't require comments, but
if any readers wish a more heavily commented version of the code I can
do that. The X Macros are possibly unnecessary for only two types but
I'm probably going to keep on using X Macros gratuitously. I don't have
any strong forces acting to reel it in.

ehrm. I've run out of things to say so I'll stop.

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

#140840

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:
> > (Sorry that this is all so vague, but it's a big topic and I don't know
> > where you want to go with it.)
> 
> Many possible goals pop into my imagination when I think about this
> stuff: a short, readable my_scanf() function without UB on integer
> overflow; portable, simple regex powers, maybe an implementation of
> grep(1) in <100 lines; a one-file compiler for the language specified
> in the 1974 C manual (pre K&R); and of course, step 3 is profit!

Also, having regex engines and the ability to attach code to it is
almost the power of awk. For a simple compiler, my idea is that you
can attach code to the parser to yield a syntax directed compiler.
And all with a fairly small amount of code. Gotchas and sharp edges
aplenty, but power, raw savage manipulative POWER! HAHA!

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

#140842

W dniu niedziela, 10 lutego 2019 22:49:44 UTC+1 użytkownik luser droog napisał:
> 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:
> > > (Sorry that this is all so vague, but it's a big topic and I don't know
> > > where you want to go with it.)
> > 
> > Many possible goals pop into my imagination when I think about this
> > stuff: a short, readable my_scanf() function without UB on integer
> > overflow; portable, simple regex powers, maybe an implementation of
> > grep(1) in <100 lines; a one-file compiler for the language specified
> > in the 1974 C manual (pre K&R); and of course, step 3 is profit!
> 
> Also, having regex engines and the ability to attach code to it is
> almost the power of awk. For a simple compiler, my idea is that you
> can attach code to the parser to yield a syntax directed compiler.
> And all with a fairly small amount of code. Gotchas and sharp edges
> aplenty, but power, raw savage manipulative POWER! HAHA!

parsing is probably the least interesting thing in writing compiler (more interesting would be collecting thiose working data and buiding assembly out of it) - im not sure as i only get 2k lines of my fury compiler written

to be honest most annoying thing when writing c sompiler i found that sily thing: format of writing negative numbers as -321 and so on i mean using "-" sign in souble role as a part of integer value and as an proper operator, this is real annoying (or at least seemed annoying to me) (to this extent i think if to not redefine it)

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

#140867

W dniu niedziela, 10 lutego 2019 23:14:21 UTC+1 użytkownik fir napisał:
> W dniu niedziela, 10 lutego 2019 22:49:44 UTC+1 użytkownik luser droog napisał:
> > 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:
> > > > (Sorry that this is all so vague, but it's a big topic and I don't know
> > > > where you want to go with it.)
> > > 
> > > Many possible goals pop into my imagination when I think about this
> > > stuff: a short, readable my_scanf() function without UB on integer
> > > overflow; portable, simple regex powers, maybe an implementation of
> > > grep(1) in <100 lines; a one-file compiler for the language specified
> > > in the 1974 C manual (pre K&R); and of course, step 3 is profit!
> > 
> > Also, having regex engines and the ability to attach code to it is
> > almost the power of awk. For a simple compiler, my idea is that you
> > can attach code to the parser to yield a syntax directed compiler.
> > And all with a fairly small amount of code. Gotchas and sharp edges
> > aplenty, but power, raw savage manipulative POWER! HAHA!
> 
> parsing is probably the least interesting thing in writing compiler (more interesting would be collecting thiose working data and buiding assembly out of it) - im not sure as i only get 2k lines of my fury compiler written
> 
> to be honest most annoying thing when writing c sompiler i found that sily thing: format of writing negative numbers as -321 and so on i mean using "-" sign in souble role as a part of integer value and as an proper operator, this is real annoying (or at least seemed annoying to me) (to this extent i think if to not redefine it)

i would probably introduce "shorter minus" sign, that would be used to note negative number, and would look like -2
but being helf short and be to rightside

what if i want introduce this kind of sign in my language? is that in unicode and i just can write unicode texts or there is empty space in unicode i can use, or what?

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

#140868

W dniu wtorek, 12 lutego 2019 09:32:06 UTC+1 użytkownik fir napisał:
> W dniu niedziela, 10 lutego 2019 23:14:21 UTC+1 użytkownik fir napisał:
> > W dniu niedziela, 10 lutego 2019 22:49:44 UTC+1 użytkownik luser droog napisał:
> > > 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:
> > > > > (Sorry that this is all so vague, but it's a big topic and I don't know
> > > > > where you want to go with it.)
> > > > 
> > > > Many possible goals pop into my imagination when I think about this
> > > > stuff: a short, readable my_scanf() function without UB on integer
> > > > overflow; portable, simple regex powers, maybe an implementation of
> > > > grep(1) in <100 lines; a one-file compiler for the language specified
> > > > in the 1974 C manual (pre K&R); and of course, step 3 is profit!
> > > 
> > > Also, having regex engines and the ability to attach code to it is
> > > almost the power of awk. For a simple compiler, my idea is that you
> > > can attach code to the parser to yield a syntax directed compiler.
> > > And all with a fairly small amount of code. Gotchas and sharp edges
> > > aplenty, but power, raw savage manipulative POWER! HAHA!
> > 
> > parsing is probably the least interesting thing in writing compiler (more interesting would be collecting thiose working data and buiding assembly out of it) - im not sure as i only get 2k lines of my fury compiler written
> > 
> > to be honest most annoying thing when writing c sompiler i found that sily thing: format of writing negative numbers as -321 and so on i mean using "-" sign in souble role as a part of integer value and as an proper operator, this is real annoying (or at least seemed annoying to me) (to this extent i think if to not redefine it)
> 
> i would probably introduce "shorter minus" sign, that would be used to note negative number, and would look like -2
> but being helf short and be to rightside
> 
> what if i want introduce this kind of sign in my language? is that in unicode and i just can write unicode texts or there is empty space in unicode i can use, or what?

i could also add a method for inserting more characters from keyboard, its like hold left control (or some other like shift) and press like 6 to 'toggle' in set of couple of characters under '6' family (it may be like 3 of them in the begining and maybe more like 10 in future)

i would just like to gave more usable 'punctuation' signs in code character set

short minus would be my first proposition, but yu eventually would find more

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

#140885

On Tuesday, February 12, 2019 at 2:32:06 AM UTC-6, fir wrote:
> W dniu niedziela, 10 lutego 2019 23:14:21 UTC+1 użytkownik fir napisał:
> > W dniu niedziela, 10 lutego 2019 22:49:44 UTC+1 użytkownik luser droog napisał:
> > > 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:
> > > > > (Sorry that this is all so vague, but it's a big topic and I don't know
> > > > > where you want to go with it.)
> > > > 
> > > > Many possible goals pop into my imagination when I think about this
> > > > stuff: a short, readable my_scanf() function without UB on integer
> > > > overflow; portable, simple regex powers, maybe an implementation of
> > > > grep(1) in <100 lines; a one-file compiler for the language specified
> > > > in the 1974 C manual (pre K&R); and of course, step 3 is profit!
> > > 
> > > Also, having regex engines and the ability to attach code to it is
> > > almost the power of awk. For a simple compiler, my idea is that you
> > > can attach code to the parser to yield a syntax directed compiler.
> > > And all with a fairly small amount of code. Gotchas and sharp edges
> > > aplenty, but power, raw savage manipulative POWER! HAHA!
> > 
> > parsing is probably the least interesting thing in writing compiler (more interesting would be collecting thiose working data and buiding assembly out of it) - im not sure as i only get 2k lines of my fury compiler written
> > 
> > to be honest most annoying thing when writing c sompiler i found that sily thing: format of writing negative numbers as -321 and so on i mean using "-" sign in souble role as a part of integer value and as an proper operator, this is real annoying (or at least seemed annoying to me) (to this extent i think if to not redefine it)
> 
> i would probably introduce "shorter minus" sign, that would be used to note negative number, and would look like -2
> but being helf short and be to rightside
> 
> what if i want introduce this kind of sign in my language? is that in unicode and i just can write unicode texts or there is empty space in unicode i can use, or what?

There's probably something like that somewhere in Unicode. There's probably
a way of requesting new glyphs. But you could also use the existing practice
of APL which has 2 minus signs. Regular minus - is the function. High Minus
¯ is the decorator for negative numbers.

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

#140893

luser droog <luser.droog@gmail.com> writes:

> On Tuesday, February 12, 2019 at 2:32:06 AM UTC-6, fir wrote:
>> W dniu niedziela, 10 lutego 2019 23:14:21 UTC+1 użytkownik fir napisał:
<cut>
>> > to be honest most annoying thing when writing c sompiler i found
>> > that sily thing: format of writing negative numbers as -321 and so
>> > on i mean using "-" sign in souble role as a part of integer value
>> > and as an proper operator, this is real annoying (or at least
>> > seemed annoying to me) (to this extent i think if to not redefine
>> > it)

You don't need to worry about that because, in C, '-' is never part of
an integer constant, it is always an operator.
 
>> i would probably introduce "shorter minus" sign, that would be used
>> to note negative number, and would look like -2 but being helf short
>> and be to rightside
>> 
>> what if i want introduce this kind of sign in my language? is that in
>> unicode and i just can write unicode texts or there is empty space in
>> unicode i can use, or what?
>
> There's probably something like that somewhere in Unicode.

Unicode has several dashes of different length and, more significantly,
distinguishes between the hyphen: '-' and the minus sign: '−'.

> There's probably a way of requesting new glyphs. But you could also
> use the existing practice of APL which has 2 minus signs. Regular
> minus - is the function. High Minus ¯ is the decorator for negative
> numbers.

This is a much better idea because it's more obvious.  Having syntax
errors caused by using the wrong length dash is just asking for trouble.
But then there the original problem is non-existent because the token
'-' is always an operator in C and is never part of an integer constant.

-- 
Ben.

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

#140898

AT Wednesday 13 February 2019 07:56, Ben Bacarisse wrote:

> luser droog <luser.droog@gmail.com> writes:
> 
>> On Tuesday, February 12, 2019 at 2:32:06 AM UTC-6, fir wrote:
>>> W dniu niedziela, 10 lutego 2019 23:14:21 UTC+1 użytkownik fir napisał:
> <cut>
>>> > to be honest most annoying thing when writing c sompiler i found
>>> > that sily thing: format of writing negative numbers as -321 and so
>>> > on i mean using "-" sign in souble role as a part of integer value
>>> > and as an proper operator, this is real annoying (or at least
>>> > seemed annoying to me) (to this extent i think if to not redefine
>>> > it)
> 
> You don't need to worry about that because, in C, '-' is never part of
> an integer constant, it is always an operator.
>  
>>> i would probably introduce "shorter minus" sign, that would be used
>>> to note negative number, and would look like -2 but being helf short
>>> and be to rightside
>>> 
>>> what if i want introduce this kind of sign in my language? is that in
>>> unicode and i just can write unicode texts or there is empty space in
>>> unicode i can use, or what?
>>
>> There's probably something like that somewhere in Unicode.
> 
> Unicode has several dashes of different length and, more significantly,
> distinguishes between the hyphen: '-' and the minus sign: '−'.
> 
>> There's probably a way of requesting new glyphs. But you could also
>> use the existing practice of APL which has 2 minus signs. Regular
>> minus - is the function. High Minus ¯ is the decorator for negative
>> numbers.
> 
> This is a much better idea because it's more obvious.  Having syntax
> errors caused by using the wrong length dash is just asking for trouble.
> But then there the original problem is non-existent because the token
> '-' is always an operator in C and is never part of an integer constant.

And what does the poor human reader of the code do?
 
-- 
Reinhardt

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

#140909

Reinhardt Behm <rbehm@hushmail.com> writes:

> AT Wednesday 13 February 2019 07:56, Ben Bacarisse wrote:
>
>> luser droog <luser.droog@gmail.com> writes:
>> 
>>> On Tuesday, February 12, 2019 at 2:32:06 AM UTC-6, fir wrote:
>>>> W dniu niedziela, 10 lutego 2019 23:14:21 UTC+1 użytkownik fir napisał:
>> <cut>
>>>> > to be honest most annoying thing when writing c sompiler i found
>>>> > that sily thing: format of writing negative numbers as -321 and so
>>>> > on i mean using "-" sign in souble role as a part of integer value
>>>> > and as an proper operator, this is real annoying (or at least
>>>> > seemed annoying to me) (to this extent i think if to not redefine
>>>> > it)
>> 
>> You don't need to worry about that because, in C, '-' is never part of
>> an integer constant, it is always an operator.
>>  
>>>> i would probably introduce "shorter minus" sign, that would be used
>>>> to note negative number, and would look like -2 but being helf short
>>>> and be to rightside
>>>> 
>>>> what if i want introduce this kind of sign in my language? is that in
>>>> unicode and i just can write unicode texts or there is empty space in
>>>> unicode i can use, or what?
>>>
>>> There's probably something like that somewhere in Unicode.
>> 
>> Unicode has several dashes of different length and, more significantly,
>> distinguishes between the hyphen: '-' and the minus sign: '−'.
>> 
>>> There's probably a way of requesting new glyphs. But you could also
>>> use the existing practice of APL which has 2 minus signs. Regular
>>> minus - is the function. High Minus ¯ is the decorator for negative
>>> numbers.
>> 
>> This is a much better idea because it's more obvious.  Having syntax
>> errors caused by using the wrong length dash is just asking for trouble.
>> But then there the original problem is non-existent because the token
>> '-' is always an operator in C and is never part of an integer constant.
>
> And what does the poor human reader of the code do?

I'm not sure what you mean.  If you are referring to the "different
lengths of dash" option, then the poor reader should complain to the
language designer.  Maybe my comment that it's "just asking for trouble"
was too mild?

-- 
Ben.

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

#140942

On 2019-02-13, Reinhardt Behm <rbehm@hushmail.com> wrote:
> AT Wednesday 13 February 2019 07:56, Ben Bacarisse wrote:
>> 
>> This is a much better idea because it's more obvious.  Having syntax
>> errors caused by using the wrong length dash is just asking for trouble.
>> But then there the original problem is non-existent because the token
>> '-' is always an operator in C and is never part of an integer constant.
>
> And what does the poor human reader of the code do?

For the most part ignore the issue.  The computer knows the whether
-23 is an integer constant with the value -23 or the unary negation
of +23 but it is somethign the programmer rarely needs to be
concerned with.  The only time I can see it rearing its head is at
INT_MIN - on a twos complement machine, and even them it is
implementation-defined).

C is full of oddities like that - character constants having integer
value comes to mind.  For the most part it doesn't matter.  If it
did it wouldn't have been made that way in the first place.

-- 
Andrew Smallshaw
andrews@sdf.org

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

#140907

W dniu środa, 13 lutego 2019 00:56:28 UTC+1 użytkownik Ben Bacarisse napisał:
> But then there the original problem is non-existent because the token
> '-' is always an operator in C and is never part of an integer constant.
> 

if so this is some interesting information 

but i see some problem here, and i discovered it writing elements of my compiler

im to exhausted today to more deeply focus and try to find and describe what i see a problem here but as the begining of the problem was something like that:

whan i was doing what someone calls parsing c code i named first step as a 'atomisation' c code is amde from atoms of only few types

- alfanumeric identifiers (like 'foo', 'printf' etc)
- numbers (like 22, -88, 0x67f, 23.87f etc)
- operators like + * { } ( \ / etc
- immediate strings like "ad asdas"
- comments
(probably all maybe i forgot somethiong)

this minus played in two roles is probably one and only breaking of some clarity on this level of atomisation 

and it is imo realy unfortunate you must write special program logic to distinguish if you deal with - operator or it is just simply a number you met ehen you do atomisation (and it has some consequences in to tired to mention now)

i dont even wana talko on thit as it is some deeper harder topic.. i would prefer to get to conclusion that adding short rightside minus (you realy may make it and no worry people will mistake it, it depends just on look of fonts, anyway if that would be changed in language you would be just a lot of syntax errors in separate cases forcing you to repair a line so its not a problem

more interesting is just to note that thich change should be done, futuristic c should add new chars to it chrset,

the primary question is what to add
the secondary is how to do encoding (if to use unicode (20byte unicode i could accept) and what fields exactly

i will maybe state a thread on it

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

#140911

W dniu środa, 13 lutego 2019 12:03:01 UTC+1 użytkownik fir napisał:
> W dniu środa, 13 lutego 2019 00:56:28 UTC+1 użytkownik Ben Bacarisse napisał:
> > But then there the original problem is non-existent because the token
> > '-' is always an operator in C and is never part of an integer constant.
> > 
> 
> if so this is some interesting information 
> 
> but i see some problem here, and i discovered it writing elements of my compiler
> 
> im to exhausted today to more deeply focus and try to find and describe what i see a problem here but as the begining of the problem was something like that:
> 
> whan i was doing what someone calls parsing c code i named first step as a 'atomisation' c code is amde from atoms of only few types
> 
> - alfanumeric identifiers (like 'foo', 'printf' etc)
> - numbers (like 22, -88, 0x67f, 23.87f etc)
> - operators like + * { } ( \ / etc
> - immediate strings like "ad asdas"
> - comments
> (probably all maybe i forgot somethiong)
> 
> this minus played in two roles is probably one and only breaking of some clarity on this level of atomisation 
> 
> and it is imo realy unfortunate you must write special program logic to distinguish if you deal with - operator or it is just simply a number you met ehen you do atomisation (and it has some consequences in to tired to mention now)
> 

in reality this is not quite about that someone just need write the code just to check if it is finaly part of a number or it is subtraction but more on this that it block some gramatic plane

to be honest i dont even rethinked if it is really 'block' to gramathics or maybe this oparatorial precedence ir rather an 'unblock' to grmamatic plane..but on some more shallow plane i deal with it it seem to be 'block' (and thats why i dont like it)

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")


> i dont even wana talko on thit as it is some deeper harder topic.. i would prefer to get to conclusion that adding short rightside minus (you realy may make it and no worry people will mistake it, it depends just on look of fonts, anyway if that would be changed in language you would be just a lot of syntax errors in separate cases forcing you to repair a line so its not a problem
> 
> more interesting is just to note that thich change should be done, futuristic c should add new chars to it chrset,
> 
> the primary question is what to add
> the secondary is how to do encoding (if to use unicode (20byte unicode i could accept) and what fields exactly
> 
> i will maybe state a thread on it

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

#140916

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.

-- 
Ben.

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

#140917

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

2) you do like aditionnal type checking on expressions whan you use each one minus for each one task

i also wonder if both should not be allowed, sorta like eamples you write also allowed as a side to normal shortminus "-2"

besides there is a question if allowing such expresions like a = ----------2;
or b = -----+--+++---3; has any real use

not to saying i would want to delegalize it (im a freedom man) but still this is some point of wonder ;c

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

#140919

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

will also work but it feels like workarounds

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

#140921

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

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web