I agree that on modern systems size is not that important anymore, but it is unpleasant to have an executable of serveral MBs when you know that the same program written in another language will be only a few hundred KBs.
On the other hand, it would be welcome to have a flavor of Gambit which is less expressive. I do not know how burdensome it would be to be able to prune whole parts of gambit to create "non development-ready" applications (that is, once the final product is to be delivered, compile it with a version of gambit which does not embed the whole runtime, does not allow debugging, etc). Or, maybe, allow the user to explicitely tell what he needs to import
I support this idea. As I have suggested in a previous mail, we should aim at making Gambit-C as modular as possible. For example, the system may be a bunch of modules: -- basic runtime -- numbers -- full numeric tower support -- characters and strings -- various data structures like hash table, vectors,... -- networking -- SRF1 -- SRF2 and so on
The above partition of the modules is only a random suggestion, but you get the idea. With such a system, only the relevant parts get into the final program, so we pay for only when we need.
Regards, Peter
----- 郵件原件 ---- 寄件人﹕ Adrien Piérard pierarda@iro.umontreal.ca 收件人 peter lo peter19852001@yahoo.com.hk 副本(CC) Bradley Lucier lucier@math.purdue.edu; Gambit Mailing List gambit-list@iro.umontreal.ca 傳送日期﹕ 2009 年 8月 18 日 星期二 上午 11:01:24 主題: Re: [gambit-list] Re: Re: How to create small standalone executable with Gambit-C?
2009/8/18 peter lo peter19852001@yahoo.com.hk:
and honestly when we intend to distribute executables, we do not want to leave out users using Windows.)?
It hurts me to say that, but size really isn't important anymore, *especially* when targetting desktop OS's like Windows, is it?r
On the other hand, it would be welcome to have a flavor of Gambit which is less expressive. I do not know how burdensome it would be to be able to prune whole parts of gambit to create "non development-ready" applications (that is, once the final product is to be delivered, compile it with a version of gambit which does not embed the whole runtime, does not allow debugging, etc). Or, maybe, allow the user to explicitely tell what he needs to import
(declare (with-great-power-comes-great-responsability ;; EVAL's environment should only know those, should it be used read current-input-port current-output-port char=? list + - /*))
(define (arithmetic-evaluator) ...)
(eval '(car '(1 2))) ;; segfault. You should've added CAR too. Don't complain to us.
Even though this is far from complete, this may be a compromise. (And this is in favor of giving a seconde parameter to EVAL, if the user has the capacity to create environments).
So, forgiving the fact that I am not an expert language implementer, how realistic are those ideas for Gambit-C?
P!