C++ STL

C++ STL

[Maurício]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 660 bytes --]

    Hi,

    I've learned a little about guile, and it ocurred to me that porting the
C++ Standard Template Library to guile could be interesting. We could, for
instance, define several operations a given type of iterator or generator
should supply, and then all algorithms (copy, merge, sort, transform etc.)
using those would be readily available. Since guile has support for
functional style, I think those algothims could be even more general than
they are in C++. Has anyone tried that already?

    Maurício






_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: C++ STL

[Eric E Moore]

[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]

"Maurício" <briqueabraque@yahoo.com> writes:

>     Hi,
>
>     I've learned a little about guile, and it ocurred to me that
> porting the C++ Standard Template Library to guile could be
> interesting. We could, for instance, define several operations a
> given type of iterator or generator should supply, and then all
> algorithms (copy, merge, sort, transform etc.)  using those would be
> readily available. Since guile has support for functional style, I
> think those algothims could be even more general than they are in
> C++. Has anyone tried that already?

Not the whole STL, but good chunks of it.  For example we already have
a generic singly linked list type, with sort (sort), merge (merge),
copy (list-copy), transform (map) etc.  operations defined on it.
Similarly we have some functions for operating on tree structures
(built as lists of lists).  We have a (non-resizing) vector type,
which is less supported than the others, but at least can be sorted,
and supports a transform operation (of sorts).

The way that variable access works in scheme means that iterators and
much of the rest of the STL aren't especially needed.

It might be worth generalizing some of the functions, but most
schemers tend to use the list-based ones most of the time, which are
quite good.

-- 
Eric E. Moore

[-- Attachment #2: Type: application/pgp-signature, Size: 184 bytes --]

Re: C++ STL

[Brett Viren]

Eric E Moore writes:
 > The way that variable access works in scheme means that iterators and
 > much of the rest of the STL aren't especially needed.

Also, the compile-time type safty of C++ templates is a mismatch with
scheme's run time version, so accessing STL templates from scheme
wouldn't work so well, I guess.  You could come up with new types in
scheme and would have to recompile your STL interface library to use
them.

However, going the other way, an STL based wrapper for Scheme could be
useful.  For example, if MyClass was a C++ class which had a
corresponding GOOPs class "my-class", then it would be cool to be able
to do things like:

list<MyClass> mcl 
  = scm_to_list<MyClass*>(gh_eval_str("(some-func-returning-list-of-my-class)"));

And, 

MyClass* mc 
  = dynamic_cast<MyClass*>(gh_eval_str("(some-func-returning-my-class)"));

 > It might be worth generalizing some of the functions, but most
 > schemers tend to use the list-based ones most of the time, which are
 > quite good.

In fact, the more I learn "modern" C++, as typified in Stroustrup's
3rd Ed., the more scheme-like it seems.  Particularly in the area of
binders, functors, etc.

It almost even has lambda via functions like mem_fun<>() or with via
slots from libsigc++.

What C++ drastically lacks, imo, however is reflection.

Anyways,
-Brett.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: C++ STL

[Maurício]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1693 bytes --]

    Yes, I think you are right. However, I think there are some ideas that
could be interesting to use. For instance, it would be nice if we could do
things like this:

(for_each_c++ (i (iota 1 10)) (line (file_lines "file_name.txt)) (in
stdinput)
    (some_function i line in))

meaning that some_function would be executed with i going from 1 to 9, line
would be consecutive lines from a file and in would be lines got from user
input (and the "loop" would finish when i or line became #f). In this
example, for_each_c++ itself could be a generator that would return the
consecutive values of some_function, and so it could be used inside another
for_each_c++ (or other iterator-aware algorithm).


    Maurício


"Eric E Moore" <e.e.moore@sheffield.ac.uk> wrote in message
news:87elewcylt.fsf@dyn006239.shef.ac.uk...

>Not the whole STL, but good chunks of it.  For example we already have
a generic singly linked list type, with sort (sort), merge (merge),
copy (list-copy), transform (map) etc.  operations defined on it.
Similarly we have some functions for operating on tree structures
(built as lists of lists).  We have a (non-resizing) vector type,
which is less supported than the others, but at least can be sorted,
and supports a transform operation (of sorts).

>The way that variable access works in scheme means that iterators and
much of the rest of the STL aren't especially needed.

>It might be worth generalizing some of the functions, but most
schemers tend to use the list-based ones most of the time, which are
quite good.






_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: C++ STL

[Eric E Moore]

[-- Attachment #1: Type: text/plain, Size: 1799 bytes --]

"Maurício" <briqueabraque@yahoo.com> writes:

>     Yes, I think you are right. However, I think there are some ideas that
> could be interesting to use. For instance, it would be nice if we could do
> things like this:
>
> (for_each_c++ (i (iota 1 10)) (line (file_lines "file_name.txt)) (in
> stdinput)
>     (some_function i line in))
>
> meaning that some_function would be executed with i going from 1 to 9, line
> would be consecutive lines from a file and in would be lines got from user
> input (and the "loop" would finish when i or line became #f). In this
> example, for_each_c++ itself could be a generator that would return the
> consecutive values of some_function, and so it could be used inside another
> for_each_c++ (or other iterator-aware algorithm).

Oh.  Well, we have streams, and stream-for-each.

The following code is untested (so probably doesn't work :), but
should be close enough to what would that it makes the point we can do
this.  

(use-modules (ice-9 streams))

(define (counting-stream n)
  (lambda (x)
    (if (>= x n) #f (cons (1+ x) (1+ x))))

(stream-for-each some-function
                 (make-stream (countto 10) 1)
                 (port->stream (open-input-file "file_name.txt") read-line)
                 (port->stream (current-input-port) read-line))

Also, read-line seems to not be in CVS guile (well, the oldish one I
have installed), but it's not too long to write (if one is unfussy
about it):

;
; Why do we no longer have read-line?
;

(define (read-line port)
  (let f ((chars ()))
    (let ((c (read-char port)))
      (cond 
       ((equal? c #\newline)
        (list->string (reverse chars)))
       ((eof-object? c) c)
       (else
        (f (cons c chars)))))))

-- 
Eric E. Moore

[-- Attachment #2: Type: application/pgp-signature, Size: 184 bytes --]

Re: C++ STL

[Marius Vollmer]

Eric E Moore <e.e.moore@sheffield.ac.uk> writes:

;; Why do we no longer have read-line?
;
; We have, it's in (ice-9 rdelim) now.  The 1.6 release will also have
; read-line in the default environment, but the next major release
; after that will not.  A plain CVS checkout will get you the
; branch for the this second next release.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user