[gambit-list] Thoughts on Scheme

Jason Felice jason.m.felice at gmail.com
Mon Jan 7 10:37:08 EST 2013


Thanks for the feedback.  I appreciate it.  I think I'd like to narrow my
focus to the primary thing, which was the lack of generality of the
built-in procedures, and generics.

Making these efficient to compile (especially with a module system) seems
hard, but rewarding.  I'm thinking about how to do this more.  Personally,
I don't think efficiency in terms of constant factors should often win
versus code which could be more general.   Clearly this is a value choice;
however, I wonder how well a compiler can eliminate type dispatching
without adding type annotation to the language.

So, I'm thinking about these things and will let them stew for... another
10 years?  I don't know.

Thanks,
-Jason



On Sun, Jan 6, 2013 at 5:38 AM, Álvaro Castro-Castilla <
alvaro.castro.castilla at gmail.com> wrote:

> I agree with Meng.
> I see syntax-rules as a DSL for hygienic macros. It is completely
> "schemey" in the same way libraries like Kanren for logic programming, or
> FrTime for reactive programming are. The only difference is that when using
> hygienic macros, your code becomes data as well, to be processed before it
> actually turns into code.
> Actually, when you take into account a couple of pitfalls regarding
> lexical scoping and shadowing and use a variety of techniques, including
> continuation-passing-style, writing syntax-rules macros are extremely
> powerful and similar to regular recursive scheme. Unhigienic macros are
> well-known timebombs that are waiting to explode as soon as client code
> does something the library didn't think of. They are useful for
> self-sufficient systems, as Mikael said.
>
> Meng, I wasn't aware of this "riaxpander", it seems chicken also has it.
> Is your riaxpander implementation open source?
>
> I would add these comments to the original post:
>
> - CAR and CDR are shorter than FIRST and REST (why not HEAD-TAIL?), so
> besides the historical meaning, I prefer them for this reason. However, you
> can always define your own first and rest (the former is actually defined
> in SRFI-1). About making them generic, next point:
> - I think the procedure specialization for types (char=, *-lenght, etc...)
> is good as it favors performance. If you want the generic ones, it is
> straightforward to define. For instance, that's what the author of SRFI-47
> does: replace array=? with an array-augmented version of R5RS equal?. While
> you can do your own specialization, you couldn't do it the other way
> around: given a generic procedure in R5RS, specialize it for your types.
> - Mikael's point about symmetry is absolutely beautiful. And indeed I
> defend the usefulness of values, which are of special interest in
> functional programming where you avoid side-effects. Also, the points about
> C/C++ (and assembly I may add) are completely true, but that's one of the
> reasons I find Gambit a particularly powerful system.
> - Generics are defined in several libraries, there are many
> implementations.
> - Promise and force are re-defined in R5RS terms in SRFI-45. I agree with
> this point, but I don't know the deeper reasons why they are included,
> because even opening the possibility to  implementations-defined optimized
> representation of this primitives could have been done with an SRFI.
>
> Thanks to everyone for your comments.
>
> Best regards
>
>
>
> On Sat, Jan 5, 2013 at 1:16 PM, Meng Zhang <wsxiaoys.lh at gmail.com> wrote:
>
>> Great post Mikael! So happy to read your thoughts.
>>
>> On Sat, Jan 5, 2013 at 6:37 PM, Mikael <mikael.rcv at gmail.com> wrote:
>>
>>>
>>> The syntactic-closures based macro systems (syntax-rules/syntax case
>>> including define-syntax, syntax-rules, let-syntax, letrec-syntax) bring
>>> incredible complexity and with that low debuggability through a very
>>> complex identifier concept based a kind of duality of the identifier symbol
>>> in itself and the syntactic environment in which it is used in a particular
>>> instance, and brings a complex API for handling macros with this, that by
>>> nature is not Schemy and not suited for debugging.
>>>
>>> Per came with the suggestions above based on having spent approx 6
>>> months fulltime on developing the Black Hole module system, which does
>>> hybrid define-macro and syntactic closures expansion.
>>>
>>> There might be some caveat I didn't get, but, I'd guess you could
>>> actually make a macro expander that supports both an alias macro system as
>>> per above and a syntactic-closures for compatibility with code that uses
>>> it, possibly by splitting expansion into two expansion phases, thus
>>> isolating all the identifier-related complexity.
>>>
>>>
>> While talking about the syntactic-closures, If we ignore syntax-case,
>> I'll disagree that it brings "incredible" complexity. I've been uncertain
>> on syntactic-closures for years, while this Holiday I finally got spare
>> time reading its implementation in riaxpander/chibi-scheme, I found
>> the concept of it is quite straight forward. Though I deadly missed an
>> easy-to-understand, concrete implementation with document for it during
>> the learning process.
>>
>> I've cloned such a system in gambit, and keep digging on how to
>> integrate hygiene with module system and gambit's compiling process.
>>
>> Thanks
>> Meng
>>
>>
>>
>>
>> _______________________________________________
>> Gambit-list mailing list
>> Gambit-list at iro.umontreal.ca
>> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
>>
>>
>
> _______________________________________________
> Gambit-list mailing list
> Gambit-list at iro.umontreal.ca
> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20130107/842d9a67/attachment.htm>


More information about the Gambit-list mailing list