Re: [Chicken-hackers] Clean versus pure in types.db
Jörg F. Wittenberger scripsit: >> I've never had much sympathy for the CL and R6RS viewpoint that >> programmers should be able to count on a run-time exception being >> raised when they've done something silly. > > Just because silly programs exist. I've contributed to that pile > myself. I didn't express myself too well there. What I meant was that in R6RS, if you write (car 13), you can reliably count on getting a run-time exception. An R6RS-conformant compiler *must not* reject this program, though it might implement it as a call to `raise` instead of `car`. I would much rather have the compiler reject such a program early, as is permitted by R5RS (and R7RS) semantics, where such a program "is an error" (and so the implementation can do what it wants). The effective difference (as I understand it) between "clean" and "pure" is that the compiler can't remove a call to a "clean" procedure whose result is unused because it *might* raise an exception that the programmer *might* rely on catching. In the case of a call to a known procedure on arguments of known type, where the result is not used but the interpreter definitely *would* raise an exception, I'm okay with letting the compiler suppress the unnecessary call. If the programmer wants to raise a bad argument type exception, they should do so explicitly. -- The first thing you learn in a lawin' familyJohn Cowan is that there ain't no definite answers co...@ccil.org to anything. --Calpurnia in To Kill A Mockingbird ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Clean versus pure in types.db
On Mar 12 2012, John Cowan wrote: Felix scripsit: I used "pure" only half-heartedly. Strictly speaking a "pure" function should not even throw an error, the "pure" meaning: this procedure will not have any effect whatsoever, regardless of arguments (so it can be removed if the result is unused). "(length 42)" will signal an error, so it is not pure. Frankly, if it were treated as pure I doubt if any Real World programs would be affected. While I'd bet what is located at the lower end of my spine on that. ;-) I've never had much sympathy for the CL and R6RS viewpoint that programmers should be able to count on a run-time exception being raised when they've done something silly. Just because silly programs exist. I've contributed to that pile myself. While I agree that programs SHOULD not depend on such r/t exceptions eventually they do. But your are right, John: it would be an interesting option to have a compiler switch, which would treat all "clean" declarations as if they where declared "pure" (e.g., as if things where one level stricter than known to work so far). /Jörg ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] ugarit and tuples start breaking on 2012/03/03
* Mario Domenech Goulart [120312 17:35]: > > Regarding the other eggs that can be seen in the diff: skiplists breaks > > because it depends on tuples. > > Hmmm. Not really. skiplists does not depend on tuples > (http://tests.call-cc.org/master/linux/x86/2012/03/04/salmonella-report/dep-graphs/skiplists.html). > > It also breaks because of `assert'. I have opened a ticket for this, it's: http://bugs.call-cc.org/ticket/797 Kind regards, Christian -- Who can (make) the muddy water (clear)? Let it be still, and it will gradually become clear. Who can secure the condition of rest? Let movement go on, and the condition of rest will gradually arise. -- Lao Tse. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Allow assert to accept an arbitrary expression as the message
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/12/2012 02:03 PM, Felix wrote:
>> Tell you what, shall I make it say (if (string? msg) msg "> assertion message was supplied>") or something like that? I'll think of
>> better wording.
>
> At run-time (I'd not recommend this, as it produces more code than necessary)
> or at expansion time? The latter is ok, I guess.
Ah, but my whole goal was to allow one to put an arbitrary expression in
"msg" and have it evaluated at run-time if the assertion fails. In
Ugarit, I've written things like (excuse wrapping):
(assert (or (eq? type leaf-type) (eq? type ks-type))
(sprintf
"unlink-sexpr-stream!: Invalid block type (expected ~a)"
(list leaf-type ks-type)) type)
I use sprintf to make up a more meaningful assertion failure message!
Ok, how about we ditch the checks at all, but still allow expressions in
the message position.
Attached is a patch that produces the following behaviour in csi:
#;3> ,x (assert some-expression (sprintf "Some expression has failed")
foo bar baz)
(##core#if
(##core#check some-expression)
(##core#undefined)
(##sys#error (sprintf "Some expression has failed") foo bar baz))
...and if I fudge in a fake get-line-number:
#;6> ,x (assert some-expression (sprintf "Some expression has failed")
foo bar baz)
(##core#if
(##core#check some-expression)
(##core#undefined)
(##sys#error
(string-append "(foo.scm:1) " (sprintf "Some expression has failed"))
foo
bar
baz))
Does that make you happy?
>
> cheers,
> felix
>
ABS
- --
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9eJq4ACgkQRgz/WHNxCGrFugCggRidwCXfiohizwhAGTIaWwOC
WSMAmQGI5fQ5r1oeoPlQ4xoxZ6jYIaw6
=+9p/
-END PGP SIGNATURE-
>From 93267fb17d4d61712517b93f9b0843719e74ba2a Mon Sep 17 00:00:00 2001
From: Alaric Snell-Pym
Date: Mon, 12 Mar 2012 16:37:29 +
Subject: [PATCH] Rather than requiring assert's message to statically be a string, instead
allow it to be an expression that evaluates (at assertion failure time)
to something that can be turned into a string.
No documentation changes were required, as I believe this is the behaviour
implied by the documentation to begin with...
---
chicken-syntax.scm |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/chicken-syntax.scm b/chicken-syntax.scm
index 71576b2..4683a74 100644
--- a/chicken-syntax.scm
+++ b/chicken-syntax.scm
@@ -176,11 +176,9 @@
(msg-and-args (cddr form))
(msg (if (null? msg-and-args)
"assertion failed"
- (let ((msg-str (car msg-and-args)))
- (##sys#check-string msg-str 'assert)
- msg-str)))
+ (car msg-and-args)))
(msg (if ln
- (string-append "(" ln ") " msg)
+ `(,(r 'string-append) ,(string-append "(" ln ") ") ,msg)
msg)))
`(##core#if (##core#check ,exp)
(##core#undefined)
--
1.7.4.1
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] ugarit and tuples start breaking on 2012/03/03
On Mon, 05 Mar 2012 15:42:27 -0500 Mario Domenech Goulart wrote: > Something changed in the core that makes ugarit and tuples break on > 2012/03/04. They were not breaking the day before. > > You can see the salmonella diff here: > http://tests.call-cc.org/master/linux/x86/2012/03/04/yesterday-diff/ > > The installation error messages for ugarit and tuples are here: > http://tests.call-cc.org/master/linux/x86/2012/03/04/salmonella-report/install/tuples.html > http://tests.call-cc.org/master/linux/x86/2012/03/04/salmonella-report/install/ugarit.html > > The core commits range in which the cause of the problems may be is > b7f7e36 - b8363cb. > > Regarding the other eggs that can be seen in the diff: skiplists breaks > because it depends on tuples. Hmmm. Not really. skiplists does not depend on tuples (http://tests.call-cc.org/master/linux/x86/2012/03/04/salmonella-report/dep-graphs/skiplists.html). It also breaks because of `assert'. Best wishes. Mario -- http://parenteses.org/mario ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Clean versus pure in types.db
Felix scripsit: > I used "pure" only half-heartedly. Strictly speaking a "pure" function should > not even throw an error, the "pure" meaning: this procedure will not have > any effect whatsoever, regardless of arguments (so it can be removed if the > result is unused). "(length 42)" will signal an error, so it is not pure. Frankly, if it were treated as pure I doubt if any Real World programs would be affected. I've never had much sympathy for the CL and R6RS viewpoint that programmers should be able to count on a run-time exception being raised when they've done something silly. -- Income tax, if I may be pardoned for saying so, John Cowan is a tax on income. --Lord Macnaghten (1901) co...@ccil.org ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Allow assert to accept an arbitrary expression as the message
From: Alaric Snell-Pym Subject: Re: [Chicken-hackers] [PATCH] Allow assert to accept an arbitrary expression as the message Date: Mon, 12 Mar 2012 12:12:20 + > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 03/12/2012 11:52 AM, Felix wrote: > >> In the case of "assert", I think it is not too much to expect the user >> to pass a string. > > Tell you what, shall I make it say (if (string? msg) msg " assertion message was supplied>") or something like that? I'll think of > better wording. At run-time (I'd not recommend this, as it produces more code than necessary) or at expansion time? The latter is ok, I guess. cheers, felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] pending patches
* felix winkelmann [120312 12:53]: > > - [PATCH] Raise error on construction of too large vectors/blobs > >(this is a long thread with multiple patches) > > I have to review this, since it seems to duplicate ##sys#check-range. Oh, that has been your concern? I have completely misinterpreted your mail then... It can still work fine without introducing the replication. I can rework this if needed. The error message would be a bit less clear then but the core leaner, which I like (better error messages are second in the like list)... Thanks & Kind regards, Christian -- Who can (make) the muddy water (clear)? Let it be still, and it will gradually become clear. Who can secure the condition of rest? Let movement go on, and the condition of rest will gradually arise. -- Lao Tse. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Fix a few more mistakes in types.db
From: Peter Bex Subject: [Chicken-hackers] [PATCH] Fix a few more mistakes in types.db Date: Sun, 11 Mar 2012 21:05:28 +0100 > Hi there, > > I found a bug in the specialization for the ROUND procedure; the > specialization calls C_a_i_flonum_round while it should call > C_a_i_flonum_round_proper. This results in a difference when the > following program is interpreted versus when it is compiled with > various levels of optimization: > > (print (round 4.5)) ;; 5.0 when compiled with -O3 or higher, 4.0 otherwise > > The correct answer is 4.0 since R5RS says round needs to round to the > nearest even number when the number is halfway between two integers. > > I added a test for this to library-tests.scm, but figured out that > it wasn't compiled at all, which is why this bug wasn't caught by > "make check". Since the library is large and has many specializations, > it makes sense to compile the library test. As we add more tests, these > will automatically test any additional specializations. > > After making it compile, I found several more mistakes which I've also > fixed in this patch. Thanks. Signed off and pushed. > > By the way, I don't understand why the continuation test at the end > used to work; when compiled it complains the second time it calls > (k #f) that k is false, which I'd expect. Can someone explain why > this isn't the case in interpreted mode? In compiled mode, the list of toplevel expressions is treated like being inside a big "(begin ...)" form. In interpreted mode this is not the case: each toplevel form represents an expression entered at the REPL and the continuation does not include the previously evaluated expressions. Don't ask for details though, or the attempt to mentally follow the twisted paths of continuations for each case will just make both our heads hurt and not make anyone wiser. cheers, felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] pending patches
>> Hm. Can't find that one. > > original mail: > http://lists.nongnu.org/archive/html/chicken-hackers/2012-02/msg00050.html > > I replied to that twice, but nongnu has issues displaying the thread > properly. So here's the link of my second reply directly: > http://lists.nongnu.org/archive/html/chicken-hackers/2012-03/msg00018.html > > All patches were applied except for the final one: > http://lists.nongnu.org/archive/html/chicken-hackers/2012-03/msg00019.html > Ok. > I hope this mail helps to untangle it somewhat. It does. Thanks, Peter. cheers, felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] pending patches
Here's a couple of links to the archive. Luckily, nongnu doesn't scrub attachments :) On Mon, Mar 12, 2012 at 12:50:56PM +0100, Felix wrote: > > > > - [PATCH] fix special cases for vector/list-ref in scrutinizer when > > argument count is wrong > >(here there's a reply with a modified patch) > > Hm. Can't find that one. original mail: http://lists.nongnu.org/archive/html/chicken-hackers/2012-02/msg00050.html I replied to that twice, but nongnu has issues displaying the thread properly. So here's the link of my second reply directly: http://lists.nongnu.org/archive/html/chicken-hackers/2012-03/msg00018.html > > - [CR] deprecate "make" syntax in setup-api > >(you said you'd send a patch to the list for this one) > > Did so just now. Thank you. I'll take a look later unless someone beats me to it. > > - Re: [Chicken-hackers] [PATCH] random returns the same number on x86_64 > > all the time > >(this is a reply to a patch mail which was applied, but the reply > > contains another patch) > > I lost track. All patches were applied except for the final one: http://lists.nongnu.org/archive/html/chicken-hackers/2012-03/msg00019.html > > - [PATCH] Raise error on construction of too large vectors/blobs > >(this is a long thread with multiple patches) > > I have to review this, since it seems to duplicate ##sys#check-range. Fair enough. > > - [PATCH] Bugfix for #791 and unpack flonums correctly for integer? > > Can't remember. http://lists.nongnu.org/archive/html/chicken-hackers/2012-03/msg00010.html > > - [PATCH] Allow assert to accept an arbitrary expression as the message > > Ah, yeah. This is being discussed currently. > > - [PATCH] Fix a few more mistakes in types.db > > Can't remember. I posted that yesterday: http://lists.nongnu.org/archive/html/chicken-hackers/2012-03/msg00060.html > What a mess. I hope this mail helps to untangle it somewhat. Cheers, Peter -- http://sjamaan.ath.cx -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Allow assert to accept an arbitrary expression as the message
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/12/2012 11:52 AM, Felix wrote: > In the case of "assert", I think it is not too much to expect the user > to pass a string. Tell you what, shall I make it say (if (string? msg) msg "") or something like that? I'll think of better wording. > > cheers, > felix > ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9d6CQACgkQRgz/WHNxCGrJuQCdHn6ieFeoztowAWmsyvx5WH2M EdUAnjKbc9BwCVET0iyLFTckgZE5CTlz =flEY -END PGP SIGNATURE- ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Allow assert to accept an arbitrary expression as the message
From: Alaric Snell-Pym Subject: Re: [Chicken-hackers] [PATCH] Allow assert to accept an arbitrary expression as the message Date: Mon, 12 Mar 2012 10:21:57 + > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 03/10/2012 11:54 AM, Felix wrote: > >> Unfortunately "->string" might not always be available in code that uses >> the "assert" syntax. It would be nice if "assert" only depended on the >> base library. > > Ah-hah! Do you have a suggestion, or shall I do more research as to > what's available and pick a good way of stringifying arbitrary messages? > with-output-to-string is probably not an option either, I suppose? It's > not huge deal to just assume that msg must be a string at run time > (after all, that's what the documentation states), but I'm keen to make > error-reporting code very robust to strange inputs, as it's rarely well > tested and it's a right pain if the error you get from some exceptional > circumstance is "bad argument type - not a string: some-symbol" ;-) In the case of "assert", I think it is not too much to expect the user to pass a string. cheers, felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] pending patches
From: Peter Bex Subject: Re: [Chicken-hackers] pending patches Date: Mon, 12 Mar 2012 10:13:29 +0100 > On Mon, Mar 12, 2012 at 08:25:45AM +0100, Felix wrote: >> Hi! >> >> Too many patches are floating in limbo in the moment (and I'm aware of >> being unable to catch up, particularly in the case of the more involved >> patches which I really like to review before they go into "master"). > > There are no really involved ones left anymore, I think. > >> A suggestion: if a patch remains pending for a longer period, it might >> be sensible to create a trac ticket, add the patch and assign the >> ticket to someone (when in doubt, assign it to me). Otherwise patches >> will get lost, or submitters will feel ignored. > > What works great for me is using the "flag" feature of mutt. When a > message comes in, it start out being "unread". When I read it and see > it's a patch, I flag it. Then when someone applies the patch, I > unflag it. So everything that requires attention is either unread or > flagged. > > That way I can easily see which patches are still outstanding. These > are, in chronological order: > > - [PATCH] fix special cases for vector/list-ref in scrutinizer when argument > count is wrong >(here there's a reply with a modified patch) Hm. Can't find that one. > - [CR] deprecate "make" syntax in setup-api >(you said you'd send a patch to the list for this one) Did so just now. > - Re: [Chicken-hackers] [PATCH] random returns the same number on x86_64 all > the time >(this is a reply to a patch mail which was applied, but the reply > contains another patch) I lost track. > - [PATCH] Raise error on construction of too large vectors/blobs >(this is a long thread with multiple patches) I have to review this, since it seems to duplicate ##sys#check-range. > - [PATCH] Bugfix for #791 and unpack flonums correctly for integer? Can't remember. > - [PATCH] Allow assert to accept an arbitrary expression as the message Ah, yeah. > - [PATCH] Fix a few more mistakes in types.db Can't remember. What a mess. cheers, felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
[Chicken-hackers] [CR] deprecation of "make"
The CR (#792) has been accepted. Attached is the patch, once more.
cheers,
felix
>From e11bb2fec4d8ce13a5f4031980280ccaa8521fe6 Mon Sep 17 00:00:00 2001
From: felix
Date: Sat, 25 Feb 2012 11:46:13 +0100
Subject: [PATCH] deprecate 'make' syntax
---
manual/Extensions | 10 --
setup-api.scm |8 +++-
2 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/manual/Extensions b/manual/Extensions
index 6ecda63..230b83f 100644
--- a/manual/Extensions
+++ b/manual/Extensions
@@ -197,16 +197,6 @@ to {{chicken-install}}) and {{-feature compiling-extension}} options to the comp
Equivalent to {{(run (csc FORM ...))}}.
- make
-
-(make ((TARGET (DEPENDENT ...) COMMAND ...) ...) ARGUMENTS)
-
-A ''make'' macro that executes the expressions {{COMMAND ...}}, when any of the dependents
-{{DEPENDENT ...}} have changed, to build {{TARGET}}. This is the same as the {{make}}
-extension, which is available separately. For more information, see
-[[http://wiki.call-cc.org/egg/make|make]].
-
-
patch
(patch WHICH REGEX SUBST)
diff --git a/setup-api.scm b/setup-api.scm
index a61a4bb..3aa0c93 100644
--- a/setup-api.scm
+++ b/setup-api.scm
@@ -39,7 +39,7 @@
((run execute)
compile
standard-extension
- make make/proc
+ make make/proc ; DEPRECATED
host-extension
install-extension install-program install-script
setup-verbose-mode setup-install-mode deployment-mode
@@ -290,6 +290,9 @@
;;; "make" functionality
+;;; DEPRECATED
+;;; vvv
+
(define (make:find-matching-line str spec)
(let ((match? (lambda (s) (string=? s str
(let loop ((lines spec))
@@ -443,6 +446,9 @@
'('())
(cddr form)))
+;;;^^^
+;;; DEPRECATED
+
;;; Processing setup scripts
--
1.6.0.4
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Allow assert to accept an arbitrary expression as the message
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/10/2012 11:54 AM, Felix wrote: > Unfortunately "->string" might not always be available in code that uses > the "assert" syntax. It would be nice if "assert" only depended on the > base library. Ah-hah! Do you have a suggestion, or shall I do more research as to what's available and pick a good way of stringifying arbitrary messages? with-output-to-string is probably not an option either, I suppose? It's not huge deal to just assume that msg must be a string at run time (after all, that's what the documentation states), but I'm keen to make error-reporting code very robust to strange inputs, as it's rarely well tested and it's a right pain if the error you get from some exceptional circumstance is "bad argument type - not a string: some-symbol" ;-) > > cheers, > felix > ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9dzkQACgkQRgz/WHNxCGqdlwCfatIcLVeDVQt+zkJVQoP0o7uM zLMAn0uVDUkmOcWIHATfJ03z314aFSbt =rSO5 -END PGP SIGNATURE- ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] pending patches
On Mon, Mar 12, 2012 at 08:25:45AM +0100, Felix wrote: > Hi! > > Too many patches are floating in limbo in the moment (and I'm aware of > being unable to catch up, particularly in the case of the more involved > patches which I really like to review before they go into "master"). There are no really involved ones left anymore, I think. > A suggestion: if a patch remains pending for a longer period, it might > be sensible to create a trac ticket, add the patch and assign the > ticket to someone (when in doubt, assign it to me). Otherwise patches > will get lost, or submitters will feel ignored. What works great for me is using the "flag" feature of mutt. When a message comes in, it start out being "unread". When I read it and see it's a patch, I flag it. Then when someone applies the patch, I unflag it. So everything that requires attention is either unread or flagged. That way I can easily see which patches are still outstanding. These are, in chronological order: - [PATCH] fix special cases for vector/list-ref in scrutinizer when argument count is wrong (here there's a reply with a modified patch) - [CR] deprecate "make" syntax in setup-api (you said you'd send a patch to the list for this one) - Re: [Chicken-hackers] [PATCH] random returns the same number on x86_64 all the time (this is a reply to a patch mail which was applied, but the reply contains another patch) - [PATCH] Raise error on construction of too large vectors/blobs (this is a long thread with multiple patches) - [PATCH] Bugfix for #791 and unpack flonums correctly for integer? - [PATCH] Allow assert to accept an arbitrary expression as the message - [PATCH] Fix a few more mistakes in types.db Cheers, Peter -- http://sjamaan.ath.cx -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Clean versus pure in types.db
From: Peter Bex Subject: [Chicken-hackers] Clean versus pure in types.db Date: Sun, 11 Mar 2012 18:26:59 +0100 > Hi all, > > I was looking through types.db and noticed that some procedures > were marked "clean" and others "pure". If I understand correctly, > the difference is that "clean" procedures may still have side-effects > but will not mutate their input arguments (so pure is a more strict > notion which implies everything clean implies, plus more) > > If that's correct, why are procedures like "length" and "list-tail" > marked clean but not pure? > > (length (#(procedure #:clean #:enforce) length (list) fixnum) ; may loop > ((null) '0) > ((list) (##core#inline "C_u_i_length" #(1 > > (##sys#length (#(procedure #:clean #:enforce) ##sys#length (list) fixnum) > ((null) '0) > ((list) (##core#inline "C_u_i_length" #(1 > > (list-tail (forall (a) (#(procedure #:clean #:enforce) list-tail ((list-of a) > fixnum) (list-of a > > Now, these are special-cased so maybe that's the reason? However, > append, reverse and mem* are not special-cased and AFAICT should be > pure but are all only marked "clean". I used "pure" only half-heartedly. Strictly speaking a "pure" function should not even throw an error, the "pure" meaning: this procedure will not have any effect whatsoever, regardless of arguments (so it can be removed if the result is unused). "(length 42)" will signal an error, so it is not pure. "(identity )" will always return and accept any argument, so it is definitely pure (the argument count will be checked at compile time). It is likely that the distinction between "clean" and "pure" is not done consistently throughout types.db. cheers, felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
[Chicken-hackers] pending patches
Hi! Too many patches are floating in limbo in the moment (and I'm aware of being unable to catch up, particularly in the case of the more involved patches which I really like to review before they go into "master"). A suggestion: if a patch remains pending for a longer period, it might be sensible to create a trac ticket, add the patch and assign the ticket to someone (when in doubt, assign it to me). Otherwise patches will get lost, or submitters will feel ignored. cheers, felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
