[Chicken-hackers] [PATCH] Evaluate length/##sys#length subforms when specializing for null

[Evan Hanson]

---
 types.db |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/types.db b/types.db
index 2621686..2b6c85b 100644
--- a/types.db
+++ b/types.db
@@ -156,11 +156,11 @@
 (##sys#list (#(procedure #:pure) ##sys#list (#!rest) list))
 
 (length (#(procedure #:clean #:enforce) length (list) fixnum) ; may loop
-   ((null) '0)
+   ((null) (let ((#(tmp) #(1))) '0))
((list) (##core#inline "C_u_i_length" #(1
 
 (##sys#length (#(procedure #:clean #:enforce) ##sys#length (list) fixnum)
- ((null) '0)
+ ((null) (let ((#(tmp) #(1))) '0))
  ((list) (##core#inline "C_u_i_length" #(1
 
 ;; these are special cased (see scrutinizer.scm)
-- 
1.7.10.4


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [PATCH] Avoid building unnecessary forall types during simplification when no typevars are used

[Evan Hanson]

Previously, if typevars were given in a polymorphic type specification
but none of them were actually used within its body, type simplification
would still produce a "forall" type, e.g. `(forall () list)` where
simply a `list` would do. This patch fixes these cases by only keeping
the "forall" when at least one typevar is used within a type's body.
---
 scrutinizer.scm |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scrutinizer.scm b/scrutinizer.scm
index c437933..77b14f5 100644
--- a/scrutinizer.scm
+++ b/scrutinizer.scm
@@ -1389,7 +1389,7 @@
  (cdr e)))
   (else t)
 (let ((t2 (simplify t)))
-  (when (pair? typeenv)
+  (when (pair? used)
(set! t2 
  `(forall ,(filter-map
 (lambda (e)
-- 
1.7.10.4


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [PATCH] Mark vector and ##sys#vector as pure

[Evan Hanson]

As with list/##sys#list.
---
 types.db |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/types.db b/types.db
index 2621686..9575a1b 100644
--- a/types.db
+++ b/types.db
@@ -571,8 +571,8 @@
 (vector-set! (#(procedure #:enforce) vector-set! (vector fixnum *) undefined))
 
 ;; special cased (see scrutinizer.scm)
-(vector (#(procedure #:clean #:clean) vector (#!rest) vector))
-(##sys#vector (#(procedure #:clean #:clean) ##sys#vector (#!rest) vector))
+(vector (#(procedure #:pure) vector (#!rest) vector))
+(##sys#vector (#(procedure #:pure) ##sys#vector (#!rest) vector))
 
 (vector-length (#(procedure #:clean #:enforce) vector-length (vector) fixnum)
   ((vector) (##sys#size #(1
-- 
1.7.10.4


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [PATCH] Remove the unused typename procedure from scrutinizer.scm

[Evan Hanson]

---
 scrutinizer.scm |   75 +--
 1 file changed, 1 insertion(+), 74 deletions(-)

diff --git a/scrutinizer.scm b/scrutinizer.scm
index c437933..2221aac 100644
--- a/scrutinizer.scm
+++ b/scrutinizer.scm
@@ -30,7 +30,7 @@
procedure-type? named? procedure-result-types procedure-argument-types
noreturn-type? rest-type procedure-name d-depth
noreturn-procedure-type? trail trail-restore walked-result 
-   typename multiples procedure-arguments procedure-results
+   multiples procedure-arguments procedure-results
smash-component-types! generate-type-checks! over-all-instantiations
compatible-types? type<=? match-types resolve match-argument-types))
 
@@ -895,79 +895,6 @@
 (cute set-car! (cddr t) <>
 
 
-;;; Converting type into string
-
-(define (typename t)
-  (define (argument-string args)
-(let* ((len (length (delete '#!optional args eq?)))
-  (m (multiples len)))
-  ;;XXX not quite right for rest/optional arguments
-  (cond ((memq '#!rest args)
-(sprintf "~a or more arguments" len))
-   ((zero? len) "zero arguments")
-   (else
-(sprintf 
-"~a argument~a of type~a ~a"
-  len m m
-  (string-intersperse (map typename args) ", "))
-  (define (result-string results)
-(if (eq? '* results) 
-   "an unknown number of values"
-   (let* ((len (length results))
-  (m (multiples len)))
- (if (zero? len)
- "zero values"
- (sprintf 
- "~a value~a of type~a ~a"
-   len m m
-   (string-intersperse (map typename results) ", "))
-  (case t
-((*) "anything")
-((char) "character")
-(else
- (cond ((symbol? t) (symbol->string t))
-  ((pair? t)
-   (case (car t)
- ((procedure) 
-  (if (or (string? (cadr t)) (symbol? (cadr t)))
-  (->string (cadr t))
-  (sprintf "a procedure with ~a returning ~a"
-(argument-string (cadr t))
-(result-string (cddr t)
- ((or)
-  (string-intersperse
-   (map typename (cdr t))
-   " OR "))
- ((struct)
-  (sprintf "a structure of type ~a" (cadr t)))
- ((forall) 
-  (sprintf "~a (for all ~a)"
-(typename (third t))
-(string-intersperse
- (map (lambda (tv)
-(if (symbol? tv)
-(symbol->string tv)
-(sprintf "~a being ~a" (first tv) (typename 
(second tv)
-  (second t))
- " ")))
- ((not)
-  (sprintf "NOT ~a" (typename (second t
- ((pair)
-  (sprintf "a pair wth car ~a and cdr ~a"
-(typename (second t))
-(typename (third t
- ((vector-of)
-  (sprintf "a vector with element type ~a" (typename (second t
- ((list-of)
-  (sprintf "a list with element type ~a" (typename (second t
- ((vector list)
-  (sprintf "a ~a with the element types ~a"
-(car t)
-(map typename (cdr t
- (else (bomb "typename: invalid type" t
-  (else (bomb "typename: invalid type" t))
-
-
 ;;; Type-matching
 ;
 ; - "exact" means: first argument must match second one exactly
-- 
1.7.10.4


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [PATCH 0/5] List scrutiny special cases

[Evan Hanson]

Hi hackers,

Here are some list-related scrutiny improvements. I started with pair
walking for the scrutinizer's special cases to fix #759 (patch #2),
which made adding special cases for drop & tail easy (#3). The other
special cases (#4, #5) are basically just improving result type accuracy
for make-list, make-vector and reverse, where possible.

The list-copy types.db fix (#1) speaks for itself, I think. Let me know
if anything looks off.

Cheers,

Evan
>From fd3de2653850806947de6461d3c1db332278e1fc Mon Sep 17 00:00:00 2001
From: Evan Hanson 
Date: Sat, 16 Aug 2014 16:16:29 +1200
Subject: [PATCH 1/5] Fix list-copy types.db entry to allow any argument type

list-copy accepts any argument type (returning non-pair arguments
unchanged), so its type should be a -> a. This also means it can be
marked pure, and improves the scrutinizer's accuracy on list-copy calls
since the argument type can be preserved as the result type.
---
 tests/typematch-tests.scm |3 +++
 types.db  |2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/tests/typematch-tests.scm b/tests/typematch-tests.scm
index bbd5a3c..6cbcc9a 100644
--- a/tests/typematch-tests.scm
+++ b/tests/typematch-tests.scm
@@ -263,6 +263,9 @@
 (mx fixnum (##sys#vector-ref '#(1 2 3.4) 0))
 (mx (vector fixnum float) (vector 1 2.3))
 (mx (list fixnum float) (list 1 2.3))
+(mx (list fixnum float) (list-copy (list 1 2.3)))
+(mx (pair fixnum float) (list-copy (cons 1 2.3)))
+(mx fixnum (list-copy 1))
 
 (: f1 (forall (a) ((list-of a) -> a)))
 (define (f1 x) (car x))
diff --git a/types.db b/types.db
index 2621686..e5c0771 100644
--- a/types.db
+++ b/types.db
@@ -1924,7 +1924,7 @@
 (last (#(procedure #:clean #:enforce) last (pair) *))
 (last-pair (#(procedure #:clean #:enforce) last-pair (pair) *))
 (length+ (#(procedure #:clean #:enforce) length+ (list) *))
-(list-copy (forall (a) (#(procedure #:clean #:enforce) list-copy ((list-of a)) 
(list-of a
+(list-copy (forall (a) (#(procedure #:pure) list-copy (a) a)))
 (list-index (forall (a) (#(procedure #:enforce) list-index ((procedure (a 
#!rest) *) (list-of a) #!rest list) *)))
 (list-tabulate (forall (a) (#(procedure #:enforce) list-tabulate (fixnum 
(procedure (fixnum) a)) (list-of a
 (list= (#(procedure #:clean #:enforce) list= (#!optional (procedure (list 
list) *) #!rest list) boolean)
-- 
1.7.10.4

>From 2f96ca6af2cfdb29b10dd00f656fa2a2f22f0e37 Mon Sep 17 00:00:00 2001
From: Evan Hanson 
Date: Sat, 16 Aug 2014 16:42:07 +1200
Subject: [PATCH 2/5] Walk nested pair types in special-cased scrutiny for
 list-ref/list-tail

Also, remove the unused ##sys#list-ref alias and its special case.

Fixes #759.
---
 library.scm   |1 -
 scrutinizer.scm   |   86 +++--
 tests/typematch-tests.scm |   16 +++--
 3 files changed, 65 insertions(+), 38 deletions(-)

diff --git a/library.scm b/library.scm
index 74980fb..fb85c86 100644
--- a/library.scm
+++ b/library.scm
@@ -4763,7 +4763,6 @@ EOF
 (define ##sys#list? list?)
 (define ##sys#null? null?)
 (define ##sys#map-n map)
-(define ##sys#list-ref list-ref)
 
 
 ;;; Promises:
diff --git a/scrutinizer.scm b/scrutinizer.scm
index c437933..c756067 100644
--- a/scrutinizer.scm
+++ b/scrutinizer.scm
@@ -2232,42 +2232,60 @@
   (define-special-case vector-ref vector-ref-result-type)
   (define-special-case ##sys#vector-ref vector-ref-result-type))
 
+
+;;; List-related special cases
+;
+; Preserve known element types for list-ref, list-tail.
+
 (let ()
-  (define (list-ref-result-type node args rtypes)
-(or (and-let* ((subs (node-subexpressions node))
-   ((= (length subs) 3))
-   (arg1 (walked-result (second args)))
-   ((pair? arg1))
-   ((eq? 'list (car arg1)))
-   (index (third subs))
-   ((eq? 'quote (node-class index)))
-   (val (first (node-parameters index)))
-   ((fixnum? val))
-   ((>= val 0))  ;XXX could warn on failure (but needs 
location)
-   ((< val (length (cdr arg1)
-  (list (list-ref (cdr arg1) val)))
-   rtypes))
-  (define-special-case list-ref list-ref-result-type)
-  (define-special-case ##sys#list-ref list-ref-result-type))
 
-(define-special-case list-tail
-  (lambda (node args rtypes)
-(or (and-let* ((subs (node-subexpressions node))
-   ((= (length subs) 3))
-   (arg1 (walked-result (second args)))
-   ((pair? arg1))
-   ((eq? 'list (car arg1)))
-   (index (third subs))
-   ((eq? 'quote (node-class index)))
-   (val (first (node-parameters index)))
-   ((fixnum? val))
-   ((>= val 0))
-   ((<= val (length (cdr arg1)   ;XXX could warn on 
failure (but needs location)
-  (let ((rest (list-tail (cdr arg1) val)))

Re: [Chicken-hackers] Made a start with CHICKEN 5 proposal

[Felix Winkelmann]

>> * Designing a decent POSIX API is a hard task. I have not seen any
>>   reasonably good API wrapper for that yet - they are either too
>>   lowlevel (Basis, Ocaml, etc.), or too highlevel.
> 
> For now a modest refactoring would be enough.
> 
> [begin of short brain dump about the POSIX situation]
> 
> Putting things like, for example, "directory" in some other unit would
> make more sense to me, because there's nothing inherently POSIXy in
> reading the contents of a directory. (though the _implementation_
> happens to rely on the C POSIX API, of course), and I think it belongs
> with make-pathname and friends (ie, a "paths" or "files" module).
> 
> Ideally, there wouldn't be much left of the "posix" unit except some
> deeply POSIXy things like fork, signal, fcntl, environment vars etc.
> Probably this means the really high-level things move elsewhere.
> In time, we might even move the POSIX unit out of core into an egg
> and keep only truly "portable" (or essential) things in core.  I'm
> not sure what will happen to POSIX in the future, but I think its
> hegemony will end sooner rather than later.  the landscape is shifting
> so quickly with these mobile devices (think Windows Phone, Firefox OS
> but also the crippled POSIX support on iOS and Android), OS research
> is slowly picking up again and the Linux crowd seems to be taking an
> increasingly aggressive stance against "backwards compatibility" (think
> Wayland, systemd etc).

Quite true.

>> * Changing the string representation is much harder than you think
>>   (quoting John: "If Chibi can do it, so can we" completely ignores
>>   the fact that writing a string-representation implementation from
>>   scratch is something vastly different than modifying an existing
>>   one, one that is much older and much more widely used from
>>   foreign/native code.)
> 
> Agreed.  Recall that my suggestion was simply to "bless" UTF-8 as the
> canonical internal representation (which is the case, de facto, anyway)
> and *maybe* adding some detection code to reject invalid sequences rather
> than just continuing with bogus data.  Possibly making the default
> string ops the ones from the UTF-8 egg.  Anything beyond that is
> overkill and I would definitely not support changing the encoding in
> this effort.

I basically agree, but please note that UTF8-aware string-mutation
would have to invole "become!", which is very inefficient.

>> * Numeric tower support: this is also hard, and will have a
>>   considerable performance impact, needs changes in the compiler, in
>>   all the icky C glue code and particularly in foreign code - which
>>   means things will break all over the place in user code.
> 
> There is strong support from the community to do this, and I'm willing
> to put in the required effort.  I feel very strongly about adding at
> least bignum support to core.  I don't care as much about ratnums and
> I don't care at all about compnums, but it may be simpler to add them;
> the code to support them too is relatively straightforward.

Again, you are basically right, but currently we can distinguish
between numeric types by testing a single bit. Any additional numeric
type will have a performance cost. We also will need a C API to access
bignums, and it's not clear to me how to handle bignums being passed
to foreign functions (simply throw an error?) Many ugly issues are
hiding in the details.

>> * Port-refactoring: again - basically a good idea, but tricky to
>>   design, and may have a large performance impact, and the refactoring
>>   will be work-intensive (all the direct peeking and poking in port
>>   records needs to be localized and changed). This change should also
>>   ideally be considered to be done in tandem with changing the string
>>   representation.
> 
> Here too, a modest change would be enough.  Just using a proper
> struct/record type would make later refactorings easier.  The best
> part is that the performance impact of adding an offset to the write
> buffer is a positive one.  But if we won't be able to make this work,
> I won't be too sad, I promise ;)

Ok, that sounds reaonable.

>> * I think John's idea of putting all the little SRFIs in a few (or a
>>   single) module is better that splitting everything up into
>>   modules. Having modules for each and everything looks nice on paper
>>   but quickly gets old when you have to modify your module imports
>>   every time you use a common but nonstandard language construct.  I
>>   understand that some people like this kind of bureaucracy, but
>>   what's wrong with making things easier for the user?
> 
> Yeah, I said much the same at the start of the section about SRFIs.
> However, I think it *does* make it easier for the user to _also_ offer
> the SRFI libraries separately.  There's already a hacky workaround for
> require-extension's builtin-features in eval.scm so that you can say,
> for example, (require-extension (srfi 2)), so I think it makes sense to
> also provide "full

Re: [Chicken-hackers] [PATCH 0/5] List scrutiny special cases

[Felix Winkelmann]

From: Evan Hanson 
Subject: [Chicken-hackers] [PATCH 0/5] List scrutiny special cases
Date: Tue, 9 Sep 2014 02:57:17 -0700

> Hi hackers,
> 
> Here are some list-related scrutiny improvements. I started with pair
> walking for the scrutinizer's special cases to fix #759 (patch #2),
> which made adding special cases for drop & tail easy (#3). The other
> special cases (#4, #5) are basically just improving result type accuracy
> for make-list, make-vector and reverse, where possible.

Wow, cool. I have to try these patches out. But note that hardcoding
special cases for SRFI-1 procedures is moot, since these will be
thrown of the core system, sooner or later (or in other words: there
will be only internally used variants, possibly with less error
checking).


felix

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] Made a start with CHICKEN 5 proposal

[Alex Shinn]

On Tue, Sep 9, 2014 at 5:57 AM, Peter Bex  wrote:

>
> - The "new" syntax-rules foolishly changed the underscore to act as
>a wildcard symbol, making it - strictly speaking - incompatible with
>R5RS.  I don't think it's a good idea to support this in core.
>

I think this has been discussed here before, but it's R6RS
which is incompatible and breaks many macros here.  R7RS
"fixed" this for basically all realistic cases by requiring that
using _ as a literal overrides the wildcard behavior.

- For no good reason, R7RS syntax-rules allows not only renaming
>ellipsis identifiers, but also quoting them (which I think is
>a bit ugly).  I *think* this is entirely backwards compatible,
>so we could add that to core.
>

The ellipsis renaming (and also already supported by Chicken tail
patterns) are just Taylor Campbell's SRFI 46.  It makes many
macros more readable than (... ) escaping.  The latter, however,
is very widely supported.  Probably providing both forms of
escape was overkill, but these are easy to implement and entirely
backwards compatible.

-- 
Alex
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH 0/5] List scrutiny special cases

[John Cowan]

Felix Winkelmann scripsit:

> Wow, cool. I have to try these patches out. But note that hardcoding
> special cases for SRFI-1 procedures is moot, since these will be
> thrown of the core system, sooner or later (or in other words: there
> will be only internally used variants, possibly with less error
> checking).

Eventually, there should be a way for eggs to add types to the scrutinizer
database through a public API of some kind.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
You're a brave man! Go and break through the lines, and remember while
you're out there risking life and limb through shot and shell,
we'll be in here thinking what a sucker you are!--Rufus T. Firefly

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] Made a start with CHICKEN 5 proposal

[Alex Shinn]

On Tue, Sep 9, 2014 at 7:05 PM, Felix Winkelmann <
felix.winkelm...@bevuta.com> wrote:

>
> IIRC, full R7RS-compatibility requires "(import-for-syntax (r7rs))" or
> something like this. I was wondering about that, since it would be
> quite a barrier for portable code to have to take care of this.  Or
> can we simply make this implicit in the "define-library" macro?
>

There's no import-for-syntax in R7RS small.  In fact,
there's nothing related to phasing at all - since only
syntax-rules is supported, there are trivially no phasing
issues.

The only potentially controversial decision wrt macros
is that we did not provide the equivalent of Chicken's

  (export (syntax: macro-id ids-expanded-to ...))

instead requiring the macro expander simply detect
such indirect references.  It's not all that commonly
needed, so if it's difficult for Chicken to do this it can
be considered a low-priority todo.  Authors of libraries
which want to use this idiom can always cond-expand
to provide the additional exports explicitly for Chicken.

-- 
Alex
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH 0/5] List scrutiny special cases

[Mario Domenech Goulart]

Hi John,

On Tue, 9 Sep 2014 08:03:29 -0400 John Cowan  wrote:

> Felix Winkelmann scripsit:
>
>> Wow, cool. I have to try these patches out. But note that hardcoding
>> special cases for SRFI-1 procedures is moot, since these will be
>> thrown of the core system, sooner or later (or in other words: there
>> will be only internally used variants, possibly with less error
>> checking).
>
> Eventually, there should be a way for eggs to add types to the
> scrutinizer database through a public API of some kind.

If I understand correctly your comment, that's already supported
(http://wiki.call-cc.org/man/4/Types#using-type-information-in-extensions).

See the new eggs Felix created out of core code for examples
(binary-search, memory-mapped-files, object-evict and queues -- all in
svn).

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] [PATCH 0/5] List scrutiny special cases

[John Cowan]

Mario Domenech Goulart scripsit:

> If I understand correctly your comment, that's already supported
> (http://wiki.call-cc.org/man/4/Types#using-type-information-in-extensions).

Thanks, that's helpful.  The trouble is that such a file is an internal
(not publicly documented, unstable) format.  So if I want to ship portable
code along with type information for Chicken, I have to:

1) insert the type declarations in the code

2) compile with the -emit-type-file option

3) strip out the declarations again

4) hope the .types file continues to work with new compiler releases

That's really intolerable.  I suppose if I confine myself to : and
define-type, then I could ship my code along with macros that turn them
into (begin).


-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
One art / There is / No less / No more
To do / All things / With sparks / Galore   --Douglas Hofstadter

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH 0/5] List scrutiny special cases

[Moritz Heidkamp]

John Cowan  writes:

> Thanks, that's helpful.  The trouble is that such a file is an internal
> (not publicly documented, unstable) format.  So if I want to ship portable
> code along with type information for Chicken, I have to:
>
> 1) insert the type declarations in the code
>
> 2) compile with the -emit-type-file option
>
> 3) strip out the declarations again
>
> 4) hope the .types file continues to work with new compiler releases

Wait, what? Why not just something like this:

  (cond-expand
(chicken
  (include "chicken-type-decls.scm"))
(else))


> That's really intolerable.  I suppose if I confine myself to : and
> define-type, then I could ship my code along with macros that turn them
> into (begin).

FTR, there is the type-stubs egg which defines those macros and some
more. It's purpose is to make code compatible with CHICKENS that didn't
yet have the type syntax but could be used for portability purposes,
too.

Moritz

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] Made a start with CHICKEN 5 proposal

[Mario Domenech Goulart]

Hi gentlemen,

On Mon, 8 Sep 2014 22:57:02 +0200 Peter Bex  wrote:

> On Thu, Sep 04, 2014 at 12:44:54AM +0200, Felix Winkelmann wrote:
>
>> So, in short: forget about unicode, the full numeric tower,
>> chicken-install, port-refactoring and everything but modularization,
>> the internal structure (and size!) and the necessary issues of doing a
>> major release (e.g. the question of how to integrate that with
>> henrietta.)
>
> I think we can do minor things to make changing things in a backwards-
> compatible way.  These are important to postpone the need to "break the
> world" a third time as much as possible.
>
> I'd really like to hear other people's ideas about what would be the
> best way to integrate the changes with Henrietta.  Personally, I think
> the easiest way is to simply deploy a second copy of henrietta which
> reads from a different cache, populated by a second henrietta-cache cron
> job which reads from a different master list.

I think that approach sounds good.  We'd have /release/5/egg-locations
in svn and a new henrieta-cache instance would use it to populate a
separate cache.  We'd need a CHICKEN 5-specific henrietta providing an
URI for CHICKEN 5 eggs (chicken-install 5 would use that URI).

What is not clear to me is how to manage the egg repositories to work
with both CHICKEN 4 and 5.  We'll certainly have to maintain egg code
for CHICKEN 4 until CHICKEN 5 really catches.  During this period, how
will egg authors manage their egg repositories?  How will egg authors
specify "this egg version is for CHICKEN N" in the source repository (by
branching, I suppose).  And how to manage versions?

Will we be able to get along with changes by simply cond-expand'ing
against chicken-5?

Assuming egg authors won't create new repositories for their eggs for
CHICKEN 5, the henrietta-cache instance for CHICKEN 5 would still cache
versions that are only compatible with CHICKEN 4, although they will be
only meant to be used by CHICKEN 5.  I think that's not a really serious
issue, but I thought it should be mentioned, just in case somebody tries
"chicken-install5 :".  We can work around
that by providing .release-info files specific to CHICKEN 5 (e.g., in a
chicken-5 branch), containing the versions compatible with CHICKEN 5
only.  Maybe there are better options?

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] Made a start with CHICKEN 5 proposal

[Felix Winkelmann]

> Assuming egg authors won't create new repositories for their eggs for
> CHICKEN 5, the henrietta-cache instance for CHICKEN 5 would still cache
> versions that are only compatible with CHICKEN 4, although they will be
> only meant to be used by CHICKEN 5.  I think that's not a really serious
> issue, but I thought it should be mentioned, just in case somebody tries
> "chicken-install5 :".  We can work around
> that by providing .release-info files specific to CHICKEN 5 (e.g., in a
> chicken-5 branch), containing the versions compatible with CHICKEN 5
> only.  Maybe there are better options?

Well, the problem are eggs that are not in our central repository. There
must be a way to mark for which versions an egg is intended. That's why
I propose another entry in the .release-info files.


felix

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] Made a start with CHICKEN 5 proposal

[Mario Domenech Goulart]

On Tue, 09 Sep 2014 16:29:21 +0200 (CEST) Felix Winkelmann 
 wrote:

>> Assuming egg authors won't create new repositories for their eggs for
>> CHICKEN 5, the henrietta-cache instance for CHICKEN 5 would still cache
>> versions that are only compatible with CHICKEN 4, although they will be
>> only meant to be used by CHICKEN 5.  I think that's not a really serious
>> issue, but I thought it should be mentioned, just in case somebody tries
>> "chicken-install5 :".  We can work around
>> that by providing .release-info files specific to CHICKEN 5 (e.g., in a
>> chicken-5 branch), containing the versions compatible with CHICKEN 5
>> only.  Maybe there are better options?
>
> Well, the problem are eggs that are not in our central repository.

I think the versioning thing also affects the eggs in svn too.  For
example, suppose right now you have egg foo at version 1.0.  When
CHICKEN 5 is released, foo will be ported to CHICKEN 5.  What version
will it be in CHICKEN 4 and 5?

After we have the egg for both CHICKEN 4 and 5, how to manage new
versions?

I'm quite sure we have a solution for this problem, which is basically
the same as we had in the CHICKEN 3->4 transition.  Unfortunately, since
I was the last person I know to switch to CHICKEN 4, I didn't actually
faced that problem with my eggs.  Since nobody else was using CHICKEN 3,
I just froze egg versions for that CHICKEN version and continued to
update eggs for CHICKEN 4 only.

> There must be a way to mark for which versions an egg is
> intended. That's why I propose another entry in the .release-info
> files.

Another alternative would be using another .release-info file.  That
approach wouldn't require changes in henrietta-cache.

For example, we'd have

  https://raw.github.com/mario-goulart/awful/master/awful.release-info

for CHICKEN 4, and

  https://raw.github.com/mario-goulart/awful/chicken-5/awful.release-info

or

  https://raw.github.com/mario-goulart/awful/master/awful.release-info.5

for CHICKEN 5.  Of course, other variations are possible.

It'd be just a matter of pointing to a CHICKEN 5-specific
.release-info.

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] Made a start with CHICKEN 5 proposal

[John Cowan]

Felix Winkelmann scripsit:

> > * Designing a decent POSIX API is a hard task. I have not seen any
> >   reasonably good API wrapper for that yet - they are either too
> >   lowlevel (Basis, Ocaml, etc.), or too highlevel.

Part of the problem is that Posix is huge.  There are 1191 system interfaces
in 82 modules, in the 2013 version.  Some of these are language-specific,
like setjmp/longjmp, but most are not.  Any Posix binding (other than ones
that involve invoking arbitrary C code directly) has to be selective, and
I have never seen any principles set forth for selecting them.

Peter Bex scripsit:

> Putting things like, for example, "directory" in some other unit would
> make more sense to me, because there's nothing inherently POSIXy in
> reading the contents of a directory.

+1

> I'm not sure what will happen to POSIX in the future, but I think
> its hegemony will end sooner rather than later.  the landscape is
> shifting so quickly with these mobile devices (think Windows Phone,
> Firefox OS but also the crippled POSIX support on iOS and Android),

I think "crippled" is an exaggeration, at least for Android.
There is no Sys V IPC, but that's always been a marginal
feature for most users.  Likewise, there is no pthread_cancel,
but arguably canceling a thread from outside the thread
is a design mistake anyway, except perhaps for a debugger.  See

for why Java doesn't have it.

> the Linux crowd seems to be taking an increasingly aggressive stance
> against "backwards compatibility" (think Wayland, systemd etc).

But these don't affect POSIX system interface conformance.  Linux is
almost 100% conformant and I don't see it ceasing to be so.

> Agreed.  Recall that my suggestion was simply to "bless" UTF-8 as the
> canonical internal representation (which is the case, de facto, anyway)

That is what I meant also, and perhaps adding the Chibi string-cursor API
for people who need more efficiency.

> and *maybe* adding some detection code to reject invalid sequences
> rather than just continuing with bogus data.

That doesn't concern me too much.

> Possibly making the default string ops the ones from the UTF-8 egg.

+1 to that.

> Anything beyond that is overkill [...]

+1

> There is strong support from the community to do this, and I'm willing
> to put in the required effort.  I feel very strongly about adding at
> least bignum support to core.  I don't care as much about ratnums and
> I don't care at all about compnums, but it may be simpler to add them;
> the code to support them too is relatively straightforward.

+1 to bignums, +0 to the rest.

> - When dealing with foreign procedures returning full-width 64-bit
>integers, as those simply cannot be fully represented by flonums.

Right.  Bignums that fit in 64 bits should be properly marshaled and
unmarshaled by the core.  Biggernums that don't should provoke errors
at the FFI interface, in the same way (and for the same reasons)
that strings containing NUL do.

> - Having bignums be external to the core causes a lot of headaches when
>one generates them and passes them to some library.  For instance,
>storing very large numbers in a database is perfectly sane and
>generally possible with the DECIMAL type, but this requires all the
>database eggs to pull in the numbers egg, which they currently don't.
>In short, the numbers egg is "contagious".

Long ago I proposed to Felix an implementation of the numbers egg using
run-time hooks rather than modular renaming of procedures, such that +
would always go through a hook which would invoke either the fixnum-flonum
definition in core, or else the definition in any egg that had loaded
itself into this hook (with the understanding that such eggs don't compose).

I don't think this would play well with types, though.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Income tax, if I may be pardoned for saying so, is a tax on income.
--Lord Macnaghten (1901)

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] Made a start with CHICKEN 5 proposal

[John Cowan]

Felix Winkelmann scripsit:

> I basically agree, but please note that UTF8-aware string-mutation
> would have to invole "become!", which is very inefficient.

True, but it is also very rare in core: only 8 uses, most of which
could be easily removed.  (I exclude of course the
SRFI-13 and SRFI-14 libraries themselves.)

> Again, you are basically right, but currently we can distinguish
> between numeric types by testing a single bit. Any additional numeric
> type will have a performance cost. We also will need a C API to access
> bignums, and it's not clear to me how to handle bignums being passed
> to foreign functions (simply throw an error?) Many ugly issues are
> hiding in the details.

Note my previous post on bignums vs. biggernums.  If there is also a
way to pass arbitrary exact integers as strings, that should do it.

> >> * Please use long, explicit library names, it's easier to remember
> >>   ("there are many ways to abbreviate something, but only one way not
> >>   to" - I forgot who said this, John will tell me, I'm sure.) 

It's the .sig of David B. Lamkins, but whether he invented it, he doesn't say.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Ambassador Trentino: I've said enough. I'm a man of few words.
Rufus T. Firefly: I'm a man of one word: scram!--Duck Soup

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] Made a start with CHICKEN 5 proposal

[Oleg Kolosov]

On 09/04/14 13:30, "Jörg F. Wittenberger" wrote:
> Am 29.08.2014 20:50, schrieb Oleg Kolosov:
>> On 08/23/14 19:35, Peter Bex wrote:
>>> I've made a start on the wiki, at what we'd like CHICKEN 5 to be about.
>> I've remembered one more thing: why not stick the terminating '\0' at
>> the end of all strings in internal representation? This looks pretty
>> harmless but could make some common FFI uses a breeze.
>
> Don't, please.
>
> a) This would make "some forms of abuse" "safe anyway".  But internal
> \0 would have to handled for correct programs anyway. Eventually one
> ends up rewriting mostly working code at that point.
>
> b) I don't recall the full story.  But we had precisely this problem
> once with RScheme (which does have this terminating \0).  In the end
> Donovan Kolbly (creator of RScheme) commented on the topic: "I was
> young."
>
> ___
> Chicken-hackers mailing list
> Chicken-hackers@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-hackers

This might be entirely point of view issue, but I don't see the problem
in allowing some abuse to gain performance, with the assumption that the
user knows what he is doing. In our commercial system we have few
applications where CHICKEN's string handling was found as a bottleneck
(indexing large number of database entries, filtering lists of thousands
of file names, etc.). Equivalent pure C version is few times (sometimes
order of magnitude) faster with the same algorithms. Even doing heavy
lifting in C and just pushing data back to CHICKEN hurts performance a
lot (our GUI is written in Scheme).

So, all the convenience and safety of high level language is meaningless
because we ended up not using it for those applications.

-- 
Regards, Oleg Kolosov


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH 0/5] List scrutiny special cases

[Evan Hanson]

> > Felix Winkelmann scripsit:
> >> Wow, cool. I have to try these patches out. But note that hardcoding
> >> special cases for SRFI-1 procedures is moot, since these will be
> >> thrown of the core system, sooner or later (or in other words: there
> >> will be only internally used variants, possibly with less error
> >> checking).

Yeah, I thought about that, but once the code was written I figured I'd
put it out there in any case (that's patches #1, #3 and #4). Maybe it'll
be possible to add them to the srfi-1 module when the time comes (either
as a hack or via some future extension to the API -- see below).

> On Tue, 9 Sep 2014 08:03:29 -0400 John Cowan  wrote:
> > Eventually, there should be a way for eggs to add types to the
> > scrutinizer database through a public API of some kind.

There is in general, per Mario's response. However, the reason these are
"special cases" is because they're trying to preserve information in a
way that can't be expressed with the current type specification
language.

If you call `(reverse (list 1 #\2 "3"))`, it's clear that the resulting
type should be `(list string char fixnum)`. However, reverse has the
type `((list-of a) -> (list-of a))`, so the resulting type will be
`(list-of (or fixnum char string))`. That information loss would be nice
to avoid, but in order to do so a specialization needs programmatic
access to the call's argument types. This is done behind the scenes for
a handful of procedures in the scrutinizer, hence "special case".

I don't know what user-level provisions for this would look like.
(Thinking out loud now.) It'd be easiest if we allowed the user to
register a handler procedure at scrutiny time, but that's its own can of
worms. Otherwise, I think you'd have to eval something somewhere.

(: reverse (forall (a) ((list-of a) -> (list-of a)))
   (((list . #(a))) ; capture part of the argument type as #(a)
((list [reverse #(a)])) ; refer to #(a) somehow in the result type
#(node)))   ; "node" = leave the original node unchanged

Evan

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] Made a start with CHICKEN 5 proposal

[Felix Winkelmann]

>> Well, the problem are eggs that are not in our central repository.
> 
> I think the versioning thing also affects the eggs in svn too.  For
> example, suppose right now you have egg foo at version 1.0.  When
> CHICKEN 5 is released, foo will be ported to CHICKEN 5.  What version
> will it be in CHICKEN 4 and 5?

But we already have branches in the egg repository, and we can take
care of that ourselves. But we should put to much burden on those that
provide eggs in their own repositories, by forcing them to maintain
multiple branches.

> 
>   https://raw.github.com/mario-goulart/awful/master/awful.release-info
> 
> for CHICKEN 4, and
> 
>   https://raw.github.com/mario-goulart/awful/chicken-5/awful.release-info
> 
> or
> 
>   https://raw.github.com/mario-goulart/awful/master/awful.release-info.5
> 
> for CHICKEN 5.  Of course, other variations are possible.
> 
> It'd be just a matter of pointing to a CHICKEN 5-specific
> .release-info.

That might be possible, yes.


felix

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] Made a start with CHICKEN 5 proposal

[Felix Winkelmann]

> Long ago I proposed to Felix an implementation of the numbers egg using
> run-time hooks rather than modular renaming of procedures, such that +
> would always go through a hook which would invoke either the fixnum-flonum
> definition in core, or else the definition in any egg that had loaded
> itself into this hook (with the understanding that such eggs don't compose).

That is basically te right approach, but will be terribly inefficient,
and I mean _really_ inefficient. Any attempt to get fast code must
somehow compile to primitive arithmetic instructions, integer or
float.  We do "reasonably" well right now, but still need better
performance (i.e. unboxed flonum operations). If a tight loop with an
integer counter needs an extra out-of-line (or even CPS)
procedure-call, we lose heavily.


felix

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] Made a start with CHICKEN 5 proposal

[Felix Winkelmann]

>> >> * Please use long, explicit library names, it's easier to remember
>> >>   ("there are many ways to abbreviate something, but only one way not
>> >>   to" - I forgot who said this, John will tell me, I'm sure.) 
> 
> It's the .sig of David B. Lamkins, but whether he invented it, he doesn't say.

Thanks for clearing that up. I knew that your encyclopedic brain can
be relied on. I darkly recall having read it in CLTL2 by Guy Steele,
but wasn't sure where he got it from.


felix

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] Made a start with CHICKEN 5 proposal

[John Cowan]

Felix Winkelmann scripsit:

> Thanks for clearing that up. I knew that your encyclopedic brain can
> be relied on. I darkly recall having read it in CLTL2 by Guy Steele,
> but wasn't sure where he got it from.

In this case it's Dr. Google who can be relied upon.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Work hard / play hard,  co...@ccil.org
die young / rot quickly.

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers