I'm interpreting the byte contents of a binary file using a a simple case
statement. The incoming stuff consists of integers, which I'd like to
assign symbolic "names" to - so that I don't have to look at raw integers
when reading the case statement code itself.
I had expected this to work, but it doesn't:
(defconstant thing 3)
(case (next-byte-from-file)
(thing (stuff)))
and seems to need to be written as
(case (next-byte-from-file)
(#.thing (stuff)))
Is there a "better" / more elegant way to achieve this?
pt
Paul Tarvydas wrote:
> I'm interpreting the byte contents of a binary file using a a simple case
> statement. The incoming stuff consists of integers, which I'd like to
> assign symbolic "names" to - so that I don't have to look at raw integers
> when reading the case statement code itself.
>
> I had expected this to work, but it doesn't:
>
> (defconstant thing 3)
>
> (case (next-byte-from-file)
> (thing (stuff)))
>
> and seems to need to be written as
>
> (case (next-byte-from-file)
> (#.thing (stuff)))
>
> Is there a "better" / more elegant way to achieve this?
I like the #.thing trick. If you really want to lose it, tho, how about
a simple casenum macro which expands into a cond (apologies if I am
stating the obvious)?
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton <·······@nyc.rr.com> writes:
> Paul Tarvydas wrote:
> > I'm interpreting the byte contents of a binary file using a a simple case
> > statement. The incoming stuff consists of integers, which I'd like to
> > assign symbolic "names" to - so that I don't have to look at raw integers
> > when reading the case statement code itself.
> how about a simple casenum macro which expands into a cond
> (apologies if I am stating the obvious)?
You got it almost right. Write a case-like macro that evaluates
constant keys (not using EVAL, of course), and expands into CASE :-)
I believe comp.lang.lisp has seen several of these already.
Regards,
Jorg Hohle
Telekom/T-Systems Technology Center
"Joerg Hoehle" <······@users.sourceforge.net> wrote in message
··················@users.sourceforge.net...
> Kenny Tilton <·······@nyc.rr.com> writes:
> > Paul Tarvydas wrote:
> > > I'm interpreting the byte contents of a binary file using a a simple
case
> > > statement. The incoming stuff consists of integers, which I'd like to
> > > assign symbolic "names" to - so that I don't have to look at raw
integers
> > > when reading the case statement code itself.
>
> > how about a simple casenum macro which expands into a cond
> > (apologies if I am stating the obvious)?
>
> You got it almost right. Write a case-like macro that evaluates
> constant keys (not using EVAL, of course), and expands into CASE :-)
> I believe comp.lang.lisp has seen several of these already.
Personally, given the specialized requirements that make someone want this I
think it is a good situation for #.
(case foo
(#.+one+ (first-stuff))
(#.+two+ (second-stuff)))
with appropriate definitions of +one+ and +two+ of course.
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
Paul Tarvydas <········@attcanada.ca> writes:
> I'm interpreting the byte contents of a binary file using a a simple case
> statement. The incoming stuff consists of integers, which I'd like to
> assign symbolic "names" to - so that I don't have to look at raw integers
> when reading the case statement code itself.
>
> I had expected this to work, but it doesn't:
>
> (defconstant thing 3)
>
> (case (next-byte-from-file)
> (thing (stuff)))
>
> and seems to need to be written as
>
> (case (next-byte-from-file)
> (#.thing (stuff)))
>
> Is there a "better" / more elegant way to achieve this?
Perhaps
(case (aref *things* (next-byte-from-file))
(thing (stuff))
(...))
Where *things* is an array of symbols indexed by integers. If the
range of integer values is large, a hash table may be more
appropriate.
Bj�rn
Paul Tarvydas wrote:
> I'm interpreting the byte contents of a binary file using a a simple case
> statement. The incoming stuff consists of integers, which I'd like to
> assign symbolic "names" to - so that I don't have to look at raw integers
> when reading the case statement code itself.
>
> I had expected this to work, but it doesn't:
>
> (defconstant thing 3)
>
> (case (next-byte-from-file)
> (thing (stuff)))
>
> and seems to need to be written as
>
> (case (next-byte-from-file)
> (#.thing (stuff)))
>
> Is there a "better" / more elegant way to achieve this?
It may be good to know why this is the way it is. The CASE form does not
evaluate the keys because this enables some optimizations, like
determining jump tables at compile time.
I'd write a wrapper function next-symbol-from-file, similar to what
Bjoern suggested.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza wrote:
> It may be good to know why this is the way it is. The CASE form does not
> evaluate the keys because this enables some optimizations, like
> determining jump tables at compile time.
Now that you mention it, my expectation is not that CASE evaluates its keys,
but that DEFCONSTANT could (should?) be a way of declaring "manifest
constants" (constants which are known at compile-time).
I was expecting an optimization which noticed that the defconstant creates a
name which is dutifully replaced by its constant value by the compiler -
somewhat like a macro. Maybe I'm just unaware of a less-commonly used form
of macros (or reader macros)?
pt
Paul> I was expecting an optimization which noticed that the
Paul> defconstant creates a name which is dutifully replaced by its
Paul> constant value by the compiler - somewhat like a macro.
It sort of goes back to the multiple namespace issue: Even as you do
(defconstant thing 3) you should still expect the symbol THING to
behave normally. That is you can still use it to name a function, a
class, a slot, bind it with LET or use it as a symbolic CASE key.
Ole
·········@cern.ch wrote:
> It sort of goes back to the multiple namespace issue: Even as you do
> (defconstant thing 3) you should still expect the symbol THING to
> behave normally. That is you can still use it to name a function, a
> class, a slot, bind it with LET or use it as a symbolic CASE key.
Not quite: you're not allowed to bind symbols naming constants with LET,
and using them as slot names is controversial (the standard can be read as
prohibiting that).
Cheers,
-- Nikodemus "Not as clumsy or random as a C++ or Java.
An elegant weapon for a more civilized time."
Nikodemus> Not quite: you're not allowed to bind symbols naming
Nikodemus> constants with LET, and using them as slot names is
Nikodemus> controversial (the standard can be read as prohibiting
Nikodemus> that).
I stand corrected, sorry for posting desinformation without checking
my sources.
So I guess the only reason DEFCONSTANT doesn't affect symbolic CASE
keys is that it has been decided it shouldn't?
Ole
·········@cern.ch wrote:
> So I guess the only reason DEFCONSTANT doesn't affect symbolic CASE
> keys is that it has been decided it shouldn't?
More likely the reason that the CASE keys aren't evaluated at all...
Cheers,
-- Nikodemus "Not as clumsy or random as a C++ or Java.
An elegant weapon for a more civilized time."
·········@random-state.net writes:
> you're not allowed to bind symbols naming constants with LET,
> and using them as slot names is controversial (the standard can
> be read as prohibiting that).
Which sections of the standard -- perhaps WITH-SLOTS or boa
lambda lists?
Kalle Olavi Niemitalo <···@iki.fi> wrote:
>> you're not allowed to bind symbols naming constants with LET,
>> and using them as slot names is controversial (the standard can
>> be read as prohibiting that).
> Which sections of the standard -- perhaps WITH-SLOTS or boa
> lambda lists?
7.5.1 "...The name of a slot is a symbol that is syntactically valid for
use as a variable name."
However, I at least am being persuaded that constants should be fine
there. For details see sbcl-devel.
Cheers,
-- Nikodemus "Not as clumsy or random as a C++ or Java.
An elegant weapon for a more civilized time."
Paul Tarvydas wrote:
> I was expecting an optimization which noticed that the defconstant creates a
> name which is dutifully replaced by its constant value by the compiler -
> somewhat like a macro. Maybe I'm just unaware of a less-commonly used form
> of macros (or reader macros)?
Symbol macros are close (see define-symbol-macro). However, CASE still
doesn't replace symbol macros by their expansion.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."