On 2021-09-11 13:27, Drew DeVault wrote:
> I'm not very fond of lisp.

That may be unfortunate for me... I was going to ask why. But then read 
this:

> 
> Haskell
> 
> * and every other functional-oriented programming language in its 
> class, such as elixir, erlang, most lisps, even if they resent being 
> lumped together
> 
> Pros: it’s FUNCTIONAL, reasonably fast, useful when the answer to your 

Dear Drew,


Seems like you cover much ground in your blog, but not much was written 
by you about the buzz around the corner.

What do you think about AI, ML and the poor elder: symbolic ai?


Thanks!

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.