Peter Bex scripsit:
> This inconsistency could be considered a bug: if a new identifier is
> introduced at the toplevel which "shadows" a macro, it could erase the
> macro. It's not a priority because the spec doesn't really say what to
> do, and the responses of various Schemes differ in this.
Hi there,
I have registered an assembly for CHICKEN enthusiasts and other
lispy people for the upcomming 31C3:
https://events.ccc.de/congress/2014/wiki/Assembly:The_%28un%29employed_schemers_%26_lispers_guild
If you can make it to Hamburg, I am looking forward to hacking with you there!
Cheers,
Hi,
> that's right, but you can also try to protect against a client that
> tries to obtain information from the server side to which it isn't
So, you'd actually be protecting the association between the server and the
legitimate client against an unauthorized third party, no?
> entitled. Howeve
On Tue, 28 Oct 2014, Florian Zumbiehl wrote:
[...]
I am not sure I understand what you mean--you never can protect against a
client that doesn't want to protect the session, they always could just
publish the session key, or the decrypted data, or whatever. The protection
should always focus on
On Tue, Oct 28, 2014 at 11:02:40PM +0100, Michele La Monaca wrote:
> On Tue, Oct 28, 2014 at 9:35 PM, Peter Bex wrote:
> > Yes, this is according to spec. Macros aren't first-class, so whenever
> > you use the same identifier in a non-application context it will look up
> > the identifier in the
