[Prev][Next][Index][Thread]

Re: "Lisp" syntax differences

Chris Page wrote:
...
> There's been a raging discussion on comp.lang.lisp about Lisp syntax. Dylan
> was mentioned a number of times, not surprisingly.

  I haven't seen the lastest on those threads but I seen enough of them
  over the years to have a good guess what the main "fightin' words" are. 

> It got me wondering: What, exactly, are the "hard" differences between Dylan
> and Lisp syntax? 

  Syntax doesn't significantly matter.   Semantic differences are the 
  difficult part of computer language translations.  At least the 
  ones I've participated in.  :-)


> By that I mean, for example, if you wanted to convert
> between the two, what cannot be converted?

  You are likely to get into a heap of trouble when you get to macros. 
  That's because the semantics, meaning, of what you are doing is going
  to change significantly if you are dealing with maniplating lisp flavored
  s-expressions versus manipulating infix, syntactic marker rich, source
  fragments. 

  You also may end up with some interesting effects of trying to model
  "adjectives" in a compatible way in the two different surface syntaxes. 
  I guess that might go into the category of macros also. 


> I don't know how close the "Lisp syntax" version is to really being Lisp
> syntax,

   IMHO "Lisp syntax" is that you 
             a.  open and close with a left/right paren 
             b.  the operator comes first
             c.  the operands and/or markers (keywords, punctuation )
                 come in the middle. 

   [ For lack of a better word, the more "uniform core" lisp syntax doesn't
     have markers.  At some point all the macros are expanded and you're
     just left with operands and arguments. ] 

   That's it.  It isn't that hard to translate to. The hard part is 
   can you "say" what is being said in the other language. 
   Given a fixed core language than cannot be expanded with user defined
   constructs with the same set of underlying predefined functions mapping
   one to one shouldn't be to much of problem. 


> By the way, if there's a complete and deterministic transformation between
> Dylan and Lisp syntaxes, both could be supported. It occurs to me that a
> Dylan parser could easily handle both and use Lisp syntax if it sees a "("
> at top-level.

   If you leave macros out yeah sure.   That's sort of like how you can 
   mostly model the exception semantics of Dylan in Java/C++ , but not 
   not the restart semantics. Does the missing part matter much? 


Lyman
References: