Note for self: static scope is a synonym of lexical scope, see

   
https://en.wikipedia.org/wiki/Scope_(computer_science)#Lexical_scope_vs._dynamic_scope_2

On 2021-05-31 01:09, Andres Navarro wrote:
> The difference is that $define! captures the dynamic (not static)
> environment and modifies that environment. $set! modifies the
> environment that is explicitly passed to it (and so, previously
> captured or constructed by the user). They are equi powerful, so one
> can be defined in terms of the other but depending on context you may
> wish to use one or the other.
> 
> Having to do ($set! (current-environment) x y) get olds real quick and

On 2021-05-31 00:36, Andres Navarro wrote:
> I think you are misunderstanding that code.  You can use $define! to
> make recursive definitions just fine, see for example the definition
> of list-tail from R-1RK, section 5.7.2 (page 68):
> 
> ($define! list-tail
>     ($lambda (ls k)
>         ($if (>? k 0)
>               (list-tail (cdr ls) (- k 1))
>               ls)))
> 
> The use of $let in the $vau redefinition you mention has nothing to do
> with recursion. It is saving the original definition of $vau (the one
> that just handles a single expression) to use later, because $define!

Hello Andres

On 2021-05-31 00:34, Andres Navarro wrote:
> While I like the idea of a charter for a new Kernel report, I wouldn't
> rush into it.  I would love to see how many people are interested in
> the language, who they are, what are their experiences and
> expectations of it.

I fully agree. The draft proposal goal is to start a conversation over
matters that are not personal (and so do my other proposals/questions
that I sent yesterday).

There is no way to see who is subscribed to the list.

In many places Kernel will rely on pattern matching to map the
operands inside the static environment of an operative. They always
refer to `$define!` to explain how the pattern matching happens.

Here is the text of the subsection 4.9.1 (page 50):

> ($define! <definiend> <expression>)
> 
> definiend should be a formal parameter tree, as described below; 
> otherwise, an
> error is signaled.
> 
> The $define! operative evaluates <expression> in the dynamic
> environment (that is, the environment in which the ($define! ...)

The operative `$define` looks like:

```scheme
($define! <definiend> <expression>)
```

And `$set` looks like:

```scheme
($set! <exp1 → env> <formals> <exp2 → obj>)
```

It is not clear what is the difference between both, except for the
fact that `$define!` change its static environment, which is

At least R6RS and R7RS, when defining a lambda with `define` it is
possible for the lambda to be recursive. In R-1RS, at several places,
derivations will redefine an operative and save the original
definition of the operative in right hand side (rhs), inside a
`$let`. Such as page 63, where `$vau` is extended with a sequence
body:

```scheme
($define! $vau
   ($let (($vau $vau)) ; save the primitive
     ($vau (formals eformal . body) env
       (eval (list $vau formals eformal
                   (cons $sequence body))
             env))))

That is based on R7RS WG1 Charter:

   http://scheme-reports.org/2009/working-group-1-charter.html

## Purpose

The working group R0RS-core will develop specifications, documents,
and proofs of practical implementability for a language that embodies
the essential character of Kernel and that can be extended and
integrated with other systems.

The purpose of this work is to facilitate sharing of Kernel code. One
goal is to be able to reuse code written in one conforming
implementation in another conforming implementation without

Hello kernelers!


Thanks for joining this adventure.

We know little about each other except we share a common interest
about Kernel language.

## Who Am I?

I am Software Engineer by day with then years of experience. Nowadays
I mostly work with Python's Django, and I used to dabble with ReactJS,
and Backbone. Recently, I deployed the primary product of my company
at a popular public cloud service.

On 2021-04-26 15:34, Timothée Floure wrote:
>> My idea is to build a search service following the philosophy of
>> sr.ht of independent services that will have its own API that may
>> be triggered from a build job. list and todo will require specific
>> hooks.
> 
> Why not implement it as a feature of hub.sr.ht first? That's where
> projects are grouped - I wonder if yet another service is not a bit
> overkill / premature. Do we need arbitrary search across arbitrary
> groups of projects?

The initial rational is because it rely on asyncio, hence it would
have been a service anyway, I understand I does not have to be exposed
in the gui.

On 2021-04-26 04:47, Miles Rout wrote:
> On Sun, Apr 25, 2021 at 03:50:05PM +0200, Amirouche wrote:
>> The idea is to build search.sr.ht service that would allow project
>> to setup search for their project hosted on source hut.
>> 
>> The goal of search is to find information that is hidden or not easy
>> to find. In the context of sr.ht, a project is built out of several
>> independent services repository, list, todo, and wiki: going through
>> the search box of those services requires multiple clicks.
> 
> Is your idea to allow search within a project, between projects, or
> both?  I find it hard to imagine where it would be useful to have
> between-project search except in one very specific way: searching all
> public Sourcehut projects' descriptions for a particular string or tags