Re: Writing libraries for C programs using Guile Scheme

[Stefan Israelsson Tampe]

The beauty of scheme is that it is quite possible to design statically typed meta language. And if we let the guile hacker doggies chew on the guile stake a little bit more, you would also see a speedup of the generated code that will essentially mean that just a tiny bit of C-code needs to be written. In all a perfect setup for fast maintainable and secure code. But the bit's needs to be in place. Why don't we try to copy typed racket over to guile?

/Stefan

On Sat, Mar 8, 2014 at 5:37 PM, Taylan Ulrich Bayırlı/Kammer <address@hidden> wrote:

Mateusz Kowalczyk <address@hidden> writes:

> On 08/03/14 00:32, Mark H Weaver wrote:
>> Mateusz Kowalczyk <address@hidden> writes:
>>> I doubt that going from a single inherently unsafe but bloody fast
>>> language to slightly less unsafe but much slower language is an
>>> advantage here…
>>
>> "Slightly less unsafe"?  Seriously?
>
> Sure. You get rid of pointer arithmetic which is the beg evil in C but
> you lose any kind of static typing. It's about as safe as Python, Ruby
> and whatever new and hip dynamic language is popular today: not a
> whole lot.

Your tone makes me unsure whether I should try to argue but, since when
does "safety" in programming languages have anything to do with static
as opposed to dynamic type-checking?

The notion of safety I know prescribes well-defined behavior in error
situations, and disallowing behavior that doesn't make sense from an
abstract point of view, which is roughly anything that exposes details
of the underlying machinery during computation, like the raw
byte-sequences denoting the abstract entities worked with.  These are
also, from my knowledge, the main target of security exploits,
specifically memory unsafety.

If we treat safety/unsafety as a boolean, then the dynamically typed
languages you mentioned are safe, whereas C is not; both in terms of
types and memory, and memory safety is the security-relevant notion of
safety I know.

If we were to treat it as a continuum, I would rather call a type-safe,
memory-safe, dynamically typed language slightly less safe than a
type-safe, memory-safe, statically typed language, and I'm unsure how
much this notion of safety is relevant to security exploits.

The mention of speed, by the way, seems very off-the-mark.

I know nothing about any previous arguments you were in, but from these
three e-mails alone I'll sadly have to agree that you appear to have a
bias against so-called "dynamic" languages. :-)

Taylan