Questions on kl

[Joel Shellman]

Is this the canonical documentation on kl functions?
http://www.shenlanguage.org/Documentation/shendoc.htm#The Primitive
Functions of K Lambda

I'm not clear on what simple-error should evaluate to. It says
string-->A, but what should A be?
And "prints an exception" seems a little confusing when the parameter
is of string type. If it's printing an "exception" wouldn't it take an
exception?

Also, there are various entries in that chart where the Type column is
empty, or hd shows _. It would be nice to have some more clarity on
some of those. For example, what should happen for the expression:
(simple-error (defun f (X) (+ X X)))

Also, would the following be an error because the cons expression
evals to a list not an atom (and the str description is: "maps any
atom to a string")?
(str (cons "blue" ()))

[Mark Tarver]

On May 26, 4:57 pm, Joel Shellman <j...@mentics.com> wrote:
> Is this the canonical documentation on kl functions?http://www.shenlanguage.org/Documentation/shendoc.htm#ThePrimitive
> Functions of K Lambda
>
> I'm not clear on what simple-error should evaluate to. It says
> string-->A, but what should A be?

An error is thought of as returning an error object sometimes
represented formally as bottom (_|_) which inhabits every type. Hence
simple-error returns the type A for all A. Computationally the error
is returned as an exception which is printed off at the top level;
however this exception can be trapped and replaced by another object
as long as type constraints are obeyed.

> And "prints an exception" seems a little confusing when the parameter
> is of string type. If it's printing an "exception" wouldn't it take an
> exception?
>
> Also, there are various entries in that chart where the Type column is
> empty, or hd shows _. It would be nice to have some more clarity on
> some of those. For example, what should happen for the expression:
> (simple-error (defun f (X) (+ X X)))

Not every function in Shen has a type; for example eval. This is not
an oversight. 'hd' actually is not totally specified in its
behaviour; given [] as an argument under CL it returns []. The typed
version 'head' is better behaved but a little slower because it does a
cons? test on its argument. For that reason, 'hd' is included for
speed.

'simple-error' takes a string as an input. Regarding 'defun', the
spec says

defun in Kl requires little explanation except to note that all
functions defined using it must sustain currying and that the
namespace model is dual (see the document on porting for more on
this). There is no necessity to support nested definitions in the
manner of Scheme. defun is a top level construction and there is no
obligation to support the evaluation of defun within an expression;
this also holds true of define unless it is used in a package.

> Also, would the following be an error because the cons expression
> evals to a list not an atom (and the str description is: "maps any
> atom to a string")?
> (str (cons "blue" ()))

It would not be *guaranteed* to work in virtue of the specification; a
porter might try to put more action into this function than is in the
spec but to rely on extra-spec features to run your code is unwise
because portability is at risk.

Mark

[Dmitry Cherkassov]

Joel Shellman <jo...@mentics.com> writes:

> I'm not clear on what simple-error should evaluate to. It says
> string-->A, but what should A be?

Generally speaking, simple-error should not evaluate to anything.
It should issue non-local exit to trap-error which handles it.

> Also, would the following be an error because the cons expression
> evals to a list not an atom (and the str description is: "maps any
> atom to a string")?
> (str (cons "blue" ()))

AFAIK yes. For such edge cases you can fire-up clisp port of shen and
check it out.

--
With best regards,
Dmitry

[Joel Shellman]

>> Also, would the following be an error because the cons expression
>> evals to a list not an atom (and the str description is: "maps any
>> atom to a string")?
>> (str (cons "blue" ()))
>
> AFAIK yes. For such edge cases you can fire-up clisp port of shen and
> check it out.

Well... I'm trying to implement the spec. The clisp port might have
behavior that is not required by the spec as Mark just mentioned in
his post.

[Joel Shellman]

>> I'm not clear on what simple-error should evaluate to. It says
>> string-->A, but what should A be?
>
> An error is thought of as returning an error object sometimes
> represented formally as bottom (_|_) which inhabits every type.  Hence
> simple-error returns the type A for all A.  Computationally the error
> is returned as an exception which is printed off at the top level;
> however this exception can be trapped and replaced by another object
> as long as type constraints are obeyed.

Ah, ok. So it throws/fires/raises an error (or exception?). May I
suggest that the description: "prints an exception" is confusing?
Also, there seems to be terminology: error and exception seem to be
used interchangeably. Is that correct? If so, it might be useful to
either choose one and stick with it, or mention they are synonymous,
or if there is a difference, clarify it somewhere. I understand that's
a bit nit-picky, but if this is a language specification, we probably
want to avoid multiple interpretations.

>> Also, there are various entries in that chart where the Type column is
>> empty, or hd shows _. It would be nice to have some more clarity on
>> some of those. For example, what should happen for the expression:
>> (simple-error (defun f (X) (+ X X)))
>
> Not every function in Shen has a type; for example eval.

Wouldn't it evaluate to whatever the code evaluated to? So, although
it might not have a concrete static type, it will evaluate to some
type at runtime.

> This is not
> an oversight.  'hd' actually is not totally specified in its
> behaviour; given [] as an argument under CL it returns [].

Ah, I see. So the behavior is platform dependent. May I suggest that
the type column should mention that instead of just being blank?

I'm still learning Shen, but... just as an early impression... if the
intention is to be able to "write once, run anywhere", is there
sufficient platform dependent behavior that might make that difficult?

> The typed version 'head' is better behaved but a little slower because it does a
> cons? test on its argument.  For that reason, 'hd' is included for speed.

Right. Though we could also keep both safety and speed with a
dependent types version, couldn't we?

> defun in Kl requires little explanation except to note that all

Ah, sorry I didn't catch that part. So, it's just special.

Thanks!