[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Shrinking the C core
From: |
Emanuel Berg |
Subject: |
Re: Shrinking the C core |
Date: |
Wed, 23 Aug 2023 01:55:21 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Alfred M. Szmidt wrote:
>>> Please keep the CC intact, not everyone subscribed.
>>
>> Yes, that is some Gnus configuration "ghost" I must have
>> done, several people have pointed it out, but I have been
>> unable to locate it - so far.
>
> I suppose that is also why I get a bounce from you?
No, that is something else, and only happens on MLs.
In ~/.fdm.conf I have a line like this
match case "emacs-devel@gnu.org" in headers action "drop"
I put it there since I read those messages with Gnus and
Gmane, thus can dispose of the e-mails copies saying the same
thing - maybe that is what is causing the failure delivery
messages. Let's comment it out then and see if it helps.
> That is not the meaning of dynamically or statically typed.
> Statically typed languages you know every type at compile
> time, in a dynamically typed language you have no clue about
> it either at compile time or run time. The article in
> question claims that Lisp is statically typed, which is
> a total misunderstanding of the term.
>
>> That would be really nice to have BTW, are you saying that
>> isn't possible with Lisp? Why not?
>
> Because you literally always have to check the type, even
> with a declare/declaim you are allowed to pass garbage.
> The compiler can produce a warning, but it isn't an error in
> Lisp, while it is an error in a statically typed language
> already at compile time. In Lisp you never know the types
> of things.
In C types are explicit in the source and in SML the types of
everything, including functions and by extention combinations
of functions, can be inferred, so that the type of a function
to add two integers is described as a mapping from integer,
integer to another integer.
Those methods cannot be used to get a statically typed Lisp?
Why not? Because of the Lisp syntax?
--
underground experts united
https://dataswamp.org/~incal
- Re: Shrinking the C core, (continued)
- Re: Shrinking the C core, Emanuel Berg, 2023/08/20
- Re: Shrinking the C core, Alfred M. Szmidt, 2023/08/21
- Re: Shrinking the C core, Ihor Radchenko, 2023/08/21
- Re: Shrinking the C core, Alfred M. Szmidt, 2023/08/21
- Re: Shrinking the C core, Ihor Radchenko, 2023/08/21
- Re: Shrinking the C core, Alfred M. Szmidt, 2023/08/21
- Re: Shrinking the C core, Ihor Radchenko, 2023/08/21
- Re: Shrinking the C core,
Emanuel Berg <=
- Re: Shrinking the C core, Alfred M. Szmidt, 2023/08/23
- Re: Shrinking the C core, Emanuel Berg, 2023/08/23
- Re: Shrinking the C core, Emanuel Berg, 2023/08/25
- Re: Shrinking the C core, Emanuel Berg, 2023/08/20
- Re: Shrinking the C core, tomas, 2023/08/20
- Re: Shrinking the C core, Ihor Radchenko, 2023/08/20
- RE: [External] : Re: Shrinking the C core, Drew Adams, 2023/08/20
- Type declarations in Elisp (was: [External] : Re: Shrinking the C core), Ihor Radchenko, 2023/08/21
- Type declarations in Elisp (was: [External] : Re: Shrinking the C core), Gerd Möllmann, 2023/08/21
- Re: Type declarations in Elisp, Eli Zaretskii, 2023/08/21