Re: [Boost-docs] The beauty of LATEX

Subject: Re: [Boost-docs] The beauty of LATEX
From: Joel de Guzman (joel_at_[hidden])
Date: 2011-10-25 15:03:50

On 10/25/2011 6:01 PM, Daniel James wrote:
> On 22 October 2011 11:09, Joel de Guzman <joel_at_[hidden]> wrote:
>>
>> Let me re-code that using the latest syntax tweak
>> (http://pastebin.com/rvQfCVKh),
>>
>> [def foo a][[a]]
>>
>> [def bar][x]
>>
>> [foo [[lambda][bar]]]
>>
>> Here, foo expects a nullary lambda. You pass [lambda][bar],
>> which, when evaluated in foo as [a], returns the text 'x'.
>>
>> Did I get that right? I think it's quite consistent with
>> our current behavior where arguments become nullary templates
>> that need to be invoked. Here, lambdas are n-ary functions.
>> It just so happens that bar is also nullary.
> 
> Yes, that works. Although now when you want to pass the function as a
> parameter, you have to define another lambda function. Which could get
> very verbose - especially if the function takes a few arguments. It

That's how it's done in lisp/scheme, it's foolish to go invent
something else.

> also requires you to always know how many arguments a function takes.

What's wrong with that? Ah, you want it like C function pointers
where you pass only f and be done with it? That's too limiting.
You can't even curry with it.

> No, the idea was to pass the function 'bar' to foo, then when it calls
> 'f' it should call 'bar' at the global scope because it was bound
> there, not the local scope. Since this is a functional language, you
> probably could call nullary functions early, but functions that take
> arguments will need to be bound. It should be okay with the lambda
> syntax as long as a closure is created for the lambda.
> 
>> Could you please re-code that with the latest syntax?
>> It would also help if you provide meaningful cases like
>> dup, cat, etc. instead of foo and bar.
> 
> [def [foo f bar] [f]]
> [def [bar] 1]
> [foo [lambda[] [bar]]]
> 
> The point of not using meaningful names is to consider it as the
> interpreter would consider it. And I'm not sure how to create a simple
> realistic example with this issue - these problems normally turn up in
> more complicated examples. There were a couple of tickets for such
> problems with quickbook:
> 
> https://svn.boost.org/trac/boost/ticket/2034
> https://svn.boost.org/trac/boost/ticket/2036

Ah static/lexical vs. dynamic scoping. Both Scheme and Lisp
now are lexically scoped by default. A good thing about
modelling the language from Scheme is that when in doubt,
we just do as Scheme does.

I know I did it wrong the first time. Thanks for fixing it.

> It wasn't immediately obvious what was going on.
> 
>>> Oh, I forgot to mention before, you need something to distinguish
>>> between lists and non-lists, for handling trees.
>>
>> Expound please?
> 
> Certain generation tasks will require processing trees, and the
> current language doesn't allow for that. For a very simple example,
> say you write:
> 
> [def [list items]
>   <ol>
>     [transform [items] [lambda [x] <li>[x]</li>]
>   </ol>
> ]
> 
> Now someone accidentally writes:
> 
> [list item]
> 
> The result is:
> 
> <ol>
>   <li>i</li>
>   <li>t</li>
>   <li>e</li>
>   <li>m</li>
> </ol>
> 
> Which from the user's perspective is a bit weird. It would be nicer to
> have a either reasonable error message or to generate something more
> sensible.
> 
> Now let's say you generate a tree:
> 
> [para
>     [para Some Text]
>     [table]
>     More text
> ]
> 
> And you wish to fix it up to:
> 
> [para Some Text]
> [table]
> [para More text]
> 
> That's a fairly simple tree transformation, but impossible to
> implement with the current language.
> 
> You might also want to consider returning lists and functions from
> functions, it isn't entirely clear how that works or if it's possible.

Again, I welcome you to go in and tweak the informal specs.
It just started out as an academic exercise. I'm sure there
are lots of holes still, especially since it hasn't been
tested. Soonish, I intend to write a prototype as a playground
of ideas. I'm sure by then a lot of issues will slowly reveal
themselves.

PS> Rest in peace, John McCarthy. http://tinyurl.com/6e29e8q

Regards,
-- 
Joel de Guzman
http://www.boostpro.com
http://boost-spirit.com