Idea: infir types of constants

Just surfing, I noticed something about the D programming language: The types of constants need not be specified explicitly as the compiler infers their types http://en.wikipedia.org/wiki/Type_inference from the right-hand sides of assignments. const fact_7 = Factorial!(7); Now in C++,

A TEMP block?

S06 Temporization, along with 'temp' variables, defines a TEMP block. Do we really need such a thing? It appears to be a LEAVE block with another level of indirection. Hmm, that is, the body of the TEMP block executes at its normal place at run-time, unlike the episodic blocks it resembles;

Re: Clarify Design by Contract

John M. Dlugosz wrote: PRE/POST on methods: When applied to a method, the semantics provide support for the Design by Contract style of OO programming: a precondition of a particular method is met if all the PRE blocks associated with that method return true. Otherwise, the

Re: Idea: infir types of constants

John M. Dlugosz wrote: Just surfing, I noticed something about the D programming language: The types of constants need not be specified explicitly as the compiler infers their types http://en.wikipedia.org/wiki/Type_inference from the right-hand sides of assignments. const fact_7 =

Re: Nomenclature Question - BEGIN etc.

How about 'contingent blocks', because they are contingent on some event, without having to use the word 'event'. Richard TSa wrote: HaloO, Larry Wall wrote: Hmm, maybe control event blocks and control events, then... I would call them flow blocks because this is where they are called and

Re: Idea: infir types of constants

I'm thinking that if strong typing is enabled, mixing untyped and typed things will cause warnings or errors that need not be there. I'm thinking that 'constant' is more special than other variables, and that the formal description of strong typing and static types should say that the

Re: Clarify Design by Contract

Moritz Lenz moritz-at-casella.verplant.org |Perl 6| wrote: This is described in depth in Object oriented software construction by Bertrand Meyer. OK, reading about it in Wiki, I see what it's supposed to do. PRE - derived classes may weaken but not strengthen. So if it fails, but the

Re: Q on function returning

On Apr 13, 2008, at 1:20 , John M. Dlugosz wrote: So, what is the role of the inner and outer return types that are declared on the function? While some details have changed since then, you might want to review this thread:

Re: Idea: infir types of constants

On Apr 13, 2008, at 2:02 , John M. Dlugosz wrote: In Perl 6, I think you would have to arrange to write the return type later rather than sooner to do this: sub foo (::T $a, T $b) is of T and writing it the other way around would violate the one-pass parsing. Just from looking at

Re: Clarify Design by Contract

John M. Dlugosz wrote: Moritz Lenz moritz-at-casella.verplant.org |Perl 6| wrote: This is described in depth in Object oriented software construction by Bertrand Meyer. OK, reading about it in Wiki, I see what it's supposed to do. PRE - derived classes may weaken but not strengthen.

Help understanding syntax in S06 Pairs as lvalues

:(:who($name), :why($reason)) := (why = $because, who = me); What do the symbols $name and $reason refer to? Are they names already in scope? Alternately, the my declarator can also force treatment of its argument as a signature. That would be my (:who($name), :why($reason)) := (why =

the nature of 'temp'

Does 'temp' operate on the value or on the container? The text starts, The temp macro temporarily replaces the value of an existing variable... and the description seems consistent with that. temp $*foo = 'foo'; The restore feature is generated by calling VAR($*foo).TEMP, and the method

RE: cross operator and empty list

-Original Message- From: Moritz Lenz [mailto:[EMAIL PROTECTED] Sent: Saturday, April 12, 2008 10:37 AM To: [EMAIL PROTECTED] Cc: p6l Subject: Re: cross operator and empty list [EMAIL PROTECTED] wrote: Technically the Cartesian cross operator doesn't have an identity value. It has.

context vs context

The term context is used for two different purposes. I don't like that. The context can refer to list context, item context etc. The context can also refer to the dynamic calling chain, which are Context objects navigated by the context function.

Re: cross operator and empty list

Miller, Hugh wrote: From: Moritz Lenz [mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Technically the Cartesian cross operator doesn't have an identity value. It has. The set which contains only the emty set, or in perl terms ([]); Or am I missing something? Should be a (any) 1 point set