Live data from Hacker News

Show HN: Fe – A tiny, embeddable language implemented in ANSI C

github.com

21–23 of 23 posts

Re: Show HN: Fe – A tiny, embeddable language implemented in ANSI C

#21

Earlier quoted context omitted.

> I didn't see if the language supports a fluid let (any variable name is looked up at run time when the reference is encountered thru the stack levels until the name is found. [...] These are called dynamic variables in Lisp. They're only really useful as a way of doing things like I/O redirection, and you can just shallow-bind them to make them fast (but then they need to be per-thread as well, and pushing a bindin…

fluid-let is a famous Scheme imitation of dynamic variables. SRFI-15: https://srfi.schemers.org/srfi-15/srfi-15.html [1999]

Ahh, ok.

Re: Show HN: Fe – A tiny, embeddable language implemented in ANSI C

#22

Earlier quoted context omitted.

I haven't used ATS, but I don't think it interops strongly. Hows does calling a ATS function with fancy typed arguments from C work? My idea of strong interop is not having to write any glue code at all and being able to call any function. I assume there are some types that don't interface with C well. That said, thanks for mentioning it. I should keep it in mind as it does do some of the stuff I want my language to.

I apologize for being ambiguous. You wouldn't gain the benefits of ATS by interfacing with its C bindings from C. You would gain safety and security in interfacing with unsafe C on the ATS side through the ATS type system. I was speaking about interfacing in the opposite direction.

> I apologize for being ambiguous.

No need to apologize. I also should have been more clear about what I meant by strong interoperability.

> I was speaking about interfacing in the opposite direction.

I think that having really strong interoperability requires both directions, but the being called from C is the one that is more restrictive on fancy types.

Re: Show HN: Fe – A tiny, embeddable language implemented in ANSI C

#23

Earlier quoted context omitted.

I apologize for being ambiguous. You wouldn't gain the benefits of ATS by interfacing with its C bindings from C. You would gain safety and security in interfacing with unsafe C on the ATS side through the ATS type system. I was speaking about interfacing in the opposite direction.

> I apologize for being ambiguous. No need to apologize. I also should have been more clear about what I meant by strong interoperability. > I was speaking about interfacing in the opposite direction. I think that having really strong interoperability requires both directions, but the being called from C is the one that is more restrictive on fancy types.

Unfortunately, C is C, and we all know what that means. Anything that achieves true type safety in both directions in going to be a monstrosity on the C side. Lots of boilerplate, marshalling of types, etc.

It all starts to look like COM, lol. Take care man.

Post reply on HN