git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Atharva Raykar <raykar.ath@gmail.com>
To: Phillip Wood <phillip.wood123@gmail.com>
Cc: Johannes Sixt <j6t@kdbg.org>,
	git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [GSOC][PATCH] userdiff: add support for Scheme
Date: Tue, 30 Mar 2021 12:34:38 +0530	[thread overview]
Message-ID: <D8256AFA-898E-4388-8FCC-7D3D340C001E@gmail.com> (raw)
In-Reply-To: <09678471-b2a2-8504-2293-e2b34a3a96e8@gmail.com>



> On 29-Mar-2021, at 15:48, Phillip Wood <phillip.wood123@gmail.com> wrote:
> 
> Hi Atharva
> 
> On 28/03/2021 13:23, Atharva Raykar wrote:
>> On 28-Mar-2021, at 05:16, Johannes Sixt <j6t@kdbg.org> wrote:
> > [...]
>>>> diff --git a/t/t4018/scheme-local-define b/t/t4018/scheme-local-define
>>>> new file mode 100644
>>>> index 0000000000..90e75dcce8
>>>> --- /dev/null
>>>> +++ b/t/t4018/scheme-local-define
>>>> @@ -0,0 +1,4 @@
>>>> +(define (higher-order)
>>>> +  (define local-function RIGHT
>>> 
>>> ... this one, which is also indented and *is* marked as RIGHT.
>> In this test case, I was explicitly testing for an indented '(define'
>> whereas in the former, I was testing for the top-level '(define-syntax',
>> which happened to have an internal define (which will inevitably show up
>> in a lot of scheme code).
> 
> It would be nice to include indented define forms but including them means that any change to the body of a function is attributed to the last internal definition rather than the actual function. For example
> 
> (define (f arg)
>  (define (g x)
>    (+ 1 x))
> 
>  (some-func ...)
>  ;;any change here will have '(define (g x)' in the hunk header, not '(define (f arg)'

The reason I went for this over the top level forms, is because
I felt it was useful to see the nearest definition for internal
functions that often have a lot of the actual business logic of
the program (at least a lot of SICP seems to follow this pattern).
The disadvantage is as you said, it might also catch trivial inner
functions and the developer might lose context.

Another problem is it may match more trivial bindings, like:

(define (some-func things)
  ...
  (define items '(eggs
                  ham
                  peanut-butter))
  ...)

What I have noticed *anecdotally* is that this is not common enough
to be too much of a problem, and local define bindings seem to be more
favoured in Racket than other Schemes, that use 'let' more often.

> I don't think this can be avoided as we rely on regexs rather than parsing the source so it is probably best to only match toplevel defines.

The other issue with only matching top level defines is that a
lot of scheme programs are library definitions, something like

(library
    (foo bar)
  (export ...)
  (define ...)
  (define ...)
  ;; and a bunch of other definitions...
)

Only matching top level defines will completely ignore matching all
the definitions in these files.

  parent reply	other threads:[~2021-03-30  7:05 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-27 17:39 [GSOC][PATCH] userdiff: add support for Scheme Atharva Raykar
2021-03-27 22:50 ` Junio C Hamano
2021-03-27 23:09   ` Junio C Hamano
2021-03-28  3:16     ` Ævar Arnfjörð Bjarmason
2021-03-28  5:37       ` Junio C Hamano
2021-03-28 12:40       ` Atharva Raykar
2021-03-29 10:08         ` Phillip Wood
2021-03-30  6:41           ` Atharva Raykar
2021-03-30 12:56             ` Ævar Arnfjörð Bjarmason
2021-03-30 13:48               ` Atharva Raykar
2021-03-28 12:45     ` Atharva Raykar
2021-03-28 11:51   ` Atharva Raykar
2021-03-28 18:06     ` Junio C Hamano
2021-03-29  8:12       ` Atharva Raykar
2021-03-29 20:47         ` Junio C Hamano
2021-03-29 10:12     ` Phillip Wood
2021-03-27 23:46 ` Johannes Sixt
2021-03-28 12:23   ` Atharva Raykar
2021-03-29 10:18     ` Phillip Wood
2021-03-29 10:48       ` Johannes Sixt
2021-03-29 13:12         ` Ævar Arnfjörð Bjarmason
2021-03-29 14:06           ` Phillip Wood
2021-03-30  7:04       ` Atharva Raykar [this message]
2021-03-30 10:22         ` Atharva Raykar
2021-04-05 10:04           ` Phillip Wood
2021-04-05 17:58             ` Johannes Sixt
2021-04-06 12:29             ` Atharva Raykar
2021-04-06 19:10               ` Phillip Wood
2021-04-03 13:16 ` [GSoC][PATCH v2 0/1] userdiff: add support for scheme Atharva Raykar
2021-04-03 13:16   ` [GSoC][PATCH v2 1/1] " Atharva Raykar
2021-04-05 10:21     ` Phillip Wood
2021-04-06 10:32       ` Atharva Raykar
2021-04-08  9:14   ` [GSoC][PATCH v3 0/1] " Atharva Raykar
2021-04-08  9:14   ` [GSoC][PATCH v3 1/1] userdiff: add support for Scheme Atharva Raykar
2021-04-12 23:04     ` Junio C Hamano

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=D8256AFA-898E-4388-8FCC-7D3D340C001E@gmail.com \
    --to=raykar.ath@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=j6t@kdbg.org \
    --cc=phillip.wood123@gmail.com \
    /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://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).