iterate-devel March 2005

iterate-devel@common-lisp.net

3 participants
5 discussions

Re: [iterate-devel] type declarations from the Iterate package
by Hoehle, Joerg-Cyril 29 Mar '05

29 Mar '05

Hi, Marc Battyani wrote: [Thanks for your feedback] >> I was wondering (given zero e-mail traffic on this subject here) if >>somebody had noticed that Iterate outputs quite dubious type declarations >when being asked for them (i.e. (declare (iterate:declare-variables)))? >I used it a few times. The (declare (iterate:declare-variables)). > IIRC it worked for me. I always tend to express myself too generally :-( For *some* constructs, Iterate outputs wrong type declarations. It depends on a) the construct and b) the implementation (more precisely the results of TYPE-OF). E.g. in CLISP, (type-of 0) -> BIT and (macroexpand-1'(iter:iter(declare(iter:declare-variables))(iter:repeat 0))) reveals (LET* ((#:COUNT3 0)) (DECLARE (TYPE BIT #:COUNT3)) ...) whose type is evidently broken. Obviously the code was written with (type-of 0) -> FIXNUM in mind. Widening that topic, I'm wondering whether generally, even the implementation's LOOP or other iteration constructs always produce correct declarations in border cases. E.g. suppose array-dimension-limit = most-positive-fixnum Loop code traversing a vector could possibly be written like: (declare (fixnum running-var)) ; because array-dimension fits a fixnum (incf running-var step) ; might escape fixnum limit (when (> running-var limit) (loop-finish)) but not like this (let ((var (+ running-var step))) ; no type declaration for var, ; could be a bignum after last iteration (if (> var limit) (loop-finish)) (setq running-var var)) ; in this case var is not too large Similarly, consider (dotimes (i most-positive-fixnum) (declare (fixnum i)) ...) Within the user-visible body, the type declaration holds. Yet dotimes could be implemented using (incf i) (when (> i #:limit) ...), thereby breaking the type declaration. Is that just academic and I'm worrying too much? Regards, Jörg Höhle.

1 0

[iterate-devel] type declarations from the Iterate package
by Hoehle, Joerg-Cyril 18 Mar '05

18 Mar '05

Hi, I was wondering (given zero e-mail traffic on this subject here) if somebody had noticed that Iterate outputs quite dubious type declarations when being asked for them (i.e. (declare (iterate:declare-variables)))? On CLISP, nobody notices, since they are ignored anyway, but on CMUCL... Did anybody understand the *intent* of J. Amsterdams type handling explained in the Iterate manual? 1. It looks to me that Iterate's handling of type declarations is somewhat broken, at least in the light of current compiler standards (things looked differently ten years ago). Other than that, I fixed a few unrelated bugs and will soon export remove-clause -- don't hold your breath. After that, I'll try to look into the topic of type declarations. Does anybody care about these at all anyway?? Regards, Jorg Hohle

2 1

[iterate-devel] Integration with CL-ENUMERATIONS and ITERATE
by Hoehle, Joerg-Cyril 18 Mar '05

18 Mar '05

Hi, I wrote: >It appears that it [iterate for Postgresql result sets] > cannot currently be written using only names exported >from the ITERATE package. The only thing lacking is an >interface to add-loop-body-wrapper Well, I find add-look-body-wrapper quite an odd name to be exported from the Iterate package. OTOH, I'm quite against gratuitous name changes to software packages that have been basically working for the last ten years. So far, I have (hopefully) managed to maintain strict compatibility. Should I a) just export iterate:add-loop-body-wrapper b) keep iterate::add-loop-body-wrapper and export a different name for the same function, e.g. create iterate:add-wrapper or iterate:add-wrapping-form c) maintain status quo What do users think? In case you don't remember, the issue at hand is that unless some such functionality is exported, one cannot pretend that Iterate presents an API (visible from the list of exported names) that can be used for extending Iterate in some useful ways (e.g. pretend FOR ... IN-FILE did not exist and provide it). Regards, Jorg Hohle

1 0

Re: [iterate-devel] Integration with CL-ENUMERATIONS and ITERATE
by Hoehle, Joerg-Cyril 11 Mar '05

11 Mar '05

Marco Antoniotti wrote: >I would like to provide an ITERATE extension to leverage the >ENUMERATION instances. I went through the manual but I am a little >unclear about how to user DEFMACRO-DRIVER etc. >Could anybody help me? Sure, send this to the list. I admit that I'm also confused by the proliferation of terms and lack of definitions (or hard to find definitions in flowtext), e.g. defclause defclause-driver defmacro-driver defmacro-clause defclause-sequence What's a clause? what's driver? etc. My finding so far is that a driver comes into play when FOR can be replaced by GENERATE. defmacro-* is best suited for users writing extensions, drawing from the macro concept, i.e. the body expands to other iterate clauses and CL forms. C.f. iterate-test.lisp I'll make a note that the manual should provide a glossary, or at least make the index work -- where does a TeX .ind file come from? Also unclear to me is top-level vs. anywhere forms. Why are some clauses (mostly FOR, but not all of them) restricted to the top-level? As an exercise, I just looked at iterate-pg.lisp. It appears that it cannot currently be written using only names exported from the ITERATE package. The only thing lacking is an interface to add-loop-body-wrapper for the sake of with-pg-cursor. Other than that, it could be written like (defmacro-driver (FOR var-spec IN-RELATION query ON-CONNECTION conn) (add-loop-body-wrapper `(with-pg-cursor ,cursor ,conn ,query)) `(for ,var-spec = (first (or (pg-result #) (finish)))) or `(for/generate ,var-spec next (first (or (pg-result #) (terminate)))) ) Alternatively, with-pg-cursor might be "inlined" into the expansion using iterate:finally-protected and with clauses. That would also prevent double evaluation of CONN. I recommend that you stick to the manual as long as possible and write a macro-clause or -driver. Don't look at the internals, don't use return-driver-code, make-binding etc. Actually, it may be a worthwhile exercise to rewrite some part of Iterate in a system construction manner, building drivers on top of others. It could make code shorter and possibly easier to maintain. E.g. FOR ... IN could be written as follows: (defmacro-driver (FOR var IN list &optional BY (step ''cdr)) (let ((for/gen (if generate 'generate 'FOR))) `(,for/gen (,var) ON ,list BY ,step))) and the expansion is only slightly worse than now (one temporary let) Regards, Jorg Hohle

1 0

[iterate-devel] Integration with CL-ENUMERATIONS and ITERATE
by Marco Antoniotti 10 Mar '05

10 Mar '05

Hi I just submitted a new package to common-lisp.net called CL-ENUMERATION. It is a rendition of the Java Enumeration/Iterator interfaces in CL. It is essentially a way to let Java, C++, Python etc programmer migrate to CL. I would like to provide an ITERATE extension to leverage the ENUMERATION instances. I went through the manual but I am a little unclear about how to user DEFMACRO-DRIVER etc. Could anybody help me? Thanks Marco -- Marco Antoniotti http://bioinformatics.nyu.edu NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 715 Broadway 10th FL fax. +1 - 212 - 998 3484 New York, NY, 10003, U.S.A.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

iterate-devel March 2005