Re: My thoughts on C# and gaming.

On Wed, Jan 27, 2010 at 7:54 PM, OvermindDL1 <[email protected]> wrote:
>> I apologize if we are talking at cross-purposes or if I have been
>> unclear in conveying my point.
>>
>> In posting the above Ruby DSL, I was attempting to respond to
>> your statement, "all other differences are primarily syntactical
>> in nature and thus not very interesting as far as I am concerned."
>>
>> As cool as Lisp is--which I have gleaned more from reading about
>> its design than from my meager experience with the language so far--
>> my understanding is that Lisp syntax won't allow an uncluttered
>> DSL like the above to be parsed *as Lisp*.
>>
>> Ruby syntax, on the other hand, is flexible enough to parse the
>> above *as Ruby*.
>>
>> As such, it is relatively common for Ruby programmers to create
>> so-called internal DSLs rather than external DSLs, when the intent
>> is simply to bring the programming language itself closer to the
>> problem domain.  (Obviously if the DSL is intended to be edited by
>> an untrusted user, than an internal DSL would be a poor choice.)
>>
>> At the risk of belaboring the point, my argument is that Ruby's
>> syntactical flexibility is useful, and as far as I know, can't
>> readily be mimicked by the other languages we've been discussing.
>
> Actually, with read-macros in LISP, you can make LISP look like
> anything, so you could probably change:
>  p ARGF.read.scan(/\d{1,3}(\.\d{1,3}){3}/).uniq.size
> Into a Lisp version of something like:
>  #Ruby p ARGF.read.scan(/\d{1,3}(\.\d{1,3}){3}/).uniq.size
>
> Lisp can literally become anything.  The combination of macros and
> read-macros are insanely powerful.  The D language comes pretty close
> to that power (although not completely) with its string templates and
> mixin support.  You can quite *literally* make a Ruby parser embedded
> in Lisp in such a way that you can freely mix both.

I guess I should describe read-macro's quickly to explain how that
works.  A read-macro in Lisp looks for a token string (usually
starting with #) where an open parenthesis usually can usually appear.
 As I recall, most LISP implementations (any that follow the standard)
match the first two characters after that, but you can match further
more inside your read-macro.  At that point your read-macro is passed
the character stream directly, and you match things and build a Lisp
structure based on the stream input (in other words you build a
parser).  When you reach the end of the part of the stream that you
want to parse then you just return the Lisp structure you built, and
it compiles that structure as code in-place, and parsing happens
through normal Lisp after that as normal.

So I guess in Ruby'ish/Python psuedo-code, it could be like this:

defRM Ruby(input): # defRM == defReadMacro, will match #Ruby
  return parseRubyStream(input)

#Ruby someRuby.code

And when the #Ruby line is reached is then passes the input iterator
(starting at the space after the #Ruby) to the Ruby defRM
function/read-macro, where it then makes an ast and returns it and it
is compiled in-place.  Makes more sense in Lisp, but you can see how
that pattern can be extended to other languages that support
data-as-code/code-as-data, or jsut any that can build their own syntax
tree at least.
_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com