Re: short question about books

[Pascal J. Bourguignon]

anog...@gmx.at writes:

 Hi awesome hackers,

 i'm a noob. Which book is better for learning programming?

 * SICP http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussman-lectures/
 * How to Design Programs http://htdp.org/2003-09-26/
 * anything else

Read both, in this order:

1. How to Design Programs http://htdp.org/2003-09-26/
2. SICP http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussman-lectures/

If you should read only one, then only SICP (and watch the videos).

-- 
__Pascal Bourguignon__ http://www.informatimago.com/

Re: short question about books

[Pascal J. Bourguignon]

ri...@happyleptic.org writes:

 If you should read only one, then only SICP (and watch the videos).

 Out of curiousity, what's interresting about the videos ?

It's easier to watch them than to read the book ;-)

Multi-channel is better for learning.  Reading the book is nice for
the symbolic brain, watching the video is better for the neural
network.


-- 
__Pascal Bourguignon__ http://www.informatimago.com/

Re: Are `eqv?' and `eq?' the same?

[Pascal J. Bourguignon]

Alexandru Cojocaru xo...@gmx.com writes:

 Hi,

 from the GUILE manual [0]:

     `eq?' tests just for the same object (essentially a pointer
 comparison)
     `eqv?' extends `eq?' to look at the value of numbers and
 characters.

 this is what I get:

     scheme@(guile-user) (eq? 3 (+ 1 2))
     $1 = #t

 is this behavior intentional or some type of bug?

Yes.


A some implementations internalize small integers (and characters).

A lot of implementations even don't allocate small integers (fixnums) as
objects, but encode them instead as immediate values.


So:

 (let ((x 3)
   (y (+ 1 2)))
(eq? x y))

could be represented in memory in different ways:

   +---+
x: |  f:3  |
   +---+
y: |  f:3  |
   +---+



   +---+
x: |  p0---|--+
   +---+  |
y: |  p0---|+ |
   +---+| |
| |
v v
   +--+
   |f:3   |
   +--+

   +---+
x: |  p1---|-+
   +---+ |
y: |  p2---|+|
   +---+||
||
vv
   +--++--+ 
   |f:3   ||f:3   |
   +--++--+

This later case would occur if the number was a bignum:
b:391278903129038129038129038901238901 for example.
(f: denotes the type tag for fixnums, b: the type tag for bignums).


Now, even if we're in the second situation, for example, we could get
it also with:  (let ((x 3) (y x)) (eq? x y)),  it is still possible that
in the process of calling a function such as eq? the argument be copied,
so that in 

   (define (eq? a b) …)

we could get a situation like:

   +---+
a: |  p1---|-+
   +---+ |
b: |  p2---|+|
   +---+||
||
vv
   +--++--+ 
   |f:3   ||f:3   |
   +--++--+

even starting from the second or (less probable) first situation!


Now, if inside eq? we have the first or second situation, then the
result will be #t, and in the third situation, the result will be #f.


That's all you learn from eq?, which, for characters and numbers, is not
much interesting: it only tells you something about how numbers are
implemented and processed by the implementation.



-- 
__Pascal Bourguignon__
http://www.informatimago.com/

Re: How to read integers from file faster?

[Pascal J. Bourguignon]

Darren Hoo darren@gmail.com writes:

 It is way too slow to read numbers from a file simply by using `read' 

 for example a txt file contains 10,000,000 line of numbers:

To get speed, I would:

1- open a binary file,

2- perform double-buffering I/O,  (ie. read a buffer while you process
   another),

3- assume the input format is as specified, ie. no check.
   …
   (let ((byte (vector-ref buffer i)))
 (if (= byte 10)
(begin (set! values (cons value values))
   (set! value 0))
(set! value (+ (* value 10) (mod byte 16)
   …


Actually, only using buffered I/O matters.  For big files, what slows
down is I/O, not the handling of characters or checking of the syntax or
anything that's done in memory.  If you want to read your data faster,
keep it in RAM, or else in SSD.

-- 
__Pascal Bourguignon__
http://www.informatimago.com/

Re: Message Passing with GOOPS

[Pascal J. Bourguignon]

Marko Rauhamaa ma...@pacujo.net writes:

 GOOPS also, surprisingly, seems to be decades behind in trying to
 present objects as collections of slots.

 I once heard this story. The French king had a royal ball in honor of
 the birthday of the French queen. When some lordly guests presented
 their gift, a pair of fancy stockings, the king drew a fit, declaring:
 The Queen of France does not have legs!

 Similarly, in my mind, objects don't have slots, they interact.

You are right.  Slots are an implementation detail.  Notice that you
have them in all (common) OO systems.  But the difference with CLOS,
with the MOP, (I don't know if GOOPS implements the MOP, Meta Object
Protocol), slots are reified as first class objects, and can be added or
removed from a class (therefore, to all its instances).

This allows you to forget slots as features of classes, but instead, as
an implementation mechanism for certain kinds of relationships.  So you
can define a macro define-associations and use it to describe how your
objects interrelate and interact with others, and this macro will add
slots as needed to implement those associations:

https://github.com/informatimago/abnotation/blob/master/src/core/model.lisp
https://github.com/informatimago/lisp/blob/master/clext/association.lisp#L575


-- 
__Pascal Bourguignon__ http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: Embedding Guile with sandboxing

[Pascal J. Bourguignon]

Matthew Keeter  writes:

> I’m currently embedding Python in a C / C++ application that evaluates 
> user-provided scripts.
>
> Obviously, this is terribly unsafe: user-provided scripts can execute 
> arbitrary malicious actions,
> and there’s no good way to sandbox Python in a desktop context.
>
> If I were to replace Python with Guile, is there a way to sandbox it so that 
> arbitrary (perhaps
> malicious) user-provided scripts can be run safely?

Well, I would use ecl (Embeddable Common Lisp) rather, but the problem
is not specific to a language.

To ensure "safety", you need to _control_ things.

Using a general algorithmic programming language with OS or platform
interfaces will never be safe.

What you need is to write your own implementation. It doesn't matter of
what language.

For example, you could take pypy, expurge it from the "dangerous"
operations and go on with the resulting restricted python.

Or you could do the same with guile or Common Lisp.

The advantage of the later languages, is that it is easier to write
languages in them, reusing parts of the existing infrastructure.  I
imagine the same can be done with pypy.   On the other hand, if you mix
metalinguistic layers, you may introduce leaking bugs.  


Ultimately, the problem comes down to the fact that the underlying
hardware and OS layer is not safe itself.  One easy way to allow
potentially hostile code to run, is to make it run in a chroot, nope, we
know it's not safe, so in its own virtual machine (either on an
hypervisor or a qemu or simular), but, nope, we know it's not safe
(there are exploitable bugs in hypervisors and qemu, etc).


So you need to implement a language that won't provide any unwanted
OS/platform API and that won't provide any way to generate code accessing
to any unwanted feature, and that still allows user to write useful
programs, while making no mistake; and since it will run on an unsafe
platform, how will you ensure that a program written in your language
will never be able to have any nefarious side effects?

For example, the x86 MMU is turing complete.  How do you ensure that
there is no way any program written in your language will not have the
side effect of introducing a nefarious program in the underlying MMU?


Perhaps it would be easier to select good users, and just give them full
Common Lisp with ecl (or full guile).


-- 
__Pascal Bourguignon__ http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: There is no SCAN (introducing Compan)

[Pascal J. Bourguignon]

Panicz Maciej Godek  writes:

> Therefore, I wrote Compan, which is meant to be a "Community Package
> Manager" for Guile.

Unfortunately, it's specific to guile.

Wouldn't it be better to have a system that could be used to distribute
scheme libraries, including portable libraries and portability layers?

Granted, we may want to support r5rs, r6rs and r7rs libraries (perhaps
some libraries can run on all those versions; after all, most r4rs
libraries also ran on r5rs), in addition to the various common or main
scheme implementations.

I guess some basis for such a system could be quicklisp (
http://quicklisp.org https://github.com/quicklisp ), which would have to
be ported to scheme from Common Lisp (and yet, some parts such as
infrastructure quicklisp-dist or quicklisp-controller wouldn't have to
be translated, or only much later).


-- 
__Pascal Bourguignon__ http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk