So, in my ongoing attempts to work out a syntax for type declarations
that I like, I've decided that I want to be able to do something like
this (shadowing cl:defun, of course):
(defun [foo - number] ([x - number] [y - number])
(+ x y))
with square brackets denoting the type declaration if the second
argument in there is a -. However, I'd like to be able to use this
syntax different places, in different ways. For example, in the body of
the function, I'd like
[x - fixnum] => (the fixnum x)
and so on. So I would like to have the [foo - bar] syntax interpreted
in different ways in different contexts. However, all my attempts at
doing such a thing have come to naught. The most obvious thing I've
come up with is setting up the readtable changes like this:
(defvar *typed-expander* #'(lambda (expr type)
`(the ,type ,expr)))
(defmacro type-macro (&rest form)
(dbind (expr type) form
(funcall *typed-expander* expr type)))
(defun expand-bracketed-form (form)
(if (eql (second form) '-)
(dbind (expr dash type) form
(declare (ignore dash))
`(type-macro ,expr ,type))
;; something else.
))
(set-syntax-from-char #\] #\))
(set-macro-character
#\[
#'(lambda (s c)
(declare (ignore c))
(expand-bracketed-form (read-delimited-list #\] s t))))
and then if I have a macro somewhere else where I want the syntax to
work differently, doing something like this:
(defmacro foo (bar (&rest baz) &body body)
(let ((*typed-expander* #'(lambda (expr type) (quux type expr))
;; macro definition goes here.
)
However, this doesn't work worth a damn. What am I missing? What should
I be doing so that I can have the syntax work differently in different
macros?
TIA,
Pillsy
"Pillsy" <·········@gmail.com> writes:
> So, in my ongoing attempts to work out a syntax for type declarations
> that I like, I've decided that I want to be able to do something like
> this (shadowing cl:defun, of course):
>
> (defun [foo - number] ([x - number] [y - number])
> (+ x y))
>
> with square brackets denoting the type declaration if the second
> argument in there is a -. However, I'd like to be able to use this
> syntax different places, in different ways. For example, in the body of
> the function, I'd like
>
> [x - fixnum] => (the fixnum x)
>
> and so on. So I would like to have the [foo - bar] syntax interpreted
> in different ways in different contexts. However, all my attempts at
> doing such a thing have come to naught. The most obvious thing I've
> come up with is setting up the readtable changes like this:
>
>
> (defvar *typed-expander* #'(lambda (expr type)
> `(the ,type ,expr)))
>
> (defmacro type-macro (&rest form)
> (dbind (expr type) form
> (funcall *typed-expander* expr type)))
> [...]
> However, this doesn't work worth a damn. What am I missing? What should
> I be doing so that I can have the syntax work differently in different
> macros?
What you are missing is that the reader macros are executed long
before the normal macros are expanded.
To do what you want, you can have a reader macro that expands always
to the same form, and then, use a code walker in the various macros to
scan the forms and substitute the correct CL forms in each context for
the form returned by the reader macro.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Logiciels libres : nourris au code source sans farine animale."
Pascal Bourguignon wrote:
[...]
> To do what you want, you can have a reader macro that expands always
> to the same form, and then, use a code walker in the various macros to
> scan the forms and substitute the correct CL forms in each context for
> the form returned by the reader macro.
And that did the trick exactly. Thanks again.
Cheers, Pillsy
"Pillsy" <·········@gmail.com> schrieb im Newsbeitrag ·····························@l12g2000cwl.googlegroups.com...
> So, in my ongoing attempts to work out a syntax for type declarations
> that I like, I've decided that I want to be able to do something like
> this (shadowing cl:defun, of course):
>
> (defun [foo - number] ([x - number] [y - number])
> (+ x y))
>
> with square brackets denoting the type declaration if the second
> argument in there is a -. However, I'd like to be able to use this
> syntax different places, in different ways. For example, in the body of
> the function, I'd like
>
> [x - fixnum] => (the fixnum x)
>
> and so on. So I would like to have the [foo - bar] syntax interpreted
> in different ways in different contexts. However, all my attempts at
> doing such a thing have come to naught. The most obvious thing I've
> come up with is setting up the readtable changes like this:
>
>
> (defvar *typed-expander* #'(lambda (expr type)
> `(the ,type ,expr)))
>
> (defmacro type-macro (&rest form)
> (dbind (expr type) form
> (funcall *typed-expander* expr type)))
>
> (defun expand-bracketed-form (form)
> (if (eql (second form) '-)
> (dbind (expr dash type) form
> (declare (ignore dash))
> `(type-macro ,expr ,type))
> ;; something else.
> ))
>
> (set-syntax-from-char #\] #\))
>
> (set-macro-character
> #\[
> #'(lambda (s c)
> (declare (ignore c))
> (expand-bracketed-form (read-delimited-list #\] s t))))
>
> and then if I have a macro somewhere else where I want the syntax to
> work differently, doing something like this:
>
> (defmacro foo (bar (&rest baz) &body body)
> (let ((*typed-expander* #'(lambda (expr type) (quux type expr))
> ;; macro definition goes here.
> )
>
> However, this doesn't work worth a damn. What am I missing? What should
> I be doing so that I can have the syntax work differently in different
> macros?
>
> TIA,
> Pillsy
>
Hi Pillsy,
I think you are totally mislead in what you are doing here. While learning Lisp under the influence of languages you learned before, you try to introduce a concept that is contrary to Lisps philosophy - with reason! While I think it is not too difficult to introduce strong typing into Lisp and - learning this is a benefit for you, I think in first place you should *experience the benefit of weak typing*. I believe strong typing is *premature optimization* and this is according to Knuth `the root of evil' :)
Weak typing is one cause of Lisps brevity. On the other hand, weak typing makes your routines/functions more general, more abstract and thus more reusable. Be aware that programs usually spent 90% of their time running 10% of the code. It is much more efficient to do profiling when you recognize that you *have* a performance problem than using strong typing to avoid performance issues long before they arise. Lisps brevity is one key to achieve best program maintainability.
If you use strong typing to avoid coding errors I'd suggest the following style:
1. create small functions to be tested immediately at the REPL
2. use functional style(/pradigm) whenever possible
3. apply regression tests
My last practical project experience: I wrote a complex batch program which was similar to a VB6 program I had written a few years ago. The current project had extreme load requirements compared to the old quite smart VB program. Without any performance measure the Lisp program's performance was *far superior* (not to mention development time :)) ).
Andreas
Andreas Thiele wrote:
[...]
> Hi Pillsy,
Hi Andreas.
> I think you are totally mislead in what you are doing here.
Always a possibility.
> While I think it is not too difficult to introduce strong typing
> into Lisp and - learning this is a benefit for you, I think in first
> place you should *experience the benefit of weak typing*.
> I believe strong typing is *premature optimization* and this is
> according to Knuth `the root of evil' :)
I'm not looking to add strong typing to the language; I'm just looking
for a more convenient and attractive way of expressing the optional
type declarations that CL provides for. My motives for this are for
optimization, but not so much early optimization; I have a working
program I'm trying to make faster.
> Be aware that programs usually spent 90% of their time running
> 10% of the code. It is much more efficient to do profiling when
> you recognize that you *have* a performance problem than using
> strong typing to avoid performance issues long before they arise.
Exactly what I've been doing. I let the profiler show me the slow spots
and then try to speed them up. A lot of times, that means adding
declarations.
Cheers,
Pillsy
"Pillsy" <·········@gmail.com> schrieb im Newsbeitrag ····························@n67g2000cwd.googlegroups.com...
> Andreas Thiele wrote:
> [...]
> Exactly what I've been doing. I let the profiler show me the slow spots
> and then try to speed them up. A lot of times, that means adding
> declarations.
>
> Cheers,
> Pillsy
>
So, maybe I'm doing you wrong (and I'm misled :)) ). Seems you have special performance issue heavily dependent on typing.
What are you doing? Do you have examples?
Andreas
Andreas Thiele wrote:
> So, maybe I'm doing you wrong (and I'm misled :)) ). Seems you
> have special performance issue heavily dependent on typing.
> What are you doing? Do you have examples?
I'm working on a Monte Carlo simulation, and I have to do a lot of
floating point math and array lookups in the inner loop; type
declarations are there to try to cut down on all the boxing and
unboxing (and have helped considerably, I might add.)
Cheers,
Pillsy