在 2006/7/5 上午 12:15 時，chromatic 寫到：
On Tuesday 04 July 2006 21:01, Audrey Tang wrote:
Hence I'm puzzled why you raise the "dynamic language" categorization
as a justification, for that term usually refers to dynamic typing,
not to :immediate. If it is referring to :immediate, then Python/
Ruby/PHP would become static languages. :-)
That doesn't quite seem fair; dynamic is a lot broader than just
typing.
Certainly any statically typed language with decent support for
generic
operations (or at least type-safe polymorphism) and a non-static
loading
scheme would be sufficiently dynamic.
I can't point to an example of such a language, but there you go.
Haskell with Language.Haskell.Eval and Language.C.Eval is one such
language
that I know of. However, allowing unbounded evaluation within the
assembler
cycle does not facilitate dynamic programming, so I'd still say it's
entirely
besides the point for the :immediate discussion.
I agree there should be a static subset of functionality, that
guarantees
(or at least declares) that their result will not change across
different
runs, and those operations may be allowed in :immediate. In that sense
it's not unlike the manifest sections in CLR, or constant table
constructor
instructions in many other runtimes -- TrueType fonts included.
Assembler-level unbounded evaluation via :immediate (aka BEGIN) does not
facilitate dynamic languages at all, up and including Perl 5.
Thanks,
Audrey
PGP.sig
Description: This is a digitally signed message part
