Re: (declare (pure ...))
> On 9 Feb 2024, at 21:06, Al wrote: > > Hi, > > > what does (declare (pure ..)) mean to csc? Is the function supposed to be > > * only side-effect free, or ... > > * also return the same value when called with the same arguments? The first implies the second: to be able to choose from a set of return values for the same given argument, you do need to have side-effects, e.g., interact with a RNG which maintains state, read from a file, maintain an index into a circular vector of results, etc.. Here's what the docs say: http://wiki.call-cc.org/man/5/Declarations#pure -- Pietro Cerutti I've pledged to give 10% of income to effective charities and invite you to join me. https://givingwhatwecan.org Sent from a small device - please excuse brevity and typos.
Re: "cannot coerce inexact literal to fixnum"
On 2024-02-10 02:42, Al wrote: ... if I enable fixnum, csc chokes on both the third and fourth display's with: "Error: cannot coerce inexact literal `2147483647' to fixnum". It compiles and runs fine if those lines are commented out (or if fixnum is disabled). So the error comes from a check for (big-fixnum?) in chicken-core/core.scm. It is defined in chicken-core/support.scm: (define (big-fixnum? x) ;; XXX: This should probably be in c-platform (and (fixnum? x) (feature? #:64bit) (or (fx> x 1073741823) (fx< x -1073741824) ) ) ) (define (small-bignum? x) ;; XXX: This should probably be in c-platform (and (bignum? x) (not (feature? #:64bit)) (fx<= (integer-length x) 62) ) ) Maybe the condition in big-fixnum should be negated? Apply the restrictive #x3fff limit only when NOT (feature? #:64bit) ? Also, I've looked at Ken's number-limits egg. It has #define MOST_POSITIVE_INT32 ((int32_t) 0x3fffL) I don't know why this (as opposed to 0x7fff) would apply to #:64bit installs..? In any case the documentation on call-cc.org says * most-negative-integer32 Smallest negative int32_t value * most-positive-integer32 Largest negative (sic!) int32_t value ... which is ALSO wrong for most-positive-integer32 , but it does refers to int32_t, as opposed to chicken's internal representation (which uses up an extra bit.)
"cannot coerce inexact literal to fixnum"
(import (chicken fixnum)) ; (declare (fixnum)) (define mp most-positive-fixnum) (display mp) (newline) (display (string->number (number->string mp))) (newline) (display #x7fff) (newline) (display (string->number "#x7fff")) (newline) Obviously the first number is much greater than INT32_MAX. However, if I enable fixnum, csc chokes on both the third and fourth display's with: "Error: cannot coerce inexact literal `2147483647' to fixnum". It compiles and runs fine if those lines are commented out (or if fixnum is disabled). Not sure what's wrong here. Tried with both 5.3.0 and 5.3.1-pre. -- Al
Re: compiler types: records / collections interaction
> On Feb 9, 2024, at 11:59 AM, Al wrote: > > Suppose I need a record of a record type myrec, and collections (vectors-of, > lists-of and hash-tables) with values myrec. (define-type myrec (struct myrec)) (define-type myrec-vec (vector-of myrec)) (: myrv-ref (myrec-vec fixnum —> myrec) (define myrv-ref vector-ref) > > > What combination of > > * define-record-type (srfi-9, srfi-99, chicken define-record, whatever) and > > * (declare type ...) > > can I use to inform the compiler that (for collections of myrec) vector-ref > returns myrec's (likewise list car/cdr, hash-table-ref)? And that it needs > not emit any instance-type-checking code for objects extracted from such > collections? > > > Furthermore, how can I see what the compiler thinks of a given identifier? > I've used 'csc -ot' but it only emits types for some identifiers. Maybe it > inlines others, I don't really know. > > > Separately, how can I tell the compiler that fields in these records have > certain types? Add type declarations for the implicitly-defined per-field > accessors and mutators? (import typed-records) (define-record myrec (a : float) (b : symbol)) does this for you (: make-myrec (float symbol -> (struct myrec))) (: myrec? (* -> boolean : (struct myrec))) (: myrec-a ((struct myrec) -> float)) (: myrec-b ((struct myrec) -> symbol)) > > > I've tried unwrapping collections of myrec, and also myrec fields, and it > seems to make a huge difference in the speed of compiled code. Presumably > because I don't know how to tell the compiler to omit type checking in "safe" > cases. I know I could use some of the more aggressive optimization levels, > but I don't really want to compile unsafe code everywhere, just where I'm > using the correct types. > > > Thanks, > > Al > >
Re: (declare (pure ...))
Hi Al, what does (declare (pure ..)) mean to csc? Is the function supposed to be * only side-effect free, or ... * also return the same value when called with the same arguments? I can't remember where `(declare)` is documented, but I believe this [0] is also relevant. [0] https://wiki.call-cc.org/man/5/Types#purity Good luck! siiky
Re: compiler types: records / collections interaction
Hi Al, What combination of * define-record-type (srfi-9, srfi-99, chicken define-record, whatever) and * (declare type ...) can I use to inform the compiler that (for collections of myrec) vector- ref returns myrec's (likewise list car/cdr, hash-table-ref)? And that it needs not emit any instance-type-checking code for objects extracted from such collections? For "native" Scheme types, there's at least `list-of` and `vector-of` [0]. The type definitions of car/cdr, vector-ref, etc are in the file types.db (you can find it at $PREFIX/lib/chicken/11/types.db). For other data-structures you have to look at the specific implementation. For example, SRFI-69 [1] mentions types in the changelog. They're not mentioned in the docs, however, so you'll have to dig through the code to confirm this. Separately, how can I tell the compiler that fields in these records have certain types? Add type declarations for the implicitly-defined per-field accessors and mutators? To annotate the types of the fields of a record, take a look at defstruct[2]. There may be other alternatives, I only know of this one. [0] https://wiki.call-cc.org/man/5/Types#type-syntax [1] https://wiki.call-cc.org/eggref/5/srfi-69 [2] https://wiki.call-cc.org/eggref/5/typed-records#defstruct Good luck! siiky
(declare (pure ...))
Hi, what does (declare (pure ..)) mean to csc? Is the function supposed to be * only side-effect free, or ... * also return the same value when called with the same arguments? Thanks, Al
compiler types: records / collections interaction
Suppose I need a record of a record type myrec, and collections (vectors-of, lists-of and hash-tables) with values myrec. What combination of * define-record-type (srfi-9, srfi-99, chicken define-record, whatever) and * (declare type ...) can I use to inform the compiler that (for collections of myrec) vector-ref returns myrec's (likewise list car/cdr, hash-table-ref)? And that it needs not emit any instance-type-checking code for objects extracted from such collections? Furthermore, how can I see what the compiler thinks of a given identifier? I've used 'csc -ot' but it only emits types for some identifiers. Maybe it inlines others, I don't really know. Separately, how can I tell the compiler that fields in these records have certain types? Add type declarations for the implicitly-defined per-field accessors and mutators? I've tried unwrapping collections of myrec, and also myrec fields, and it seems to make a huge difference in the speed of compiled code. Presumably because I don't know how to tell the compiler to omit type checking in "safe" cases. I know I could use some of the more aggressive optimization levels, but I don't really want to compile unsafe code everywhere, just where I'm using the correct types. Thanks, Al
