# Re: [idea] Converting sha1 evaluator into parser/interpreter

2 messages from 2006-05-21 to 2006-05-21. Participants: Jakub Narebski.
Thread: https://gitlist.dev/t/4230

## Jakub Narebski, 2006-05-21 08:06

Subject: Re: [idea] Converting sha1 evaluator into parser/interpreter
Message-ID: <e4p71u$t0s$1@sea.gmane.org>
URL: https://gitlist.dev/e/e4p71u%24t0s%241%40sea.gmane.org

```
Shawn Pearce wrote:

> There was just a short conversation on #git about converting
> the sha1 expression evaluator into a split parser/interpreter
> model.  The idea here would be to convert an expression such as
> 
>   HEAD@{yesterday}~3^{tree}
> 
> into a an expression tree such as (in LISP style):
> 
>   (peel-onion (walk-back 3 (date-spec yesterday (ref HEAD))))

Rather

    (peel-onion 'tree (walk-back 3 (date-spec yesterday (ref HEAD))))
 
> with such a tree it is relatively easy to evaluate the expression,
> but its also easy to determine if a ref name is valid.  Just pass
> it through the parser and see if you get back anything more complex
> then '(ref <input>)'.

Didn't you meant to see if we get correct tree (not a forest), 
and if the root of said tree is '(ref <commit-ish>)' [1]?

Interpreting said parse tree anch checking if it folds to correct object
reference is the task of interpreter, not parser...


[*1*] if I understand currectly that <commit-ish> mean direct sha1,
shortened sha1, or ref (head or tag)? commit-ish is not in 
git glossary...

-- 
Jakub Narebski
Warsaw, Poland

```

## Jakub Narebski, 2006-05-21 10:13

Subject: Re: [idea] Converting sha1 evaluator into parser/interpreter
Message-ID: <e4peg7$g3b$1@sea.gmane.org>
URL: https://gitlist.dev/e/e4peg7%24g3b%241%40sea.gmane.org
In-Reply-To: <e4p71u$t0s$1@sea.gmane.org>

```
Jakub Narebski wrote:

> Shawn Pearce wrote:
> 
>> There was just a short conversation on #git about converting
>> the sha1 expression evaluator into a split parser/interpreter
>> model.  The idea here would be to convert an expression such as
>> 
>>   HEAD@{yesterday}~3^{tree}
>> 
>> into a an expression tree such as (in LISP style):
>> 
>>   (peel-onion (walk-back 3 (date-spec yesterday (ref HEAD))))
>>
>> with such a tree it is relatively easy to evaluate the expression,
>> but its also easy to determine if a ref name is valid.  Just pass
>> it through the parser and see if you get back anything more complex
>> then '(ref <input>)'.
> 
> Didn't you meant to see if we get correct tree (not a forest), 
> and if the root of said tree is '(ref <commit-ish>)' [1]?

I'm sorry. Of course branch names (ref names) should be limited to the ones
that doesn't make problems for the parser, i.e. they should parse to single
element parse tree:

   <input> ---parses to---> (ref <input>)

and doesn't give problems for other parsers (e.g.commit list parser
including '^A B' and 'A..B'; remotes branch mapping parser 'srcref:destref'
and '+srcref:destref') and shell (e.g. globbing).


P.S. Hmmm... is '--' branch name (heads/--) possible?
P.P.S. Would branch name which include '!' and/or '$' cause trouble?

-- 
Jakub Narebski
Warsaw, Poland

```