L.B. Stanza Programming Language
License: Other
This Repo has been cleaned up and a new version of the repo has been created called 'lbstanza'. This is the old non-cleaned-up version.
L.B. Stanza (or Stanza for short) is a new optionally-typed general purpose programming language designed to help programmers tackle the complexity of architecting large programs and significantly increase the productivity of application programmers across the entire software development life cycle.
Visit www.lbstanza.org for details.
Can be observed by setting $STANZA_CONFIG to some absolute path where the drive specifier is of the form <drive>:/ instead of <drive>:\ (e.g. STANZA_CONFIG="C:/path/to/stanza" stanza foo.stanza -o foo)
This seems to be because the path parser assumes a drive specifier must end with \. This is untrue, forward slashes are accepted in place of back-slashes in all but a few Windows APIs (and we should be no different.) This is particularly annoying on Cygwin/MSYS/MinGW where use of forward slashes is prevalent, to avoid messy issues with escaping back-slashes.
In my experience, allowing less-often used arguments of a function to have sane defaults using named optional arguments has been extremely useful to writing flexible yet easy-to-use APIs. (In my opinion, it is python's single greatest feature.) Is this possible in lbstanza? If not, would you please consider implementing it? Maybe something like
defn line (x:Double, slope:Double, intercept:Double = 0) -> Double :
intercept + slope * x
Or whatever variation on that makes the lexing and parsing easiest. intercept would not need to be specified, so line(4, 4) would produce 16. line(4, 4, intercept = -3) would produce 13.
I notice the source includes a compiled binary of the Stanza compiler, but no source code. I wanted to ask a few questions:
Thanks!
# qmake --version
QMake version 3.0
Using Qt version 5.6.2 in /usr/lib64
For doesn't work, when using too many arguments
for (x in xs y in ys) f :
…
Wouldn't it be better if this construct would macro-expand into something like f(fn(x y) : (…) [xs ys]) instead of f(fn(x y) : (…) xs ys)?
(a second for-like macro for this would also be ok)
Then one would be able to define functions that work for all number of arguments and specialized versions of the functions could be defined anyway (instead of defn f (fun:(A B) -> C a:Seq<A> b:Seq<B>) -> Seq<C> the functions could be defined defn f (fun:(A B) -> C ab:[Seq<A> Seq<B>]) -> Seq<C>)
x86 supports 16-bit literals and registers. However, Stanza currently has no native support for 16-bit. The canonical C term for this is short. I propose that Stanza adds a new type Short for 16-bit integers.
The main use case I have for this is support Unicode, specifically UTF-16. UTF-16 is often needed for parsing modern websites. A possible consequence is that Stanza may choose to borrow Unicode for many syntax symbols such as -> and :>, allowing the programmer to use Unicode in his or her program.
linku
the resolve-path function doesn't work for symbolic links?
When trying to compile helloworld example in CentOS 7, stanza failed silently with only one word message:
% stanza examples/helloworld.stanza -o helloworld
Killed
Other programs in examples/ are all the same.
Do not know how to diagnose this problem, any hint?
How far off is support for gcc 7? What version of gcc is currently supported?
It would be nice to be able to define setable functions (like setf in common lisp)
You would be able to write get(array i) = value for set(array i value)
Maybe using a syntax like this:
defsetter v get(x y) set(x y v)
It should also be possible to use it in structs then like this:
defstruct Test:
x with: (setable => true)
val v = Test(1)
x(v) = 2
println(x(v)) ;;prints 2
How would I call c functions from libraries? Can I even do that? The stanza by example tutorial uses pure c files, but not any libraries..
So you could write something like Tuple<3,Int> instead of [Int,Int,Int]
and also create multiple similar types like this:
defstruct mover<N,T> :
pos : Tuple<N T> ;may also be other similar Types
vel : Tuple<N T>
In struct example in Stanza by Example, this line:
println("There are %_ dogs in the kennel.")
should be
println("There are %_ dogs in the kennel." % [length(dogs)])
The networking library isn't the only issue-- I get that this language is new, but when will other libraries for convenience be planned?
I've created an IRC channel #lbstanza on freenode if anyone is interested (webchat). Perhaps it could be mentioned in the readme or on the website?
In "Creating a New Shape" section of "Architecting Programs" chapter,
defn total-area (ss:Vector<Point|Circle>) :
should be updated to
defn total-area (ss:Vector<Point|Circle|Rectangle>) :
I am new to Stanza and sometimes just try out things that seem intuitive.
The following code compiles, but does not behave the way that I would expect it to behave:
deftype Animal
defstruct Dog <: Animal
defstruct Cat <: Animal
defn check-for-animal (a:Maybe<Animal>):
match(a):
(d:One<Dog>) : println("it's a dog")
(c:One<Cat>) : println("it's a cat")
(n:None) : println("nothing to see")
check-for-animal(One(Cat()))
check-for-animal(One(Dog()))
check-for-animal(None())
this prints
it's a dog
it's a dog
nothing to see
When I try to determine the type of One(Cat()) (e.g. by compiling var x:Int = One(Cat())), the compiler confirms that the type is One<Cat>. So why is it cast to an object of type One<Dog> by match?
What am I missing here?
Code in http://lbstanza.org are not always showed using monospace fonts. I think we need to specify a fallback font for code tag, e.g.:
font-family: "Menlo", monospace;
I recently wrote something like the following:
val char:Char = foo(bar)
if char == 'x' or char =="y":
println("branch 1")
else:
println("branch 2")
And couldn't figure out why branch 1 was not executing when char was 'y'. The issue is that y is in double quotes in the comparison, making it a String rather than a Char, so the comparison was always false. As far as I understand, the problem stems from the fact that equal? is defined as:
public defmulti equal? (a:Equalable, b:Equalable) -> True|False
Which means that the compiler has no way of noticing the mistake, because Char and String are both Equalable. However, we could introduce:
defn same-type-equal?<?T> (a:?T & Equalable, b:T & Equalable) -> True|False:
a == b
Then compiling same-type-equal?('y', "y") gives the following error:
Cannot call function same-type-equal? of type (Equalable&Char, Equalable&Char) -> True|False
with arguments of type (Char, String).
While same-type-equal?('y', 'y') compiles without error.
I see a few ways to solve this issue:
=== operator that would use same-type-equal? (And analogous !== operator), so that 'x' === "x" does not compile. I like this option.equal? multi for comparing Char values to String values.'x' == "x".equal? to same-type-equal?. From what I can tell, this goes against the design philosophy of the language, because users would no longer be able to write methods for equal? that take two different types, even if it makes sense in some cases.I am interested in hearing other people's opinions on this issue, whether they think it should be solved, and if so, the best way to do so.
Hi,
I find Stanza an interesting language, and would like to know more. Currently all I can do is read the docs, but if I have a question, I have nowhere to go. It would be awesome to have a mailing list and/or IRC channel (or something else).
In section Printing Integers, output of
print(1)
print(" and a ")
print(2)
print(" and a ")
println(1)
println(2)
println(3)
println(4)
should be
1 and a 2 and a 1
2
3
4
i.e. no newline after ... and a.
When compile and run following code:
defpackage tests:
import core
import math
println(PI)
Following result seems not to be correct:
0.000000000000000
On the Stanza mailing list, it was mentioned that it would be nice to have a BufferedInputStream that wraps an existing InputStream and buffers up to n characters from that stream. I think this would be great! I have come up with the following, and would like some feedback on the desired interface.
Type:
deftype BufferedInputStream <: InputStream
Creation:
Create a stream with a buffer of size n:
public defn BufferedInputStream(i:InputStream, n:Int) -> BufferedInputStream
Create a stream with the default buffer size:
public defn BufferedInputStream(i:InputStream) -> BufferedInputStream
Interface:
Like Stanza's StringInputStream:
Identical to the peek? multi for StringInputStream
public defmulti peek? (s:BufferedInputStream, i:Int) -> Char|False
public defmulti peek? (s:BufferedInputStream) -> Char|False
Like fill, but does not remove the read characters from the stream:
public defmulti peek-fill (c:CharArray, r:Range, s:BufferedInputStream) -> Int
Similar to Java's BufferedInputStream, where a stream can be reset to a marked position:
Marks the stream's current position, allowing the stream to be reset to the current position if no more than n characters are read from the stream after the call to mark. Returns false if the mark could not be set, otherwise true:
public defmulti mark (s:BufferedInputStream, n:Int) -> False|True
Resets the stream to the most recent mark. Returns false if there is no valid mark set, otherwise true:
public defmulti reset (s:BufferedInputStream) -> False|True
Something else: Explain it in a comment!
Which of the options do you prefer, and how would you change it? I lean slightly towards option 1, but would like some feedback before submitting a pull request.
When compiling the git version of stanza using scripts/make-compiler.sh, the linux binary version of stanza-0.11.28 available from the website allocates in excess of 3.5 GiB of memory, then crashes with "Cannot allocate memory" after it tries to allocate more. (I only have 4 GiB of RAM.) Seems like a memory leak.
example:
defn double<?T> (x:T):
x + x
println(double(1))
says that there is no function plus for arguments of type (T, T)
When compiling first version of shapes package in "Stanza by Example" with Stanza 0.9.1, it failed with following message:
% stanza shapes.stanza shapes-main.stanza -o shapes
FATAL ERROR: No matching branch.
at core/core.stanza:1462.16
at core/collections.stanza:351.15
at core/collections.stanza:358.17
at core/collections.stanza:408.17
at core/collections.stanza:287.16
at core/collections.stanza:298.16
at compiler/stz-kform.stanza:4680.9
at compiler/stz-kform.stanza:6056.21
at compiler/stz-kform.stanza:5703.32
at compiler/stz-kform.stanza:6052.12
at compiler/stz-kform.stanza:5706.9
at compiler/stz-kform.stanza:5807.12
at compiler/stz-kform.stanza:5807.12
at compiler/stz-kform.stanza:5402.15
at core/core.stanza:3099.9
at core/core.stanza:4101.16
at compiler/stz-kform.stanza:5391.30
at compiler/stz-kform.stanza:5647.12
at core/core.stanza:840.16
at compiler/stz-kform.stanza:5626.17
at core/core.stanza:840.16
at compiler/stz-kform.stanza:5625.14
at compiler/stz-kform.stanza:5390.9
at compiler/stz-kform.stanza:5413.24
at compiler/stz-kform.stanza:6587.24
at core/core.stanza:3099.9
at core/core.stanza:4101.16
at compiler/stz-kform.stanza:6585.27
at core/core.stanza:840.16
at compiler/stz-kform.stanza:6596.11
at compiler/stz-kform.stanza:174.3
at compiler/stz-compiler.stanza:97.21
at compiler/stz-main.stanza:206.3
at compiler/stz-main.stanza:296.21
at core/core.stanza:3699.22
at core/core.stanza:840.16
at core/core.stanza:3698.14
at core/core.stanza:969.20
at core/core.stanza:991.31
at core/core.stanza:855.16
at compiler/stz-main.stanza:294.10
at compiler/stz-main.stanza:306.0
There already exists a tag that hints the compiler to do tail optimisation (defn*). I figure there could also be a tag that tells the compiler to fail if the function is not pure. I would find such a feature enormously useful for compile time error checking of functions I write and for identifying which functions in an unfamiliar API do not have any side effects / will always produce the same result given the same input. I'll give an example. In it, I'll use defn to mean the function is not necessarily pure, and defn+ to mean that it is.
defn+ pure_example (a:Double, b:Double, c:Double) -> Double :
((- b) + sqrt(b * b - 4 * a * c) / (2 * a)
defn impure_example (a:Double, b:Double, c:Double) -> Double :
println("a=%_ b=%_ c=%_" % [a, b, c])
((- b) + sqrt(b * b - 4 * a * c) / (2 * a)
This would compile. If the second function's tag were defn+, though, it would not compile.
Why isn't this possible?
defn compose<?T ?U ?V> (f:?T -> ?U g:U -> ?V) -> T -> V :
{g $ f $ _}
instead of defmulti and multiple defmethod also allow a syntax like from multifn
defmulti test (object):
(x:Int) : x*2
(x:Float) : x/2
also maybe allow only using types for defmulti because the name is unneccesary anyway
defmulti test (Int) would be the same as defmulti test (object:Int)
examples/helloworld.stanza, compiled by the binary version of stanza 1.11.7 available here, fails to run, with the following errors:
[eric@vault stanza]% ./stanza install -platform linux
[eric@vault stanza]% ls
ChangeLog.txt core fast-pkgs pkgs stanza
compiler examples License.txt runtime
[eric@vault stanza]% ./stanza examples/helloworld.stanza -o helloworld
[eric@vault stanza]% ls
ChangeLog.txt core fast-pkgs License.txt runtime
compiler examples helloworld pkgs stanza
[eric@vault stanza]% ./helloworld
./helloworld: Symbol `malloc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `malloc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `malloc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `malloc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `malloc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `malloc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `malloc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `malloc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fprintf' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fprintf' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fprintf' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fprintf' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fprintf' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fprintf' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fprintf' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fprintf' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fprintf' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `free' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `free' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `free' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `free' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `exit' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `exit' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `exit' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fputc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fputc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fputc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fputc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fputc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fputc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fputc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fputc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fputc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fputc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fputc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fputc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fputc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fputc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fputc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fputc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fputc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fputc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fputc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fputc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `sprintf' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `sprintf' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `sprintf' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `sprintf' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `sprintf' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `sprintf' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `sprintf' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fopen' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fopen' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fopen' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fopen' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fopen' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fopen' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fclose' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fclose' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fclose' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fputs' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `ferror' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `ferror' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `ferror' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `ferror' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `ferror' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `ferror' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `ferror' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `ferror' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `ferror' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fgetc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fgetc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fgetc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fgetc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fgetc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fgetc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fgetc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fgetc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fgetc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fgetc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fgetc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fgetc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fgetc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fgetc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `fgetc' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `strerror' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `remove' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `getenv' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `setenv' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `system' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `strlen' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `sscanf' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `sscanf' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `srand' causes overflow in R_X86_64_PC32 relocation
./helloworld: Symbol `rand' causes overflow in R_X86_64_PC32 relocation
zsh: segmentation fault (core dumped) ./helloworld
[eric@vault stanza]%
The versions of some of the critical packages:
[eric@vault stanza]% uname -a
Linux vault 4.12.13-1-ARCH #1 SMP PREEMPT Fri Sep 15 06:36:43 UTC 2017 x86_64 GNU/Linux
[eric@vault stanza]% pacman -Qi glibc gcc
Name : glibc
Version : 2.26-4
Description : GNU C Library
Architecture : x86_64
Name : gcc
Version : 7.2.0-2
Description : The GNU Compiler Collection - C and C++ frontends
Architecture : x86_64
The same thing happens in version 0.11.27.
The iteration order of a queue is the opposite of the conventional sense. Technically the theoretical definition of a queue does not impose anything or whether you should be able to iterate over a queue, but this is counter intuitive to iterate in the opposite order than popping. Queues are FIFO and it makes sense to iterate in the same order: If you add 1 then 2 then 3 to the queue, iterating should give you 1 then 2 then 3 (and leave all 3 elements in the queue of course).
I checked in python (deque from collections) and java (java.util.LinkedList implementation of java.util.Queue) and they do what I was expecting.
Stanza:
$ jstanza repl
stanza> val q = Queue<Int>()
stanza> add(q, 1)
stanza> add(q, 2)
stanza> add(q, 3)
stanza> println(to-tuple $ q)
[3 2 1]
Python:
lbstanza$ python3.8
Python 3.8.0 (default, Feb 25 2021, 22:10:10)
[GCC 8.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from collections import deque
>>> d = deque()
>>> d.append(1)
>>> d.append(2)
>>> d.append(3)
>>> d
deque([1, 2, 3])
>>> list(d)
[1, 2, 3]
Java:
import java.util.LinkedList;
import java.util.Queue;
class Main
{
// Iterate through Queue in Java
public static void main(String[] args)
{
Queue<Integer> queue = new LinkedList<Integer>();
queue.add(1);
queue.add(2);
queue.add(3);
for (Integer item: queue) {
System.out.println(item);
}
}
}
gives
1
2
3
I want to be able to write
defstruct Complex<?T>:
real : ?T
imag : T
instead of
deftype Complex<T>
defmulti real<?T> (complex:Complex<?T>) -> T
defmulti imag<?T> (complex:Complex<?T>) -> T
defn Complex<?T> (real:?T imag:T):
new Complex:
defmethod real (this):
real
defmethod imag (this):
imag
Right now, there is no way to quickly get started using the compiler. One must go to the main website download the distribution AND also go to Documentation to discover how to install and use the stanza binary.
Ideally, one should only need to download the distribution to get started. Proposals for improving usability:
help command. help without arguments would be equivalent to -h and --help. help may also take an argument that is a command, and it will describe the command and list the available flags/options.Apparently comparing values of type Long and Int evaluates to false, e.g. :
println("(0 == 0L): %_" % [(0 == 0L)])
prints
(0 == 0L): false
I understand that there are reasons why comparing Int and Long might not be a good idea. However, if the intention is to disallow this operation I would expect comparing Int and Long values to result in a (compile or runtime) error.
The current behavior caused a subtle bug in my code where I wanted to check if the result of a function was zero, but forgot that the function returned a Long result and I was checking equality to 0 instead of 0L.
There is no link to go back to homepage inside Stanza by Example pages.
I think logo icon on the top left is a good place to have a such link.
I've also created a wrapper called stz, for Fish Shell, that gives you a quick way to execute one-liners and scripts.
brew install fisherman/tap/fisherman # works easily with fisherman plugin manager
fisher i stz
set -Ux STX_BIN "/path/to/stanza" # not needed with linuxbrew or /usr/local/bin loc
stz -e 'print(1)' # converts to a temp script file, compiles that, and executes it.
stz -r some-stanza-file.stanza # compiles the provided file and executes it
stz compile some-stanza-file.stanza -o some-stanza-bin # passes anything else to stanzaJust thought I'd share since I'm not aware of a mailing list or forum and no one comes on IRC yet 😄
No error is reported when compiling following code with Stanza 0.9.1, which is supposed to be an error as stated in Stanza by Example.
defpackage mypackage :
import core
defn main () :
println("Code goes here")
main()
When you have an untyped label, Stanza still expects you to return something:
label ret :
...
ret()
Gives you Cannot call function ret of type ? -> Void with arguments of type ().
So you have to do:
label ret :
...
ret(true)
Is this expected behavior?
I've created a Homebrew/Linuxbrew Tap for installing stanza here. With this you can install stanza very easily.
brew install MadcapJake/lbstanza/stanza-linux # or stanza-macI was wondering if you want to move that repo to the StanzaOrg, it might look nice (would change that tap to StanzaOrg/tap/stanza-linux) but not necessary. Perhaps you'd also add it to the Downloads page as an installation option?
I think Stanza's analysis prior to compiling would be really nice to integrate into editors but it would be best to ensure the process closes post-analysis instead of continuing through the compilation process. You could provide a -c flag to the compile subcommand (to be used instead of -o or -s) or maybe an entire subcommand check.
Otherwise, both -o and -s take between 10-20 seconds on my machine to complete.
As an aside, using atom-build with this .atom-build.json file (in your project's base directory) does quite well and even highlights any errors in the file (though it would need some tweaking to include any other needed stanza files for larger projects):
{
"cmd": "stanza",
"args": ["compile", "{FILE_ACTIVE}", "-o", "{FILE_ACTIVE_NAME_BASE}"],
"cwd": "{PROJECT_PATH}",
"sh": true,
"name": "L.B. Stanza Compile",
"errorMatch": [
"(?<file>[\\w\\/\\.\\-]+):(?<line>\\d+)\\.(?<col>\\d+):(?<message>.+)(?: Possibilities are:)?"
]
}Is it possible to have Effect system
A stanza program such as:
defstruct Point :
x: Double
y: Double
val hm: HashTable<Point,Vector<Point>> = HashTable<Point,Vector<Point>>()
hm[Point(0.0, 0.0)] = Vector<Point>()
compiles properly, unfortunately at runtime it crashes:
FATAL ERROR: Cannot cast value to type.
at core/collections.stanza:382.16
at core/collections.stanza:286.16
at test.stanza:7.0
B.T.W.
found implementing this:
andreaferretti/kmeans#47
I'm trying to call a c function that has an array parameter, but there doesn't seem to be an array type for lostanza?
I know there are default operators you can overload, but why isn't there any support for custom operators like |> or $?
For example, if you compile the following test program:
defpackage test:
import core
defn main ():
val args = command-line-arguments()
Process(args[1], args[1 through false], STANDARD-IN, PROCESS-OUT, PROCESS-OUT)
main()
And run it, passing any valid executable as an argument (e.g. ./test gcc), the test program seems to run fine in most cases. However, sometimes it will cause a segmentation violation. If run in the debugger (I used gdb), this segfault occurs reliably. This is due to an exception being thrown in the Windows runtime due to our closing a file handle twice.
Specifically, we redirect STDOUT and STDERR to the same handle (the PROCESS-OUT pipe), spawn the process with its STDOUT and STDERR set to the write end of the pipe, and then close those write ends in our process. However, since STDOUT and STDERR point to the same pipe, the latter action closes the PROCESS-OUT pipe twice, causing a segfault.
The same behavior can be observed if both streams are redirected to PROCESS-ERR (other combinations of redirections are not yet supported.)
Multi line commetns are useful for uncommenting not working stuff
Is it possible to write statical typed math-libraries (like vector-math or math with seqables), that is extendable for new number-types (not only the 5 default types, maybe also complex-vectors)?
defn plus<?T> (x:Seqable<?T> y:Seqable<T>) doesn't work for this without using dynamic typing.
I assume the file stanza is for bootstrapping purposes.
Unfortunately, there's not just one "stanza", but probably dozens included in the repo, because all the history is conserved.
Considering the executable is OSX-only, it's not even useful/sufficient/required for users of other operating systems, yet they have download it dozens of times.
I just cloned it, the repo takes up 461MB for me, which might be a serious problem for people with a worse internet connection.
Could these executables perhaps be extracted into their own repo, and then linked as a submodule, or hosted in some other way?
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.