Re: Runtime macros

"Randall Randall" <randall@xxxxxxxxxxxxxxxxxx> wrote in message
news:42bf16b5$1_2@xxxxxxxxxxxxxxxxxxxxx
> Coby Beck wrote:
>> "Randall Randall" <randall@xxxxxxxxxxxxxxxxxx> wrote in message
>> news:42bedf36$1_4@xxxxxxxxxxxxxxxxxxxxx
>>
>>>be a static type to the programmer). Runtime macros with optional
>>>replacement would allow DEFUN forms, for example, to register the
>>>"function"
>>>as a macro rather than a function, and at runtime, the macro could
>>>examine
>>>the actual arguments it got, in addition to their names, and provide
>>>appropriate declarations in its output, and then ask the compiler to
>>>replace it with the function in question. The programmer need not write
>>>declarations again (except for those cases where it wouldn't be possible
>>>to figure out the proper declaration from a single example), and yet,
>
>> When is a single example *ever* going to tell you what to expect
>> everytime? ISTM, if there are cases where you as a programmer can know
>> that the first type seen indicates it is always that type that that can
>> only be an artifact of some implementation detail about your whole
>> system, eg harware, or third party code etc.
>
> Is it really the case that most people write most functions such
> that they can either take, for example, an integer, cons, or array
> for a given argument? I would expect to use CLOS methods for that,
> in CL, but maybe I'm odd.

No, not so often, *but* this is something you usually know at programming
time, which is usually before compile time.

>> You could have a special defun type form that checks if it has yet been
>> called, if this is the first time, check the types of its arguments, put
>> the declarations into the body of its code, compile it and them setf the
>> symbol-function so that next time it just proceeds.
>
> It's true that that's an alternative way of doing the example
> use of what I was talking about. I'll have to think about it
> some more.

I can't help thinking that this is a case of very premature optimization
though. Usually declarations are the kind of thing you do well after
everything is settled and humming along and you need to fix a bottleneck.
In such a case surely you would know why you might get one type or
another...

--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")



.

Relevant Pages

  • Re: Runtime macros
    ... > be a static type to the programmer). ... > as a macro rather than a function, and at runtime, the macro could examine ... > declarations again (except for those cases where it wouldn't be possible ... You could have a special defun type form that checks if it has yet been ...
    (comp.lang.lisp)
  • Re: variable declaration
    ... > think about the cost of lack of var declarations. ... > programmer will waste while remembering exact variable name. ... Traceback: ...
    (comp.lang.python)
  • Re: B0
    ... if you've got an assembler like MASM, TASM, or HLA that supports ... declarations, this union declaration makes it very clear that my_va* ... programmer rather than a great programmer. ...
    (alt.lang.asm)
  • Re: Different syntax for declarations.
    ... the docstring is placed after declarations. ... decl-defun would still end up as a macro having the signature ... in spite of the wrapping progn and declaim material. ...
    (comp.lang.lisp)
  • Re: Indirect referencing in VB6
    ... > literal variable names and somehow use them to point to the value. ... > programmer before I was a VB programmer so I must have been thinking of ... >> indirection and procedure calls in traditional languages. ...
    (microsoft.public.vb.general.discussion)