I've been working on a domain-specific language for a bit now and got
most of it working how I'd like and this morning went to go wrap it in
a package. The problem is now it doesn't work because the symbols it
creates are part of that package. So, if I'm outside that package, the
symbols don't match and I'm pretty much hosed.
One solution that I can do (and it works, I just dislike it) is to
make all my symbols in that package keywords, but I'm pinging here to
see if anyone has some other suggestions I can try.
Thanks!
Jeff M.
On Mar 17, 5:00 pm, "Jeff M." <·······@gmail.com> wrote:
> I've been working on a domain-specific language for a bit now and got
> most of it working how I'd like and this morning went to go wrap it in
> a package. The problem is now it doesn't work because the symbols it
> creates are part of that package. So, if I'm outside that package, the
> symbols don't match and I'm pretty much hosed.
>
> One solution that I can do (and it works, I just dislike it) is to
> make all my symbols in that package keywords, but I'm pinging here to
> see if anyone has some other suggestions I can try.
>
> Thanks!
>
> Jeff M.
Can't you use the :export keyword of defpackage and export the symbols
you need? i.e.
(defpackage :my-package
(:use :foo)
(:export :symbol1
:symbol2
:symbol3...))
Sölvi P.
On Mar 17, 12:00 pm, "Jeff M." <·······@gmail.com> wrote:
> a package ... doesn't work because the symbols it
> creates are part of that package.
Export the symbols if you want them to be fixed, or
make them arguments in your macros if you want the
user to name their own.
------------------------------------------------
Dan Bensen
http://www.prairienet.org/~dsb/
Jeff M. wrote:
> I've been working on a domain-specific language for a bit now and got
> most of it working how I'd like and this morning went to go wrap it in
> a package. The problem is now it doesn't work because the symbols it
> creates are part of that package. So, if I'm outside that package, the
> symbols don't match and I'm pretty much hosed.
>
> One solution that I can do (and it works, I just dislike it) is to
> make all my symbols in that package keywords, but I'm pinging here to
> see if anyone has some other suggestions I can try.
I have little idea what you are talking about from this description.
This is esp. confusing: "because the symbols it creates are part of that
package". Is this simply about not knowing about exporting symbols? How
about an example of some code that does not compile and the actual
warning or error you get?
The good news is that you do not have to do anything weird, you just
gotta do a lot better on the problem report.
hth, kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
In article <·························@cv.net>,
Ken Tilton <···········@optonline.net> wrote:
> Jeff M. wrote:
> > I've been working on a domain-specific language for a bit now and got
> > most of it working how I'd like and this morning went to go wrap it in
> > a package. The problem is now it doesn't work because the symbols it
> > creates are part of that package. So, if I'm outside that package, the
> > symbols don't match and I'm pretty much hosed.
> >
> > One solution that I can do (and it works, I just dislike it) is to
> > make all my symbols in that package keywords, but I'm pinging here to
> > see if anyone has some other suggestions I can try.
>
> I have little idea what you are talking about from this description.
> This is esp. confusing: "because the symbols it creates are part of that
> package". Is this simply about not knowing about exporting symbols? How
> about an example of some code that does not compile and the actual
> warning or error you get?
I think I can translate for you. He's written a DSL implementation.
Something like LOOP, which has lots of special symbols that have to be
recognized within the language, and he's using EQ to compare the input
against his symbols.
LOOP accomplishes this by using STRING-EQUAL rather than EQ, so it
doesn't care what package its keywords are in.
Others have suggested using EXPORT. That's OK if the users always USE
the package, so that they'll inherit all the public symbols. But if
they typically use the DSL by invoking it with a qualified symbol, they
won't get all the keywords, and they'll need to qualify them as well.
Would LOOP be as popular if you had to write something like:
(loop:loop loop:for i loop:in mylist
loop:do (print i)
loop:finally loop:return i)
I think the most common solution to this is to use :keywords, so you get
something like
(loop:loop :for i :in mylist
:do (print i)
:finally :return i)
Some people even write their loops like this (except for the package
prefix in loop:loop), even though it's not required, because they like
the keywords to stand out.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
Barry Margolin wrote:
> Others have suggested using EXPORT. That's OK if the users always USE
> the package, so that they'll inherit all the public symbols. But if
> they typically use the DSL by invoking it with a qualified symbol, they
> won't get all the keywords, and they'll need to qualify them as well.
> Would LOOP be as popular if you had to write something like:
>
> (loop:loop loop:for i loop:in mylist
> loop:do (print i)
> loop:finally loop:return i)
That is what ITERATE does.
CL-USER> (setq *print-length* 20)
20
CL-USER> (loop for s being each external-symbol of :iterate collect s)
(ITERATE:AS ITERATE:ELSE ITERATE:MAXIMIZE ITERATE:DEFSYNONYM
ITERATE:DISPLAY-ITERATE-CLAUSES ITERATE:INITIALLY ITERATE:UNTIL
ITERATE:IF-FIRST-TIME ITERATE:FIRST-TIME-P ITERATE:FIRST-ITERATION-P
ITERATE:ITER ITERATE:MINIMIZE ITERATE:SUMMING ITERATE:IN
ITERATE:NUNIONING ITERATE:FOR ITERATE:COLLECTING ITERATE:FINDING
ITERATE:NEXT-ITERATION ITERATE:ACCUMULATING ...)
CL-USER>
I wouldn't like having to fully qualify each symbol with the package
name, either, but I also personally don't find either using the package
or importing the specific symbols I want to use to be an issue.
However, I did have a silly little utility macro UNCOMMON-LISP:AS, which
I renamed to USE so that I wouldn't have to bother with shadowing
imports from one or the other package, and qualifying the other symbol
with its package.
Barry Margolin wrote:
> In article <·························@cv.net>,
> Ken Tilton <···········@optonline.net> wrote:
>
>
>>Jeff M. wrote:
>>
>>>I've been working on a domain-specific language for a bit now and got
>>>most of it working how I'd like and this morning went to go wrap it in
>>>a package. The problem is now it doesn't work because the symbols it
>>>creates are part of that package. So, if I'm outside that package, the
>>>symbols don't match and I'm pretty much hosed.
>>>
>>>One solution that I can do (and it works, I just dislike it) is to
>>>make all my symbols in that package keywords, but I'm pinging here to
>>>see if anyone has some other suggestions I can try.
>>
>>I have little idea what you are talking about from this description.
>>This is esp. confusing: "because the symbols it creates are part of that
>>package". Is this simply about not knowing about exporting symbols? How
>>about an example of some code that does not compile and the actual
>>warning or error you get?
>
>
> I think I can translate for you. He's written a DSL implementation.
> Something like LOOP, which has lots of special symbols that have to be
> recognized within the language, and he's using EQ to compare the input
> against his symbols.
Ah, thx.
>
> LOOP accomplishes this by using STRING-EQUAL rather than EQ, so it
> doesn't care what package its keywords are in.
Clever! Might be just what the OP needs.
>
> Others have suggested using EXPORT. That's OK if the users always USE
> the package, so that they'll inherit all the public symbols. But if
> they typically use the DSL by invoking it with a qualified symbol, they
> won't get all the keywords, and they'll need to qualify them as well.
Ah, well if I want to use a DSL I should think I'd be using its package.
I mean, I wouldn't run around China speaking Latin, would I?
Anyway, nice overview of the issues. Thx.
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
In article <························@cv.net>,
Ken Tilton <···········@optonline.net> wrote:
> Ah, well if I want to use a DSL I should think I'd be using its package.
> I mean, I wouldn't run around China speaking Latin, would I?
The problem is that importing lots of symbols with names that are common
words is that it's likely to cause conflicts. It's likely that several
different DSLs will use the same keywords, and if you try to USE two of
these packages in your application you'll get complaints.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
On Mon, 17 Mar 2008 10:00:21 -0700, Jeff M. wrote:
> I've been working on a domain-specific language for a bit now and got
> most of it working how I'd like and this morning went to go wrap it in a
> package. The problem is now it doesn't work because the symbols it
> creates are part of that package. So, if I'm outside that package, the
> symbols don't match and I'm pretty much hosed.
>
> One solution that I can do (and it works, I just dislike it) is to make
> all my symbols in that package keywords, but I'm pinging here to see if
> anyone has some other suggestions I can try.
It really depends on how the DSL is meant to be used. If it's something
like LOOP, then you simply test for SYMBOL-NAME rather than EQ'ness when
dereferencing the symbols.
Other options are actually exporting the symbols, using a reader macro,
or, as you know, using keywords.
If you want to tell us a little more about the DSL and its usage, you
might solicit some better advice :).
Cheers,
drewc
>
> Thanks!
>
> Jeff M.
--
Posted via a free Usenet account from http://www.teranews.com
On Mar 17, 1:47 pm, Drew Crampsie <·············@gmail.com> wrote:
> On Mon, 17 Mar 2008 10:00:21 -0700, Jeff M. wrote:
> > I've been working on a domain-specific language for a bit now and got
> > most of it working how I'd like and this morning went to go wrap it in a
> > package. The problem is now it doesn't work because the symbols it
> > creates are part of that package. So, if I'm outside that package, the
> > symbols don't match and I'm pretty much hosed.
>
> > One solution that I can do (and it works, I just dislike it) is to make
> > all my symbols in that package keywords, but I'm pinging here to see if
> > anyone has some other suggestions I can try.
>
> It really depends on how the DSL is meant to be used. If it's something
> like LOOP, then you simply test for SYMBOL-NAME rather than EQ'ness when
> dereferencing the symbols.
>
> Other options are actually exporting the symbols, using a reader macro,
> or, as you know, using keywords.
>
> If you want to tell us a little more about the DSL and its usage, you
> might solicit some better advice :).
Thanks everyone for the recommendations.
In the end I just decided to make the various symbols keywords (there
weren't too many of them). The DSL is nothing special, it's really
just an assembler with some special features thrown in. For example:
(arm:asm
((:cmp :r0 :r1)
(:bne skip)
(:add :r0 :r2 :r2 :lsl 4)
skip
(:bx :lr)))
I really wanted the instructions and registers to not be keywords
(just extra typing and characters that tend to obscure the code some).
I may try just using #'symbol-name and #'equal, though.
Thanks again!
Jeff M.
Jeff M. wrote:
> On Mar 17, 1:47 pm, Drew Crampsie <·············@gmail.com> wrote:
>> On Mon, 17 Mar 2008 10:00:21 -0700, Jeff M. wrote:
>>> I've been working on a domain-specific language for a bit now and got
>>> most of it working how I'd like and this morning went to go wrap it in a
>>> package. The problem is now it doesn't work because the symbols it
>>> creates are part of that package. So, if I'm outside that package, the
>>> symbols don't match and I'm pretty much hosed.
>>> One solution that I can do (and it works, I just dislike it) is to make
>>> all my symbols in that package keywords, but I'm pinging here to see if
>>> anyone has some other suggestions I can try.
>> It really depends on how the DSL is meant to be used. If it's something
>> like LOOP, then you simply test for SYMBOL-NAME rather than EQ'ness when
>> dereferencing the symbols.
>>
>> Other options are actually exporting the symbols, using a reader macro,
>> or, as you know, using keywords.
>>
>> If you want to tell us a little more about the DSL and its usage, you
>> might solicit some better advice :).
>
>
> Thanks everyone for the recommendations.
>
> In the end I just decided to make the various symbols keywords (there
> weren't too many of them). The DSL is nothing special, it's really
> just an assembler with some special features thrown in. For example:
>
> (arm:asm
> ((:cmp :r0 :r1)
> (:bne skip)
> (:add :r0 :r2 :r2 :lsl 4)
> skip
> (:bx :lr)))
>
> I really wanted the instructions and registers to not be keywords
> (just extra typing and characters that tend to obscure the code some).
> I may try just using #'symbol-name and #'equal, though.
>
> Thanks again!
>
> Jeff M.
You could try using T. Bradshaw's "Read-time Packages"
http://www.tfeb.org/lisp/hax.html#READ-PACKAGES
This would make the syntax weird, though.
Tim S