Re: "Dynamic" (was discussion for #39711 -- [TODO] Make PIR->PBC reentrant)

[Audrey Tang]

在 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. :-)

scheme would be sufficiently dynamic.

I can't point to an example of such a language, but there you go.

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

besides the point for the :immediate discussion.


runs, and those operations may be allowed in :immediate.  In that sense

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

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 I agree there should be a static subset of functionality, that guarantees (or at least declares) that their result will not change across different it's not unlike the manifest sections in CLR, or constant table constructor

PGP.sig
Description: This is a digitally signed message part