On Monday, March 4, 2013, David A. Wheeler <dwhee...@dwheeler.com> wrote:
> Alan Manuel Gloria:
>> Looking at the repo, it seems dwheeler has managed to make a short
>> summary of Honu.
>
> Yes.  It'll take some time to set up the mailing list, get people on it,
etc.  I want to get the process started quickly... to make sure you can be
part of it.
>
>> So, for now, I'd like to add a few short observations on Honu:
>>
>> 1.  It does not appear to have something like a "quote" syntax,
>> instead having list "constants" be expressed using more-mainstream
>> [...] syntax, which is actually nearer to (list x ...) than (quote (x
>> ...)). This means that instead of using symbols as labels for, say,
>> modes or states or enumerations (as would be second nature to a Lisp
>> programmer), Honu programmers are subtly encouraged to use global
>> variables bound to numbers (a technique more typical in mainstream
>> languages that cannot quote source-level identifiers).
>
> Is it possible that they just didn't document "quote"?
> I don't know for sure if the "This means..." is true.  If you could dig in
> and make sure of that, that'd be awesome.  If that is true, the loss
> of "quote" is in my mind a devastating weakness.

It's *possible* but as I understand it, pratt parsing's basemost parser
emits a flat list of tokens, and the actual parser takes that flat list and
in Honu calls into the macro code of detected defined keywords. The
low-level macro example suggests that, and shows the recursion to the pratt
parser expression parser entry point.

This could mean that a defined quote macro could be implemented which
recurses into the expression parser, which recurses into the macro
dispatch. So an innocent "quote foo" could mean something different if foo
is defined as a macro.

A quote syntax form could return a single token after it, maybe. But this
is not as powerful as the Lisp quote.

I'm not certain what happens if a macro expands to itself. In particular
this suggests a possibly bad interaction with the parser for "syntax"
keyword.

>
>> 2.  I think it might be better to clarify the discussion into saying
>> that Honu does not implicitly separate reading from macro-expansion.
>> Instead, in Honu macro-expansion appears to be an inherent part of the
>> parsing process, largely due to the Pratt parser technique that
>> appears to be the basis of Honu's parser.
>
> Okay.
>
>> (I'm posting this here since I don't have access to my hacking
>> computer right now, and I'll just do this later unless dwheeler gets
>> impatient or bored and does it anyway).
>
> Please edit away!
>
> I've made a few edits after I submitted the draft anyway.
>
> --- David A. Wheeler
>
>
>
------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> Readable-discuss mailing list
> Readable-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/readable-discuss
>
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss

Reply via email to