Hi Joseph, et.al., I tend to think of Bigloo as a language environment that allows me to play with functional programming in a diverse setting: interpreter, compiler, on JVM (and previously: on dotNet), from Windows or Linux, or the Web. I learned a lot while trying to run various ideas on it: monads, relational programming, compilers, etc.
There is a lot of value in unification in this very diverse world, where you have (Oca)ML, Haskell, Prolog, etc. (I am not even speaking about older and cool newfangled languages with FP features). Bigloo offers a no-nonsense API and tends to stick to the latest sane Scheme standard: R5RS. The same goes for Hop, which was very useful in unifying diverse Web APIs and supporting presentations, papers (I wrote quite a few papers using hoptex and hop-2.2.1) as well as great Wiki pages. Although I am not too happy with R5RS support in Bigloo (esp. syntax-rules macros and call/cc),and of course R6RS (most notably: syntax-case macros) is totally missing, Manuel is very helpful in supporting non-standard extensions (such as allowing more conformant syntax-rules Alexpander) and helping solve ensuing compiler problems. This is especially needed since there is no rich type-system while one still wants to express complex relationships (ala overloading, or type-classes) between types (ab)using syntax-rules macros, or enforce a linear/affine logic discipline on bindings. Some time ago I also managed to interface Stalin-generated code directly from Bigloo, thanks to the use of the same Boehm GC, allowing one to compile a complex piece of code in a whole-program style with Stalin while still having a modular wrapper around it, with shared-memory serving as an interface in-between. I think that with a little more polishing and publicity (e.g., offering a notebook-like environment for Bigloo with Hop, for example), maybe in conjunction with an LLVM backend that would enable writing Bigloo sub-modules for e.g., Julia or Python packages, it could enable more people to enjoy the benefits of classic Scheme for symbolic computing while still leveraging all the existing packages found in these communities. Kind regards, Peter On Sat, Jun 20, 2020 at 10:48 AM Damien Mattei <[email protected]> wrote: > Hello, > > > i'm using a lot of Lisp/Scheme language both personnally and > professionally and also have been teaching Scheme (Racket) a semester, and > here is a summary of what i know about use and "popularity" (term used by > Joseph) of those language, i think the comparison of those language and > bigloo is important, i differ two "popularity": academic one and > professional one based on academic use and job offers and compare them with > their level of differenciation from Scheme/Lisp: > > > language > differentiation > Academic popularity (use,course,community) > Professional popularity (use,job offers) > popularity :all comunities (public,professionnal,academic...) > Scheme R5RS (ex: Guile,MIT scheme) > 0 > + > + > ++ > Lisp (Lisp,common lisp...) > 0 > + > + > ++ > Kawa (Scheme) > ++ > + > + > ++ (same as Scheme) > Racket (Scheme) > +++++ > ++ > + > +++ (little more than Scheme) > Clojure/ClojureScript (Lisp) > +++++++ > + > ++ > ++++ > Bigloo > ++ > + > + > ++ (same as Scheme) > > > In conclusion, and in my opinion, differentiation of a language, can bring > popularity and community. > > Clojure have a community,Racket have a community, of a different type, > Racket community is first academic, but what will happen if the university > supporting Racket want to stop the project and funding? racket also have > users but will they continue the project. Instead Clojure is a private > project with a public team of developers, have a very little professional > impact factor as there is some job offers about it, not with Racket which > only have a community in university. Racket as keep a core of language of > Scheme which make it a good teaching language as could be Bigloo,Clojure > has only keep the Lisp Language and is not a good Lisp to learn Lisp. > > If Bigloo come in the same way as Racket by differentiating from Scheme > ("Racket is not Scheme") i'm not sure it will have more popularity in > professional use as Racket do not have success to touch the professionnal > world. Even Clojure , have little impact factor professionally but it have > a community. > > A few more note about item : > > module: vary a lot with the Scheme 5racket,Bigloo,kawa) > > call/cc: a nightmare in every scheme compilator, but who use this feature? > not me for this reason (no support in compilation) > > is it really a useful abstraction? not sure > > typing: th force of Schem/Lisp is to have no typing, i try to avoid it > unless necessary > > SRFI support is important and this is the opposite of differentiation. > > Personally, i prefer to use Scheme/Lisp that have keep a core of language > standardized with SRFI support, > > so i can change of Scheme and compiler if i'm in need. > > I dislike Raket specific extension "Racket is not Scheme" and it is worse > in Clojure even if they are powerfull and cool language. > > Damien > > ---------- Forwarded message --------- > From: Damien MATTEI <[email protected]> > Date: Sat, Jun 20, 2020 at 10:47 AM > Subject: Fwd: [bigloo] How do you perceive Bigloo? > To: Damien Mattei <[email protected]> > > > > > > -------- Message transféré -------- > Sujet : [bigloo] How do you perceive Bigloo? > Date : Fri, 19 Jun 2020 23:32:03 +0000 (UTC) > De : Joseph Donaldson <[email protected]> <[email protected]> > Répondre à : Joseph Donaldson <[email protected]> > <[email protected]> > Pour : Bigloo Mailing List <[email protected]> > <[email protected]> > > Hello, All, > > How do you perceive Bigloo? Do you see it as just an implementation of > scheme or as its own language, albeit heavily based on/inspired by scheme? > I ask because, personally, I am increasingly seeing it as a separate > language and am wondering if it would be beneficial to promote it as such. > For example, although it is generally straight forward to port scheme code > to Bigloo, it often is sub-optimal without modification to properly support > Bigloo's module system, macros support (especially when used with > libraries), and type system. Additionally, some traditional scheme > features, such as call/cc, are inefficiently supported in Bigloo making > code relying on them impractical. Conversely, code targeting Bigloo in my > experience is difficult to move to other scheme systems unless it forfeits > all of the extensions (modules, type annotations, object systems, etc...) > that make Bigloo a practical language for my development needs. Further, by > claiming to be a scheme, Bigloo is often compared to other scheme > implementations in a manner which fails to highlight its strengths. For > example, https://ecraven.github.io/r7rs-benchmarks/ compares the > performance of a number of scheme implementations, and while Bigloo ranks > fairly well, I am confident that if the Bigloo versions of the benchmark > programs were written in a more idiomatic Bigloo style, leveraging type > annotations and eschewing call/cc, it would have an even better showing. > > So, would distancing Bigloo from scheme in a manner similar to what Racket > has done open opportunities for differentiating, growing, and popularizing > Bigloo? I am curious to hear your thoughts. > > Best Regards, > Joseph Donaldson >
