Date   

Re: 2020 Status

 

Hi Eric,

The purity annotations has been deferred until later. One of the primary reasons for adding it is to give the optimizer more information to make more aggressive transformations. However, there's a number of other optimizations that will have more impact that we decided to prioritize first. (Such as the LLVM backend).

Patrick


Re: 2020 Status

Eric Toombs
 

I asked a few years ago about guarantees for pure functions. Any work
happening there?

On 2020-01-05 13:21, Patrick S. Li wrote:
Cool, a Dylan fan! Jonathan Bachrach, my advisor, was one of the early
people to work on that system. It influenced Stanza's design greatly.

Sounds good. Just post here if you have any questions.

Patrick


Re: 2020 Status

 

Cool, a Dylan fan! Jonathan Bachrach, my advisor, was one of the early people to work on that system. It influenced Stanza's design greatly.

Sounds good. Just post here if you have any questions.

Patrick


Re: 2020 Status

p.z.trotter@...
 

Hi Patrick,

Thanks for the quick response - very helpful and very encouraging.

I use LLVM iwith OpenDylan and its proved very useful for C/C++  libray  and platform integration

Stanza is a already a lovely language to work with and I can see LLVM backend and LSP support will  help drive a lot of adoption.

I'll dig into the experimental branch and post to the forums if i have any questions.

thanks much.

P,

 


Re: 2020 Status

 

Hello!

Stanza development is active however the website has definitely fallen behind just because I have been so busy. The short of it is that I founded a company called JITX when I graduated, where we are writing a programming language for designing electronics, and Stanza is our main development language. So development on Stanza is proceeding along because of that. The experimental branch has a REPL now (quite a fancy one too, that I need to write about) and a very convenient built-in build system and test framework.

The main features slated for development are an LLVM backend for Stanza, and Language Server Protocol support. We're very excited for both of them. The LLVM port should allow Stanza to run on just about every platform under the sun, and the LSP support will allow Stanza to be nicely integrated into most of the major IDEs.

This forum is still the best place for discussions/questions.

Cheers, Patrick


2020 Status

p.z.trotter@...
 

Hi, all.

I am thoroughly enjoying going through L.B.Stanza's codebase and interested in contributing.

There appears to be semi-regualr activity in the git repo but fewer regular announcements here and the website news section is now a few years old.

What is the best place to learn what is happening/status/roadmap? orr just to ask questions? (e.g. REPL status for example)
or to discuss areas to contribute/contribute - beyond current github issues?

thanks much.

p.

 

 


Re: stanza equivalent of piping operator?

Yves Cloutier
 

Thanks Patrick, this work too


Re: stanza equivalent of piping operator?

 

There isn't currently a |> operator, but there is a $ operator, which does the same thing but the order is reversed.

val x = to-seq $ sort $ [2, 4, 3, 5]


stanza equivalent of piping operator?

Yves Cloutier
 

Maybe I missed it in the docs, but does stanza have something like the |> operator like in F# or Elixir to chain functions together to, for example, pass the otput of a function as the input of another like:

val x = [ 2 4 3 5 ] |> sort  |> to-seq


New PDF Documentation Available

Yves Cloutier
 

For those of you who prefer offline documentation, PDF versions of the Stanza reference and Tetris documentation, with clickable TOC have been added to the documentation page:

bstanza_reference.pdf

lbstanza_tetris.pdf

I used regexes to convert HTML to latex. I think it's 99% good, but if you find any glaring mistakes, please let me know.


Re: Creating Structs using MyStruct(x, y, x) vs creating an object using 'new MyObject'

 

Hi Yves,

Glad that you enjoyed reading chapter 4. Proper multiple-dispatch is a feature that we knew we wanted from the very beginning.

The defstruct expansion is indeed done using Stanza's macro system. If you are curious, the gen-defstruct function in compiler/stz-core-macros.stanza contains the implementation for how defstruct is expanded. The implementation is a bit complex, but it's ultimately just a bunch of s-exp manipulation.

Patrick


Creating Structs using MyStruct(x, y, x) vs creating an object using 'new MyObject'

Yves Cloutier
 

First off just wanted to say I was reading chapter 4.6 - Underneath the Hood" and found it pretty interesting to understand the mechanism of how Stanza decides which method/multi to apply.  Multi-file "matching". Brilliant.

Now, I was gonna ask a question asking to clarify the difference use case for creating an instance f a struct vs using objects, but as I kept reading  a bit further, 4.15 - Revisiting Defstruct clearly explained.

Following the code sample on p.77, it states:

"defstruct construct expands to: 1. A type definition; 2. getter functions; 3 setter functions...".
Is this expansion done via macros?


Re: Architecting and Documenting Software Solutions

Yves Cloutier
 

Patrick, thanks so much for taking the time to explain a little bit about this part of the engineering process.  I found this very insightful.

What you say here is exactly the reason why I asked the question:

More importantly, notice what is not specified: the location of the functions. In a traditional OOP language, the location of each function is a big part of the program architecture. Should handle-request be a method in the Window class? Or should it be a method in the Request class? Or should it be a stand-alone function? Or should it be a method of a third RequestHandler class? Our belief is that these questions are ultimately not important, and serve only to detract from real architectural decisions: what are the things in the program, and what are the possible interactions between them.
I'm following some books on compiler construction. Some of them are quite old (pre-OOP), some of them do things with OOP, some of them do things using FP.  And seeing that stanza allows you to do things in any of these paradigms (though the OO being a bit different than most others) I found myself getting stuck deciding which approach to use, and how to structure things, Should I use a type here, should I use a bunch of variables to do this and stick them in a module, or should I put them together in a struct? 

Though not building a compiler, I'm working on a typesetting alternative to *TeX. The aim is to provide a higher-level of abstraction over low-level Groff/Troff.  Well I guess all phases of a compiler would need to be in there. A scanner, a parser and the code generator being the part that generates Groff/Troff source code as the target.

stanza having functions as first-class naturally led me to wonder about parser combinators I've seen and used in FP, the possibility of following a similar approach in Stanza, or whether there was any real advantage over recursive-descent and more traditional [Scan input] -> (Token List) -> [Parse Token List] -> (AST) -> [Generate Target Code].

As well looking a bit more at the macro documentation, I imagined a program taking a language spec or grammar and *generated* a corresponding scanner/parser at compile-time using macros.  But I'm really no there yet in my abilities. But I can imagine it!

Anyhow, thanks again for your insight.  The JIT compiler project seems very interesting.  Any chance we will see it as a course on Coursera or other MOOC any time in the future ? ;)

Regards



Re: Architecting and Documenting Software Solutions

 

Hi Yves,

Thanks for the awesome question! Achieving a flexible software architecture is something that we expressly designed Stanza for, and something I am personally very passionate about.

We strongly advocate adopting a layered software architecture when coding in Stanza. (Actually, we advocate a layered architecture when coding in any language, but Stanza was designed to make it easy.) In a layered architecture, developers partition their software into separate layers of abstraction. Each layer presents its own API, and is responsible for abstracting away some detail of the machine. The lowest layer will be concerned with how to shuffle bytes around in memory, and how to interface with external peripherals. The highest layer will expose almost no details of the machine, and instead be concerned only with business requirements. Each layer can access the API of the immediate layers below it, but may not "skip a layer".

Within an individual layer, developers will think about their software architecture as comparised of a set of 'things', along with defined relationships between those 'things'.

As an example, consider the architecture of a spreadsheet program (like Microsoft Excel).

A low-level layer may concern itself with details of file management and input devices. The 'things' that this layer manages are mice, keyboard, files, directories, etc. These would be modeled as types in Stanza:

  deftype Mouse
  deftype Keyboard
  deftype File
  deftype Directory

The relationships between these things are represented as functions that operate upon these types:

  defn get-x-position (m:Mouse) -> Int
  defn get-y-position (m:Mouse) -> Int
  defn make-directory (s:String) -> Directory
  defn contains? (d:Directory) -> File
  ...

Another layer may concern itself with the GUI event loop, and the details of how to draw widgets to the screen:

  deftype Request
  deftype RepaintWindowRequested <: Request
  deftype ResizeWindowRequested <: Request
  deftype ButtonClickRequested <: Request

  deftype Shape
  deftype Circle <: Shape
  deftype Rectangle <: Shape
  deftype Line <: Shape

  deftype Window
  deftype Button

  defn draw (w:Window, s:Shape) -> False
  defn handle-request (w:Window, r:Request) -> False
  defn intersects? (s1:Shape, s2:Shape) -> True|False
  ...

And the highest abstraction layer will concern itself with objects that the user directory deals with:

  deftype Project
  deftype Formula
  deftype SpreadsheetCell

  deftype Cell
  deftype NumberCell <: Cell
  deftype NameCell <: Cell
 
  defn evaluate (f:Formula) -> Int
  defn store (c:Cell, f:Formula) -> False
  defn clear (c:Cell) -> False
  defn make-project (name:String) -> Project
  defn save (p:Project) -> False
  ...

More importantly, notice what is not specified: the location of the functions. In a traditional OOP language, the location of each function is a big part of the program architecture. Should handle-request be a method in the Window class? Or should it be a method in the Request class? Or should it be a stand-alone function? Or should it be a method of a third RequestHandler class? Our belief is that these questions are ultimately not important, and serve only to detract from real architectural decisions: what are the things in the program, and what are the possible interactions between them.

An architectural document consists of an exhaustive listing of all the types in the program, and a description of all the interactions between those types. I used such a document to describe the implementation requirements of a just-in-time compiler in the graduate course that I taught, and it worked wonderfully. By the end of the course, we had thirty students successfully implement a just-in-time compiler from scratch, and ... they all behaved the same. So that we actually prepared a suite of benchmark programs and had the students compete against each other on the speed of their compiler.

Regards, Patrick


Architecting and Documenting Software Solutions

Yves Cloutier
 

Patrick,

What approach(es) do you use when planning and documenting solutions to be implemented with stanza?

For example, typically one starts with business requirements, then functional requirements, then software specification document etc...

Often we see class diagrams and UML diagrams, which usually go hand in hand with OOP.

Since lbstanza is not OOP in the classical sense, and not purely functional in the classical sense, which approach do you use for planning out and modelling a solution?

In my day job I'm a business/system analyst and most of my work is documenting business requirement and other technical documentation that developers would use for implementation. 

So I'm curious to know what your approach to documentation is for solutions you develop in stanza ;)

Regards


Re: Web Dev in Stanza

Yves Cloutier
 

I can certainly try :S


PDF Version of "Reference"

Yves Cloutier
 

Patrick, 

Would the documentation on http://lbstanza.org/reference.html  also be available as a PDF?

Regards


Re: Web Dev in Stanza

 

There is no native Stanza server as of yet. I've written some small scrapers using the curl library for interfacing with a REST api, but nothing substantial. You're welcome to try out porting a server though. It seems like one of those milestones that all new languages hit one day!


Web Dev in Stanza

Yves Cloutier
 
Edited

Are there any examples of web development using lbstanza? Has anyone done it?

Or is it currently limited to doing it through using bindings to a C based web server?


Re: lbstanza still active?

Eric Toombs
 

Oh, definitely. I haven't used my pocket calculator in years since I realised I could do all my maths about 10x more quickly and more effectively in the python repl.

21 - 40 of 251