public inbox for ~johnnyrichard/olang-devel@lists.sr.ht
 help / color / mirror / code / Atom feed
From: "Carlos Maniero" <carlos@maniero.me>
To: "Johnny Richard" <johnny@johnnyrichard.com>,
	<~johnnyrichard/olang-devel@lists.sr.ht>
Subject: Re: [PATCH olang v1 4/4] parser: create simplified parser for tiny AST
Date: Fri, 01 Mar 2024 00:34:59 -0300	[thread overview]
Message-ID: <CZI3JYXV5X2D.13G2ZBJDT2AN5@maniero.me> (raw)
In-Reply-To: <20240228190956.78191-5-johnny@johnnyrichard.com>

> +ast_node_t *
> +ast_make_node_fn_def(arena_t *arena, string_view_t identifier, type_t return_type, ast_node_t *block);
> +
> +ast_node_t *
> +ast_make_node_literal_u32(arena_t *arena, uint32_t value);
> +
> +ast_node_t *
> +ast_make_node_return_stmt(arena_t *arena);
> +
> +ast_node_t *
> +ast_make_node_block(arena_t *arena);

s/ast_make/ast_new just to keep consistency with other functions that
allocate memory.

> +void
> +lexer_print_token_highlight(lexer_t *lexer, token_t *token, FILE *stream)
> +{
> +    size_t offset = token->location.bol;
> +    char *str = lexer->source.chars + offset;
> +
> +    size_t i = 0;
> +    while ((i + offset) < lexer->source.size && str[i] != '\n' && str[i] != 0) {
> +        ++i;
> +    }
> +    string_view_t line = { .chars = str, .size = i };
> +    fprintf(stream, "" SV_FMT "\n", SV_ARG(line));
> +    fprintf(stream, "%*s\n", (int)(token->location.offset - token->location.bol + 1), "^");
> +}

1. It bothers me a little that the lexer is performing IO operations.
   IMO, the parser should be responsible for error handling. But I can live
   with this if you think this is the right place for this function.

2. An alternative is making the lexer returning the line *string_view*
   and make the parser do the rest.

3. nitpick: Isn't *(i + offset) < lexer->source.size* and *str[i] != 0*
   redundant? The last char will (or at least should) always be a NULL
   terminator.

4. I spent some time trying to understand what this function was
   supposed to do. I believe that having a function that just returns
   the token's line could help (2). But an alternative here is using the
   *string_view* struct instead of having *str* and *i*. Something like
   this:

     void
     lexer_print_token_highlight(lexer_t *lexer, token_t *token, FILE *stream)
     {
         size_t offset = token->location.bol;
         string_view_t line = { .chars = lexer->source.chars + offset, .size = 0 };
     
         while (line.chars[i] != '\n' && line.chars[i] != 0) {
             ++line.size;
         }

         fprintf(stream, "" SV_FMT "\n", SV_ARG(line));
         fprintf(stream, "%*s\n", (int)(token->location.offset - token->location.bol + 1), "^");
     }

> +    if (!skip_expected_token(parser, TOKEN_COLON))
> +        return NULL;
> +
> +    skip_line_feeds(parser->lexer);
> +
> +    type_t fn_return_type;
> +    if (!parser_parse_type(parser, &fn_return_type)) {
> +        return NULL;
> +    }

nitpick: I’ve spotted some inconsistency with the use of brackets in
if statements. Just throwing it out there, but I believe we should be
using brackets in all if statements. However, I’m totally fine with
removing them in guard clauses, as long as we maintain a consistent
style.

This is great work man! I'm excited of how close we are now from start
the back-end.

  parent reply	other threads:[~2024-03-01  3:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-28 19:04 [PATCH olang v1 0/4] create initial syntax analysis logic Johnny Richard
2024-02-28 19:04 ` [PATCH olang v1 1/4] string_view: add string view formatter for printf fmt Johnny Richard
2024-02-28 19:04 ` [PATCH olang v1 2/4] string_view: add string view conversion to uint32_t Johnny Richard
2024-02-29 15:16   ` Carlos Maniero
2024-02-29 22:40     ` Johnny Richard
2024-02-28 19:04 ` [PATCH olang v1 3/4] lexer: add token lookahead capability Johnny Richard
2024-02-28 19:04 ` [PATCH olang v1 4/4] parser: create simplified parser for tiny AST Johnny Richard
2024-02-28 18:11   ` [olang/patches/.build.yml] build success builds.sr.ht
2024-03-01  3:34   ` Carlos Maniero [this message]
2024-03-01 22:23     ` [PATCH olang v1 4/4] parser: create simplified parser for tiny AST Johnny Richard
2024-03-01 22:33 ` [PATCH olang v1 0/4] create initial syntax analysis logic Johnny Richard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CZI3JYXV5X2D.13G2ZBJDT2AN5@maniero.me \
    --to=carlos@maniero.me \
    --cc=johnny@johnnyrichard.com \
    --cc=~johnnyrichard/olang-devel@lists.sr.ht \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.johnnyrichard.com/olang.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox