some more functions for preLisp, hash-table related
eduitnoa rubicubez
notation.
(defmacro h.delete-if(h k v &body cond)
`(h.each ,h ,k ,v (when (progn ,@cond) (remhash ,k ,h))))
(defmacro h.select (h k v &body cond)
`(let (re)
(h.each ,h ,k ,v (when (progn ,@cond) (push (list ,k ,v) re)))
re))
(defun h.length(h)
(hash-table-count h))
(defun h.values_at(h &rest keys)
(loop for k in keys collect (gethash k h)))
(defun h.keys(h)
(let (re)
(h.each-key h1 k (push k re))
re))
(defun h.values(h1 &aux re)
(h.each-value h1 v (push v re))
re)
(defun h.empty?(h)
(zerop (hash-table-count h)))
(defun h.value?(h v)
(h.each-value h v1 (when (equal v v1) (return-from h.value? t)))
nil)
(defun h.delete(h k)
(prog1 (gethash k h) (remhash k h)))
(defun h.invert(h)
(let ((h1 (make-hash-table)))
(h.each h k v (h.setf h1 v k))
h1))
(defun h.inspect(h)
(let ((s "") (sep ""))
(h.each h k v
(setq s (s.+ s sep (to-str k) " => " (to-str v))
sep ", "))
s))
Drew Crampsie
> I just translated some of the functions in ruby usando "preLisp"
> notation.
>
> (defmacro h.delete-if(h k v &body cond)
> `(h.each ,h ,k ,v (when (progn ,@cond) (remhash ,k ,h))))
You might want to consider learning Common Lisp before you try and 'fix'
it. Consider :
(defun make-foo (value)
(let ((table (make-hash-table)))
(setf (gethash :value table) value)
table))
(let ((foos (loop for n from 1 to 5 do (make-foo n))))
(h.delete-if (pop foos) :value 3))
... and that's beside the point, this should be a function. There is no
need to use a macro here, and a few good reasons not to!
As for the rest of this, you need to look at DEFGENERIC and figure out
why what you are doing is a serious step backwards.
It's generally a bad idea to try and fix something that :
a) is not broken
b) you know nothing about
c) is better than your solution
All i can suggest is that you learn lisp and use lisp before you try to
figure out what's good for beginners and what's good for lisp.You have
to learn lisp on its own terms, not try to turn it into something that
familiar and comfortable.
For some reason Common Lisp attracts a fair share of people who as a
first reaction try to 'fix' it. If lisp is so broken that you
need to turn it into ruby, why not stick with ruby?
Cheers,
drewc
eduitnoa rubicubez
Drew Crampsie ha escrito:
> For some reason Common Lisp attracts a fair share of people who as a
> first reaction try to 'fix' it. If lisp is so broken that you
> need to turn it into ruby, why not stick with ruby?
I understand your point of view.
See now from this way, I try to construct a ruby to Lisp translator,
but it must be top speed, so you must pay a price with declarations,
so as an intermediate place, I construct a preLisp notation.
Thanks for the feedback, I think now I have an overview of what Lisper
think about this.
Cheers.
Pascal J. Bourguignon
> Drew Crampsie ha escrito:
>> For some reason Common Lisp attracts a fair share of people who as a
>> first reaction try to 'fix' it. If lisp is so broken that you
>> need to turn it into ruby, why not stick with ruby?
>
>
> I understand your point of view.
>
> See now from this way, I try to construct a ruby to Lisp translator,
> but it must be top speed, so you must pay a price with declarations,
> so as an intermediate place, I construct a preLisp notation.
First there's the problem of Ruby Syntax. Since Ruby is not a
language that is defined, it has no syntax. There's a yacc source
file somewhere, and if you like yacc, you will have a lot of joy with
it!
Anyways, translating it to one of the lisp equivalent (eg cl-lalr,
zebu, etc) will already be a lot of work, but the main problem is that
any day, on a whim of Matz, your translated grammar will be obsolete.
That's the problem with languages with no definition, you're at a
moving target, and nowadays with Internet and remote VCS, these
targets move very fast!
You're a lucky guy! Here is a Ruby grammar in sexp form I made last
year (I don't have the exact Ruby version at hand, and I can't
guarantee that it's correct, caveat emptor).
http://paste.lisp.org/display/92988
Well, I guess that once you've got the syntax tamed, it will be rather
easy to write the runtime library (implement the Ruby object system),
and the Ruby library (implement the Ruby classes) in CL. Translating
Ruby code to Lisp will in general be rather straightforward, but
you'll have to be careful with a few gotchas (eg. dealing with the
scope of variables is "surprizing" in Ruby).
> Thanks for the feedback, I think now I have an overview of what Lisper
> think about this.
>
> Cheers.
--
__Pascal Bourguignon__ http://www.informatimago.com/