unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: "Maciek Godek" <pstrychuj@gmail.com>
To: guile-user@gnu.org
Subject: Re: Me no understand scoping
Date: Sat, 2 Aug 2008 23:36:24 +0200	[thread overview]
Message-ID: <e2ceda030808021436q7f96762oa91e89db4821bc48@mail.gmail.com> (raw)
In-Reply-To: <49dd78620808021043h66f6d953uff37c35d018afb80@mail.gmail.com>

>> I'm currently working on a little project (in my spare time). [...]
>
> Many thanks for providing this description.  The project looks fun, so
> I hope it continues to go well.
>
> A few thoughts occurred to me when reading through.
>
> 1. IMO this could be really beautifully done in GOOPS, by defining
> custom metaclasses and slot types.

I've been considering that, and I'm still having doubts.
The main reason is that there's no documented way
of accessing GOOPS objects from C (except from using
scm_c_eval_string etc.), or at least I couldn't find any
documentation for that.
Besides (which is the matter of personal taste), I don't
like the idea of using generics and trashing the global
namespace with them. (I mean, the sole idea of generics
is fine, but I wouldn't want to be forced to use them)

I also get this unpleasant feeling that all these 'getters'
and 'setters' are entities multiplied beyond necessity
(even the infamous C++ doesn't explicate them)

I'm really trying to get close
to the classical OOP notation: object.method() -- and
it's probably why I explore the potential of using these
"poor man's objects"

> 2. You say that your protocol is lisp-ish.  I have found it really
> useful, both in GDS and in another client/server project, to express
> the protocol entirely in lisp forms.  Simply because this means that
> you can use `read' to read exactly one protocol instruction; no
> parsing required!

Yeah, I had a similar idea, although at first I thought of
making a more efficient (but less elastic) binary protocol
that would require some mechanisms to convert various
supported guile types to binary form. I eventually concluded
that it's better to keep everything textual not only to praise
my laziness, but also it would be better to make a statistical
information-theory based compression protocol to speed
it up (if it turns out necessary).

> 3. It's still not obvious to me how this ends up using the-environment
> and local-eval.  If class variables never interact directly with the
> real environment, they could be just stored in a hash table..

I'm just looking for the most expressive way to use the language.
I've first heard of lisp like two years ago or so and even started
to learn that language from David Lamkins' "Successful Lisp"
and caught some of its spirit from Petet Graham's "On Lisp",
but I always kept getting distracted, finding other things to do.
But the point is that I saw that there is a 'make-hash-table' function
available in lisp -- and this lead me to the conclusion that it's probably
because the scopes/closures/environments implicitly use hash
tables to store their bindings (and the same mechanism was given
explicitly to the programmer).
And so I never stopped to believe that (define x 5) is more or
less equivalent to (hash-set! global-scope 'x 5).

>> PS gdm rocks! (thankyouthankyouthankyou!! it really did change
>> my way of writing the code)
>
> Do you mean GDS?  If so, thanks for your thanks!

Yes, it's a great piece of software, regardless of its name :)

There's no need for your thanks for my thanks as they are deserved.


M.




  reply	other threads:[~2008-08-02 21:36 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-29 21:18 Me no understand scoping Maciek Godek
2008-07-30  3:24 ` Clinton Ebadi
2008-07-30  8:42   ` Maciek Godek
2008-07-30 14:03     ` Jon Wilson
2008-07-30 15:04       ` Klaus Schilling
2008-07-30 19:24       ` Maciek Godek
2008-07-31  7:20         ` Neil Jerram
2008-07-31 19:21           ` Maciek Godek
2008-07-31 21:37             ` Neil Jerram
2008-07-31 23:07               ` Maciek Godek
2008-08-02 17:43                 ` Neil Jerram
2008-08-02 21:36                   ` Maciek Godek [this message]
2008-08-08 20:54                     ` Neil Jerram
2008-08-10 21:49                       ` Maciek Godek
2008-08-09 11:05                     ` Andy Wingo
2008-08-10 22:30                       ` Maciek Godek
2008-09-11 14:56                       ` JonWilson
2008-07-31 23:48             ` Clinton Ebadi
2008-08-01 22:00               ` Maciek Godek
2008-08-02  5:13                 ` Jon Wilson
2008-08-02 21:35                   ` Maciek Godek
     [not found] <cmu-lmtpd-29005-1217434291-0@mail-imap1.uio.no>
2008-07-30 16:18 ` Kjetil S. Matheussen
2008-07-30 19:03   ` Clinton Ebadi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e2ceda030808021436q7f96762oa91e89db4821bc48@mail.gmail.com \
    --to=pstrychuj@gmail.com \
    --cc=guile-user@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).