Re: The beauty of LATEX

On 22 October 2011 11:09, Joel de Guzman <[email protected]> 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
also requires you to always know how many arguments a function takes.

>> Whenever you have a list parameter, you'll need to either bind it to
>> the state at the location it was passed or do a function lookup at
>> that point, so that this doesn't do the wrong thing:
>>
>> [def foo f bar][[`call [`f]]]
>> [def bar][1]
>> [`foo [bar] 2]
>>
>> I'm not sure that call 'foo' is correct, the right call might be:
>> [`foo [[bar]][2]].
>
> Ok, I think too much super-luminal neutrinos zipped through
> me and I'm lost :P Are you invoking bar at function call
> to foo?

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

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.